1. OMG Mailing List
  2. OMG SysML 1.7 Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: sysml-rtf
  • Issues Count: 1,005

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML17-132 ConnectorProperty notation in wrong section. SysML 1.4 SysML 1.7 Deferred closed
SYSML17-147 Diagram formality confusion SysML 1.4 SysML 1.7 Deferred closed
SYSML17-140 Causality of constraints in parametric diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-136 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 SysML 1.7 Resolved closed
SYSML17-135 No support for dot notation in activity and sequence diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-162 Add signal to constraint [1] for DistributedProperty SysML 1.5 SysML 1.7 Deferred closed
SYSML17-133 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 SysML 1.7 Deferred closed
SYSML17-154 Clarification of typing a binding connector SysML 1.5 SysML 1.7 Deferred closed
SYSML17-155 Inconsistency in the DirectedRelationshipPropertyPath specification SysML 1.5 SysML 1.7 Deferred closed
SYSML17-153 Replace all occurrences of "has been" by "is" SysML 1.5 SysML 1.7 Deferred closed
SYSML17-161 Add Graphical notation for General Classifier SysML 1.5 SysML 1.7 Deferred closed
SYSML17-169 Diagram header is not intuitively interpreted SysML 1.5 SysML 1.7 Deferred closed
SYSML17-175 Do not move deprecated elements SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-184 Inappropriate character for multiplying symbol with combined units SysML 1.5 SysML 1.7 Deferred closed
SYSML17-214 Hidden constraints in description of PropertySpecificType SysML 1.6 SysML 1.7 Deferred closed
SYSML17-163 Excluded UML metaclasses are not formally defined SysML 1.5 SysML 1.7 Deferred closed
SYSML17-171 DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution SysML 1.5 SysML 1.7 Deferred closed
SYSML17-164 SysML 1.6 should be based on UML 2.5.1 SysML 1.5 SysML 1.7 Resolved closed
SYSML17-149 FullPort type SysML 1.5 SysML 1.7 Deferred closed
SYSML17-271 Typos/editorials found in the SysML 1.6 specification document SysML 1.6 SysML 1.7 Resolved closed
SYSML17-237 Precise Semantics for SysML SysML 1.6 SysML 1.7 Resolved closed
SYSML17-170 DistributedProperty should be abstract SysML 1.5 SysML 1.7 Deferred closed
SYSML17-168 DistributedProperty should be abstract SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-99 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.7 Deferred closed
SYSML17-104 Pull semantics for flow properties SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-95 Clarification required for Copy relationship SysML 1.3 SysML 1.7 Deferred closed
SYSML17-97 primitive types in SysML Activities SysML 1.4 SysML 1.7 Deferred closed
SYSML17-114 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 SysML 1.7 Deferred closed
SYSML17-111 Abstract syntax for the initial values SysML 1.4 SysML 1.7 Deferred closed
SYSML17-123 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 SysML 1.7 Deferred closed
SYSML17-113 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 SysML 1.7 Deferred closed
SYSML17-116 [SysML] Semantic variation points SysML 1.4 SysML 1.7 Deferred closed
SYSML17-105 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 SysML 1.7 Deferred closed
SYSML17-112 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 SysML 1.7 Deferred closed
SYSML17-106 Semantics clarification for removing a value from an out Flow Property SysML 1.4 SysML 1.7 Deferred closed
SYSML17-102 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 SysML 1.7 Deferred closed
SYSML17-124 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 SysML 1.7 Resolved closed
SYSML17-127 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 SysML 1.7 Deferred closed
SYSML17-128 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 SysML 1.7 Deferred closed
SYSML17-118 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 SysML 1.7 Deferred closed
SYSML17-115 Can a SysML Full Port be typed by a ValueType? SysML 1.4 SysML 1.7 Deferred closed
SYSML17-129 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 SysML 1.7 Deferred closed
SYSML17-131 Parts, references, values compartments in wrong section SysML 1.4 SysML 1.7 Deferred closed
SYSML17-126 specializations of requirement should specialize AbstractRequirement SysML 1.4 SysML 1.7 Deferred closed
SYSML17-72 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 SysML 1.7 Deferred closed
SYSML17-80 Missing ownership constraints SysML 1.3 SysML 1.7 Deferred closed
SYSML17-65 Content of Requirement::/tracedTo SysML 1.4 SysML 1.7 Deferred closed
SYSML17-81 Missing type constraints for FullPort SysML 1.3 SysML 1.7 Deferred closed
SYSML17-56 Description of Item Flows SysML 1.2 SysML 1.7 Deferred closed
SYSML17-54 Blocks cannot own items flows SysML 1.2 SysML 1.7 Deferred closed
SYSML17-83 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 SysML 1.7 Deferred closed
SYSML17-88 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 SysML 1.7 Deferred closed
SYSML17-89 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.7 Deferred closed
SYSML17-96 Semantics of multiple Dependencies SysML 1.4 SysML 1.7 Deferred closed
SYSML17-91 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.7 Deferred closed
SYSML17-87 9.3.2.4 direction of ports SysML 1.4 SysML 1.7 Deferred closed
SYSML17-84 VerdictKind SysML 1.4 SysML 1.7 Deferred closed
SYSML17-92 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.7 Deferred closed
SYSML17-58 Item flows can have multiple types but item properties cannot SysML 1.2 SysML 1.7 Deferred closed
SYSML17-110 Update to Trace Relationship’ SysML 1.4 SysML 1.7 Deferred closed
SYSML17-100 The SysML classification of properties is incomplete SysML 1.4 SysML 1.7 Deferred closed
SYSML17-107 proxy and full port notation change request SysML 1.4 SysML 1.7 Deferred closed
SYSML17-85 Figure 15.8 diagram type SysML 1.3 SysML 1.7 Deferred closed
SYSML17-90 Allocation tabular notation normative? SysML 1.3 SysML 1.7 Deferred closed
SYSML17-37 callout notation issues SysML 1.4 SysML 1.7 Deferred closed
SYSML17-42 Flow properties and activity paramters SysML 1.4 SysML 1.7 Deferred closed
SYSML17-36 Proposal to have a stereotype for reference nested property SysML 1.1 SysML 1.7 Deferred closed
SYSML17-44 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 SysML 1.7 Deferred closed
SYSML17-43 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 SysML 1.7 Deferred closed
SYSML17-40 Ability for a binding connector to be typed SysML 1.1 SysML 1.7 Deferred closed
SYSML17-38 Binding to multiplicity in parametrics SysML 1.1 SysML 1.7 Deferred closed
SYSML17-41 Inheriting Allocations SysML 1.4 SysML 1.7 Deferred closed
SYSML17-64 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 SysML 1.7 Deferred closed
SYSML17-46 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 SysML 1.7 Deferred closed
SYSML17-47 SysML 1.2 Issues: Optional with streaming SysML 1.4 SysML 1.7 Deferred closed
SYSML17-53 Another issue with allocate SysML 1.4 SysML 1.7 Deferred closed
SYSML17-45 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 SysML 1.7 Deferred closed
SYSML17-51 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 SysML 1.7 Deferred closed
SYSML17-49 SysML Issue based on UML 15369 SysML 1.4 SysML 1.7 Deferred closed
SYSML17-50 SysML Issue representation of properties as associations SysML 1.4 SysML 1.7 Deferred closed
SYSML17-48 Figure B.35 object nodes SysML 1.4 SysML 1.7 Deferred closed
SYSML17-75 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.7 Deferred closed
SYSML17-69 Question about the Activity decomposition in Block Definition Diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-79 Interface blocks and protocols SysML 1.4 SysML 1.7 Deferred closed
SYSML17-5 Timing diagrams SysML 1.0 SysML 1.7 Deferred closed
SYSML17-34 Allocations should not generate dependencies SysML 1.1 SysML 1.7 Deferred closed
SYSML17-31 Binding Relationships require unit conversions SysML 1.4 SysML 1.7 Deferred closed
SYSML17-35 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 SysML 1.7 Deferred closed
SYSML17-16 ItemFlows support on Activity & Interaction Diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-14 Diagram interchange SysML 1.0 SysML 1.7 Deferred closed
SYSML17-33 AllocateActivityPartition and UML 2 semantics SysML 1.1 SysML 1.7 Deferred closed
SYSML17-15 Inferred Allocation on Allocate Activity Partitions SysML 1.4 SysML 1.7 Deferred closed
SYSML17-4 the use of <> is still unclear and inconsistent SysML 1.0 SysML 1.7 Deferred closed
SYSML17-28 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 SysML 1.7 Deferred closed
SYSML17-27 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 SysML 1.7 Deferred closed
SYSML17-166 Inconsistency between xmi and pdf for Trace and Refine specializations SysML 1.4 SysML 1.7 Resolved closed
SYSML17-519 PDF Specification of SystemOfQuantities not consistent with XMI SysML 1.6 SysML 1.7 Resolved closed
SYSML17-429 Figure E-6 is identical with E-5 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-185 Sample problem diagrams are inconsistent, need to refactor from integrated model SysML 1.5 SysML 1.7 Resolved closed
SYSML17-94 Diagram show inconsistent data SysML 1.3 SysML 1.7 Duplicate or Merged closed
SYSML17-493 Missing relationship between SystemOfUnits and Units SysML 1.6 SysML 1.7 Resolved closed
SYSML17-13 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 SysML 1.7 Deferred closed
SYSML17-9 BindingConnector ends multiplicity SysML 1.4 SysML 1.7 Deferred closed
SYSML17-8 Issue: Nested connector ends SysML 1.4 SysML 1.7 Deferred closed
SYSML17-510 The description of the semantics for the Overwrite stereotype is not consistent SysML 1.6 SysML 1.7 Resolved closed
SYSML17-63 TestCase should use PackageMerge SysML 1.2 SysML 1.7 Duplicate or Merged closed
SYSML17-7 standard way to describe a flow of data in sequence diagrams SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-222 Typo: Constraint name 8 of Adjunct Property SysML 1.6 SysML 1.7 Resolved closed
SYSML17-173 Combined call-out notation not allowed SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-492 The NoBuffer specification makes a wrong statement about the UML semantics SysML 1.6 SysML 1.7 Resolved closed
SYSML17-427 Fix figure e-5 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-255 BDD representation of activity hierarchy SysML 1.5b1 SysML 1.7 Closed; No Change closed
SYSML17-458 QUDV: PrefixedUnit has no quantity kind SysML 1.6 SysML 1.7 Resolved closed
SYSML17-499 NoBuffer has no effect if it is applied on an input pin SysML 1.6 SysML 1.7 Closed; No Change closed
SYSML17-21 Annex B / Figure B27 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-23 Annex B / Figure B.38 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-93 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.7 Duplicate or Merged closed
SYSML17-22 Annex B / Figure B.35 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-25 Figure B.34 and Figure B.35 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-61 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-60 Where have stereotypes been defined? SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-24 Annex B, Figure B.29 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-12 Sample problem: Parts are added directly into package SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-521 PDF Specification of SystemOfUnits not consistent with XMI SysML 1.6 SysML 1.7 Resolved closed
SYSML17-355 'Figure 15-4: Behavior Allocation' multiple issues in the diagram and the supporting text SysML 1.6 SysML 1.7 Resolved closed
SYSML17-2 SysML: UML Qualified Associations SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-453 Figure E.8 depicts instance specifications with invalid slots SysML 1.6 SysML 1.7 Resolved closed
SYSML17-447 QUDV: SystemOfUnits constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds not documented in PDF SysML 1.6 SysML 1.7 Resolved closed
SYSML17-29 Requirements interchange issue SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-460 Figure E.11: Make it a package diagram and update the URI's SysML 1.6 SysML 1.7 Resolved closed
SYSML17-445 QUDV: Constraints [1] and [2]of SystemOfUnits are operations SysML 1.6 SysML 1.7 Resolved closed
SYSML17-74 clarification, what "part property" is SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-449 QUDV: SystemOfUnits::accessibleQuantityKinds() is a copy & paste error SysML 1.6 SysML 1.7 Resolved closed
SYSML17-441 SimpleQuantityKind::dependsOnQuantityKinds() not specified as a redefinition SysML 1.6 SysML 1.7 Resolved closed
SYSML17-451 QUDV: Documentation of SystemOfUnits::getUnit() is missing SysML 1.6 SysML 1.7 Resolved closed
SYSML17-465 Figure E.19 not consistent with XMI SysML 1.6 SysML 1.7 Resolved closed
SYSML17-77 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-172 ConnectorProperty is redundant SysML 1.5 SysML 1.7 Resolved closed
SYSML17-506 Annex D (Sample problem) should illustrate a nominal usage of the corresponding version of SysML SysML 1.6 SysML 1.7 Resolved closed
SYSML17-251 Syntactical clarification for ConstraintBlock SysML 1.6 SysML 1.7 Duplicate or Merged closed
SYSML17-73 9.3.2.9 What is InterfaceBlock? SysML 1.4 SysML 1.7 Resolved closed
SYSML17-103 SysML Issues on Item Property values in an IBD SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-439 Return parameters of operations in annex E.5.2 have wrong parameter direction SysML 1.6 SysML 1.7 Resolved closed
SYSML17-148 Owning Block definition is unclear SysML 1.5 SysML 1.7 Resolved closed
SYSML17-11 It is not allowed in UML to display stereotypes of related elements SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-409 Figure 8-1: Wrong property notation SysML 1.6 SysML 1.7 Resolved closed
SYSML17-433 QUDV::LinearConversionUnit constraint isInvertible=true SysML 1.6 SysML 1.7 Resolved closed
SYSML17-431 QUDV::AffineConversionUnit constraint isInvertible=true SysML 1.6 SysML 1.7 Resolved closed
SYSML17-421 Description of SysMLStructureDiagram is missing SysML 1.6 SysML 1.7 Resolved closed
SYSML17-297 Figure 11-14 is identical with figure 11-13 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-411 Figure 9-5 is identical with figure 9-4 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-443 QUDV: dependOnUnits() operation is not redefined SysML 1.6 SysML 1.7 Resolved closed
SYSML17-415 Incorrect placement of sections in chapter 17 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-425 Section C.3.2.3 should not be a section, but only a headline without numbering SysML 1.6 SysML 1.7 Resolved closed
SYSML17-417 Figure 13-1 shows two identical names in the same namespace SysML 1.6 SysML 1.7 Resolved closed
SYSML17-419 Figure 12-1 shows two identical names in the same namespace SysML 1.6 SysML 1.7 Resolved closed
SYSML17-423 Remove second constraint of SysMLBehaviorDiagram SysML 1.6 SysML 1.7 Resolved closed
SYSML17-59 Definition of part SysML 1.2 SysML 1.7 Closed; No Change closed
SYSML17-435 QUDV.xmi: Prefix::symbol multiplicity should be 0..1 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-137 Missing comment for some attributes SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-139 Derived attribute should also be read only SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-52 SysML primitive value types SysML 1.4 SysML 1.7 Resolved closed
SYSML17-1 SysML: Protocol State Machines needed SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-317 Incorrect description of SysMLBlockDefinitionDiagram SysML 1.6 SysML 1.7 Resolved closed
SYSML17-109 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-141 "Allocated From" should be "Allocated" SysML 1.4 SysML 1.7 Resolved closed
SYSML17-6 Block namespace compartment: Are external relationships allowed SysML 1.4 SysML 1.7 Resolved closed
SYSML17-30 Representation of nested object nodes in activity diagrams SysML 1.1 SysML 1.7 Closed; No Change closed
SYSML17-232 Table 8.3: Row ActorPart shows Actor SysML 1.6b1 SysML 1.7 Closed; No Change closed
SYSML17-310 Figure 9-5 and 9-4 are the same SysML 1.6 SysML 1.7 Resolved closed
SYSML17-152 Parameter direction typo in XMI SysML 1.5 SysML 1.7 Resolved closed
SYSML17-150 Owned properties of an InterfaceBlock SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-17 10.3.1.2 Parametric Diagram: square box notation SysML 1.0 SysML 1.7 Resolved closed
SYSML17-39 Do parametric bindings observe derived and read-only properties SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-18 Annex B / B.4.8.3 Activity Diagram (in sample problem) SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-76 SysML: References to CreateEvent incorrect SysML 1.4 SysML 1.7 Resolved closed
SYSML17-101 About Rate, Continuous and Discrete SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-55 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 SysML 1.7 Closed; No Change closed
SYSML17-62 Association owning ends SysML 1.2 SysML 1.7 Closed; No Change closed
SYSML17-289 Allocate: Error in operation bodies SysML 1.6 SysML 1.7 Resolved closed
SYSML17-266 UML::ExceptionHandler should be part of SysML SysML 1.6 SysML 1.7 Resolved closed
SYSML17-3 SysML: Generalizing Activites SysML 1.4 SysML 1.7 Resolved closed
SYSML17-145 Shared parts are still parts SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-218 Stakeholder constraint is listed twice SysML 1.6 SysML 1.7 Resolved closed
SYSML17-70 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-220 Bad reference in section 4.2 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-10 Lack of notation for units and dimensions on values. SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-26 SysML: Align SysML Activities with Foundational UML SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-160 DirectedFeature is confusing SysML 1.5 SysML 1.7 Resolved closed
SYSML17-181 VerdictKind enumeration missing SysML 1.6 SysML 1.7 Resolved closed
SYSML17-151 The AdjunctProperty is not clearly described SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-159 Reference Properties do not reference properties SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-239 AllocateActivityPartition: Reference to UML specification is wrong SysML 1.6b1 SysML 1.7 Resolved closed
SYSML17-156 Replace UML4SysML::Kernel by UML4SysML::Generalization SysML 1.5 SysML 1.7 Resolved closed
SYSML17-176 SysML::Trace relationship is not specialized from UML::Trace in the XMI SysML 1.5 SysML 1.7 Resolved closed
SYSML17-177 SysML::Refine relationship is not specialized from UML::Refine in the XMI SysML 1.5 SysML 1.7 Resolved closed
SYSML17-182 Verdict described incorrecty SysML 1.6 SysML 1.7 Resolved closed
SYSML17-157 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-167 Description of AdjunctProperty SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-120 Inherit from a conjugated interface block SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-117 ElementGroup cannot be source or target of a dependency SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-122 Property path notation SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-134 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-125 A discarded resolution still appears in the ballot SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-142 Requirement ID should be immutable SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-144 Specify a specific part from a collection of parts on an IBD SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-143 Expand use of rake symbol for all decompositions SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-174 Connectors are not allowed in bdd SysML 1.5 SysML 1.7 Resolved closed
SYSML17-146 Numeric Literals as constraint block property parameter values SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-158 Statements missing in the abstract syntax description SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-130 Description of model elements in generated document not consistent with specification SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-165 Typo in revised text of issue SYSML16-289 SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-121 Missing property descriptions for Probability and Rate SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-57 SysML Issue on Refine limitations SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-68 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-178 Virtual member representing the whole RTF SysML 1.6 SysML 1.7 Closed; Out Of Scope closed
SYSML17-71 Property Based Requirements SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-32 Support BDD's for State Machines SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-86 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.7 Closed; Out Of Scope closed
SYSML17-98 ProxyPort with FlowProperties SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-20 Annex B / Figure B.9 SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-78 How to refer to properties of an extension? SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-66 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.7 Closed; Out Of Scope closed
SYSML17-67 InstanceSpecification equality SysML 1.3 SysML 1.7 Closed; Out Of Scope closed
SYSML17-138 Hanging Clauses Throughout SysML 1.4 SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-108 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-119 More than one View() operation allowed SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-82 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-19 Annex B / Figure B.10 SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML11-54 <> SysML 1.0 SysML 1.1 Resolved closed
SYSML16-468 The constraint#3 of NestedConnectorEnd could be replaced by a redefinition SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-191 Keyword signal in reception compartment is superfluous SysML 1.4 SysML 1.6 Resolved closed
SYSML16-662 Error in the revised text for SYSML16-132 SysML 1.5 SysML 1.6 Resolved closed
SYSML16-455 Composite properties allowed for InterfaceBlocks SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-274 Most constraints are missing their OCL statement SysML 1.5 SysML 1.6 Resolved closed
SYSML16-226 Arbitrary diagram linkage to model elements SysML 1.4 SysML 1.6 Closed; Out Of Scope closed
SYSML16-132 Semantics consistency of conjugated behavior ports SysML 1.4 SysML 1.6 Resolved closed
SYSML16-462 Setting flow properties on blocks with multiple behavioral ports SysML 1.5 SysML 1.6 Resolved closed
SYSML16-367 Constraints on Satisfy and Verify should refer to AbstractRequirement SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-349 ItemFlow constraint#3 does not make sense in every case SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-358 Allocate constraint#3 does not make sense SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-254 Clarify port usage patterns SysML 1.5 SysML 1.6 Closed; No Change closed
SYSML16-100 Incorrect constraint [2] on InterfaceBlock SysML 1.3 SysML 1.6 Duplicate or Merged closed
SYSML16-185 Instance for Initial values SysML 1.4 SysML 1.6 Resolved closed
SYSML16-131 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 SysML 1.6 Resolved closed
SYSML16-397 Diagram guidelines uses excluded UML element SysML 1.5 SysML 1.6 Resolved closed
SYSML16-389 Change keyword of binding connector from "equal" to "=" SysML 1.5 SysML 1.6 Resolved closed
SYSML16-366 Constraints for Refine and Trace can be improved SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-365 Copy constraints #2 and #3 shoud be merged together SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-353 The constraint#6 of TriggerOnNestedPort could be replaced by a redefinition SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-352 The statement of TriggerOnNestedPort constraint#5 is wrong SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-351 The statement of TriggerOnNestedPort constraint#4 is not appropriate SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-348 ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation SysML 1.5 SysML 1.6 Closed; No Change closed
SYSML16-356 Rate constraint#2 is ambiguous SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-355 Probability constraint#1 is ambiguous SysML 1.5 SysML 1.6 Closed; No Change closed
SYSML16-354 The OCL statement of ConstraintBlock constraint#3 is wrong SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-198 Most diagram headers in document are not consistent with Appendix A, p 189. SysML 1.4 SysML 1.6 Resolved closed
SYSML16-343 Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-329 Constraints redundancy in DirectedRelationshipPropertyPath SysML 1.5 SysML 1.6 Closed; No Change closed
SYSML16-154 Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous SysML 1.4 SysML 1.6 Resolved closed
SYSML16-326 BoundReference constraint#3 is unclear SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-325 Typo in AdjunctProperty Constraint#10 SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-136 Update SysML references to UML model library StandardProfileL2 SysML 1.3 SysML 1.6 Closed; No Change closed
SYSML16-357 Allocate constraint#1 could be replaced by a redefinition SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-342 The statement of InvocationOnNestedPortAction constraint#3 is not appropriate SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-341 Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-80 Issue on Block constraint#4 SysML 1.4 SysML 1.6 Duplicate or Merged closed
SYSML16-76 Problems with property-specific types SysML 1.3 SysML 1.6 Resolved closed
SYSML16-106 Constraint [5] should include specializations of Requirement SysML 1.3 SysML 1.6 Duplicate or Merged closed
SYSML16-92 remove figure numbers from diagram frames SysML 1.3 SysML 1.6 Resolved closed
SYSML16-151 Provide support to capture engineering quantities and support intricate calculations SysML 1.4 SysML 1.6 Closed; Out Of Scope closed
SYSML16-314 The association-like notation is ambiguous SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-149 <> should be a reference (dashed box) SysML 1.4 SysML 1.6 Resolved closed
SYSML16-160 Cannot navigate and represent deep nested defining feature in a slot SysML 1.4 SysML 1.6 Transfered closed
SYSML16-40 Parsing Text in Requirements SysML 1.1 SysML 1.6 Duplicate or Merged closed
SYSML16-38 Inability to represent dependent, independent parameters on constraint properties SysML 1.1 SysML 1.6 Closed; Out Of Scope closed
SYSML16-34 Requirement constants should be integrated into Model-centric vision of SysmL SysML 1.4 SysML 1.6 Closed; Out Of Scope closed
SYSML16-33 Section: 8/8.3.2 Inability to efficiently capture datasets SysML 1.1 SysML 1.6 Closed; Out Of Scope closed
SYSML16-399 Nested diagrams in SysML SysML 1.5 SysML 1.6 Resolved closed
SYSML16-393 Binding connectors have no keyword syntax in parametric diagrams SysML 1.5 SysML 1.6 Resolved closed
SYSML16-275 Typo in xmi file for orderedMember SysML 1.4 SysML 1.6 Resolved closed
SYSML16-382 Allow a Requirement to be contained on Any Diagram SysML 1.5 SysML 1.6 Closed; No Change closed
SYSML16-387 Equal sign for binding connector SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-79 Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior SysML 1.2 SysML 1.6 Closed; Out Of Scope closed
SYSML16-181 Binding Connector should not be typed SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-303 References to UML specification in block constraints are not correct SysML 1.5 SysML 1.6 Resolved closed
SYSML16-300 Remove sentences about qualified associations in clause 8.3.1.3 SysML 1.5 SysML 1.6 Resolved closed
SYSML16-299 Remove the statement about N-ary associations from 8.3.1.3 SysML 1.5 SysML 1.6 Resolved closed
SYSML16-229 Constant Block Value Properties SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-130 Flow property description: incorrect wording (§9.3.2.7) SysML 1.4 SysML 1.6 Resolved closed
SYSML16-26 Section: Generalization of stereotyped elements SysML 1.0 SysML 1.6 Closed; No Change closed
SYSML16-395 Binding connectors in internal block diagrams must always show the keyword SysML 1.5 SysML 1.6 Resolved closed
SYSML16-321 View constraint#3 is incorrect SysML 1.5 SysML 1.6 Resolved closed
SYSML16-104 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 SysML 1.6 Closed; No Change closed
SYSML16-90 Is <> keyword (or stereotype) on binding connectors is part of SysML notation? SysML 1.4 SysML 1.6 Duplicate or Merged closed
SYSML16-125 Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors SysML 1.4 SysML 1.6 Duplicate or Merged closed
SYSML16-331 UnitAndQuantityKind figure missing block keyword SysML 1.5 SysML 1.6 Resolved closed
SYSML16-182 NestedConnectorEnd violates UML "roles" constraint SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-183 SysML specification document cleanups SysML 1.4 SysML 1.6 Duplicate or Merged closed
SYSML16-188 ParticipantProperty keyword SysML 1.4 SysML 1.6 Transfered closed
SYSML16-310 SysML::Block constraint#3 containts an incorrect assertion about UML SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-295 Remove [sic] in block constraints SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-44 Need to have an explicit way to bind flow properties or atomic flow ports to block properties SysML 1.1 SysML 1.6 Duplicate or Merged closed
SYSML16-69 Incorrect statement about UML n-aries SysML 1.2 SysML 1.6 Duplicate or Merged closed
SYSML16-67 Compartment labelling rules SysML 1.4 SysML 1.6 Resolved closed
SYSML16-323 AdjunctProperty constraint#8 can be simplified SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-201 Behavior Diagram Element tables imply diagrams can be nodes SysML 1.4 SysML 1.6 Resolved closed
SYSML16-203 Update description about extension of UML SysML 1.4 SysML 1.6 Resolved closed
SYSML16-345 SysML stereotype constraints should be named rather than numbered SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-332 EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-337 Compartment headers are missing in figure 8.10 and 8.11 SysML 1.5 SysML 1.6 Resolved closed
SYSML16-334 Incorrect diagram header in figure 8.11 SysML 1.5 SysML 1.6 Resolved closed
SYSML16-165 Initial values compartment header inconsistent with others SysML 1.4 SysML 1.6 Duplicate or Merged closed
SYSML16-205 SysML Provides Inadequate Support for Reuse of Requirements SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-186 The type of ParticipantProperty SysML 1.4 SysML 1.6 Resolved closed
SYSML16-171 xmi:IDs are not convenient SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-281 Clarify if the usage of qualified associations is allowed SysML 1.5b1 SysML 1.6 Closed; No Change closed
SYSML16-280 Association arrowheads should not be forbidden SysML 1.5b1 SysML 1.6 Closed; No Change closed
SYSML16-177 Incorrect multiplicity for base_xxx properties of most SysML Stereotypes SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-173 Wrong parameter for Operations in the SysML.xmi SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-166 RequirementRelated is present in the summary but no more in the document SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-211 Block constraint [4] contains a false statement SysML 1.5 SysML 1.6 Duplicate or Merged closed
SYSML16-202 Activity should not be included as graphical node included in activity diagrams SysML 1.4 SysML 1.6 Duplicate or Merged closed
SYSML16-87 Port labels inside Port symbol SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-86 Section 9.3.1.7 SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-180 AdjunctProperty principal should be a NamedElement SysML 1.4 SysML 1.6 Resolved closed
SYSML16-192 SysML does not clearly defines how an association defines properties SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-199 BNF definitions have literals/terminals in italics, which seems to imply that the occurrences of these strings should be in italics, but they are not. SysML 1.4 SysML 1.6 Resolved closed
SYSML16-187 ParticipantProperty stereotype is redundant SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-196 layout error for compartment name SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-168 DeriveReqt constraints multiplicity of Client and Supplier SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-184 ISO DIS 19514 (JTC1 Comments against SysML 1.4) SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-178 The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-174 Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-4 Section: 9.3.2.5 FlowPort SysML 1.0 SysML 1.6 Closed; No Change closed
SYSML16-43 Flow port compatibility with behavior SysML 1.1 SysML 1.6 Closed; No Change closed
SYSML16-94 Problems with 1.3 Enumeration Literals SysML 1.4 SysML 1.6 Resolved closed
SYSML16-122 SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-110 Ports and Flows SysML 1.3 SysML 1.6 Resolved closed
SYSML16-193 Constraint clarification SysML 1.4 SysML 1.6 Closed; Out Of Scope closed
SYSML16-195 Missing one right parenthesis in the constraint equation SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-5 the use of <> is still unclear and inconsistent SysML 1.0 SysML 1.6 Deferred closed
SYSML16-3 SysML: Generalizing Activites SysML 1.4 SysML 1.6 Deferred closed
SYSML16-2 SysML: UML Qualified Associations SysML 1.4 SysML 1.6 Deferred closed
SYSML16-1 SysML: Protocol State Machines needed SysML 1.4 SysML 1.6 Deferred closed
SYSML16-13 Sample problem: Parts are added directly into package SysML 1.4 SysML 1.6 Deferred closed
SYSML16-12 It is not allowed in UML to display stereotypes of related elements SysML 1.4 SysML 1.6 Deferred closed
SYSML16-11 Lack of notation for units and dimensions on values. SysML 1.4 SysML 1.6 Deferred closed
SYSML16-10 BindingConnector end s multiplicity SysML 1.4 SysML 1.6 Deferred closed
SYSML16-9 Issue: Nested connector ends SysML 1.4 SysML 1.6 Deferred closed
SYSML16-8 standard way to describe a flow of data in sequence diagrams SysML 1.0 SysML 1.6 Deferred closed
SYSML16-7 Block namespace compartment: Are external relationships allowed SysML 1.4 SysML 1.6 Deferred closed
SYSML16-6 Timing diagrams SysML 1.0 SysML 1.6 Deferred closed
SYSML16-22 Annex B / Figure B27 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-21 Annex B / Figure B.9 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-20 Annex B / Figure B.10 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-19 Annex B / B.4.8.3 Activity Diagram (in sample problem) SysML 1.0 SysML 1.6 Deferred closed
SYSML16-18 10.3.1.2 Parametric Diagram: square box notation SysML 1.0 SysML 1.6 Deferred closed
SYSML16-17 Item Flows on Activity Diagrams SysML 1.4 SysML 1.6 Deferred closed
SYSML16-16 Inferred Allocation on Allocate Activity Partitions SysML 1.4 SysML 1.6 Deferred closed
SYSML16-15 Diagram interchange SysML 1.0 SysML 1.6 Deferred closed
SYSML16-30 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 SysML 1.6 Deferred closed
SYSML16-14 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 SysML 1.6 Deferred closed
SYSML16-29 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 SysML 1.6 Deferred closed
SYSML16-28 SysML: Align SysML Activities with Foundational UML SysML 1.4 SysML 1.6 Deferred closed
SYSML16-27 Figure B.34 and Figure B.35 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-25 Annex B, Figure B.29 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-24 Annex B / Figure B.38 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-23 Annex B / Figure B.35 SysML 1.0 SysML 1.6 Deferred closed
SYSML16-45 callout notation issues SysML 1.4 SysML 1.6 Deferred closed
SYSML16-42 Proposal to have a stereotype for reference nested property SysML 1.1 SysML 1.6 Deferred closed
SYSML16-41 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 SysML 1.6 Deferred closed
SYSML16-39 Allocations should not generate dependencies SysML 1.1 SysML 1.6 Deferred closed
SYSML16-52 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 SysML 1.6 Deferred closed
SYSML16-51 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 SysML 1.6 Deferred closed
SYSML16-50 Flow properties and activity paramters SysML 1.4 SysML 1.6 Deferred closed
SYSML16-49 Inheriting Allocations SysML 1.4 SysML 1.6 Deferred closed
SYSML16-48 Ability for a binding connector to be typed SysML 1.1 SysML 1.6 Deferred closed
SYSML16-47 Do parametric bindings observe derived and read-only properties SysML 1.4 SysML 1.6 Deferred closed
SYSML16-46 Binding to multiplicity in parametrics SysML 1.1 SysML 1.6 Deferred closed
SYSML16-37 AllocateActivityPartition and UML 2 semantics SysML 1.1 SysML 1.6 Deferred closed
SYSML16-36 Support BDD's for State Machines SysML 1.4 SysML 1.6 Deferred closed
SYSML16-35 Binding Relationships require unit conversions SysML 1.4 SysML 1.6 Deferred closed
SYSML16-32 Representation of nested object nodes in activity diagrams SysML 1.1 SysML 1.6 Deferred closed
SYSML16-31 Requirements interchange issue SysML 1.4 SysML 1.6 Deferred closed
SYSML16-54 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 SysML 1.6 Deferred closed
SYSML16-53 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 SysML 1.6 Deferred closed
SYSML16-62 Blocks cannot own items flows SysML 1.2 SysML 1.6 Deferred closed
SYSML16-61 Another issue with allocate SysML 1.4 SysML 1.6 Deferred closed
SYSML16-60 SysML primitive value types SysML 1.4 SysML 1.6 Deferred closed
SYSML16-59 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 SysML 1.6 Deferred closed
SYSML16-58 SysML Issue representation of properties as associations SysML 1.4 SysML 1.6 Deferred closed
SYSML16-57 SysML Issue based on UML 15369 SysML 1.4 SysML 1.6 Deferred closed
SYSML16-56 Figure B.35 object nodes SysML 1.4 SysML 1.6 Deferred closed
SYSML16-55 SysML 1.2 Issues: Optional with streaming SysML 1.4 SysML 1.6 Deferred closed
SYSML16-73 TestCase should use PackageMerge SysML 1.2 SysML 1.6 Deferred closed
SYSML16-72 Association owning ends SysML 1.2 SysML 1.6 Deferred closed
SYSML16-71 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 SysML 1.6 Deferred closed
SYSML16-70 Where have stereotypes been defined? SysML 1.4 SysML 1.6 Deferred closed
SYSML16-68 Definition of part SysML 1.2 SysML 1.6 Deferred closed
SYSML16-66 Item flows can have multiple types but item properties cannot SysML 1.2 SysML 1.6 Deferred closed
SYSML16-65 SysML Issue on Refine limitations SysML 1.4 SysML 1.6 Deferred closed
SYSML16-64 Description of Item Flows SysML 1.2 SysML 1.6 Deferred closed
SYSML16-63 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 SysML 1.6 Deferred closed
SYSML16-78 InstanceSpecification equality SysML 1.3 SysML 1.6 Deferred closed
SYSML16-77 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.6 Deferred closed
SYSML16-75 Content of Requirement::/tracedTo SysML 1.4 SysML 1.6 Deferred closed
SYSML16-74 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 SysML 1.6 Deferred closed
SYSML16-83 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 SysML 1.6 Deferred closed
SYSML16-82 Question about the Activity decomposition in Block Definition Diagrams SysML 1.4 SysML 1.6 Deferred closed
SYSML16-81 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 SysML 1.6 Deferred closed
SYSML16-91 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.6 Deferred closed
SYSML16-89 clarification, what "part property" is SysML 1.4 SysML 1.6 Deferred closed
SYSML16-88 9.3.2.9 What is InterfaceBlock? SysML 1.4 SysML 1.6 Deferred closed
SYSML16-85 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 SysML 1.6 Deferred closed
SYSML16-84 Property Based Requirements SysML 1.3 SysML 1.6 Deferred closed
SYSML16-99 Missing type constraints for FullPort SysML 1.3 SysML 1.6 Deferred closed
SYSML16-98 Missing ownership constraints SysML 1.3 SysML 1.6 Deferred closed
SYSML16-97 Interface blocks and protocols SysML 1.4 SysML 1.6 Deferred closed
SYSML16-96 How to refer to properties of an extension? SysML 1.4 SysML 1.6 Deferred closed
SYSML16-95 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.6 Deferred closed
SYSML16-93 SysML: References to CreateEvent incorrect SysML 1.4 SysML 1.6 Deferred closed
SYSML16-107 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.6 Deferred closed
SYSML16-105 Figure 15.8 diagram type SysML 1.3 SysML 1.6 Deferred closed
SYSML16-103 VerdictKind SysML 1.4 SysML 1.6 Deferred closed
SYSML16-102 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 SysML 1.6 Deferred closed
SYSML16-101 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 SysML 1.6 Deferred closed
SYSML16-119 primitive types in SysML Activities SysML 1.4 SysML 1.6 Deferred closed
SYSML16-114 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.6 Deferred closed
SYSML16-113 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.6 Deferred closed
SYSML16-112 Allocation tabular notation normative? SysML 1.3 SysML 1.6 Deferred closed
SYSML16-111 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.6 Deferred closed
SYSML16-109 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 SysML 1.6 Deferred closed
SYSML16-108 9.3.2.4 direction of ports SysML 1.4 SysML 1.6 Deferred closed
SYSML16-118 Semantics of multiple Dependencies SysML 1.4 SysML 1.6 Deferred closed
SYSML16-117 Clarification required for Copy relationship SysML 1.3 SysML 1.6 Deferred closed
SYSML16-116 Diagram show inconsistent data SysML 1.3 SysML 1.6 Deferred closed
SYSML16-115 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.6 Deferred closed
SYSML16-133 Semantics clarification for removing a value from an out Flow Property SysML 1.4 SysML 1.6 Deferred closed
SYSML16-139 Abstract syntax for the initial values SysML 1.4 SysML 1.6 Deferred closed
SYSML16-138 Update to Trace Relationship’ SysML 1.4 SysML 1.6 Deferred closed
SYSML16-137 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.6 Deferred closed
SYSML16-135 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 SysML 1.6 Deferred closed
SYSML16-134 proxy and full port notation change request SysML 1.4 SysML 1.6 Deferred closed
SYSML16-141 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 SysML 1.6 Deferred closed
SYSML16-140 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 SysML 1.6 Deferred closed
SYSML16-121 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.6 Deferred closed
SYSML16-120 ProxyPort with FlowProperties SysML 1.4 SysML 1.6 Deferred closed
SYSML16-124 About Rate, Continuous and Discrete SysML 1.4 SysML 1.6 Deferred closed
SYSML16-123 The SysML classification of properties is incomplete SysML 1.4 SysML 1.6 Deferred closed
SYSML16-129 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 SysML 1.6 Deferred closed
SYSML16-128 Pull semantics for flow properties SysML 1.4 SysML 1.6 Deferred closed
SYSML16-127 SysML Issues on Item Property values in an IBD SysML 1.4 SysML 1.6 Deferred closed
SYSML16-126 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 SysML 1.6 Deferred closed
SYSML16-150 Missing property descriptions for Probability and Rate SysML 1.4 SysML 1.6 Deferred closed
SYSML16-155 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 SysML 1.6 Deferred closed
SYSML16-152 Property path notation SysML 1.4 SysML 1.6 Deferred closed
SYSML16-153 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 SysML 1.6 Deferred closed
SYSML16-158 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 SysML 1.6 Deferred closed
SYSML16-157 specializations of requirement should specialize AbstractRequirement SysML 1.4 SysML 1.6 Deferred closed
SYSML16-148 Inherit from a conjugated interface block SysML 1.4 SysML 1.6 Deferred closed
SYSML16-147 More than one View() operation allowed SysML 1.4 SysML 1.6 Deferred closed
SYSML16-146 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 SysML 1.6 Deferred closed
SYSML16-145 ElementGroup cannot be source or target of a dependency SysML 1.4 SysML 1.6 Deferred closed
SYSML16-144 [SysML] Semantic variation points SysML 1.4 SysML 1.6 Deferred closed
SYSML16-143 Can a SysML Full Port be typed by a ValueType? SysML 1.4 SysML 1.6 Deferred closed
SYSML16-142 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 SysML 1.6 Deferred closed
SYSML16-159 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 SysML 1.6 Deferred closed
SYSML16-156 A discarded resolution still appears in the ballot SysML 1.4 SysML 1.6 Deferred closed
SYSML16-164 ConnectorProperty notation in wrong section. SysML 1.4 SysML 1.6 Deferred closed
SYSML16-206 Expand use of rake symbol for all decompositions SysML 1.4 SysML 1.6 Deferred closed
SYSML16-204 Requirement ID should be immutable SysML 1.4 SysML 1.6 Deferred closed
SYSML16-189 Derived attribute should also be read only SysML 1.4 SysML 1.6 Deferred closed
SYSML16-167 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 SysML 1.6 Deferred closed
SYSML16-169 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 SysML 1.6 Deferred closed
SYSML16-194 Causality of constraints in parametric diagrams SysML 1.4 SysML 1.6 Deferred closed
SYSML16-197 "Allocated From" should be "Allocated" SysML 1.4 SysML 1.6 Deferred closed
SYSML16-228 Shared parts are still parts SysML 1.4 SysML 1.6 Deferred closed
SYSML16-227 Specify a specific part from a collection of parts on an IBD SysML 1.4 SysML 1.6 Deferred closed
SYSML16-176 Missing comment for some attributes SysML 1.4 SysML 1.6 Deferred closed
SYSML16-172 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 SysML 1.6 Deferred closed
SYSML16-170 No support for dot notation in activity and sequence diagrams SysML 1.4 SysML 1.6 Deferred closed
SYSML16-161 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 SysML 1.6 Deferred closed
SYSML16-162 Description of model elements in generated document not consistent with specification SysML 1.4 SysML 1.6 Deferred closed
SYSML16-163 Parts, references, values compartments in wrong section SysML 1.4 SysML 1.6 Deferred closed
SYSML16-179 Hanging Clauses Throughout SysML 1.4 SysML 1.4 SysML 1.6 Deferred closed
SYSML16-328 Inconsistency in the DirectedRelationshipPropertyPath specification SysML 1.5 SysML 1.6 Deferred closed
SYSML16-319 Clarification of typing a binding connector SysML 1.5 SysML 1.6 Deferred closed
SYSML16-298 Replace all occurrences of "has been" by "is" SysML 1.5 SysML 1.6 Deferred closed
SYSML16-294 Parameter direction typo in XMI SysML 1.5 SysML 1.6 Deferred closed
SYSML16-288 The AdjunctProperty is not clearly described SysML 1.4 SysML 1.6 Deferred closed
SYSML16-231 Diagram formality confusion SysML 1.4 SysML 1.6 Deferred closed
SYSML16-230 Numeric Literals as constraint block property parameter values SysML 1.4 SysML 1.6 Deferred closed
SYSML16-417 SysML 1.6 should be based on UML 2.5.1 SysML 1.5 SysML 1.6 Deferred closed
SYSML16-364 Statements missing in the abstract syntax description SysML 1.5 SysML 1.6 Deferred closed
SYSML16-264 Owned properties of an InterfaceBlock SysML 1.5 SysML 1.6 Deferred closed
SYSML16-263 FullPort type SysML 1.5 SysML 1.6 Deferred closed
SYSML16-253 Owning Block definition is unclear SysML 1.5 SysML 1.6 Deferred closed
SYSML16-372 DirectedFeature is confusing SysML 1.5 SysML 1.6 Deferred closed
SYSML16-371 Reference Properties do not reference properties SysML 1.5 SysML 1.6 Deferred closed
SYSML16-409 Excluded UML metaclasses are not formally defined SysML 1.5 SysML 1.6 Deferred closed
SYSML16-344 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 SysML 1.6 Deferred closed
SYSML16-333 Replace UML4SysML::Kernel by UML4SysML::Generalization SysML 1.5 SysML 1.6 Deferred closed
SYSML16-458 Inconsistency between xmi and pdf for Trace and Refine specializations SysML 1.4 SysML 1.6 Deferred closed
SYSML16-483 ConnectorProperty is redundant SysML 1.5 SysML 1.6 Deferred closed
SYSML16-482 DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution SysML 1.5 SysML 1.6 Deferred closed
SYSML16-481 DistributedProperty should be abstract SysML 1.5 SysML 1.6 Deferred closed
SYSML16-465 DistributedProperty should be abstract SysML 1.5 SysML 1.6 Deferred closed
SYSML16-464 Description of AdjunctProperty SysML 1.5 SysML 1.6 Deferred closed
SYSML16-175 Dubious UUIDs SysML 1.4 SysML 1.6 Closed; No Change closed
SYSML16-421 Typo in revised text of issue SYSML16-289 SysML 1.5 SysML 1.6 Deferred closed
SYSML16-404 Add signal to constraint [1] for DistributedProperty SysML 1.5 SysML 1.6 Deferred closed
SYSML16-373 Add Graphical notation for General Classifier SysML 1.5 SysML 1.6 Deferred closed
SYSML16-478 Diagram header is not intuitively interpreted SysML 1.5 SysML 1.6 Deferred closed
SYSML16-350 Do not move deprecated elements SysML 1.5 SysML 1.6 Deferred closed
SYSML13-12 Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints SysML 1.2 SysML 1.3 Resolved closed
SYSMLR-278 JTC1 JP3 023 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-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-332 Property path with unnamed properties is unreadable 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-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-271 JTC1 JP20 016 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-270 JTC1 JP18 015 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-269 JTC1 JP19 014 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-268 JTC1 JP17 013 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-263 JTC1 JP12 008 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-267 JTC1 JP16 012 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-265 JTC1 JP13 010 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-248 ParticipantProperty multiplicity 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-324 update constraints to set sourceContext and targetContext of «DirectedRelationshipPropertyPath» SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-279 JTC1 JP4 024 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-277 JTC1 JP5 022 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-276 JTC1 JP2 021 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-275 JTC1 JP24 020 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-274 JTC1 JP23 019 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-260 JTC1 JP9 005 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-259 JTC1 JP7 004 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-258 JTC1 JP8 003 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-272 JTC1 JP21 017 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-262 JTC1 JP10 007 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-261 JTC1 JP11 006 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-48 SysML 7.3.2.5 Viewpoint SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-257 JTC1 JP6 002 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-231 16.3.2.4 Requirement Operations OCL Inconsistent SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-256 JTC1 JP1 001 SysML 1.4 SysML 1.5 Closed; No Change 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-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-126 Forked association notation ill-formed SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-153 reception compartment not addressed 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-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-2 SysML: UML Qualified Associations 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-12 It is not allowed in UML to display stereotypes of related elements 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-10 BindingConnector SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-9 Issue: Nested connector ends 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-8 Section: 12. Interactions 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-4 Section: 9.3.2.5 FlowPort SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-3 SysML: Generalizing Activites SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-17 Item Flows on Activity Diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-16 Inferred Allocation on Allocate Activity Partitions SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-15 Section: 5.3 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-22 Annex B / Figure B27 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-19 Annex B / B.4.8.3 Activity Diagram SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-18 10.3.1.2 Parametric Diagram SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-26 Section: Generalization of stereotyped elements SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-25 Annex B, Figure B.29 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-24 Annex B / Figure B.38 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-23 Annex B / Figure B.35 SysML 1.0 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-37 AllocateActivityPartition and UML 2 semantics 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-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-27 Figure B.34 and Figure B.35 SysML 1.0 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-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-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-47 Do parametric bindings observe derived and read-only properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-46 Binding to multiplicity in parametrics SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-45 callout notation issues SysML 1.4 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-42 Proposal to have a stereotype for reference nested property 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-40 Parsing Text in Requirements SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-39 Allocations should not generate dependencies SysML 1.1 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-52 Flow properties and activity paramters SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-50 Inheriting Allocations 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-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-60 SysML Issue representation of properties as 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-70 Definition of part SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-58 Figure B.35 object nodes 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-56 Continuous flows in non-streaming situations with >1 multiplicities 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-54 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-63 Another issue with allocate SysML 1.4 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-67 SysML Issue on Refine limitations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-66 Description of Item Flows 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-75 Association owning ends SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-72 Where have stereotypes been defined? 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-69 Compartment labelling rules SysML 1.4 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-87 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 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-84 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-83 Issue on Block constraint#4 SysML 1.4 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-76 TestCase should use PackageMerge SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-79 Problems with property-specific types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-78 Content of Requirement::/tracedTo 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-88 Property Based Requirements SysML 1.3 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-81 InstanceSpecification equality SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-80 InstanceSpecifications for exactly one instance 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-95 Callout notation for port-specific types and initial values SysML 1.3 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-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-99 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-93 clarification, what "part property" is 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-91 Port labels inside Port symbol SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-98 Problems with 1.3 Enumeration Literals SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-97 SysML: References to CreateEvent incorrect SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-90 Section 9.3.1.7 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-121 Clarification required for Copy relationship 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-109 Figure 15.8 diagram type SysML 1.3 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-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-111 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-104 Incorrect constraint [2] on InterfaceBlock SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-103 Missing type constraints for FullPort SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-102 Missing ownership constraints SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-107 VerdictKind SysML 1.4 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-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-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-125 Unclear is StructuredActivityNode owned Actions should be Allocated 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-122 Semantics of multiple Dependencies SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-120 Diagram show inconsistent data 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-114 Ports and Flows 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-117 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-116 Allocation tabular notation normative? SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-115 Figures 15.5 and 15.6 diagram types SysML 1.3 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-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-128 The SysML classification of properties is incomplete 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-137 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 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-135 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-134 Pull semantics for flow properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-144 Update to Trace Relationship’ 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-142 Update SysML references to UML model library StandardProfileL2 SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-147 classifierBehaviorProperty and adjunctProperty notation 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-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-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-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-150 [SysML] Semantic variation points 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-157 Table 12.1 has incorrect "int" typed arguments (4x) 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-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-238 Missing comment for some attributes 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-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-247 specializations of requirement should specialize AbstractRequirement 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
SYSML11-132 09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port SysML 1.0 SysML 1.1 Resolved closed
SYSML13-61 Invocations of required behavior features without going through ports SysML 1.2 SysML 1.3 Resolved closed
SYSML14-49 Metamodel error in 14447 and 18407 OCL 2.3.1 SysML 1.4 Resolved closed
SYSML11-131 Section: 11.3.2.2 ControlOperator UML 2.1.1 SysML 1.1 Resolved closed
SYSML11-108 Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp SysML 1.0 SysML 1.1 Closed; No Change closed
SYSML11-107 10.Constraint, Figure 10.3 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-106 Section: 8.3.2.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-86 10.3.2.2 ConstraintProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-85 10.3.2.2 ConstraintProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-87 10 Constraint Blocks, 10.3.2.1 ConstraintBlock SysML 1.0 SysML 1.1 Resolved closed
SYSML11-95 Annex B/B.4.1.2 Package Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-94 15.3.2.3 AllocateActivityPartition SysML 1.0 SysML 1.1 Resolved closed
SYSML11-92 11 Activities, Figure 11.10 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-91 11.Activities, Figure11.10 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-89 11.Activities/11.3.2.8 Rate/Figure 11.8 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-88 11 Activities, 11.2.1 Activity Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-93 11. Activities SysML 1.0 SysML 1.1 Resolved closed
SYSML11-96 Annex B, B.4.4.3 Requirement Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-90 11 Activities, Figure 11.10 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-130 Missing tags in XMI SysML 1.0 SysML 1.1 Resolved closed
SYSML11-129 The href should reference the URI for the UML elements SysML 1.0 SysML 1.1 Resolved closed
SYSML11-128 type should be cmof:Class not uml:Class SysML 1.0 SysML 1.1 Resolved closed
SYSML11-127 4.2: StandardProfileL2 uses elements not supported by SysML SysML 1.0 SysML 1.1 Resolved closed
SYSML11-126 Section: 08 Blocks, Annex B, Annex C SysML 1.0 SysML 1.1 Resolved closed
SYSML11-109 Section: 08 Blocks: suggest need Quantity stereotype and definition SysML 1.0 SysML 1.1 Resolved closed
SYSML11-122 08. Blocks: The 'values' compartment for a part Property in an IBD SysML 1.0 SysML 1.1 Resolved closed
SYSML11-121 08.Blocks: compartment for property-specific defaultValue should be renamed SysML 1.0 SysML 1.1 Resolved closed
SYSML11-120 08.Blocks, 8.2.2 Internal Block Diagram: SysML 1.0 SysML 1.1 Resolved closed
SYSML11-119 SysML needs instance specs SysML 1.0 SysML 1.1 Resolved closed
SYSML11-111 Section: annex A.1, Activities SysML 1.0 SysML 1.1 Resolved closed
SYSML11-110 Section: Chapter 7: Viewpoint SysML 1.0 SysML 1.1 Resolved closed
SYSML11-105 Section: 9.3.2 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-104 Annex B, Figure B.18, Figure B.19 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-98 Annex B / B.4.8.3 Activity Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-97 Annex B / B.4.5.4 Block Definition Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-103 Annex / Figure B.37 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-102 Annex B / Figure B36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-101 Annex B / Figure B.36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-100 Annex B / Figure B36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-99 Annex B / Figure B.36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-125 NestedConnectorEnd multiplicity typo in Fig 8.5 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-124 p.46 under 8.3.2.4 DistributedProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-123 DistributedProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-118 SysML unnecessarily restricts aggregation of datatypes SysML 1.0 SysML 1.1 Resolved closed
SYSML11-117 Section: More constraints for flow ports SysML 1.0 SysML 1.1 Resolved closed
SYSML11-116 Section: 8.3.2.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-113 Icons for FlowPort SysML 1.0 SysML 1.1 Resolved closed
SYSML11-112 Section: Chapter 2: UML version SysML 1.0 SysML 1.1 Resolved closed
SYSML11-115 moe should be removed from section 7.4 or added to the standard SysML 1.0 SysML 1.1 Resolved closed
SYSML11-114 remove homemade stereotypes SysML 1.0 SysML 1.1 Resolved closed
SYSML11-84 08 Blocks, 8.3.2.9 Unit, 8.3.2.10 ValueType SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-83 8.3.1.2 Internal Block Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-48 Requirements are abstract SysML 1.0 SysML 1.1 Resolved closed
SYSML11-47 Question on PropertySpecificType SysML 1.0 SysML 1.1 Resolved closed
SYSML11-51 Association branching is not defined in UML SysML 1.0 SysML 1.1 Resolved closed
SYSML11-50 Uppercase/lowercase problems SysML 1.0 SysML 1.1 Resolved closed
SYSML11-45 Section: Annex A: Diagrams SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-44 Section: 16 Requirements SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-46 Section: 8.3.2 Unit/Dimension Notation SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-53 Mixed action and activity concepts SysML 1.0 SysML 1.1 Resolved closed
SYSML11-52 Constraint parameter notation conflicts with UML private ports notation SysML 1.0 SysML 1.1 Resolved closed
SYSML11-43 Section: 8.3.2.8 ValueType SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-42 Section: 16 Requirements SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-49 <> is displayed as dependency (in examples) SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-55 View as Package extension is very bad idea SysML 1.0 SysML 1.1 Resolved closed
SYSML11-41 Section: 11.3.1.1 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-63 Section: 8/3 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-62 SysML specification for containment relationship SysML 1.0 SysML 1.1 Resolved closed
SYSML11-61 SysML dimensions SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-60 SysML -- Fix for Fig 9.4 p70. SysML 1.0 SysML 1.1 Resolved closed
SYSML11-66 SysML:Ports can't be blocks SysML 1.0 SysML 1.1 Resolved closed
SYSML11-65 Section: Appendix E SysML 1.0 SysML 1.1 Resolved closed
SYSML11-56 Wrong ends of Allocate relationship used in Allocated definition SysML 1.0 SysML 1.1 Resolved closed
SYSML11-64 Address potential points of convergence between MARTE and SysML SysML 1.0 SysML 1.1 Resolved closed
SYSML11-59 8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-58 optional parameter section SysML 1.0 SysML 1.1 Resolved closed
SYSML11-57 PropertySpecificType concept is highly ineffective and suboptimal SysML 1.0 SysML 1.1 Resolved closed
SYSML11-67 Section: 5.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-69 Section: 9.4 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-68 SysML Interactions SysML 1.0 SysML 1.1 Resolved closed
SYSML11-9 SysML: Interfaces on Flow Ports SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-8 SysML: Use Cases SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-7 Section: Requirements - Figure 16.1 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-6 Section: Ports and Flows - Behavioral flow ports SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-5 Section: Blocks - BOM properties SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-4 Section 16.3.1.1 SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-3 constraints section 9.3.2.4 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-12 SysML:Architecture SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-11 SysML: << and >> vs < and > SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-1 Page 16 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-2 Section 16.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-10 SysML: Missing arrow on figure 16.8 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-40 Section: Chapter 7-17 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-39 Namespace compartment for blocks SysML 1.0 SysML 1.1 Resolved closed
SYSML11-37 Section: Appendix B SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-36 SysML doesn't explicitly support the modeling of alternative models SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-34 15.2.1Representing Allocation on Diagrams SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-33 7.1 Overview SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-31 Figure 17.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-30 Section: figure 17.6 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-28 Section: 17.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-27 Section: 11 Activities SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-29 Section: Annex A SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-32 Constraint parameter stereotype SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-35 Section 16.3.2.3 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-38 Section: 11.3.2.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-25 Chapter 8, Blocks, instance specifications for default values SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-24 Section: 6.1 Levels of Formalism SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-17 Section: 16.3.2.4 RequirementRelated (from Requirements) SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-16 Section: 9.3.2.8 ItemFlow SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-15 Semantic of default value in the scope of a DistributedProperty SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-21 Section: 7.3.2.5 Viewpoint SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-20 Section: Annex G SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-23 Section: 9, 16, C SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-22 SysML: nout-->inout SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-14 constraints on viewpoint, 7.3.2.5 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-13 Table 14.1 Use Case Diagram SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-18 How to use property specific types for atomic flow ports? SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-19 Section: Appendix B.4.5 SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-26 Section: 11 Actibities SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-82 8 Blocks, 8.3.1.2 Internal Block Diagram, 8.3.2.2 Block SysML 1.0 SysML 1.1 Resolved closed
SYSML11-81 Allocation Callout to Item Flow is Ambiguous SysML 1.0 SysML 1.1 Closed; No Change closed
SYSML11-77 Section: 8.3.1.2 Internal Block Diagram Extensions SysML 1.0 SysML 1.1 Resolved closed
SYSML11-73 Section: 8.3.2.2 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-72 Section: 11.4 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-70 Section: 9.3.2. SysML 1.0 SysML 1.1 Resolved closed
SYSML11-71 Section: 16.3.2.7 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-79 Chapter Blocks/Section 8.3.2.6 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-78 Stakeholder and Concern SysML 1.0 SysML 1.1 Closed; No Change closed
SYSML11-76 Section 7.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-75 Rate stereotype attribute SysML 1.0 SysML 1.1 Resolved closed
SYSML11-74 Section: 16.2.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-80 Section: 9.3.2 SysML 1.0 SysML 1.1 Resolved closed
SYSML14-46 Expanded Usage Examples for Viewpoints SysML 1.3 SysML 1.4 Resolved closed
SYSML14-45 Concern Relation Limitations SysML 1.3 SysML 1.4 Resolved closed
SYSML14-43 SysML DI SysML 1.3 SysML 1.4 Resolved closed
SYSML14-42 Any notation available for internal parts should apply to ports SysML 1.3 SysML 1.4 Resolved closed
SYSML14-48 Deprecated Elements update for Views and U&QK SysML 1.3 SysML 1.4 Resolved closed
SYSML14-47 Align initial clauses with UML 2.5 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-44 Annex A corrections SysML 1.3 SysML 1.4 Resolved closed
SYSML13-54 Owning block terminology SysML 1.2 SysML 1.3 Resolved closed
SYSML13-34 Internal and external connectors undefined SysML 1.2 SysML 1.3 Resolved closed
SYSML13-33 onNestedPort should enable sending directly to target SysML 1.2 SysML 1.3 Resolved closed
SYSML13-46 Binding connectors may not have constraint parameters on any end SysML 1.2 SysML 1.3 Resolved closed
SYSML13-45 Full ports should not be conjugated SysML 1.2 SysML 1.3 Resolved closed
SYSML13-49 Association decomposition in diagram element tables SysML 1.2 SysML 1.3 Resolved closed
SYSML13-48 Item flow property values SysML 1.2 SysML 1.3 Resolved closed
SYSML13-31 Sample problem using deprecated conjugated port notation SysML 1.2 SysML 1.3 Resolved closed
SYSML13-30 Ownership of item flow properties SysML 1.2 SysML 1.3 Resolved closed
SYSML13-35 Owning block undefined SysML 1.2 SysML 1.3 Resolved closed
SYSML13-29 Clarifications to flow port resolution SysML 1.2 SysML 1.3 Resolved closed
SYSML13-28 Connectors should not link ports in block definition diagram elements SysML 1.2 SysML 1.3 Resolved closed
SYSML13-44 Internal fanout from proxy ports should be clarified SysML 1.2 SysML 1.3 Resolved closed
SYSML13-43 Proxy ports should not have connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-39 InvocationOnNestedPortAction and TriggerOnNestedPort notation not extended SysML 1.2 SysML 1.3 Resolved closed
SYSML13-38 Ports that have behavior ports should be behavioral SysML 1.2 SysML 1.3 Resolved closed
SYSML13-32 Provided / required operations & receptions SysML 1.2 SysML 1.3 Resolved closed
SYSML12-16 Merge UML DataType into SysML ValueType SysML 1.1 SysML 1.2 Resolved closed
SYSML12-15 Lack of Structured Activity Node and other Activity features Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-10 SysML/Modelica Integration Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-9 Port Decomposition of a Flow Specification Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-8 Section: 11.3.2 Inability to name interruptible activity regions SysML 1.1 SysML 1.2 Resolved closed
SYSML12-7 Section: 4.2, 11.2.1 SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-13 Parametrics and Depletable Stores SysML 1.1 SysML 1.2 Resolved closed
SYSML12-12 SysML synchronization with UML/XMI version updates Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-14 Use cases in SysML are more similar to Requiremetns than Behavioral diagrams SysML 1.1 SysML 1.2 Resolved closed
SYSML12-5 Section: 9.3.2.4 Constraint about "in" flow properties SysML 1.1 SysML 1.2 Resolved closed
SYSML12-4 More than one constraint block of the same type in a parametric diagram SysML 1.1 SysML 1.2 Resolved closed
SYSML12-6 Section: 11.3.1.1, 11.3.1.4, 11.4 SysML 1.1 SysML 1.2 Resolved closed
SYSML12-11 Ambigous line crossings SysML 1.1 SysML 1.2 Resolved closed
SYSML12-17 "trigger[guard]\activity" should be "trigger[guard]/activity" SysML 1.1 SysML 1.2 Resolved closed
SYSML13-13 Appendix F out of date SysML 1.2 SysML 1.3 Resolved closed
SYSML13-5 SysML 1.2 Issues: Definition of Overwrite SysML 1.2 SysML 1.3 Resolved closed
SYSML13-4 SysML 1.2 Issues: Activity's sub-activities should be able to have mandatory multiplicity SysML 1.2 SysML 1.3 Resolved closed
SYSML13-11 SysML Issue based on UML 15370 -- Package has optional URI SysML 1.2 SysML 1.3 Resolved closed
SYSML13-10 SysML Issue based on UML 14062 -- Stereotypes/keywords and upper/lowercase SysML 1.2 SysML 1.3 Resolved closed
SYSML13-9 SysML 1.2 - Blocks SysML 1.2 SysML 1.3 Resolved closed
SYSML13-20 Test Context appears in XMI but not in Profile Spec SysML 1.2 SysML 1.3 Resolved closed
SYSML13-19 Clarification when Allocated Stereotype is applied SysML 1.2 SysML 1.3 Resolved closed
SYSML13-37 Flow property semantics only defined for external connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-36 Block shown as metaclass SysML 1.2 SysML 1.3 Resolved closed
SYSML13-3 SysML 1.2 Issues: Structure compartment wrong in spec SysML 1.2 SysML 1.3 Resolved closed
SYSML13-2 SysML 1.2 Section 16.4.4 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-1 properties allocatedFrom and allocatedTo should be capitalized SysML 1.2 SysML 1.3 Resolved closed
SYSML13-8 Structure Compartment shows blocks instead of parts SysML 1.2 SysML 1.3 Resolved closed
SYSML13-7 SysML 1.2, ch 12 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-6 SysML 1.2 Issues: Missing constraint on Rationals SysML 1.2 SysML 1.3 Resolved closed
SYSML12-40 Including Behavior Port Notation SysML 1.1 SysML 1.2 Resolved closed
SYSML12-39 Streamlined notation for representing system variance SysML 1.1 SysML 1.2 Resolved closed
SYSML12-38 Ambiguous Block Hierarchy SysML 1.1 SysML 1.2 Resolved closed
SYSML12-37 Non-atomic flow ports use property type incorrectly SysML 1.1 SysML 1.2 Resolved closed
SYSML12-35 Wrong type in fig. 15.11 SysML 1.1 SysML 1.2 Resolved closed
SYSML12-34 Ports use property type incorrectly SysML 1.1 SysML 1.2 Resolved closed
SYSML12-43 Constraining a decomposition hierarchy SysML 1.1 SysML 1.2 Resolved closed
SYSML12-36 15.3.2.2 Allocated(from Allocations) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-42 Extending Ports to Support Non-flow Properties SysML 1.1 SysML 1.2 Resolved closed
SYSML12-33 Overly restrictive statement regarding ports in blocks chapter SysML 1.1 SysML 1.2 Resolved closed
SYSML12-41 Including Property Notation for Redefinition and Subsetting SysML 1.1 SysML 1.2 Resolved closed
SYSML12-44 Typing Flow Properties and Item Properties as Enumerations SysML 1.1 SysML 1.2 Resolved closed
SYSML13-53 Broadcasting along connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-52 Events for property value changes SysML 1.2 SysML 1.3 Resolved closed
SYSML13-56 InvocationOnNestedPortAction and TriggerOnNestedPort SysML 1.2 SysML 1.3 Resolved closed
SYSML13-55 Provided and required feature abbreviations SysML 1.2 SysML 1.3 Resolved closed
SYSML13-50 Proxy port owning block definition should refer to internal structure SysML 1.2 SysML 1.3 Resolved closed
SYSML13-47 Clarify open and closed meaning of port types vs other property types SysML 1.2 SysML 1.3 Resolved closed
SYSML13-51 Contextualized item flows SysML 1.2 SysML 1.3 Resolved closed
SYSML13-58 Rate does not support the examples SysML 1.2 SysML 1.3 Resolved closed
SYSML13-57 Improvements to QUDV for SysML v1.3 SysML 1.2 SysML 1.3 Resolved closed
SYSML12-3 use of derived in Requirements SysML 1.1 SysML 1.2 Resolved closed
SYSML12-2 11.4 Activity Usage Sample: ControlOperator has regular pins SysML 1.1 SysML 1.2 Resolved closed
SYSML12-1 Section: 11.3.1.1 Activity in bdd SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML13-42 Flow properties on blocks typing internal parts SysML 1.2 SysML 1.3 Resolved closed
SYSML13-18 Claify partWithPort vs. NestedConnectorEnd SysML 1.2 SysML 1.3 Resolved closed
SYSML13-41 Non-behavioral ports on behavioral ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-40 TriggerOnNestedPort refers to onPort instead of port SysML 1.2 SysML 1.3 Resolved closed
SYSML13-26 Flow property compatibility rules should not be dependent on item flow SysML 1.2 SysML 1.3 Resolved closed
SYSML13-25 Clarify that item flow decomposition examples are not methodology SysML 1.2 SysML 1.3 Resolved closed
SYSML13-17 NestedConnectorEnd propertyPath should be non-unique SysML 1.2 SysML 1.3 Resolved closed
SYSML13-16 partWithPort change from UML needs to be clearly stated SysML 1.2 SysML 1.3 Resolved closed
SYSML13-23 Missing cross references in Deprecated Elements Annex SysML 1.2 SysML 1.3 Resolved closed
SYSML13-22 Deprecated elements package SysML 1.2 SysML 1.3 Resolved closed
SYSML13-15 NestedConnectorEnd constraints SysML 1.2 SysML 1.3 Resolved closed
SYSML13-14 NestedConnectorEnd constraints refer to metaclass SysML 1.2 SysML 1.3 Resolved closed
SYSML13-24 Water association decomposition example should be in ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-27 Remove colons from item flow classifiers in decomposition examples SysML 1.2 SysML 1.3 Resolved closed
SYSML13-21 typo in diagram C. 15 SysML 1.2 SysML 1.3 Resolved closed
SYSML12-24 Notation for multiple item flows SysML 1.1 SysML 1.2 Resolved closed
SYSML12-23 Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct SysML 1.1 SysML 1.2 Resolved closed
SYSML12-25 Example figures in chapters are redundant with Annex B sample problem SysML 1.1 SysML 1.2 Resolved closed
SYSML12-29 SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-28 SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A SysML 1.1 SysML 1.2 Resolved closed
SYSML12-22 Using composite association between activities SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-21 Chapter 7.3.1.1 Update comment stereotype diagram extension SysML 1.1 SysML 1.2 Resolved closed
SYSML12-32 SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-31 UML4SysML: Architecture & Compliance with UML subset SysML 1.1 SysML 1.2 Resolved closed
SYSML12-19 Participant Property constraint #6 not correct. SysML 1.1 SysML 1.2 Resolved closed
SYSML12-18 Fig. 11.10: Pin of ControlOperator SysML 1.1 SysML 1.2 Duplicate or Merged closed
SYSML12-27 Representing multiple item flows on the same connector SysML 1.1 SysML 1.2 Duplicate or Merged closed
SYSML12-26 The information in Annex D regarding AP233 needs to be updated SysML 1.1 SysML 1.2 Resolved closed
SYSML12-20 Connector Property value text. SysML 1.1 SysML 1.2 Resolved closed
SYSML12-30 SysML Issues based on UML 13080 New proposal for conjugate types for port SysML 1.1 SysML 1.2 Resolved closed
SYSML14-22 SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit SysML 1.3 SysML 1.4 Resolved closed
SYSML14-21 N-ary Allocation needs better definition, or deletion SysML 1.3 SysML 1.4 Resolved closed
SYSML14-10 9.3.2.8 FullPort SysML 1.3 SysML 1.4 Resolved closed
SYSML14-9 9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-20 ControlOperator stereotype should also extend the CallBehaviorAction metaclass SysML 1.3 SysML 1.4 Resolved closed
SYSML14-19 Requirements should be disallowed from typing other elements SysML 1.3 SysML 1.4 Resolved closed
SYSML14-16 SysML Issue Lower bounds on multiplicity not consistent with diagram SysML 1.3 SysML 1.4 Resolved closed
SYSML14-18 SysML Issue: State Machine Notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-17 SysML Issue: SysML Issue: Activitiy Switched on diagrams SysML 1.3 SysML 1.4 Resolved closed
SYSML14-15 Wrong compartment names SysML 1.3 SysML 1.4 Resolved closed
SYSML14-14 Full ports compartment SysML 1.3 SysML 1.4 Resolved closed
SYSML14-23 Conjugation of full ports question SysML 1.3 SysML 1.4 Resolved closed
SYSML14-13 Figure 9.8 - can roles be ports?? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-12 Figure 9.7 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-11 9.3.2.10 InvocationOnNestedPortAction SysML 1.3 SysML 1.4 Resolved closed
SYSML14-4 Part 1 of the specification SysML 1.3 SysML 1.4 Resolved closed
SYSML14-3 Issues with XMI for SysML 1.3 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-1 Constraint Blocks cannot have parameters SysML 1.3 SysML 1.4 Resolved closed
SYSML14-2 Addition of derived property notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-8 ports with flow properties are displayed the same as flow ports in SysML 1.1? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-7 9.1 InterfaceBlock - unnamed compartment SysML 1.3 SysML 1.4 Resolved closed
SYSML14-6 Table 9.1 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-5 Section 9.3.1.6 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-36 QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit SysML 1.3 SysML 1.4 Resolved closed
SYSML14-35 View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g)) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-34 SysML ISO-80000-1 libraries need update per 18269, 18435 and 18681 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-33 Navigation through non-properties SysML 1.3 SysML 1.4 Resolved closed
SYSML14-32 SysML: Unts and QualityKind SysML 1.3 SysML 1.4 Resolved closed
SYSML14-31 QUDV's support for measurement scales is impractical SysML 1.3 SysML 1.4 Resolved closed
SYSML14-30 View and Viewpoint Property Limitations (from Issue 18391 a) and f)) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-41 Wrong quantityKind for unit radian SysML 1.3 SysML 1.4 Resolved closed
SYSML14-40 Signal flow property description (§9.3.2.7) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-39 notation for inherited features SysML 1.3 SysML 1.4 Resolved closed
SYSML14-38 Addign a Behavior Compartment for Blocks SysML 1.3 SysML 1.4 Resolved closed
SYSML14-37 Missing/wrong elements in diagram table (InformationFlows) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-25 QUDV Unit/QuantityKind name redundancy SysML 1.3 SysML 1.4 Resolved closed
SYSML14-24 propertyPath property should be defined once and reused SysML 1.3 SysML 1.4 Resolved closed
SYSML14-27 9.3.2.4 direction of ports and their notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-26 Use of "inherited method" in section 9.3.2.4 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-29 Refine relationship contextualization SysML 1.3 SysML 1.4 Resolved closed
SYSML14-28 Activity model library package SysML 1.3 SysML 1.4 Resolved closed
SYSML13-60 sentence introduced in §9.1 by the resolution to issue #16280 is confusing SysML 1.2 SysML 1.3 Resolved closed
SYSML13-59 Wrong multiplicity for Requirement in stereotype description SysML 1.2 SysML 1.3 Resolved closed

Issues Descriptions

ConnectorProperty notation in wrong section.

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The diagram extension in the second paragraph of 8.3.2.6 (ConnectorProperty), should be in 8.3.1.2 (Internal Block Diagram).

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:47 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Diagram formality confusion

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    Annex A "Diagrams", whilst /informative/, sets out a confusing definition of the diagram types.

    On the one hand, there are nine SysML diagram types that have "model elements and corresponding concrete syntax", with each diagram kind cross referenced to the specific clause defining a specific part of the SysML modelling language. So for example an activity diagram "represents" (by virtue of the appropriate nodes and paths) the model elements and connectors described in the Activities clause (clause 11).

    On the other hand, there is the weaselly statement "Although the [diagram]taxonomy provides a logical organization for the various major kinds of diagrams, it does not preclude the careful mixing of different kinds of diagram types". A similar remark can be found in UML 2.5 in the form of a note in it's Annex A "Diagrams" section:
    "NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioural elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced."

    So, despite Annex A being informative, it creates at least two possible interpretations for tools to implement:
    1. A diagram can present representations of any model element and connector, or
    2. Only the specific model elements associated directly with a diagram kind (according to Annex A) can be represented on a diagram with a specific kind.

    Case 1 would allow all manner of diagrammatic mixing of model elements from the different semantic clauses, even when these clauses do not allow for any logical connection. However, it might allow an activity diagram to show a «Block» with an owned activity model. It would also allow a use case diagram to include a «Block» connected with a communications path to a use case node (since neither the use case or block clauses seem to set out a constraint to prevent this in the model).

    Case 2 would only allow the model elements from the directly associated clause along with the model elements that are common to all diagrams. This is a strict implementation, but may have consequences where more flexibility would have been desired. For example a modeller using Blocks, or user stereotyped classes, for stakeholder modelling would find that they cannot use these model elements directly on a use case diagram where only use case and actor model element types can be represented.

    The standard should also consider the practicalities of modelling tool design and usability considerations. Case 1 would imply just one diagram implementation and a large model element library (or tool bar) for the user to work with (in a model creation through the diagram paradigm). Whereas, case 2 requires distinct implementation of the diagram kinds along with their implied constraints of which model elements can be added to them, although it does mean that the model element library (or tool bar) is quite specific to each diagram kind.

    Without standardising what each diagram kind can contain, there will be no possibility of model interchange that includes the diagrams.

    On a final note, the explicit exclusion of the Profile diagram from UML seems strange because defining and working with Stereotypes is a common (albeit advanced) modelling concept in MBSE, but to do it requires specific modelling concepts (and their associated nodes and paths). Hence, the current suggestion that this is done with package diagram would seem to suggest that the aforementioned diagram case 1 was being implied.

    Suggested change (with a strict diagram syntax leaning):
    1. Make Annex A normative and remove the diagram mixing statement: "it does not preclude mixing different kinds of diagram types"
    2. Review each of the modelling clauses 8 through to 16 to check that they completely define the set of model elements and connectors that are useful to make available to modellers on the associated diagram kind. That is make explicit what is otherwise inferred by the lack of a constraint. E.g. that use case model elements can (or cannot) be connected to Blocks (or other forms of stereotyped classes) with a communication path connector.
    3. Add the UML Profile diagram to the list of SysML diagrams.

  • Reported: SysML 1.4 — Mon, 27 Feb 2017 12:56 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Causality of constraints in parametric diagrams

  • Status: closed  
  • Source: Kenntnis ( Richard Welling)
  • Summary:

    Having occasion to review all outstanding constraint block issues, I have read more closely the overview and find that the last paragraph on page 97 of the SysML 1.4 specification has significant problems. It also is the only mention in the SysML spec of constraint causality. This proposal is an attempt to clarify that paragraph while addressing concerns about constraint causality, affecting SYSMLR-99, SYSMLR-47, and SYSMLR-38. This is the paragraph as written:

    SysML identifies and names constraint blocks, but does not specify a computer interpretable language for them. The interpretation of a given constraint block (e.g., a mathematical relation between its parameter values) must be provided. An expression may rely on other mathematical description languages both to capture the detailed specification of mathematical or logical relations, and to provide a computational engine for these relations. In addition, 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.

    • The first sentence is not describing constraint blocks but rather a language for constraint expressions.
    • The second sentence again says, “block” when it is clearly referring to expressions, but then, says an “interpretation…must be provided.” By whom? Presumably by the tool provider but that's not clear.
    • The third sentence seems to say “An expression may rely on other mathematical description languages…to provide a computational engine for these relations.” It is clearly not the language that provides the computational engine but the tool implementing the language.
    • The treatment of causality is puzzling. Why was non-causality specified when causality is always at least implicit? In the F = m*a example, F is implicitly the dependent variable while a = F/m would indicate a as dependent. If the intent was to make causality non-mandatory to simplify the modeler’s task, then one could say parameters are assumed to be non-causal unless specified explicitly as such.
    • Michael Chonoles proposal (SYSMLR-47) to interpret parameters bound to derived values as dependent (output) and those bound to read-only values as independent (input) is not only useful but it should be noted that MagicDraw notates derived properties in recursive parametric diagram patterns and these clearly represent dependent variables. This is standard UML notation.

    Replace the above paragraph with the following:

    Constraint expressions may rely on any suitable mathematical description language to capture the detailed specification of mathematical or logical relations between parameters. The syntax and interpretation of the language and its associated computational engine are a tool responsibility. By default, constraints are assumed to be non-causal and do not necessarily specify dependent or independent variables, in which case specific dependent and independent variables may be defined by initial conditions and determined by the computational engine. Alternatively, dependent and independent variables (constraint parameters) may be expressed by designating their bound values as, respectively, derived ("/" prefix) or {read-only}.

    Move this paragraph to be the fourth paragraph on page 97, after paragraph starting with "Parametric diagrams include..." and before the paragraph starting with "Time can be modeled..." This places it in a logical flow that follows discussions of constraint blocks, constraints, and bindings.

  • Reported: SysML 1.4 — Sun, 22 Nov 2015 00:40 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML XMI typos in UML StandardProfile XMI references

  • Status: closed  
  • Source: NIST ( Mr. 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: Resolved — SysML 1.7
  • Disposition Summary:

    To be fixed

    To fix the XMI as requested

  • Updated: Thu, 22 Dec 2022 13:45 GMT

No support for dot notation in activity and sequence diagrams

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Add signal to constraint [1] for DistributedProperty

  • Status: closed  
  • Source: Bombardier Transportation ( Karsten Koechlin)
  • Summary:

    At the moment the stereotype distrubtedProperty is only allowed to be applied to properties of classifier stereotyped by Block or ValueType.
    We would like to apply the distributedProperty stereotype also to properties of classifier stereotyped by Signal.
    Reason: The properties of a block are transmitted by signal properties, the properties of the signal should also reflect the distribution.

  • Reported: SysML 1.5 — Mon, 22 Jan 2018 12:43 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do.

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    An inconsistency has been noted among requirement dependencies. «copy» and «deriveReqt» are the only requirement dependencies that do NOT have an operation to 'get' the supplier end («refine», «satisfy», «verify») or the client end («trace») of the dependency. The reason for this inconsistency is not clear.

  • Reported: SysML 1.4 — Thu, 24 Mar 2016 16:30 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Clarification of typing a binding connector


Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Some DirectedRelationshipPropertyPath constraint definitions assume that the relationship on which this stereotype is applied is binary but there is no formal constraint enforcing it.

  • Reported: SysML 1.5 — Thu, 10 Aug 2017 12:27 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Replace all occurrences of "has been" by "is"

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In several places of the SysML specification document the term "has been" is used. It should be replaced by "is".

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 07:44 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Add Graphical notation for General Classifier

  • Status: closed  
  • Source: Sierra Nevada ( Mr. Chas Galey)
  • Summary:

    The usage of Generalization in SysML is a key part of establishing Domain Specific Languages and contexts for models. In particular it has great ability to establish reusability within our models. However, the only mechanism via which we can visually denote the nature of an object is via non-normative extensions to M2 via stereotypes such as <<Car>> or other examples. This is undesirable, we should have the ability (on classes and parts typed by those classes) to optionally display the General (or any General class of a Block) classifier of a Block on BDD's, IBD's and Parametric diagrams. This will, greatly enhance the readability of our diagrams, remove the complexity of implementing M2 stereotypes simply designed for visualization, and expose via the diagram usage of reusable libraries to make the foundation of our models.

    Example Format might be (in ASCII art):

    ------------
    <<Block>>
    [Car]
    Porsche
    --------------

  • Reported: SysML 1.5 — Fri, 20 Oct 2017 05:22 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Diagram header is not intuitively interpreted

  • Status: closed  
  • Source: INCOSE / SSI ( Troy Peterson)
  • Summary:

    The SysML diagram header is not easily interpreted. Suggest a new format that provides the same information and content but following the typical naming convention used in SysML - i.e. name:Type

    Suggestion/Example:

    From:
    req [Package] Auto_Specification [Automobile System Requirements]

    To:
    Automobile System Requirements:req | Auto_Specification:Package

    Optional format adds "[req]" as an option to turn on to in bold or white text on a black background filling the header box around the diagram kind "req" in this case. Image examples provided to Rick Steiner and Sandy Friedenthal in separate communications.

    [req] Automobile System Requirements:req | Auto_Specification:Package

  • Reported: SysML 1.5 — Thu, 13 Sep 2018 04:34 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Do not move deprecated elements

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    Between SysML 1.2 and SysML 1.3, some stereotypes were deprecated
    This deprecation was done by moving Stereotypes from their original package to a new "DeprecatedElements" package.

    Changing the qualified names of these stereotypes may break some code in tooling. Ideally the deprecation should be indicated without changing the element.

    SysML 1.3 : http://www.omg.org/spec/SysML/20120401/SysML.xmi
    SysML 1.2 :http://www.omg.org/spec/SysML/20100301/SysML-profile.uml

  • Reported: SysML 1.5 — Mon, 11 Sep 2017 15:08 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    No change

    That's not an issue about the specification but about the way of working. Request registred and agreed

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inappropriate character for multiplying symbol with combined units

  • Status: closed  
  • Source: Schindler Aufzüge AG ( Markus WALKER)
  • Summary:

    Some of the combined units use a period character instead of a multiply symbol. An example is the unit ‹newton metre› where the symbol is ‹N.m›. In contrary, other units make use of the middle dot character, e.g., ‹kilogram metre squared per second›, using the symbol ‹kg · m 2/s›.

    The SI Guide prescribes to use a middle dot or a thin space or if not ambiguous no character to combine different units that are multiplied.

  • Reported: SysML 1.5 — Fri, 22 Feb 2019 16:04 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Hidden constraints in description of PropertySpecificType

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of the PropertySpecificType states:

    The PropertySpecificType stereotype can be applied to classifiers that type exactly one property and that are owned by the owner of that property. Classifiers with this stereotype applied shall be generalized by at most one
    other classifier.

    The constraint section covers only "can be applied to classifiers that type exactly one property". The other constraints

    "that are owned by the owner of that property."
    and
    "Classifiers with this stereotype applied shall be generalized by at most one
    other classifier."

    are missing.

  • Reported: SysML 1.6 — Sun, 17 Mar 2019 10:25 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Excluded UML metaclasses are not formally defined

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 4.1. excludes several UML metaclasses from SysML. However, figure 4.2 shows that the SysML profile imports the whole UML. Instead, the SysML profile should use the metamodelReference and metaclassReference properties to import only the included elements.

  • Reported: SysML 1.5 — Fri, 9 Feb 2018 12:54 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    While it is not possible to check if a value conforms to, for example, uniform or mean distribution, it is possible to check, if it conforms to constraints of the specified distribution. For example, the minimum and maximum values of a uniform distribution.

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 17:14 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML 1.6 should be based on UML 2.5.1

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    SysML should be based on the newest available UML specification. Current UML specification is version 2.5.1. SysML 1.5. is still based on UML 2.5.

  • Reported: SysML 1.5 — Fri, 23 Feb 2018 14:29 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fix it

    Agreed, to take care about it for SysML 1.7

  • Updated: Thu, 22 Dec 2022 13:45 GMT

FullPort type

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Split from SYSML16-86:

    What is the type of FullPort? Spec says nothing

  • Reported: SysML 1.5 — Thu, 16 Mar 2017 07:42 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Typos/editorials found in the SysML 1.6 specification document

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    This issue is dedicated to collect all typos and editorials we find in the SysML1.6 specification document. See linked annotated PDF for the list.

    -------------------------------------------------------------------------------------------------------
    >>> Note to RTF Chairs: do not schedule this issue for voting before the last ballot of the RTF; until then we update the list in the issue description if we find new typos <<<
    -------------------------------------------------------------------------------------------------------

  • Reported: SysML 1.6 — Tue, 10 Dec 2019 17:40 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Fixed typos/editorials in SysML 1.6

    This resolution fixes all typos summarized in the issue.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Precise Semantics for SysML


DistributedProperty should be abstract

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The DistributedProperty itself does not make sense. As specified in the specification specific distributions should be defined as subclasses of the DistributedProperty stereotype. Therefore, the stereotype should be abstract.

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 17:05 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

DistributedProperty should be abstract

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The DistributedProperty stereotype should be abstract since it needs to be specialized in order to be usable.

  • Reported: SysML 1.5 — Mon, 7 May 2018 12:45 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    duplicate

    Duplicate by SYSML17-170

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Key: SYSML17-99
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Pull semantics for flow properties

  • Legacy Issue Number: 18876
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    To be addressed by SysML v2

    This kind of topic shall now be deferred to SysMLv2

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Clarification required for Copy relationship

  • Key: SYSML17-95
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

primitive types in SysML Activities

  • Key: SYSML17-97
  • Legacy Issue Number: 18659
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics

  • Legacy Issue Number: 19328
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Abstract syntax for the initial values

  • Legacy Issue Number: 19286
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property?

  • Legacy Issue Number: 19859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section E.4 (non-normative) defines the objectiveFunction stereotype to describe objective functions for use in trade studies. However, whereas Table E.5 defines the objectiveFunction stereotype to extend (or rather generalize) ConstraintBlock, this seems to be inconsistent with the parametric diagram on the same page where the objectiveFunction stereotype is (seems to be [*]) applied to the a constraintProperty instead.
    Given the fact that constraintProperty is only 'loosely' defined in the spec (i.e. it is not part of the xmi file), the only viable alternative seems to be that objectivefunction extends uml::Property and adds the necessary constraints in order to warrant the fact that the type of the uml::Property is (stereotyped by) a ConstraintBlock...

    Please clarify the definition of the objectiveFunction stereotype.

    [*] Since there is no formal notation defined for objectiveFunction, one can of course merely guess...

  • Reported: SysML 1.4 — Mon, 30 Nov 2015 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    To fix the XMI generator, as appropriate

  • Updated: Thu, 22 Dec 2022 13:45 GMT

classifierBehaviorProperty and adjunctProperty notation

  • Legacy Issue Number: 19326
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

[SysML] Semantic variation points

  • Legacy Issue Number: 19489
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Legacy Issue Number: 18877
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

URI for the SysML Profile given in section E.3 is wrong

  • Legacy Issue Number: 19321
  • Status: closed  
  • Source: PTC ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Semantics clarification for removing a value from an out Flow Property

  • Legacy Issue Number: 18953
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The specification should clarify the semantics for 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML says nothing about how to deal with multiplicity for flow properties matching

  • Legacy Issue Number: 18783
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The ISO-80000 library has numerous instances of the SysML::ValueType stereotype applied on data types. They are intended to specify the corresponding units and quantity kinds.

    According to SysML, both unit and quantityKind properties of the ValueType stereotype shall be InstanceSpecifications.

    However in http://www.omg.org/spec/SysML/20150709/ISO-80000 all of them refer to the data type the stereotype is applied to rather than to the expected instance specifications. This could result from a bug in the ID generation algorithm used for SysML 1.4

    Example

    <SysML.Blocks:ValueType xmi:id="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029.stereotypeApplication_SysML.package_packagedElement_Blocks.stereotype_packagedElement_ValueType">
        <base_DataType xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <quantityKind xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <unit xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/></SysML.Blocks:ValueType>
    
  • Reported: SysML 1.4 — Tue, 9 Aug 2016 13:05 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    To fix the xmi generator

    To fix the XMI generator, as appropriate

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Table 12.1 has incorrect "int" typed arguments (4x)

  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Can a SysML Full Port be typed by a ValueType?

  • Legacy Issue Number: 19412
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Definition of SysML stereotypes: association ends versus attributes

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some properties of the SysML stereotypes are defined by associations and others by simple properties. It should be consistent and clearly defined how to define the stereotype properties.

    For example, propertyPath of ElementPropertyPath is defined by an association. boundEnd of BoundReference is defined by a simple property.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:19 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Parts, references, values compartments in wrong section

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Parts, references, and values compartments are described in Subclause 8.3.2.3 (Block), but should with the diagram extensions for BDDs (Subclause 8.3.1.1) with the others.

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:52 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

specializations of requirement should specialize AbstractRequirement

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-72
  • Legacy Issue Number: 17210
  • Status: closed  
  • Source: Adaptive ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing ownership constraints

  • Key: SYSML17-80
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Content of Requirement::/tracedTo

  • Key: SYSML17-65
  • Legacy Issue Number: 16373
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing type constraints for FullPort

  • Key: SYSML17-81
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Description of Item Flows

  • Key: SYSML17-56
  • Legacy Issue Number: 15985
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Blocks cannot own items flows

  • Key: SYSML17-54
  • Legacy Issue Number: 15982
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML stereotype notation creates ambiguity about to which element is the stereotype applied

  • Key: SYSML17-83
  • Legacy Issue Number: 18268
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

9.3.2.4 direction of ports and their notation (second issue)

  • Key: SYSML17-88
  • Legacy Issue Number: 18441
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figures 15.5 and 15.6 diagram types

  • Key: SYSML17-89
  • Legacy Issue Number: 18459
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Semantics of multiple Dependencies

  • Key: SYSML17-96
  • Legacy Issue Number: 18623
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Allocated notation on object nodes missing from diagram elements table

  • Key: SYSML17-91
  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

9.3.2.4 direction of ports

  • Key: SYSML17-87
  • Legacy Issue Number: 18439
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

VerdictKind

  • Key: SYSML17-84
  • Legacy Issue Number: 18312
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Libraries package should be named "SysML Model Libraries"

  • Key: SYSML17-92
  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Item flows can have multiple types but item properties cannot

  • Key: SYSML17-58
  • Legacy Issue Number: 16042
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Update to Trace Relationship’

  • Legacy Issue Number: 19284
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

The SysML classification of properties is incomplete

  • Legacy Issue Number: 18709
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

proxy and full port notation change request

  • Legacy Issue Number: 18993
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Figure 15.8 diagram type

  • Key: SYSML17-85
  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Allocation tabular notation normative?

  • Key: SYSML17-90
  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

callout notation issues

  • Key: SYSML17-37
  • Legacy Issue Number: 14575
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Flow properties and activity paramters

  • Key: SYSML17-42
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Proposal to have a stereotype for reference nested property

  • Key: SYSML17-36
  • Legacy Issue Number: 14055
  • Status: closed  
  • Source: International Business Machines ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-44
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML 1.2 Issue Viewpoint referencing other viewpoints properties

  • Key: SYSML17-43
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Ability for a binding connector to be typed

  • Key: SYSML17-40
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Binding to multiplicity in parametrics

  • Key: SYSML17-38
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inheriting Allocations

  • Key: SYSML17-41
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Can Enumerations be used on parametric diagrams for typing constraint parameters

  • Key: SYSML17-64
  • Legacy Issue Number: 16304
  • Status: closed  
  • Source: MAHLE International GmbH ( 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Continuous flows in non-streaming situations with >1 multiplicities

  • Key: SYSML17-46
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML 1.2 Issues: Optional with streaming

  • Key: SYSML17-47
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Another issue with allocate

  • Key: SYSML17-53
  • Legacy Issue Number: 15884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML 1.2 Issues: DistributedProperties on Activates

  • Key: SYSML17-45
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML Issue on Multiplicity of Use Case Communication Associations

  • Key: SYSML17-51
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML Issue based on UML 15369

  • Key: SYSML17-49
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML Issue representation of properties as associations

  • Key: SYSML17-50
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure B.35 object nodes


Callout notation for port-specific types and initial values

  • Key: SYSML17-75
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Question about the Activity decomposition in Block Definition Diagrams

  • Key: SYSML17-69
  • Legacy Issue Number: 16945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Interface blocks and protocols

  • Key: SYSML17-79
  • Legacy Issue Number: 18169
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Timing diagrams

  • Key: SYSML17-5
  • Legacy Issue Number: 10642
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Allocations should not generate dependencies

  • Key: SYSML17-34
  • Legacy Issue Number: 13840
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Binding Relationships require unit conversions

  • Key: SYSML17-31
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-35
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

ItemFlows support on Activity & Interaction Diagrams


Diagram interchange

  • Key: SYSML17-14
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

AllocateActivityPartition and UML 2 semantics

  • Key: SYSML17-33
  • Legacy Issue Number: 13342
  • Status: closed  
  • Source: NIST ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inferred Allocation on Allocate Activity Partitions

  • Key: SYSML17-15
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

the use of <> is still unclear and inconsistent

  • Key: SYSML17-4
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-28
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-27
  • 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inconsistency between xmi and pdf for Trace and Refine specializations

  • Status: closed   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    While generating code for a custom sub-profile of SysML 1.4, we got some issues (as far as I can tell the same apply for SysML 1.5)
    You can see the discussion here https://bugs.eclipse.org/bugs/show_bug.cgi?id=530565

    After some internal discussions (thanks Patrick and Jérémie for your time), here are our conclusions:

    In the normative SysML 1.4 XMI Refines and Trace stereotype are implemented as follows :

    1. Refine
    ­ Specializes SysML::Blocks::DirectedRelationshipPropertyPath.
    ­ Extends UML::Abstraction.

    • This extension is a specialization of Abstraction_Refine extension.
    • This extension is a specialization of DirectedRelationship_DirectedRelationShipPropertyPath extension.
      2. Trace
      ­ Specializes SysML::Blocks::DirectedRelationshipPropertyPath.
      ­ Extends UML::Abstraction.
    • This extension is a specialization of Abstraction_Trace extension.
    • This extension is a specialization of DirectedRelationship_DirectedRelationShipPropertyPath extension.

    [Issue 1] The profile design is not aligned with the content of the normative PDF for [SysML 1.4]. Indeed, in this latter:
    1. Refine specializes StandardProfile::Refine and SysML::Blocks::DirectedRelationshipPropertyPath.
    2. Trace specializes StandardProfile::Trace and SysML::Blocks::DirectedRelationshipPropertyPath.
    However, to the best of our knowledge, there are no indications regarding the specializations of the existing extensions relationships.

    [Issue 2] The profile design is not conformant to [UML 2.5]. Indeed, both Refine and Trace have a base_Abstraction property redefining :
    1. SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship and StandardProfile::Refine::base_Abstraction (Refine case).
    2. SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship and StandardProfile::Trace::base_Abstraction (Trace case).
    However, according to [UML 2.5] a property cannot be redefined if it is not inherited (see constraint “redefined_property_inherited” in section 9.9.17.7 in [UML 2.5]). Hence, it is not allowed to specify that StandardProfile::Refine::base_Abstraction or StandardProfile::Trace::base_Abstraction are redefined since Refine and Trace do not specialize StandardProfile::Refine and StandardProfile::Trace.

    [Remark] The usage of the “extension specialization” pattern used to define both Refine and Trace within SysML shall be rationalized. To us, the two main points for using that pattern were:
    1. To avoid the usage of multiple inheritance in Refine /Trace definitions.
    2. Enable the owned extension ends (i.e., the one owned by the newly defined extensions relationships) to redefine the owned extension ends for StandardProfile::Trace, StandardProfile::Refine and SysML::Blocks::DirectedRelationshipPropertyPath.

  • Reported: SysML 1.4 — Tue, 10 Apr 2018 14:04 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Add the missing generalizations

    The reporter is right; those generalization are missing in the model defining the profile and have to be added.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

PDF Specification of SystemOfQuantities not consistent with XMI

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operations and constraints in section E.5.2.15 SystemOfQuantities are not consistent with the definition in the XMI.

  • Reported: SysML 1.6 — Sat, 9 Apr 2022 18:03 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Sync section 5.2.15 with XMI

    The XMI is based on the QUDV model, which is the single source of truth. Therefore, the documentation of the operations and constraints in section 5.2.15 must be updated to be in sync with the XMI. This will be achieved thanks to the document generation.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure E-6 is identical with E-5

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure E-5 and E-6 are identical. Replace figure E-6 with the figure E-6 from the SysML 1.5 specification.

    Figure E-6 contains some issues:

    • Should be a bdd instead of pkg
    • Unit::dependsOnUnits is a reference property and should be displayed in a separate compartment with headline "references"
    • Multiplicity at ends of associations between Unit and SystemOfUnits are 0..1 in figure E-5, but 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
    • Multiplicity quantityKind (association between Unit and QuantityKind) is 1..* in figure E-5, and 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
  • Reported: SysML 1.6 — Sat, 17 Apr 2021 17:31 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Update figures E-5 and E-6

    Figure E-5 and E-6 are identical. Replace figure E-6 with the figure E-6 from the SysML 1.5 specification.

    Figure E-6 contains some issues:

    • Should be a bdd instead of pkg
    • Unit::dependsOnUnits is a reference property and should be displayed in a separate compartment with headline "references"
    • Multiplicity at ends of associations between Unit and SystemOfUnits are 0..1 in figure E-5, but 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
    • Multiplicity quantityKind (association between Unit and QuantityKind) is 1..* in figure E-5, and 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Sample problem diagrams are inconsistent, need to refactor from integrated model

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The diagrams in Annex D are in many ways inconsistent with each other. Fixing existing issues with each individual diagram will tend to make this problem worse, instead of better. For consistency's sake, the set of diagrams in Annex D needs to be generated from an integrated model as existing issues are addressed.

  • Reported: SysML 1.5 — Fri, 8 Mar 2019 19:15 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Replace 1.6 Annex D with 1.7 Annex D generated from integrated model.

    Two documents attached:
    1. Annex D generated from the 1.7 integrated model in TWC (SysML 1.x Specification [trunk] #1206.
    2. SYSML17-185 Resolution Document, generated from the same model (#1210) with tables showing each issue resolved & the effected diagram(s), then each of the 41 figures in both final form and annotated to show which changes have been made. Note that figures without annotated diagrams have not substantially changed from 1.6.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Diagram show inconsistent data

  • Key: SYSML17-94
  • 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Update diagrams based on integrated example model

    Merged with SYSML17-185 which collects all issues regarding annex D.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing relationship between SystemOfUnits and Units

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The units shown in figure E.15 to E.18 don't have a link to the SystemOfUnits shown in the same diagram. There has been a link in SysML 1.5, albeit erronously, because there is no direct link. An indirect link exists along the included SystemOfUnits. I think it makes sense to show these indirect links. Otherwise the unconnected SystemOfUnits shown makes no sense in the diagram.
    Suggestion: Add the intermediary SystemOfUnits.

  • Reported: SysML 1.6 — Mon, 27 Sep 2021 11:45 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Change the diagrams

    Replace diagrams

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

SysML: Interaction diagram and Data-based comm of SysML

  • Key: SYSML17-13
  • Legacy Issue Number: 11627
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:
    Original Description:

    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?

    Description revised, in a hope to capture the essence of the question being asked, using the language of SysML V1.6:

    Summary of Problem Statement:
    Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via Ports.

    SysML introduces methods of data exchanges with Blocks thru the use of Flow Properties and Interface blocks, which can then be used, to illustrate data exchanges on Sequence Diagrams. On the other hand, UML 2.0 uses Classes, & InformationFlows to convey data exchanges.

    Question:
    How can data exchange between Part Properties and/or Actors using ValueType, Blocks & Signals be illustrated on a Sequence Diagram, while using Full Ports & Proxy Ports?

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

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

BindingConnector ends multiplicity

  • Key: SYSML17-9
  • Legacy Issue Number: 11333
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Issue: Nested connector ends

  • Key: SYSML17-8
  • Legacy Issue Number: 11276
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

The description of the semantics for the Overwrite stereotype is not consistent

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The illustration given as part of the description of the Overwrite stereotype does not match the semantics defined by fUML.

    Indeed, and except in very specific situation input pins never "store" tokens. So, applying the Overwrite stereotype to an input pin does not have practical effect in most cases.

  • Reported: SysML 1.6 — Wed, 16 Feb 2022 16:55 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fix the illustration given in the SysML specification

    In the sentence referred by the issue, just replace "input pin" by "output pin"

  • Updated: Thu, 22 Dec 2022 13:45 GMT

TestCase should use PackageMerge

  • Key: SYSML17-63
  • Legacy Issue Number: 16286
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

standard way to describe a flow of data in sequence diagrams

  • Key: SYSML17-7
  • Legacy Issue Number: 11117
  • Status: closed  
  • Source: International Business Machines ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Already possible

    It is allowed by the standard, already.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Typo: Constraint name 8 of Adjunct Property

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Name of constraint 8 is "8_callAction_composite_and_consitent_type",
    but should be "8_callAction_composite_and_consistent_type".

  • Reported: SysML 1.6 — Thu, 21 Mar 2019 17:35 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Typo: Constraint name 8 of Adjunct Property

    Fix the typo as proposed.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Combined call-out notation not allowed

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure D.25 depicts a allocate call-out notation that represents more than one call-out relationship. I don't think that it is allowed.

  • Reported: SysML 1.5 — Thu, 29 Nov 2018 09:36 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

The NoBuffer specification makes a wrong statement about the UML semantics

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The sentence that says: “When the stereotype is not applied, the semantics are as in UML, specifically, tokens arriving at an object node that are refused by outgoing edges, or action for input pins, are held until they can leave the object node” is false. This is not the semantics UML specifies. Buffering is provided only for token satisfying the guard but that are not numerous enough to satisfy the “weight” condition.

  • Reported: SysML 1.6 — Wed, 6 Oct 2021 15:25 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    The sentence is correct, but restates UML semantics.

    The sentence is correct. Buffering of tokens in Pins is possible in UML. The weight is not the only reason, why the outgoing ObjectFlow might refuse to accept tokens. If the guard is not satisfied, tokens are not discarded but buffered.

    However, the second part of the sentence restates UML semantics. In terms of a clean separation of the specifications UML and SysML, the second part is removed and the sentence is changed to "When the stereotype is not applied, the semantics are as in UML."

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Fix figure e-5

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure E-5 QUDV Concepts Diagram has several minor issues:

    • Should be a bdd instead of pkg diagram
    • Diagram name should not include the diagram number E-5
    • The notation of the owner in the block rectangle is not SysML conform
    • Diagram is not a vector graphic
    • Block QuantityKind has additional unknown stereotype <<Migration>>
  • Reported: SysML 1.6 — Sat, 17 Apr 2021 08:31 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fixed figure E-5

    Editorial fixes: change diagram type from package to bdd; remove diagram number from diagram name; assure that final graphic in the PDF is a vector graphic

    The stereotype "Migration" seems to be a forgotten part of the work on the QUDV elements. It can be removed.

    The information about the owner of the blocks is less important and would cost a lot of diagram space, if the package frames were included or the blocks had full qualified names. Therefore, that information is removed from the diagram.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

BDD representation of activity hierarchy

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I would question whether it was correct to change section 11.3.1.1 "Activity" by replacing the BDD representation of activity hierarchy (as per v1.3) with adjunct action properties (introduced in v1.4). Whilst the latter is possible with the AdjunctProperty facility, the prior method, inherited from UML, is still valid. That is, unless the UML activity hierarchy is expressly deprecated from SysML. Even then, it will leave end users with the question of what the additional benefit is of the adjunct property as applied to call behaviour actions.

  • Reported: SysML 1.5b1 — Thu, 19 Sep 2019 15:45 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Closed, no change: Restrict bdd presentation of activities

    There is no need that SysML restricts the modeling of activities in block definition diagrams like it is allowed by UML rules. The paragraph above Figure 11-1 in 11.3.1.1.1 says "Properties with AdjunctProperty applied ... can be used", it doesn't say they must be used.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

QUDV: PrefixedUnit has no quantity kind

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In figure E-9, the prefixed unit kilogram has two quantity kinds mass.

    However, PrefixedUnit redefines the quantityKind property and sets the multiplicity to 0. It should not have a quantityKind.

  • Reported: SysML 1.6 — Fri, 23 Apr 2021 06:11 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove quantityKind links for kilogram in Figure E-9

    A PrefixedUnit has not quantity kinds. The slots respectively links from kilogram to mass should be removed.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

NoBuffer has no effect if it is applied on an input pin

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to the UML semantics for Activities execution, token will be placed on input pins of an action only when this action accept them. So there will be no case where token in a input pin will be "refused".

    As a consequence, applying the "NoBuffer" stereotype on an input pin will not have any effect, conversely to what the description sub clause of that stereotype suggests (in section 11.3.2.4).

    Proposal: clarify that "NoBuffer" should not be applied on input pins.

  • Reported: SysML 1.6 — Wed, 3 Nov 2021 16:48 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    No change

    No Buffer may actually has an effect on an input pin if that one is part of a structured node.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex B / Figure B27

  • Key: SYSML17-21
  • 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex B / Figure B.38

  • Key: SYSML17-23
  • 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

    Update 03/25/2019: Added newlines for readability

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Don't use the optional notation for Pins with Allocation

  • Key: SYSML17-93
  • 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merged with SYSML17-185

    Merged with SYSML17-185 which collects all issues regarding annex D.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex B / Figure B.35


Figure B.34 and Figure B.35

  • Key: SYSML17-25
  • 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.

    Update: 03/25/2019, added newlines for easier reading

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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


Where have stereotypes been defined?


Annex B, Figure B.29

  • Key: SYSML17-24
  • 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Sample problem: Parts are added directly into package

  • Key: SYSML17-12
  • Legacy Issue Number: 11499
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

PDF Specification of SystemOfUnits not consistent with XMI

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operations and constraints in section E.5.2.16 SystemOfUnits are not consistent with the definition in the XMI.

  • Reported: SysML 1.6 — Sat, 9 Apr 2022 18:09 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Sync section 5.2.16 with XMI

    The XMI is based on the QUDV model, which is the single source of truth. Therefore, the documentation of the operations and constraints in section 5.2.16 must be updated to be in sync with the XMI. This will be achieved thanks to the document generator.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

'Figure 15-4: Behavior Allocation' multiple issues in the diagram and the supporting text

  • Status: closed  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The title of the section is:

    15.4.1 Behavior Allocation of Actions to Parts and Activities to Blocks

    There is in fact no allocation of an Activity to a Block, there is an allocation of an Activity6 to a Part7.

    From p. 177:

    Specific behavior allocation of Actions to Parts are depicted in Figure 15-4.

    But the diagram includes an allocation from an Activity6 to a Part7 (that it is a part is confirmed by the «part» keyword in the allocatedTo callout).

    The allocation to Activity6 comes from a nested part ..

    The allocation is from the Activity6 to a part ...

    The use of part names 'Part5', 'Part7' with Capitals is confusing. It is much clearer to have property names that are lowerCase. If they must have names with Capitals then the Blocks that type them should be shown (see attached image).

    The use of the part name 'Block1' as the allocation target for Action1 is beyond confusing when there is a block Block1 in the same diagram.

    ASIDE: I wish the RTF diagram contributors would adopt a policy across the entire specfication of using lowerCamelCase (no spaces) for all block properties and UpperPascalCase (no spaces) for all Blocks

    The diagram figure is low resolution and needs to be replaced.

    The following may be in part MagicDraw/Cameo 19SP3 tool issues:

    • The path callout in the Note for the allocatedTo on Activity6 in the tool is '«part» Block4::Block7::part7'; the spec has '«part» Block4.Part5.Part7'
    • The tool could not (as far as I can tell) display the qualified name corresponding to Part:Block1 for the header in a swimlane
  • Reported: SysML 1.6 — Wed, 1 Jul 2020 03:34 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Behavior Allocation

    Correct the text in following way:

    Specific behavior allocation+s+ of Actions to Parts and Activities to Blocks are depicted in Figure 15-4.

    The allocation to Activity6 from action1 comes from goes to a nested part, and uses the attributes of DirectedRelationshipPropertyPath to specify the path of properties to reach that part. The sourceContext targetContext of the allocation is Block4 Block 0 and the sourcePropertyPath targetPropertyPath is (Part5) part1. Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation.

    Replace the diagram with this one:

    This diagram can be found in the specification model in the teamwork cloud under Element ID
    mdel://_19_0_4_58401de_1632821659221_739603_774

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

SysML: UML Qualified Associations

  • Key: SYSML17-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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Closed because a rationale is missing

    In principle, it would be possible to introduce qualified associations, since it is part of UML. It was discussed several times in previous issues and we agreed that it should be covered by SysML v2.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure E.8 depicts instance specifications with invalid slots

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure E.8 depicts instance specifications with a slot "name". None of the classifiers of the instance specification define the appropriate structural feature for the slot.

  • Reported: SysML 1.6 — Tue, 20 Apr 2021 10:37 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove invalid slots or replace them with another one

    The types of the instance specifications in figure E-8 and E-9 have no property "name". It seems that the author mixed it up with the name of the instance specification.

    An exception are the instance specifications SI and ISQ in figure E-8. The name slot should be replaced by "description" which is a property of SystemOfUnits and SystemOfQuantities.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

QUDV: SystemOfUnits constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds not documented in PDF

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The constraint SystemOfUnits::systemOfQuantitiesIncludesAllUnitsQuantityKinds is specified in the QUDV.xmi, but not mentioned in the PDF in section E.5.2.16.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 16:53 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Specify constraint SystemOfUnits::systemOfQuantitiesIncludesAllUnitsQuantityKinds in section E.5.2.16

    It seems that the description of the constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds has been overseen in section E.5.2.16 and should be added in the constraint subsection.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Requirements interchange issue

  • Key: SYSML17-29
  • 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Facilitating partner integration is out of scope of SysML

    The reporter asks for additional elements in SysML to facilitate requirement interchange. Although this would be useful for SysML, it is out of scope.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure E.11: Make it a package diagram and update the URI's


QUDV: Constraints [1] and [2]of SystemOfUnits are operations

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In section E.5.2.16, the constraint [1] specifies the body condition of operation isCoherent() and constraint [2] the body condition of operation isCoherent(du).

    So, the specifications should be moved to the operation section and not be listed in the constraint section.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 16:20 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    QUDV::SystemOfUnits: Move body conditions from constraint to operation section

    The body conditions constraint [1] and constraint [2] for isCoherent() and isCoherent(du:DerivedUnit) should be moved to the operation section after the constraint section.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

clarification, what "part property" is

  • Key: SYSML17-74
  • Legacy Issue Number: 17307
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Part Property

    Part Property are defined by a composite relationship between block "<<Block>>" elements, in section 8.3.2.4 SysML v 1.6. As for the special cases, they are further defined in the appropriate sections....example the constraint block section 10.1.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

QUDV: SystemOfUnits::accessibleQuantityKinds() is a copy & paste error

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operation SystemOfUnits::accessibleQuantityKinds() specified in section E.5.2.16 is not mentioned in the QUDV.xmi and is identical with the operation of same name in SystemOfQuantities in the previous section E.5.2.15.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 17:02 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove accessibleQuantityKinds() from SystemOfUnits

    It seems that the documentation of SystemOfUnits::accessibleQuantityKinds() was added by accident to the description in section E.5.2.16. It is a copy of the operation in section E.5.2.15.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SimpleQuantityKind::dependsOnQuantityKinds() not specified as a redefinition

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    SimpleQuantityKind::dependsOnQuantityKinds() redefines the operation QuantityKind::dependsOnQuantityKinds(), but the redefinition is neither specified in the PDF nor in the QUDV.xmi.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 11:20 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    SimpleQuantityKind::dependsOnQuantityKinds() redefines QuantityKind::dependsOnQuantityKinds()

    The redefinition of the inherited operation dependsOnQuantityKinds() should be specified.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

QUDV: Documentation of SystemOfUnits::getUnit() is missing

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operation SystemOfUnits::getUnit() in the QUDV.xmi in not mentioned in section E.5.2.16.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 17:12 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    QUDV: Add documentation of SystemOfUnits::getUnit()

    Add the documentation of SystemOfUnits::getUnit() specified in the QUDV.xmi in section E.5.2.16

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure E.19 not consistent with XMI

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The constant numbers in figure E.19 are not consistent with the ISO-80000.xmi

  • Reported: SysML 1.6 — Fri, 7 May 2021 17:50 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Update figure E.19

    The elements depicted in figure E.19 are not part of the ISO-80000.xmi model anymore. The figure should be updated to depict the current content of the model.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSML17-77
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Constraint parameters do not need to be constrained to not be derived

    A constraint parameter is a normal property of a constraint block that is not typed by a constraint block. Therefore, it can also be defined as a derived property. According to the UML definition of derived properties, some constraint parameters might be derived:

    "If a Property has isDerived = true, it is derived and its value or values may be computed from other information."

    It seems not to be useful to make the distinction of derived and non-derived properties, but there is no need to forbid them, and it does not contradict the non-causal nature of constraints blocks.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

ConnectorProperty is redundant

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ConnectorProperty is redundant. The same feature is provided by AdjunctProperty.

    see slide 17: http://tinyurl.com/ybvdx6ew

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 18:26 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Deprecate ConnectorProperty

    The AdjunctProperty with a connector as principal provides the same capability as the ConnectorProperty. To continue to be backward compatible, the stereotype ConnectorProperty will not be removed, but marked as deprecated in the specification.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex D (Sample problem) should illustrate a nominal usage of the corresponding version of SysML

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Considering the purpose of the sample problem, it shall be adjusted so that it reflects a nominal usage of SysML. Usage of obsolete concept/stereotypes shall be replaced without further justification.
    This includes, for instance, the replacement of "UML standard port"/Interfaces by proxy ports/InterfaceBlocks.

    Hence, and even if we will try to keep the sample problem as close as possible to its previous version, some figures of even some parts of it will change, as appropriate with regard to the illustration objective.

    The goal of this issue is to get a global RTF agreement on this.

  • Reported: SysML 1.6 — Thu, 6 Jan 2022 16:54 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Agree on this update principle

    Per this resolution, and as requested by the issue, we allow the subgroup in charge of the Annex D "Sample problem" to apply changes on it in order to keep it in synchronization with the SysML specification it is part of and in order to make sure it provides an appropriate illustration of a common usage of it.

    Changes related to this concerns will be gathered in a single resolution to a specific issue about "keeping the sample model up-to-date" so that the RTF will still be asked for a global approval of them.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Syntactical clarification for ConstraintBlock

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    There is no clear statement saying how the expression that specifies the constraint is managed, even if we can imagine that the intent was to use the ownedRule for that purpose it's not formally stated.

    Assuming ownedRule is used, it's not specified either how to deal with ConstraintBlocks that would have more than one ownedRule (since the current specification only consider "one" constraint only)

  • Reported: SysML 1.6 — Thu, 5 Sep 2019 14:35 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-252

    The resolution to issue SYSML17-252 implies resolving this one first. For that reason its is convenient to merge them and to provide a common resolution that is specified as a resolution proposal for SYSML17-252

  • Updated: Thu, 22 Dec 2022 13:45 GMT

9.3.2.9 What is InterfaceBlock?

  • Key: SYSML17-73
  • Legacy Issue Number: 17255
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Resolved — SysML 1.7
  • Disposition Summary:

    Improve the description

    We propose to improve the Description sub-clause of 9.3.2.10 Interface Block by highlighting the definition first, then a bit about their usage.

    Issues about the constraints have already been fixed

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML Issues on Item Property values in an IBD

  • 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: SysML Issues on Item Property values in an IBD

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Return parameters of operations in annex E.5.2 have wrong parameter direction

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The return parameters of the operations in annex 5.2 have the parameter direction "in" in the QUDV.xmi, but should have parameter direction kind "return".

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 09:21 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Set parameter direction kind of return parameters to "return"

    The specification PDF is correct, but not the QUDV.xmi.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Owning Block definition is unclear

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The definition of owning block for proxy port given in the description sub-section of 9.3.2.7 FlowProperty is unclear and misleading. It should be reworded and moved to the ProxyPort description

  • Reported: SysML 1.5 — Thu, 2 Mar 2017 15:41 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove the sentence between parenthesis

    The sentence will be removed

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-11
  • Legacy Issue Number: 11496
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    No change

    The reporter makes a confusion between the stereotype and the keyword symbol (<<xxx>>) that is usually used for representing that a stereotype is applied on the element on which this keyword appears, but not always (see UML 2.5.1 Annex C).

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure 8-1: Wrong property notation

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The properties notation depicted in figure 8-1 is not correct. If the type is not shown, also the ':' is not shown according to the property notation BNF given in the UML specification in section 9.5.4:

    <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

  • Reported: SysML 1.6 — Sun, 21 Mar 2021 16:58 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Figure 8-1: Updated property notation

    If a property is depicted without a type, the ':' is not shown. The property syntax is defined in section 9.5.4 of the UML 2.5.1 specification:

    <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

QUDV::LinearConversionUnit constraint isInvertible=true

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The QUDV model contains a constraint "invertible: isInvertible=true" for LinearConversionUnit, but is not mentioned in the specification document. I propose to add it to the description in section E.5.2.7.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 05:26 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Add constraint description to LinearConversionUnit

    The constraint forces that the inherited property isInvertible is set to true. It is part of the QUDV.xmi, but not described in the specification document.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

QUDV::AffineConversionUnit constraint isInvertible=true

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The QUDV model contains a constraint "invertible: isInvertible=true" for AffineConversionUnit, but is not mentioned in the specification document. I propose to add it to the description in section E.5.2.1.

  • Reported: SysML 1.6 — Sun, 18 Apr 2021 11:17 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Add constraint description to AffineConversionUnit

    The constraint forces that the inherited property isInvertible is set to true. It is part of the QUDV.xmi, but not described in the specification document.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Description of SysMLStructureDiagram is missing

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In appendix B, the description stereotype SysMLStructureDiagram in figure B.3 is missing in section B.2.

  • Reported: SysML 1.6 — Tue, 13 Apr 2021 09:24 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Added description for SysMLStructureDiagram

    The description of the abstract stereotype SysMLStructureDiagram is missing and should be added.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure 11-14 is identical with figure 11-13


Figure 9-5 is identical with figure 9-4

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The figure 9-5 is identical with 9-4. It should be the attached figure.

  • Reported: SysML 1.6 — Mon, 22 Mar 2021 13:14 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Replace with figure 9-5

    Figure 9-5 is identical to figure 9-4.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

QUDV: dependOnUnits() operation is not redefined

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The QUDV blocks DerivedUnit, ConversionBasedUnit, and SimpleUnit define each a dependsOnUnits() operation which should be a redefinition of the inherited Unit::dependsOnUnits() operation.

    The redefinition is neither specified in PDF nor in the QUDV.xmi.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 12:52 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Redefine dependsOnUnits() operation

    The QUDV blocks DerivedUnit, ConversionBasedUnit, and SimpleUnit define each a dependsOnUnits() operation and inherit the Unit::dependsOnUnits() operation. The definition of the redefinition is missing in the PDF and the QUDV.xmi.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Incorrect placement of sections in chapter 17

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section 17.2 contains a subsection 17.2.1.1, but no subsection 17.2.1.

    Section 17.2.1.1 as well as 17.2.2.1, 17.2.2.2, and 17.2.2.3 cover content from UML and does not add SysML specific information.

  • Reported: SysML 1.6 — Mon, 5 Apr 2021 12:52 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    *Rearrangement of sections in chapter 17 *

    The sections mentioned in the issue description repeat content from the UML specification. It is sufficient to repeat the notation in the diagram table. Therefore, the sections 17.2.1.1, 17.2.2.1 - 17.2.2.3 should be deleted.

    The section 17.2.1 is missing. It got lost after SysML 1.4, and should be added again.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Section C.3.2.3 should not be a section, but only a headline without numbering

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section C.3.2.3 Semantic Variation Points should not be a section with its own numbering. It is just a headline like "Description" in section C.3.2.2.

    The FlowPort was a stereotype of SysML 1.2. In the SysML 1.2 specification document, the section "Semantic Variation Point" was also only a unnumbered headline of the section about FlowPort.

  • Reported: SysML 1.6 — Thu, 15 Apr 2021 14:19 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove section numbering C.3.2.3

    It seems that the numbering was introduced by accident in SysML v1.3 and should be removed.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure 13-1 shows two identical names in the same namespace

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In figure 13-1, the upper left state machine has two adjunct properties of the same name.

    I propose to simply rename the properties to "submachine state name1" and "submachine state name2".

  • Reported: SysML 1.6 — Mon, 5 Apr 2021 16:36 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Rename identical adjunct properties

    It is allowed to have two states with the same name, but not two adjunct properties. The adjunct property "submachine state name" must be renamed.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Figure 12-1 shows two identical names in the same namespace

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In figure 12-1, the upper left interaction has two adjunct properties of the same name.

    I propose to simply rename the properties to "interaction use name1" and "interaction use name2".

  • Reported: SysML 1.6 — Thu, 8 Apr 2021 16:06 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Rename identical adjunct properties

    It is not allowed to have two adjunct properties of the same name owned by a namespace.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Remove second constraint of SysMLBehaviorDiagram

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The second constraint of the SysMLBehaviorDiagram is a copy of the second constraint of SysMLActivityDiagram.

  • Reported: SysML 1.6 — Tue, 13 Apr 2021 09:28 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove second constraint of SysMLBehaviorDiagram

    Resolve the copy&paste error by removing the second constraint of SysMLBehaviorDiagram.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Definition of part

  • Key: SYSML17-59
  • Legacy Issue Number: 16058
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Definition of a "Part" SysML v1.2, includes ports

    The current Definition of a "part" includes ports, is this intentional?

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

QUDV.xmi: Prefix::symbol multiplicity should be 0..1

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the QUDV.xmi, the multiplicity of Prefix::symbol is 1 while the specification in section 5.2.8 defines a 0..1 multiplicity.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 05:31 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fix multiplicity of Prefix::symbol in XMI

    The multiplicity of Prefix::symbol in the XMI should be set to 0..1 as specified in the PDF.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing comment for some attributes

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Closed, no change: Missing comments in XMI

    The current XMI for SysML 1.6 includes all the descriptions of the stereotypes and stereotype features. The model that was used to generate the XMI is the same model that was used to generate the stereotype descriptions in the specification PDF document.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Derived attribute should also be read only

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    In the xmi file representing the profile, that can be found here:
    ptc/2015-07-05 http://www.omg.org/spec/SysML/20150709/SysML.xmi

    The derived attributes should also be set to read-only:
    <ownedAttribute xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Requirement_ownedAttribute.master" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Requirement_ownedAttribute.master" xmi:type="uml:Property">
    <name>master</name>
    <isDerived>true</isDerived>
    ...
    </ownedAttribute>

    In Papyrus SysML 1.1 version, the derived attributes have been set to read-only.
    It will be the same for SysML 1.4 implementation. See https://git.eclipse.org/r/#/c/71034/2/core/org.eclipse.papyrus.sysml14/resources/profile/SysML.profile.uml

    It would be good to provide for SysML 1.5 either the profile with readonly or specify in the norm what should be implemented for the write access

  • Reported: SysML 1.4 — Thu, 28 Apr 2016 10:42 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Derived properties are not required to be read-only

    The UML specification allows that derived properties are changeable:

    ----------------------------
    Section 9.5.3:
    Derived Properties are often specified to be read-only (i.e., clients may not directly change values). But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property. The derivation for a derived Property may be specified by a constraint.
    ----------------------------

    A derived property can change if a value of the derivation expression changes.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML primitive value types

  • Key: SYSML17-52
  • Legacy Issue Number: 15882
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Resolved — SysML 1.7
  • Disposition Summary:

    Specialize SysML primitive values types from UML primitive value types

    The SysML primitive values types have no relationship to the UML primitive value types and there is also no relationship to the Literal metaclasses. Therefore, it is not possible to define values for properties typed by a SysML primitive value type.

    A solution is to inherit the SysML primitive value types from the appropriate UML primitive value types.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

SysML: Protocol State Machines needed

  • Key: SYSML17-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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Protocol State Machines deferred to SysML v2

    Table 4-1 excludes the model element ProtocolStatemachines from the UML4SysML subset. The impact of introducing ProtocolStatemachines in SysML v1 is too big for v1 and out of scope for an RTF.

    The need for ProtocolStatemachines was already sent to the team working on SysML v2. They identified a high coverage with the SysML v2 RFP requirement INF 1.07.1.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Incorrect description of SysMLBlockDefinitionDiagram

  • Status: closed  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Description mentions SysMLBlockDefinitionDiagram stereotype extends UMLPackageDiagram whereas it extends UMLClassDiagram according to Figure B.3 page 219.

  • Reported: SysML 1.6 — Fri, 27 Mar 2020 06:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: SysMLBlockDefinitionDiagram extends UMLClassDiagram

    The SysML Diagram Interchange stereotype SysMLBlockDefinitionDiagram extends UMLClassDiagram (see figure B.3). Section B2.3 incorrectly states that SysMLBlockDefinitionDiagram extends UMLPackageDiagram.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Convention for enumeration not used for ControlValue

    The issue affects version 1.3. It was resolved in the meantime (see SysML 1.6).

  • Updated: Thu, 22 Dec 2022 13:45 GMT

"Allocated From" should be "Allocated"

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The term "Allocated From" associated with the From end of an allocation relationship is confusing when it appears in compartment or callout notation. Nerijus mentions numerous user complaints about this. A more intuitive and meaningful term would be simply "Allocated", which when appearing in a compartment label implies that the subject element has the listed elements in the compartment allocated to it.

  • Reported: SysML 1.4 — Thu, 19 Nov 2015 15:49 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolved: Rename "allocatedFrom"

    The term "allocatedFrom" in the allocate compartment or callout notation is confusing for many model users. After a discussion the RTF decided to rename it to "allocatedElements".

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Block namespace compartment: Are external relationships allowed

  • Key: SYSML17-6
  • Legacy Issue Number: 11011
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Resolved — SysML 1.7
  • Disposition Summary:

    Clarified that external relationships from and to block namespace compartment are allowed

    Replace the first paragraph of the section with the revised text.

    Text with change marks:
    A compartment with the label “namespace” may appear as part of a block definition to show blocks and other NamedElements that are defined in the namespace Namespace of a containing block. This compartment may contain any of the graphical elements of a block definition diagram. All blocks or other named elements NamedElements that are defined shown in this compartment belong to the namespace Namespace of the containing block, provided this is legal. Elements that cannot be owned by a Block, like Dependencies, can still be shown in the compartment, but without implications for their owner. Relationships between Elements inside and outside of the block’s Namespace may also be shown. Since the relationship is then half outside of the compartment, no conclusion about ownership can be drawn from the diagram.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:
    • rationale.pptx 550 kB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

Representation of nested object nodes in activity diagrams

  • Key: SYSML17-30
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Corresponding actions shall be used

    • There are two possible cases we see where we would need to work on parts from a whole: (a) the part remains owned by the whole and we just need a reference on it to focus the folowwing behavior on this part, or (b): the part is "dismounted" from the whole (i.e. the ownership changes) and then tit is flowing apart from the whole. In both cases it's necessary to specifiy the appropriate action to be performed:
    • in case (a): actions like "UnmarshallAction" or "ReadStructuralFeatureAction" can be used. Alternatively the "transformation" property of an ObjectFlow can be used. Note that this transformation shall be "side effect free".
    • in case (b): we would use "RemoveStructralFeatureValueAction" for transferring ownership

    We propose a "Closed, no change" resolution.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Table 8.3: Row ActorPart shows Actor

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The row ActorPart in table 8.3 should depict SysML::Blocks::PartProperty typed by UML4SysML::Actor, but it shows an Actor.

  • Reported: SysML 1.6b1 — Sat, 18 May 2019 17:37 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Resolution: Show properties typed by Actor in ActorPart row of table 8.3

    The row ActorPart in table 8.3 shows Actor elements instead of properties typed by an Actor.

    SYSML17-286 asks for removing the row ActorPart from the table.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure 9-5 and 9-4 are the same

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 9-5 (Item Flow Stereotype) is the same as Figure 9-4 (Provided and Required Features).

  • Reported: SysML 1.6 — Thu, 5 Mar 2020 15:39 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Replace figure 9.5

    The figure 9.5 is by accident identical with figure 9.4 and must be replaced.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Parameter direction typo in XMI


Owned properties of an InterfaceBlock

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Split from SYSML16-86:

    What are possible owned properties of the InterfaceBlock? Values, FlowProperties? other? In 9.1 InterfaceBlock it is not flow nor value

  • Reported: SysML 1.5 — Thu, 16 Mar 2017 07:43 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Owned properties of an InterfaceBlock

    InterfaceBlock constraint 2_no_part defines the possible owned properties.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

10.3.1.2 Parametric Diagram: square box notation

  • Key: SYSML17-17
  • 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: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Clarify square box notation in parametric diagrams

    The paragraph 10.3.1.2 in SysML 1.0 is identical with the text in paragraph 10.3.1.2.3 in SysML 1.6. The reporter is right that the statements are misleading. It is intended to specify the notation of constraint parameters.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Do parametric bindings observe derived and read-only properties

  • Key: SYSML17-39
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    ConstraintBlock is a constraint no a mechanism

    A ConstraintBlock is intended to represent a constraint that can happen to be met or violated. Tools vendors providing simulation facilities may want to implement a synchronization mechanism based on it but it's not required by this specification. If such a mechanism is provided, it is expected that either the tool will enforce the constraint or will notify a constraint violation if any. But again, this is not part of this specification.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex B / B.4.8.3 Activity Diagram (in sample problem)

  • Key: SYSML17-18
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Already fixed

    This issue does not appears anymore in the specification

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML: References to CreateEvent incorrect

  • Key: SYSML17-76
  • 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: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: References to create and destruction messages

    The referenced elements UML4SysML::CreationEvent and UML4SysML::DestructionEvent do not exist. Table 12-1 must be updated.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

About Rate, Continuous and Discrete

  • Legacy Issue Number: 18735
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Duplicate of SYSML17-265

    SYSML17-265 is also about Rate extending ObjectNodes.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

IBD notation doesn't distinguish item properties from connector labels

  • Key: SYSML17-55
  • Legacy Issue Number: 15983
  • Status: closed  
  • Source: NIST ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Stereotype keyword can be used

    There is still the possibility to show the <<ItemFlow>> stereotype keyword. By doing this there no ambiguity anymore and no change is required.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Association owning ends

  • Key: SYSML17-62
  • Legacy Issue Number: 16263
  • Status: closed  
  • Source: The MathWorks ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Already fixed

    Associations own their non-navigable ends

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Allocate: Error in operation bodies

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The body condition of the Allocate::getAllocatedFrom()
    getAllocatedFrom = Allocate.allInstances()->select(to = ref).from
    should be
    getAllocatedFrom = Allocate.allInstances()->select(supplier = ref).client

    to and from are no stereotype or metaclass properties. The appropriate properties are client and supplier defined in the metaclass "Dependency".

    Accordingly change the Allocate::getAllocatedTo() body condition as well as the name "getAllocatedFrom" to "getAllocatedTo":

    getAllocatedTo = Allocate.allInstances()->select(supplier = ref).client.

  • Reported: SysML 1.6 — Thu, 13 Feb 2020 16:19 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolved: Error in operation body conditions of getAllocatedFrom() and getAllocatedTo()

    The body condition of the Allocate::getAllocatedFrom() and Allocate::getAllocatedTo() operations are not correct. Fix them as proposed in the issue description.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

UML::ExceptionHandler should be part of SysML

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to chapter 4.1 of the SysML 1.6 specification document, RaiseExceptionAction is part of SysML, but the ExceptionHandler is not part of UML4SysML.

    It makes sense to have a complete exception mechanism in SysML, for example, to model exceptional conditions like the violation of a constraint.

    Throwing an exception is not restricted to software, but a useful logical concept of modeling flow behaviors. For instance, it is also included in BPMN.

  • Reported: SysML 1.6 — Thu, 21 Nov 2019 11:30 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Add UML::ExceptionHandler to SysML

    The UML::ExceptionHandler element is missing in SysML and must be added to UML4SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML: Generalizing Activites

  • Key: SYSML17-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: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Add example about generalizing activities

    Add a new block definition diagram (figure 11-15) depicting a activity generalization.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Shared parts are still parts

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The standard treats non-composite aggregation (white diamond) as the poor cousin of composite aggregation (black diamond) by lumping it into a group of block properties called “references”. (6th paragraph in section 8.3.2.3 Block.) So whilst parts (composite aggregation) have their own compartment, non-composite aggregates have to share a compartment with all of the reference block properties. This also occurs on the IBD with all the types of references being drawn with a dashed rectangular frame. At the very least I would propose that non-composite parts are called reference-parts (as opposed to “owned” parts for the composite ones) and are given their own compartment.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:10 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Shared parts are still parts

    New features respectively removing features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Stakeholder constraint is listed twice

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The Stakeholder constraint 1_not_association is listed twice in the specification document and the XMI.

    One constraint is named "1_not_association" the other one "not_association".

    Remove the "not_association" constraint.

  • Reported: SysML 1.6 — Tue, 19 Mar 2019 21:34 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Stakeholder constraint is listed twice

    Remove the duplicated constraint "not_association".

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Error in pending 1.3 diagram 15.6 and elsewhere

  • Key: SYSML17-70
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Wrong object flow notation

    In SysML 1.6, Figure 15.5. and 15.6. depict the object flow with a solid line.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Bad reference in section 4.2

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    At the end of section 4.2 is an unresolved reference:

    "UnitAndQuantityKind, see Erreur : source de la référence non trouvée"

    Replace it with

    UnitAndQuantityKind, see 8.3.3.2

  • Reported: SysML 1.6 — Tue, 19 Mar 2019 21:39 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Bad reference in section 4.2

    Add the correct reference to the bullet point.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Lack of notation for units and dimensions on values.

  • Key: SYSML17-10
  • Legacy Issue Number: 11493
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Notation for units and dimensions - already resolved

    The notation for units and dimensions was added in SysML 1.6 as a resolutions for issue SYSMLR-330.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML: Align SysML Activities with Foundational UML

  • Key: SYSML17-26
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Align SysML Activities with fUML

    There is no misalignment between SysML Activities and fUML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

DirectedFeature is confusing

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The intended use for the <<DirectedFeature>> stereotype is not at all clear from its specification in section 9.3.2.4 in SysML 1.5. To be clear, the current description describes what it is, but not why it is required, or how a modeller might use it. Moreover, it is not clear whether it specifically applies to ports (since its part of the section that specifies the language facilities for ports and flows (section 9), or whether it relates to features (properties?) of a block that are not ports.

    The issue was discussed at the RTF meeting of 2017-10-12 as a result of discussing issue http://issues.omg.org/browse/SYSML16-108. There was little consensus on what DirectedFeature is, although Conrad suggested the following (being my interpretation of what was said):
    A DirectedFeature of a block describes whether the block implements that feature (it's "provided") or that the feature is represents a conceptually virtualised feature as an "assumption" that something else in the model will provide it. The fulfilment of the required assumption with an actually provided realisation of that feature is by a connector between the required and the provided features.

    The problem with this interpretation is that it seems to have nothing to do with ports! There is of course further scope for confusion with the UML notation of provided and required interfaces on UML ports.
    At the very least, some examples that clearly illustrate what problem DirectedFeature solves and the types of model elements that it is to be applied to would help a lot.

  • Reported: SysML 1.5 — Thu, 12 Oct 2017 16:39 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Improved description of DirectedFeature

    The description in SysML 1.6 has improved quite considerably. However it can be further improved by slightly modifying the way the corresponding text is structured and by clarifying that any feature are implicitly "provided" if no DirectedFeature stereotype is applied

  • Updated: Thu, 22 Dec 2022 13:45 GMT

VerdictKind enumeration missing

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    VerdictKind appears in a constraint on TestCase and in Table 4.3 (SysML stereotypes, blocks, valuetypes, and datatypes), but isn't defined in the spec. I should be in a model library, like ControlValueKind (see 11.3.3.1 Package ControlValues).

  • Reported: SysML 1.6 — Mon, 21 Jan 2019 15:20 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    *Resolution: Add enumeration VerdictKind *

    The enumeration VerdictKind is missing in the specification document. It used in the constraints of the TestCase and it is part of the SysML.xmi.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

The AdjunctProperty is not clearly described

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The benefit of the recently introduced Adjunct Property is not clearly stated in the standard. The current description is somewhat baffling and a recent discussion amongst learned members of the SysML RTF revealed further uncertainty.
    The standard's development needs to be sensitive to the general criticism that SysML is too complex. Thus language features that are described from their purely functional/implementation point of view neither inform the user community what they are for or, as seems to be the case here, make it clear that this part of the language that is a solution to a problem inherited from UML that modelling tools need to implement and end users need not be too concerned with.
    I would also question whether it was correct to change section 11.3.1.1 "Activity" by replacing the BDD representation of activity hierarchy (as per v1.3) with adjunct action properties (introduced in v1.4). Whilst the latter is possible with the AdjunctProperty facility, the prior method, inherited from UML, is still valid. That is, unless the UML activity hierarchy is expressly deprecated from SysML. Even then, it will leave end users with the question of what the additional benefit is of the adjunct property as applied to call behaviour actions.

  • Reported: SysML 1.4 — Fri, 28 Apr 2017 12:53 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    AdjunctProperty not clearly defined: Resolution provided by other issue resolutions

    Split the issue to SYSML17-248 and SYSML17-255.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Reference Properties do not reference properties

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    A reference property of a Block may only be typed by (i.e. "reference") another Block. There is no current mechanism for a reference property to explicitly reference a part property of a different block. See Figure D.16 for example; the PowerSubsystem Block is assumed to be referencing the part property of the BrakeSubsystem typed by BrakePedal. This is a logical conclusion since there is only one part property typed by BrakePedal, but if there were multiple part properties typed by BrakePedal, the reference property of the PowerSubsystem Block would be ambiguous.

    Practical use of reference properties has consistently implied that a particular part property CAN be referenced (i.e. "a part property owned by another block"), but no mechanism for this is explicitly provided in SysML. Also, there does not appear to be any constraint on instance semantics of reference properties that might clarify this ambiguity at the instance level.

    See also SYSML16-42 and SYSML16-228.

  • Reported: SysML 1.5 — Tue, 17 Oct 2017 00:17 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Reference properties do not reference properties

    Discussed during May 16th, 2019, RTF meeting:

    We believe that the requested capabilities are already provided by the current SysML version. There are multiple ways to represent such constructs:

    1. A binding connector and optionally a BoundReference property can be used
    2. Derived attribute and/or an operation
    3. Specific properties that subset the collection (assuming the types of the properties owners conform to one another)
    4. Using proxy ports with appropriate connectors

  • Updated: Thu, 22 Dec 2022 13:45 GMT

AllocateActivityPartition: Reference to UML specification is wrong

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The second constraint of the stereotype AllocateActivityPartition references a section in the UML specification:

    "To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic."

    Subclause 12.3.10 does not exist. It is probably 15.6.3.1 in UML 2.5.1.

    I propose to remove the subclause reference number.

  • Reported: SysML 1.6b1 — Wed, 26 Jun 2019 12:50 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    AllocateActivityPartition: Reference to UML specification

    The subclause number references an older version of the UML specification. It is hard to manage those links between separate specifications. Therefore, we follow the proposal of the issue author to remove the absolute reference.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    In SysML 1.5 pdf document ( p 147 Table 14.2- Graphical paths included in Use Case diagrams)

    Latest element in the table :

    • Path name: Generalization
    • Concrete Syntax : ->
    • Abstract Syntax Reference : UML4SysML::Kernel
      => it should be UML4SysML::Generalization

    Also present in SysML 1.4 pdf version

  • Reported: SysML 1.5 — Wed, 30 Aug 2017 15:13 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Replace UML4SysML::Kernel with UML4SysML::Generalization

    The abstract syntax reference is not correct as pointed out by the reporter of the issue and must be resolved as proposed.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML::Trace relationship is not specialized from UML::Trace in the XMI

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML::Trace stereotype is a specialization of the UML::Trace stereotype defined in the StandardProfile.

    In the SysML XMI the SysML::Trace stereotype has no generalization relationship to the UML::Trace stereotype. It is just a stereotype extending UML::Abstraction.

  • Reported: SysML 1.5 — Tue, 15 Jan 2019 09:53 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Model generalization from stereotype SysML::Trace to UML::Trace

    The XMI is not conform to the written specification. The generalization relationship between the SysML::Refine and the UML::Refine stereotypes as specified in figure 16.1 is not defined in the XMI.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML::Refine relationship is not specialized from UML::Refine in the XMI

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML::Refine stereotype is a specialization of the UML::Refine stereotype defined in the StandardProfile.

    In the SysML XMI the SysML::Refine stereotype has no generalization relationship to the UML::Refine stereotype. It is just a stereotype extending UML::Abstraction.

  • Reported: SysML 1.5 — Tue, 15 Jan 2019 09:55 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Model generalization from stereotype SysML::Refine to UML::Refine

    The XMI is not conform to the written specification. The generalization relationship between the SysML::Refine and the UML::Refine stereotypes as specified in figure 16.1 is not defined in the XMI.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Verdict described incorrecty

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 16.1 (Requirements, Overview, search on "verdict") refers to "A verdict property of a test case", but verdicts are return parameters, which aren't properties (unless this means an adjunct).

  • Reported: SysML 1.6 — Mon, 21 Jan 2019 15:24 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Describe verdict as return parameter

    The verdict is not a property, but a return parameter of a test case. See 16.3.2.6 for the definition of a test case.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Typos/editorials found in the SysML 1.5 specification document

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    This issue is dedicated to typos and editorials we find in the SysML1.5 specification document.

    Any finding has to be recorded as an annotation added to a shared PDF document available on the OMG SVN server at: http://www.omgwiki.org/repos/SysML/trunk/Documents/formal-17-05-01(annotated).pdf

    >>> Note to RTF Chairs: do not schedule this issue for vote before the last ballot of the RTF <<<

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 14:14 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    1.6 is done

    to be replace by a new issue similar to this one but about 1.6 rather than 1.7

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Description of AdjunctProperty

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The first sentence of the description of the Adjunct property stereotype does not make sense:
    "The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states"

  • Reported: SysML 1.5 — Mon, 7 May 2018 12:13 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merged with SYSML17-248

    Discussed during RTF meeting, Sep. 19th:
    SYSML17-248 is also about clarifying the definition of an AdjunctProperty.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inherit from a conjugated interface block

  • Legacy Issue Number: 19644
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Inherit from a conjugated interface block

    The issue affects SysML 1.4. It was resolved in the meantime (see SysML 1.6).

  • Updated: Thu, 22 Dec 2022 13:45 GMT

ElementGroup cannot be source or target of a dependency

  • Legacy Issue Number: 19595
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: ElementGroup cannot be source or target of a dependency

    It is not possible to resolve the issue without a major change of the model element or a change of the UML. The addressed problem was already discussed when the ElementGroup element was created. There is no solution with the underlying UML.

    It can be resolved with SysML v2.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Property path notation

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    SysML spec says:

    The name of the referenced property is built by a string of names separated by “.”, resulting in a form of path name that identifies the property in its local context.

    The problem is that in real-life models properties/parts are unnamed. In this case, it is not clear how property path should look like, or looks like this:
    name1…..value or vehicle….value where intermediate properties are unidentifiable.

    A proposed solution would be to use type name if part name is not specified.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:14 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Property path notation

    The issue affects version 1.4. It was resolved in the meantime (see SysML 1.6).

  • Updated: Thu, 22 Dec 2022 13:45 GMT

AllocateActivityPartition should be more formaly related to allocation Relationship

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Assuming an AllocateActivityPartition is used to specify allocations, the element created in the model to represent it should be more formally linked to the corresponding Allocate relationships.

  • Reported: SysML 1.4 — Thu, 11 Feb 2016 15:33 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: AllocateActivityPartition should be more formaly related to allocation Relationship

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

A discarded resolution still appears in the ballot

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Resolution SYSML-331 was discarded from ballot#8, replaced by SYSMLR-359 then added to ballot#9.

    However in ballot#9, SYSMLR-331 still appears beside SYSMLR-359 with all the votes casted in the ballot#8!

    It's rather confusing because, in addition, JIRA said that we already voted for this ballot, which is not true!

    Can we fix this?

    Thanks

  • Reported: SysML 1.4 — Fri, 21 Oct 2016 05:56 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: A discarded resolution still appears in the ballot

    The issue is about a Jira bug, and not about SysML

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Requirement ID should be immutable

  • Legacy Issue Number: 19764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Requirement IDs, as currently specified by the standard and implemented by vendors, are not adequate to ensure robust traceability outside MBSE models. The standard describes ID as "The unique Id of the requirement”. I would suggest replacing this sentence with "The unique and immutable Id of the requirement." This immutable characteristic is key to ensure robust traceability throughout a project with external stakeholders and documents.

    The current practice of using a hierarchical number for the ID is bad practice that should be discouraged, because a hierarchical ID will necessary change when the hierarchy is refactored, which is almost guaranteed to happen. This breaks traceability. I recognize that there is also a need for a hierarchical ID, mainly to be used to sort requirement tables properly using this property. For that use case, I would suggest a new ID called HID with the following description: “A unique hierarchical identifier, used to organize requirements within a package”

    Since we now have two different IDs that serve two different purposes, we should give guidance for which one should be used as the prefix in front of the name, depending of the context. My suggestion is as follows:

    • In a traceability context, the ID should be the prefix shown in front of the name. For example, when showing the table column "Derived From", the ID should be the prefix shown, not the HID.
    • In a hierarchical context (for example, in the containment tree), the HID should be shown as the prefix in front of the name.
    • When in doubt, use the ID in preference over HID.
  • Reported: SysML 1.4 — Fri, 29 May 2015 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Requirement ID should be immutable

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Specify a specific part from a collection of parts on an IBD

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    There is no way of saying which part from a collection (i.e. a plural cardinality/multiplicity) is being shown and hence there is no clear and unambiguous way of showing multiple parts from a collection separately on an IBD. E.g. the spokes on a wheel is easily modelled in a BDD as a collection of spokes, but not easily set out in an IBD, whereas, individually named (by role) spokes can be set out in an IBD, but, for more than a few, this becomes awkward to show on a BDD.
    For at least ordered collections (i.e. plural multiplicities) of parts (aggregate roles) the traditional use of square bracket array notation could be used, e.g. mypart[10] would refer to the 10th instance of part collection called "mypart". For unordered collections a selector (i.e. query) would be required.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 17:47 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Specify a specific part from a collection of parts on an IBD

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Expand use of rake symbol for all decompositions

  • Legacy Issue Number: 19783
  • Status: closed  
  • Source: University of Detroit Mercy ( Mr. Michael J. Vinarcik)
  • Summary:

    I’d like to advocate for rakes on Call Operation nodes (that have associated methods) in the next SysML rev. We’re using operations extensively because they inherit nicely and have inputs/output parameters. By moving to Call Operations from Call Behaviors, we lose the rake that’s a visible sign you can drill deeper…so by using Call Operations with methods instead of Call Behaviors, we lose that visual cue.
    I put a stereotype with icons on the nodes as a fix, but I’d love to see it as a native function.

    I suggest that rake symbols should be expanded to include call operations on activity diagrams with methods attached (or any other situation in which drill-down is available).

  • Reported: SysML 1.4 — Tue, 9 Jun 2015 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Expand use of rake symbol for all decompositions

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Connectors are not allowed in bdd

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure D.23 depicts two blocks with ports that are connected by a connector.

  • Reported: SysML 1.5 — Thu, 29 Nov 2018 09:33 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove illegal connector/association

    Figure D.23 had, up through SysML 1.6, a bdd with a connector between the ports of two blocks. SysML 1.6 diagram was a slight modification of this, with an association between the blocks that was rendered through the ports. This is more legal, but ambiguous and doesn't meet the original intent. This proposal includes a replacement diagram without the offending connector. The diagram was generated out of the same model that generated the SysML 1.6 diagram, but with the association removed.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Numeric Literals as constraint block property parameter values

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    It would be very useful to have the ability to have literal values as parameter values to a constraint block property. (Helps with reuse of constraint blocks.) Even better, to be able to use named constants from a (shared) library package (i.e. a different namespace), which could combine a description of the value with quantity and unit attributes.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:26 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Numeric Literals as constraint block property parameter values

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Statements missing in the abstract syntax description

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description of stereotypes in the abstract syntax is missing all the "base_xxx" attributes that refer to the instances of extended elements. However this is required in order to specify the corresponding multiplicity and redefinition, if any.

    In addition, it should also be specified whether the corresponding stereotype is "required" or not. At that time, the only way to know it is to parse the normative XMI file.

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 07:18 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Statements missing in the abstract syntax description

    The issue was already fixed in SysML 1.6.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Description of model elements in generated document not consistent with specification

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The document that is generated from the model file defining the SysML profile contains descriptions of the model elements that are not consistent with the specification.

    Some description texts are completely missing, some are incomplete, and some have a different text than in the specification document.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:10 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Description of model elements in generated document not consistent with specification

    It is not a SysML issue, but an issue of the document generation tooling.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Typo in revised text of issue SYSML16-289

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typos in revised text for Annex C

    • Change "C.1.1 and C.1.2" to "C.1.2 and C.1.3".
    • Change "C.5 through C.7" to "C.4 through C.7".
  • Reported: SysML 1.5 — Mon, 5 Mar 2018 20:42 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Typo in revised text of issue SYSML16-289

    The typo refers to a typo in a revised text of a SysML 1.6 issue and is not in SysML 1.6 specification.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing property descriptions for Probability and Rate

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The stereotypes Probability and Rate in the Activities chapter have no description of their properties.

  • Reported: SysML 1.4 — Mon, 2 Jan 2017 13:01 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Missing property descriptions for Probability and Rate

    The issue was resolved in SysML 1.6.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

SysML Issue on Refine limitations

  • Key: SYSML17-57
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Refine limitations

    The refine relationship is not limited to only refine Requirement model elements. As mentioned in the cited text "it may be used to show how a text-based requirement refines a model element".

    The conclusion that this is not possible, because there is no appropriate derived property in the Requirement stereotype is not correct. However, the issue is for SysML 1.4. In SysML 1.6 the AbstractRequirement has a derived property to cover the model elements that are refined by a requirement.

    A diagram is a metaclass in UMLDI. Problem 2 in the issue description is not correct.

    The final comment in the issue description addresses a problem that is not relevant anymore since the ability of specifying many-to-many relationships like refine, satisfy, or verify was removed in a previous SysML version.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

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

  • Key: SYSML17-68
  • Legacy Issue Number: 16876
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Duplicate of SYSML17-52 and SYSML17-234

    Duplicate of SYSML17-52 and SYSML17-234

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Virtual member representing the whole RTF

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Would it be possible to create a special member in the RTF with no voting right (i.e. "assistant") , whose has the sysml-rtf@omg.org for email address?

    By adding it to the "watch this issue" list it would then become possible to notify the whole RTF automatically.

  • Reported: SysML 1.6 — Thu, 17 Jan 2019 13:48 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Not a SysML issue

    This is a JIRA feature request that was wrongly reported as a SysML issue. It is replaced by SUP-498

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Property Based Requirements

  • Key: SYSML17-71
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Property Based Requirements

    The issue was resolved with SysML 1.4 and the new SysML element AbstractRequirement that enables the definition of different model elements being a requirement.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Support BDD's for State Machines

  • Key: SYSML17-32
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Support BDD's for State Machines

    StateMachine can be depicted in block definition diagrams since they are a specialization of Behavior that is a specialization of Class.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inability to specify partial allocation and requriements satisfaction

  • Key: SYSML17-86
  • 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Inability to specify partial allocation and requriements satisfaction

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

ProxyPort with FlowProperties

  • Key: SYSML17-98
  • Legacy Issue Number: 18676
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: ProxyPort with FlowProperties

    The bindings between port properties and, for example, adjunct properties for behavior parameters are context-specific. The statement in the issue text "I can't use context-specific binding relationships" is wrong.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex B / Figure B.9

  • Key: SYSML17-20
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Diagram is changed as of formal/17-05-01

    Reporter tagged this from formal/07-09-01 referring to diagram B.9.

    As of formal/15-06-03 the issue remains but the diagram has changed name to D.9.

    In formal/17-05-01 the ambiguous name symbol was deleted from the diagram and so the issue can be closed with no change.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

How to refer to properties of an extension?

  • Key: SYSML17-78
  • Legacy Issue Number: 18168
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: How to refer to properties of an extension?

    A resolution would require new features of SysML.

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSML17-66
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: InstanceSpecifications for exactly one instance

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

InstanceSpecification equality

  • Key: SYSML17-67
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: InstanceSpecification equality

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Hanging Clauses Throughout SysML 1.4

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    ISO/IEC Directives Part 2 2016 clause 22 states than each and every clause and subclause of the spec should be numbered, and hanging clauses should be avoided. Any numbered clause containing text or figures than that has a subordinate numbered clause becomes a hanging clause, because it does not have a unique number assigned to it.

    List of known hanging clauses in SysML 1.4 (exclusive of un-numbered ‘subpart’ text on pages 1, 19, 103, 145, and 185):
    6.2 page 17
    7.1 page 21
    7.3.2 page 26 (figure only)
    8.3.1.1 page 42
    8.3.1.2 page 44
    8.3.2 page 47 (figures only)
    8.3.3.1 page 59 (figure only)
    8.3.3.2 page 60 (figure only)
    9.1 page 71
    9.3.2 page 79 (figures only)
    10.3.2 page 100 (figure only)
    11.1 page 105
    11.3.1 page 114
    11.3.2 page 117 (both text and figure)
    11.3.3.1 page 121 (both text and figure)
    12.3.1 page 133
    15.3.2 page 150 (figure only)
    15.4 page 152 (both text and figure)
    15.4.2 page 153 (both text and figure)
    16.3.2 page 164 (figure only)
    16.4 page 168
    17.2.1 page 176 (figure only)
    17.2.2 page 178 (figure only)
    B.2 page 194 (figure only)
    C.1 page 203
    E.5.2 page 254 (both figures and text)
    E.6.5 page 286 (both figure and text)
    Annex F (no paragraph number)
    G.4 page 318

  • Reported: SysML 1.4 — Thu, 18 Aug 2016 15:39 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Hanging Clauses Throughout SysML 1.4

    The issue affects SysML 1.4 and was fixed in the meantime (see SysML 1.6.).

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Legacy Issue Number: 19062
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Deprecate Unit and QuantityKind stereotypes in 1.4

    The issue asked for another solution than voted in a ballot for SysML 1.4. It is too late for this issue since the model elements were deleted in SysML 1.4.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

More than one View() operation allowed

  • Legacy Issue Number: 19623
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: More than one View() operation allowed

    The namespace semantic requires that there are only unique View() operations defined. They can have the same name, but must differ in the list of parameters. The call of the View() operation clearly selects exactly one View() operation.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Key: SYSML17-82
  • 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: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

    The AllocateActivityPartition allocates Actions only.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Annex B / Figure B.10

  • Key: SYSML17-19
  • 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: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Issue clarified by UML 2.5 and made irrelevent by SysML 1.6

    The original issue of this was with the formal gate on the sequence diagram Figure D.10.

    SysML 1.5 has Figure D.10 with a formal gate with an async StartVehicle message. This is supported by UML 17.2.4.6 "A formal Gate is just a point on the inside of the frame, as the end of a message. They may have an explicit name (see Figure 17.4)."

    SysML 1.6 has deleted the message originating from the diagram frame in general. This also solves this issue with no change.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

<>

  • Key: SYSML11-54
  • Legacy Issue Number: 11498
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    <<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too.

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 23 Aug 2021 13:39 GMT

The constraint#3 of NestedConnectorEnd could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The constraint#3 of NestedConnectorEnd could be advantageously replaced by making base_ConnectorEnd a redefinition of the base_Element property

  • Reported: SysML 1.5 — Thu, 31 May 2018 14:43 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as part of SYSML16-311:

    • Make base_ConnectorEnd a redefinition of base_Element property
    • Delete constraint#3
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Keyword signal in reception compartment is superfluous

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The resolution of issue SYSMLR-153 describes the reception compartment of blocks that was not yet covered by SysML. The notation of SYSMLR-153 is identical with the notation defined in the UML specification.

    The signal keyword before the reception is superfluous. The reception compartment already unambiguously depicts that only receptions are shown.

    I propose to remove the keyword <<signal>> from the notation.

  • Reported: SysML 1.4 — Sun, 28 Feb 2016 16:36 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Add a section in 8.3.1.1 to describe receptions compartment

    Description of receptions compartment is missing.
    Insert one similar to the other descriptions of compartments

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Error in the revised text for SYSML16-132

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Mr. Conrad Bock points out that the OCL for the InterfaceBlock::getConjugated() operation in the revised text approved in the corresponding resolution (i.e. SYSML16-289) that was included in Ballot#8 was wrong. Indeed, this OCL correspond to a obsolete version of the resolution that was based on Dependency.

    The right OCL for the body condition of that getConjugated() operation is:

    ~InterfaceBlock.allInstances()->any(ib | ib.original = self)
  • Reported: SysML 1.5 — Mon, 29 Oct 2018 20:44 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Fix the OCL code

    Fix the OCL code as suggested.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Composite properties allowed for InterfaceBlocks

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As discussed at Reston , issue SYSML16-100 shall be extended to include all kind of composite properties allowed on InterfaceBlocks

  • Reported: SysML 1.5 — Thu, 5 Apr 2018 14:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-100 (and SYSML16-274)

    Constraint to be modified to cover all kind of composite properties allowed.
    Revised text:
    Interface blocks' composite properties are either ports, value properties or flow properties

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Most constraints are missing their OCL statement

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Only few constraints specified in SysML v1.5 have a corresponding formal OCL statement. Even if not all of them can be expressed using SysML, most of them could. This would help clarifying then and will remove ambiguity that shall remain in their English description.

  • Reported: SysML 1.5 — Thu, 23 Mar 2017 17:18 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Provide OCL statements for SysML stereotype constraints everywhere possible

    The resolution will result in a version of the SysML profile models that will include OCL statements for constraints everywhere we will be able to write one or the sentence: "Cannot be expressed in OCL" otherwise

    Here is the URL to models in the SVN branch for this issue resolution: http://www.omgwiki.org/repos/SysML/branches/SYSML16-311

    Note: If you want to contribute leave a comment below, and don't forget to "lock" (SVN) but avoid keeping the version locked too long and commit your work in order to not block other contributions. Thanks!

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Arbitrary diagram linkage to model elements

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    Most modelling tools provide some means of connecting a model element to any of the diagrams in the model and then provide a means of (tool users) navigating through the linked diagrams by opening the linked diagrams directly from the nodes representing these model elements on a diagram. (The means for doing this is tool specific, although common conventions for following links exist in many GUI environments.) In general this is a very useful feature. Is it not time that the SysML standard acknowledged this and standardised it?
    Two further considerations arise:
    1. XMI support for denoting the model element diagram linkage, and
    2. The standardised means of indicating that a diagram node has linked diagrams, perhaps by the adornment with a defined glyph in a specified location on the nodes shape.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 17:10 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    Might be addressed by API in SysML20.

    Might be addressed by API in SysML20.
    Needs to be traced to SysML20 and addressed there.

    Out of scope of RTF.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Semantics consistency of conjugated behavior ports

  • Legacy Issue Number: 18952
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Resolved — SysML 1.6
  • Disposition Summary:

    Conjugation dependency proposal

    The conjugation mechanism can be implemented at type level by defining a new stereotype, specialized from InterfaceBock in order to specify a conjugated type.
    This conjugated InterfaceBlock definition shall have the same feature defined as the original type but – where applicable – with the inverted directions. Note that the corresponding features could be automatically computed or checked by the tool.
    In the conjugated InterfaceBlock, direction of any FlowProperty or DirectedFeature is inverted (i.e. as specified for a conjugated port today)

    To avoid any ambiguity or conflict the UML mechanism for port conjugation must be disabled this is achieved by adding a constraint to the SysML::Block stereotype so that all owned ports shall have their "isConjugated" property set to "false". In addition, and for consistency, the UML mechanism will be deprecated.

    In order to keep an equivalent notation one can give the conjugated interface block the same name than the original type with the tilde symbol "~" prepended but it is not required by this resolution.

    A migration procedure is provided for legacy models: for any port with isConjugated=true, get its type and look in the scope for an existing conjugated type. If none is found create it. Replace the port's type by that conjugated type and set its isConjugated property to false.

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Setting flow properties on blocks with multiple behavioral ports

  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Setting a flow property on blocks with multiple behavioral ports that also have that property causes the new value to propagate out through all the ports (see test case in B.3.2.3, Block with Multiple Behavior ProxyPorts in https://www.omg.org/spec/PSCS/1.1). Modelers should be able to specify which behavior port the value flows through.

  • Reported: SysML 1.5 — Fri, 27 Apr 2018 15:18 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Add flow property value action, onport

    Provide the requested capability

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Constraints on Satisfy and Verify should refer to AbstractRequirement

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Constraints owned by either Satisfy or Verify stereotype still refer to the SysML::Requirement stereotype while they should have been modified so that they refer to the AbstractRequirement stereotype added in 1.5

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 09:34 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as suggested by SYSML16-311
    Constraints owned by either Satisfy or Verify stereotype shall refer to SysML::AbstractRequirement instead of the SysML::Requirement stereotype.

    Revised Text:
    SysML::Satisfy::Constraint#1 shall be replaced by:
    The supplier shall be an element stereotyped by any subtype of «AbstractRequirement»

    AbstractRequirement.allInstances().base_NamedElement->includes(self.base_Abstraction.supplier)
    

    SysML::Verify::Constraint#1 shall be replaced by:
    The supplier shall be an element stereotyped by any subtype of «AbstractRequirement»

    AbstractRequirement.allInstances().base_NamedElement->includes(self.base_Abstraction.supplier)
    
  • Updated: Mon, 1 Apr 2019 18:17 GMT

ItemFlow constraint#3 does not make sense in every case

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    ItemFlow constraint#3 makes the implicit assumption that both source and target of an ItemFlow are properties:

    itemProperty shall be a property of the common (possibly indirect) owner of the source and the target.

    However they can be Classifiers as well.

  • Reported: SysML 1.5 — Tue, 12 Sep 2017 14:06 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as suggested by SYSML16-311.
    Revised text:
    If itemProperty has a value it shall be a property of the common (possibly indirect) owner of the source and the target.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Allocate constraint#3 does not make sense

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Allocate constraint#3 states:


    If subtypes of the «allocate» dependency are introduced to represent more specialized forms of allocation, then they shall have constraints applied to supplier and client as appropriate.

    This is neither clear nor verifiable. It should be removed

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 09:20 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    Remove the constraint #3 as suggested

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Clarify port usage patterns

  • Status: closed  
  • Source: GfSE e.V. ( Mr. Robert Karban)
  • Summary:

    The following sentence is misleading:

    9.1.3 Proxy Ports and Full Ports

    'SysML identifies two usage patterns for ports, one where ports act as proxies for their owning blocks
    or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).'

    There are in fact at least three usage patterns: normal (UML) ports, full, and proxy.

    There is a prevailing misunderstanding that normal ports should not be used at all in SysML.
    (There are dozens of places in the spec stating that normal ports still can be used.)

    This has lead to recent tool vendor errors not offering
    a basic ports compartment, although it is clearly specified and even shown in some figures.

    A single word might improve things:

    'SysML identifies two additional usage patterns for ports …’

    Or more verbosely:

    'SysML identifies two more specific usage patterns for ports in addition to standard ports …

  • Reported: SysML 1.5 — Sun, 5 Mar 2017 19:33 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    All usage kinds are defined

    The two "usage patterns" specified by the referenced text actually described two mutually exclusive options. A "third" option, if any will be not to choose between this two alternatives. This is specified by applying none of those SysML stereotype or, in other words, to use the UML concept of port natively.

    So, I would not be correct to tell about "additional usage patterns".

    In addition there is this sentence at the end of the first paragraph of section 9.1.3: "Ports that are not specified as proxy or full are simply called “ports.", then in the next paragraph : "Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full. Modelers can choose between
    proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology"

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Incorrect constraint [2] on InterfaceBlock

  • 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Reword constraint#2

    Modify constrain#2 as suggested and in order to merge with issue SYSML16-455 as well, as part of SYSML16-274:
    Revised text:
    Interface blocks' composite properties are either ports, value properties or flow properties_

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Instance for Initial values

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    SysML spec says:
    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.

    There is no reason why instance should be unnamed or must be owned in particular package, the same as blocks are defined in. Opposite, it would be very useful to use named instances and other packages for ownership.

    Proposal : remove both redundant constraints from the text.

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

    Instance For Initial Values

    Remove the following sentence in section 8.3.2.1 paragraph 11:

    " The instance Specification shall be unnamed and owned by the same package that own the outermost containing block for which the initial values are being specified."

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Proxy port “complete” specification (§ 9.3.2.12):

  • Legacy Issue Number: 18909
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Resolved — SysML 1.6
  • Disposition Summary:

    Clarification

    §9.3.2.12 “ProxyPort”, states the following:
    1. “Completely specified proxy ports must be connected to internal parts or be behavioral ”
    2. “Internal connectors to ports are the ones inside the port’s owner (specifically, they are the ones that do not have a UML partwithPort on the connector end linked to the port, assuming NestedConnectorEnd is not applied to that end, or if NestedConnectorEnd is applied to that end, they are the connectors that have only ports in the property path of that end) ”
    3. “When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate as if they were to those parts, and flows and invocations it receives from those parts as if they were to the outside ”
    4. “This aggregate is not a separate element of the system, and only groups the internal parts for purposes of binding to the proxy port ”
    YBE: according to the above, we can infer that a proxy port which is no more than an aggregate of its nested ports is “completely specified” if all its nested ports are either connected to internal part or behavioral

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Diagram guidelines uses excluded UML element

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Appendix A.2 Guidelines (for Diagrams) says:

    "SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to
    the artifact model element. Properties of the artifact can capture information about the document. Use a «trace»
    abstraction to relate the document to model elements. The document can represent text that is contained in the related
    model elements."

    However, the artifact model element is excluded from SysML and cannot be used (see table 4.1).

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 09:55 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Remove diagram guideline about representing documents

    The diagram guideline in section A.2 refers to the excluded UML model element Artifact.

    "SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to
    the artifact model element. Properties of the artifact can capture information about the document. Use a «trace»
    abstraction to relate the document to model elements. The document can represent text that is contained in the related
    model elements."

    The guideline should be removed. How to represent documents in SysML models must be answered by methodologies.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Change keyword of binding connector from "equal" to "="

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The keyword "equal" needs a lot of space in a diagram. It would be better to have shorter notation for binding connectors.

    The proposal is to use the equal sign = instead of the keyword with guillements <<equal>>.

  • Reported: SysML 1.5 — Wed, 17 Jan 2018 15:55 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Proposal: Change keyword of binding connector from "equal" to "="

    Add the equal sign = instead of the keyword <<equal>> as an additional alternate notation for binding connectors. Binding connectors are often used in internal block diagrams and the keyword <<equal>> clutters the diagram. The equal sign is much shorter and the meaning is commonly known.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Constraints for Refine and Trace can be improved

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Refine constraint#1 states:

    The Refine stereotype shall only be applied to dependencies

    and Refine constraint#2 states:

    Dependencies with a Refine stereotype or one of its specializations applied shall have exactly one client and one supplier.

    • SysML::Refine specializes StandardProfile::Refine that extends UML::Abstraction. So the constraints should refer to UML::Abstraction rather than to UML::Dependency
    • constraint#1 could be replaced by a redefinition

    The same with the SysML::Trace stererotype

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 08:46 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as suggested by SYSML16-311:
    1/ Refine stereotype:

    • Add a base_Abstraction property to the SysML::Requirements::Refine stereotype with the type UML::Abstraction and a multiplicity of [1] and make it a redefinition of both UML::StandardProfile::Refine::base_Abstraction and SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship
    • Delete Constraint#1 from SysML::Requirements::Refine
    • Constraint# 2 textual statement shall be replaced by:
      Abstractions with a Refine stereotype or one of its specializations applied shall have exactly one client and one supplier
    • Constraint# 2 OCL statement shall be:
      self.base_Abstraction.client->size()=1 and self.base_Abstraction.supplier->size()=1

    2/ Trace stereotype:

    • Add a base_Abstraction property to the SysML::Requirements::Trace stereotype with the type UML::Abstraction and a multiplicity of [1] and make it a redefinition of both UML::StandardProfile::Trace::base_Abstraction and SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship
    • Delete Constraint#1 from SysML::Requirements::Trace
    • Constraint# 2 textual statement shall be replaced by:
      Abstractions with a Trace stereotype or one of its specializations applied shall have exactly one client and one supplier
    • Constraint# 2 OCL statement shall be:
      self.base_Abstraction.client->size()=1 and self.base_Abstraction.supplier->size()=1
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Copy constraints #2 and #3 shoud be merged together

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Copy constraint#2 states:

    The text property of the client requirement is constrained to be a read-only copy of the text property of the supplier requirement.

    While Copy constraint#3 states:

    Constraint [2] is applied recursively to all subrequirements.

    They should be merged in one unique constraint so that the requested recursivity could be formally stated in OCL using an helper operation

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 08:33 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SysML16-274

    To be fixed as part of SYSML16-311

    • Add an "Operations" sub clause with the following operation definition:
      isCopy (in req1 : AbstractRequirement, in req2 : AbstractRequirement) : Boolean [1]
    bodyCondition:
    let subReq1: Set(AbstractRequirement) = AbstractRequirement.allInstances()->select(r | req1.base_NamedElement.ownedElement->includes(r.base_NamedElement)) in
    let subReq2: Set(AbstractRequirement) = AbstractRequirement.allInstances()->select(r | req2.base_NamedElement.ownedElement->includes(r.base_NamedElement)) in
    req1.text = req2.text and
    subReq1->size() = subReq2->size() and
    subReq1->forAll(r1 | subReq2->exists(r2 | self.isCopy(r1, r2) ))
    
    • Constraint#2's textual statement shall be replaced by:
      The text property of the client requirement is constrained to be a read-only copy of the text property of the supplier requirement and this applies recursively to all subrequirements (i.e. requirements related by a containement relationship)
    • Constraint#2's OCL statement shall be:
      let cltReq: AbstractRequirement = AbstractRequirement.allInstances()->any(r | self.base_Abstraction.client->includes(r.base_NamedElement)) in
      let supReq: AbstractRequirement = AbstractRequirement.allInstances()->any(r | self.base_Abstraction.supplier->includes(r.base_NamedElement)) in
      self.isCopy(cltReq, supReq)
      
    • Constrain#3 shall be deleted
  • Updated: Mon, 1 Apr 2019 18:17 GMT

The constraint#6 of TriggerOnNestedPort could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The constraint#6 of TriggerOnNestedPort could be advantageously replaced by making base_Trigger a redefinition of base_Element property

  • Reported: SysML 1.5 — Wed, 13 Sep 2017 06:37 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as part of SYSML16-311:

    • Make base_Trigger a redefinition of base_Element property
    • Delete constraint#6
  • Updated: Mon, 1 Apr 2019 18:17 GMT

The statement of TriggerOnNestedPort constraint#5 is wrong

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The constraint#5 of TriggerOnNestedPort states:


    The type of the port at the last position of the onNestedPort list must own or inherit the port of the stereotyped invocation action.

    This constraint should refer to the stereotyped trigger.

  • Reported: SysML 1.5 — Wed, 13 Sep 2017 06:33 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    Fix as part of SYSML16-311 as suggested.

    Constraint #5 textual statement shall be replaced by:
    The type of the port at the last position of the onNestedPort list must own or inherit the port of the stereotyped trigger

  • Updated: Mon, 1 Apr 2019 18:17 GMT

The statement of TriggerOnNestedPort constraint#4 is not appropriate

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The TriggerOnNestedPort constraint#4 is stated:

    The first constraint of ElementPropertyPath shall apply to onNestedPort

    Such a reference to another constraint that, in addition, requires substituting words in order to be contextualized is not appropriate. It shall be properly stated in a straightforward way.

  • Reported: SysML 1.5 — Wed, 13 Sep 2017 06:25 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SysML16-274

    To be fixed as part of SYSML16-311:

    • The textual statement shall be replaced by:
      The port at each successive position of the onNestedPort attribute, following the first position, shall be owned by the Block that types the port at the immediately preceding position, or a generalization of the Block.
    • The corresponding OCL statement shall be:
      self.onNestedPort->size() >1 implies self.onNestedPort->subSequence(2, self.onNestedPort->size())->forAll(p |
      let np: UML::Port = self.onNestedPort->at(self.onNestedPort->indexOf(p)-1) in
      let owners: Set(UML::Classifier) = np.type.oclAsType(UML::Classifier)->including(np.type.oclAsType(UML::Classifier)) in
      owners->includes(p.owner))
  • Updated: Mon, 1 Apr 2019 18:17 GMT

ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    ItemFlows constraint#1 implicitly implies that the corresponding InformationFlow has no more than one target and one source:

    A Connector or an Association, or an inherited Association shall exist between the source and the target of the
    InformationFlow.

    However this is not explicitly stated. Constraint#1 should be improved or a specific constraint shall be added.

  • Reported: SysML 1.5 — Tue, 12 Sep 2017 13:45 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    The constraint does not assume that

    It should be a way for the flow to occur between every source and every target ("star connection pattern").

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Rate constraint#2 is ambiguous

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Rate constraint#2 states:

    The rate of a parameter shall be less than or equal to rates on edges that come into or go out from pins and parameters nodes corresponding to the parameter

    This is ambiguous since SysML::Rate::rate is typed by UML::InstanceSpecification for which "less than or equal to" is not defined

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 08:49 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as part of SYSML16-311 by assuming than the specification of Rate can be given a OCL::Real value:

    The complete OCL statement for this constraint shall be:

    self.base_Parameter->notEmpty() implies (
    	let nodes: Set(UML::ObjectNode) =
    	if self.base_Parameter.owner.oclIsKindOf(UML::Behavior) then
    		let pOwner: UML::Behavior = self.base_Parameter.owner.oclAsType(UML::Behavior) in
    		UML::CallBehaviorAction.allInstances()->select(a | a.behavior = pOwner)->collect(a | a.argument->at(pOwner.ownedParameter->indexOf(self.base_Parameter)))
    		->union(UML::StartObjectBehaviorAction.allInstances()->select(a | a.behavior() = pOwner)->collect(a | a.argument->at(pOwner.ownedParameter->indexOf(self.base_Parameter))))
    		->union(UML::ActivityParameterNode.allInstances()->select(n | n.parameter = self.base_Parameter))
    		->asSet()		
    	else if self.base_Parameter.owner.oclIsKindOf(UML::Operation) then
    		let pOwner: UML::Operation = self.base_Parameter.owner.oclAsType(UML::Operation) in
    		UML::CallOperationAction.allInstances()->select(a | a.operation = pOwner)->collect(a | a.argument->at(pOwner.ownedParameter->indexOf(self.base_Parameter)))->asSet()
    	else
    		Set(UML::ObjectNode){}
    	endif endif in
    	nodes.incoming->flatten()->union(nodes.outgoing->flatten())
    	->forAll(e | let eRate: Rate = Rate.allInstances()->any(r |  r.base_ActivityEdge=e) in
    		(not eRate.oclIsUndefined() and self.rate. specification.realValue() <= eRate.rate. specification.realValue()))
    )
    
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Probability constraint#1 is ambiguous

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Probability constraint#1 states:


    The «probability» stereotype shall only be applied to activity edges that have decision nodes or object nodes as sources, or to output parameter sets.

    This is ambiguous since ParameterSets have no direction, only their parameters have.

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 07:48 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    A constraint defined by UML on parameter sets clarify it

    See UML::ParameterSet constraint named "same_parameterized_entity": its implies that all parameters of a set have the same direction

  • Updated: Mon, 1 Apr 2019 18:17 GMT

The OCL statement of ConstraintBlock constraint#3 is wrong

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    ConstraintBlock constraint#3 states:


    Any property of a block that is typed by a ConstraintBlock shall have composite aggregation.

    And the following OCL statement is provided


    self.ownedAttribute->forAll(p | p.type.oclIsKindOf(ConstraintBlock) implies p.aggregation = #composite)

    The OCL is invalid and wrong since "self" refers to the stereotype instance while this is the property typed by the ConstraintBlock which is constrained

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 06:52 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    Fix the OCL statement as proposed in the comment as part of SYSML16-311:

    self.base_Class.ownedAttribute->forAll(p| p.isComposite)

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Most diagram headers in document are not consistent with Appendix A, p 189.

  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The majority of diagrams with frames have problems with their headers.
    The types of problems are as follows:
    1) Just the diagram type (no element name, type, diagram type)
    2) Stereotypes in the header (not in the diagramusage field)
    3) Use of element type not listed in the Appendix (e.g., activity)
    4) Can't tell if the text field is an element name or a diagram name
    5) All text, not just the diagram type, is bold.
    6) Non-obvious element type (block, package, ?)

    These problems make the spec look like it was carelessly made. When the results are ambiguous or unclear, it encourages sloppy modeling by users.

  • Reported: SysML 1.4 — Thu, 5 Nov 2015 22:02 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Most diagram headers in document are not consistent with Appendix A, p 189.

    as part of the automatic generation of the document the headers will be consistent.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    the constraint#5 of InvocationOnNestedPortAction stereotype states:


    InvocationOnNestedPortAction shall only be applied to invocation actions

    This is because it inherits from ElementPropertyPath the ability to be potentially applied to any UML::Element.

    However we could easily restrict this by making its base_InvocationAction property a redefinition of the base_Element property of its parent.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 07:51 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as suggested by SYSML16-311:

    • Make the base_InvocationAction property a redefinition of the base_Element property of its parent stereotype.
    • Delete constraint #5
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Constraints redundancy in DirectedRelationshipPropertyPath

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The 4 first constraints of DirectedRelationshipPropertyPath are defined as follows:

    [1]sourceContext shall have a value when source is a property, otherwise it shall not have a value.
    [2]targetContext shall have a value when target is a property, otherwise it shall not have a value.
    [3]source shall be a property when sourcePropertyPath has a value.
    [4]target shall be a property when targetPropertyPath has a value.

    #1 implies #3 and #2 implies #4, so #3 and #4 are redundant and should be deleted.

  • Reported: SysML 1.5 — Thu, 10 Aug 2017 12:38 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Reporter is wrong

    Reporter was confused, nothing wrong here.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Constraint [4] of a Block says:

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

    The referenced constraint in the UML metamodel does not exist. The UML specification says:

    A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.

    I propose to remove the constraint [4], i.e. to allow to model part properties without an association. The reduces the number of model elements (1 property versus 2 properties + 1 association), makes the model simpler for the model builder and user, and reduces the effort for model maintenance.

    In particular it is valuable when using generalization and redefinition. Without an association an inherited property could simply be redefined. An inherited property defined by an association that should be redefined, requires to create a new association that specializes the association and lots of redefinitions. That makes modeling very cumbersome.

  • Reported: SysML 1.4 — Fri, 12 Feb 2016 09:41 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Remove constraint [4] from the Block stereotype: Block-typed properties must be defined by an association

    There is no justification for the constraint [4]. Without the constraint is still allowed to define those properties by an association, but it is not mandatory.

    [4] In the UML metamodel on which SysML is built, a Property that is typed by a block must [sic] 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.)

    Removing Block constraint [4] enables more efficient implementation of applications that don't depend much on graphics, but have very large numbers of associated blocks, possibly importing from other systems.

    However, in order to avoid any ambiguity, the association-like notation which was not used so far in SysML because of this constraint#4 (see SYSML16-314) need to be explicitly excluded from SysML.

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

BoundReference constraint#3 is unclear

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    BoundReference constraint#3 states the following:

    The role of boundEnd shall be a property accessible by navigation from instances of the block owning the property to which BoundReference is applied, but shall not be the property to which BoundReference is applied, or one that it is related to by redefinition.

    It's not clear what "navigable" means here. Please clarify.

  • Reported: SysML 1.5 — Tue, 8 Aug 2017 15:18 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    Clarify as suggested as part of SYSML16-311.
    Revised text:

    self.base_Property.association->notEmpty() and 
    self.boundEnd.definingEnd->notEmpty() and
    self.base_Property.association.navigableOwnedEnd->includes(self.boundEnd.definingEnd)
    
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Typo in AdjunctProperty Constraint#10

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The constraint#10 of AdjunctProperty is specified by the following sentence, which does not make sense:

    Properties with AdjunctProperty applied that have a Variable or Parameter applied shall have a lower multiplicity the same as or lower than the lower multiplicity of the Variable or Parameter, and an upper multiplicity the same as or higher than the upper multiplicity of the Variable or Parameter.

    In addition the statement could be simplified since this should be extended to any AdjunctProperty for which the principal is a kind of MultiplicityElement

  • Reported: SysML 1.5 — Tue, 8 Aug 2017 12:35 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Fix constraint#10

    Reword as proposed, as part of SYSML16-274:
    Properties with AdjunctProperty applied that have a Variable or Parameter as principal shall have a lower multiplicity the same as or lower than the lower multiplicity of their principal, and an upper multiplicity the same as or higher than the upper multiplicity of their principal.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Update SysML references to UML model library StandardProfileL2

  • Legacy Issue Number: 19123
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    SysML references to UML StandardProfile

    The references to the UML StandardProfile were already fixed with SysML 1.4.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Allocate constraint#1 could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Allocate constraint#1 states:

    The Allocate stereotype shall only be applied to abstractions

    Could be removed if its base_Abstraction property redefines the base_DirectedRelationship property it inherits from DirectedRelationship
    PropertyPath

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 09:14 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as part of SYSML16-311 by making base_Abstraction a redefinition of base_DirectedRelationship.

    Constraint#1 can then be removed

  • Updated: Mon, 1 Apr 2019 18:17 GMT

The statement of InvocationOnNestedPortAction constraint#3 is not appropriate

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The InvocationOnNestedPortAction constraint#3 is stated:

    The first constraint of ElementPropertyPath shall apply to onNestedPort

    Such a reference to another constraint that, in addition, requires substituting words in order to be contextualized is not appropriate. It shall be properly stated in a straightforward way.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 07:23 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as part of SYSML16-311 directly in the OCL statement:

    The SysML::ElementPropertyPath::Constraint#1 states:
    The property at each successive position of the propertyPath attribute, following the first position, shall be owned by the Block or ValueType that types the property at the immediately preceding position, or a generalization of the Block or ValueType.

    So the OCL code for SysML::InvocationOnNestedPortAction::Constraint#3 shall be:
    The port at each successive position of the onNestedPort attribute, following the first position, shall be owned by the Block that types the port at the immediately preceding position, or a generalization of that Block .

    self.onNestedPort->size() > 1 implies self.propertyPath->subSequence(2, self.onNestedPort->size())->forAll(p |
    let pp: UML::Property = self.onNestedPort->at(self.onNestedPort->indexOf(p)-1) in
    let owners: Set(UML::Classifier) = pp.type.oclAsType(UML::Classifier)->including(pp.type.oclAsType(UML::Classifier)) in
    owners->includes(p.owner))
    
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    InvocationOnNestedPortAction constraint #2 states:

    The port at the first position in the onNestedPort list shall be owned (directly or via inheritance) by a block that types the target pin of the invocation action, or one of the block’s generalizations

    However the InvocationAction metaclass has no "target" pin, only some of its subclasses have.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 07:14 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    To be fixed as suggested by SYSML16-311.
    The principle of the resolution will be to write the OCL code so that each possible case is considered:

    let target: UML::InputPin = if self.base_InvocationAction.oclIsKindOf(UML::CallOperationAction) then 
    	self.base_InvocationAction.oclAsType(UML::CallOperationAction).target
    else if self.base_InvocationAction.oclIsKindOf(UML::SendSignalAction) then 
    	self.base_InvocationAction.oclAsType(UML::SendSignalAction).target
    else if self.base_InvocationAction.oclIsKindOf(UML::SendObjectAction) then 
    	self.base_InvocationAction.oclAsType(UML::SendObjectAction).target
    else
    	invalid
    endif endif endif in
    not target.oclIsUndefined() and (
    let target_type: UML::Class = Block.allInstances()->any(b | b.base_Class = target.type).base_Class in
    not target_type.oclIsUndefined() and target_type.allFeatures()->includes(self.onNestedPort->first()))
    
  • Updated: Mon, 1 Apr 2019 18:17 GMT

Issue on Block constraint#4

  • Key: SYSML16-80
  • Legacy Issue Number: 16726
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Same as SYSML16-154

    Duplicate SYSML16-154

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Problems with property-specific types

  • Key: SYSML16-76
  • Legacy Issue Number: 16636
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. 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.

    CB, 2018-05-03: Address interaction with property subsetting/redefinition. For example redefinition that doesn't change the PST will cause it to be owned twice, because is repeated in the redefining property.

    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: Resolved — SysML 1.6
  • Disposition Summary:

    PST clarifications, minor corrections

    The purpose of this resolution is to clarify the semantics of the PropertySpecificType stereotype and to fix minor issues with its current description

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Constraint [5] should include specializations of Requirement

  • 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Fix constraint#5

    Fix constraint#5 as suggested, as part of SYSML16-274
    revised text:
    A nested classifier of a class stereotyped by Requirement or one of its specializations shall also be stereotyped by Requirement or one of its specializations

  • Updated: Mon, 1 Apr 2019 18:17 GMT

remove figure numbers from diagram frames

  • Key: SYSML16-92
  • Legacy Issue Number: 17423
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. 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: Resolved — SysML 1.6
  • Disposition Summary:

    Remove figure numbers from diagram names

    Some figure numbers in diagram names are still there in SysML 1.5, and they are out-of-sync with the numbering in the document.

    To decouple them we remove all numberings from the diagrams as proposed.

    The following mentioned figures are already fixed in SysML 1.5:
    Figure 4.2., Figure 4.3

    Figure C.35 is D.38, and C.36 is D.39 in SysML 1.5

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Provide support to capture engineering quantities and support intricate calculations

  • Status: closed  
  • Source: GfSE e.V. ( Mr. Robert Karban)
  • Summary:

    There is no SysML 1.6 RTF jira project yet, so I submit here.
    There is the need to capture engineering quantities and support intricate calculations than the base SysML semantics do.
    it might be worth formulating to SysML 1.6 to get initial capability while refining the approach for SysML 2.
    The attached proposal has been worked out with Bjorn Cole during OMG meetings.

  • Reported: SysML 1.4 — Fri, 30 Dec 2016 19:07 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    Out of scope for SysML RTF

    This is partially already addressed by MARTE.
    Decide how to address it in MARTE2 and SysML20 and find agreement among them how to handle this features in uipcoming meetings. Also relevant for Precise Semantics of Time WG,
    Trace it to those three.

    Out of scope for SysML RTF.

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

The association-like notation is ambiguous

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In our discussion about SYSML16-308, Mr. Conrad Bock pointed out that the association-like notation provided by UML is ambiguous.

    See below:

    In the figure below the "size" attribute is not part of an association this is only an "association-like" notation that UML allows. The point is that there in no multiplicity and the opposite side because there is no corresponding role. By the way, multiplicity on this opposite side is not constrained (i.e. it is "0..*") while with a "true" association, multiplicities that are not shown are often interpreted by some reader to be "1..1" (even if the UML specification explicitly say that: "If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model")

    In order to fix this we can either:

    • propose a better notation
    • deprecate this notation
  • Reported: SysML 1.5 — Mon, 10 Jul 2017 07:17 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merge with SYSML16-154

    It makes sense to merge this issue with SYSML16-154 (about Block constraint#4) in order to provide a consistent resolution.

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

<> should be a reference (dashed box)

  • 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: Resolved — SysML 1.6
  • Disposition Summary:

    ParticipantProperty boxes have dashed lines

    Constraint [3] of ParticipantProperty says:

    [3]The aggregation of a property stereotyped by ParticipantProperty shall be none.

    Table 8.2 clearly depicts that ParticipantProperty boxes have dashed lines.

    There are more examples for this wrong notation in the specification:
    table 9.1, table 9.2, figure 9.9, figure 9.14, figure 9.16

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Cannot navigate and represent deep nested defining feature in a slot

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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: Transfered — SysML 1.6
  • Disposition Summary:

    Transfer to UML: Slot defining feature

    The core of the problem has its origin in the UML specification.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Parsing Text in Requirements

  • Key: SYSML16-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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Duplicate of SYSML16-34

    Duplicate of SYSML16-34, out of scope

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Inability to represent dependent, independent parameters on constraint properties

  • Key: SYSML16-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: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    To be traced to SysML20

    More a natural evolution of the language, adding new features. Therefore out of scope for RTF.
    Needs to be traced to SysML20 and addressed there.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-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: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    Needs to be traced to SysML20.

    MARTE currently allows to define variables in text using $ sign.

    Needs to be traced to SysML20.
    Out of scope for RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Section: 8/8.3.2 Inability to efficiently capture datasets

  • Key: SYSML16-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: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    *new feature *

    to be transferred to SysML v2

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Nested diagrams in SysML

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Are nested diagrams allowed in SysML?

    I could not find any description that it is allowed. However, figure E.31 shows an example of nested diagrams: a parametric diagram is shown in a block definition diagram.

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 10:02 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Nested diagrams are not allowed

    Either the UML specification nor the SysML specification says something about nested diagrams. Although it could be a useful feature, it is currently not allowed.

    Figure E.31 has two nested diagrams. The diagram in the upper right corner shows a subset of the other nested diagram and could be removed.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Binding connectors have no keyword syntax in parametric diagrams

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to table 10.2. a binding connector in a parametric diagram is depicted as a solid line without a keyword.

    Figure E.31 shows a binding connector in a parametric diagram with keyword <<equal>>.

    I propose to remove the keyword in figure E.31 and to add a section below 10.3.1.2 Parametric Diagram to say that the binding connector keyword is not shown in parametric diagrams.

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 09:33 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Clarify that binding connectors are depicted without keyword in parametric diagrams

    The diagram elements table for internal block diagrams defines a keyword <<equal>> for binding connectors. The diagram elements table for parametric diagrams defines the notation without a keyword. However, the appendix shows an example of a parametric diagram with a binding connector and keyword <<equal>>.

    Although it is unusual, it is allowed to have both - normal and binding connectors - in a parametric diagram. The binding connector keyword is important to distinguish the connector kinds.

    The diagram elements table 10.2 should depict the binding connector keyword. There is no need to update parametric diagram examples in the specification document, because it is still allowed to discard the keyword (see diagram table of binding connector).

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Typo in xmi file for orderedMember

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    There is a typo in the xmi file for ElementGroup orderedMember

    See http://www.omg.org/spec/SysML/20150709/SysML.xmi
    <ownedAttribute
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber" xmi:type="uml:Property">
    <name>orderedMemeber</name>
    <isOrdered>true</isOrdered>
    <lowerValue
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_lowerValue" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_lowerValue" xmi:type="uml:LiteralInteger">
    </lowerValue>
    <upperValue
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_upperValue" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_upperValue" xmi:type="uml:LiteralUnlimitedNatural">
    <value>*</value>
    </upperValue>
    <type href="http://www.omg.org/spec/UML/20131001/UML.xmi#Element"/>
    <subsettedProperty xmi:idref="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.member"/>
    </ownedAttribute>

    Task replace orderedMemeber by orderedMember to be compliant with the pdf norm.

  • Reported: SysML 1.4 — Tue, 21 Mar 2017 08:39 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Fix the typo in the source model

    Fix the typo in the source model so that the SysML::ElementGroup::orderedMember feature is correctly spelled.

    Note that, as a consequence, its xmi:id will change as well.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Allow a Requirement to be contained on Any Diagram

  • Status: closed  
  • Source: Lockheed Martin ( Mrs. Laura E. Hart)
  • Summary:

    Strict implementation of a Requirement, which is based on a Class, restricts the expected usage of a requirement on diagrams that do not allow the visualization of a class. Not all tools enforce this, but those that do (MD), restrict the desired approaches to addressing requirements traceability and communication.

  • Reported: SysML 1.5 — Thu, 7 Dec 2017 00:44 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    SysML has no strict constraints about diagram content

    Section "16.3.1.4 Requirements on Other Diagrams" says "Requirements can also be represented on other diagrams to show their relationship to other model elements." If a tool enforces the usage of requirements on a diagram, it is a tool issue.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Equal sign for binding connector

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Would be useful to siupport an equal sign (=) for binding connectors. The current keyword is fine, but not very compact.

  • Reported: SysML 1.5 — Thu, 14 Dec 2017 16:35 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Duplicate of SYSML16-389

    SYSML16-389 also asks for the equal sign and has a proposal.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-79
  • 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: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    Out of scope

    Architecture of SysML20 will address if libraries will be a concept supported by it.
    Such a library/profile is a perfect candidate for SysML20.
    Although closer to Systems Engineering, it might also be a candidate for UML.

    Trace it to SysML20.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Binding Connector should not be typed

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Specification says

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.

    What would be the meaning of an Association used as a type for this Connector? I fail to see one. Should there be a Constraint, that doesn't allow a type for a Binding Connector?

    Suggestion
    Add following Constraint to the Binding Connector definition
    inv: type = null

  • Reported: SysML 1.4 — Fri, 26 Feb 2016 17:33 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Clarification of binding connector

    see SYSML16-319

  • Updated: Mon, 1 Apr 2019 18:17 GMT

References to UML specification in block constraints are not correct

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The Block constraint [5] quotes the UML specification. The reference to UML specification section 9.3.6 is not correct. The correct chapter number is 11.8.

    The block constraint [9] quotes the UML specification. The reference to UML specification section 9.3.7 is not correct. The correct chapter number is 11.8.

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 08:15 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Correct the references to the UML specification in block constraints [5] and [9]

    see issue description SYSML16-303

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Remove sentences about qualified associations in clause 8.3.1.3

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Remove the sentences

    "Qualified associations, shown in SysML by an open box at the end of an association path with a property name inside, are
    a specialized feature of UML that specifies how a property value can represent an identifier of an associated target. This
    capability, while useful for data modeling, does not seem essential to accomplish any of the SysML requirements for
    support of systems engineering."

    These sentences are partly incorrect (qualified associations are not shown in SysML), cover only an opinion, and could easily lead to misunderstandings. On the other side it only adds a minimal value.

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 08:02 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Remove sentences about qualified associations from 8.3.1.3

    see issue description SYSML16-300

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Remove the statement about N-ary associations from 8.3.1.3

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Remove the sentence "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." from the specification.

    N-ary associations are still excluded by the second sentence in the clause. The sentence to be removed added a motivation for the exclusion, but the statement "with no loss in expressive power" is not correct.

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 07:52 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Remove the statement about N-ary associations

    see issue description SYSML16-299

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Constant Block Value Properties

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    It would be very useful to have the ability to distinguish between value properties that are constants and those that are situational/dynamic. This may be more a case of allowing block property values to be declared as constants (or constraint values) – perhaps because they formalise values stated in requirements. Whereas the remaining block property values are derived from evaluation of the parametric constraints.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:18 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Constant Block value properties

    A constant block value property is modeled by defining a default value and setting isReadOnly to true.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Flow property description: incorrect wording (§9.3.2.7)

  • Legacy Issue Number: 18907
  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Resolved — SysML 1.6
  • Disposition Summary:

    Clarify the description of FlowProperty direction

    The current description use the term of "block" incorrectly which lead in sentences which do not make sense when attempting to deal with nested port and multiple-level structures.

    We need to make a clear distinction between a block, which defines characteristics of a type, and an instance which may hold and exchanges values, as specified by a type that classify it.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Section: Generalization of stereotyped elements

  • Key: SYSML16-26
  • Legacy Issue Number: 12255
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Generalization of stereotyped elements

    Comment from Conrad Bock:

    Inheritance doesn't mean features appear on specializations, it just means instances of those specialization support those features. This means stereotyped features are still stereotyped after "inheritance", because nothing actually happens in the model due to inheritance. Tools show inherited features for convenience. Redefinition does change the model in specializations, and as I understand it, redefining features (in specializations) need to have stereotype reapplied unfortunately. Same for subsetting features.

    Discussed during RTF meeting and decided to closed; no change.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Binding connectors in internal block diagrams must always show the keyword

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to table 8.4 it is allowed to show a binding connector without keyword <<equal>>. In that case it is identical with the normal Connector and makes the diagram ambiguous. The keyword should be mandatory.

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 09:47 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Make keyword notation for binding connectors in internal block diagrams mandatory

    Binding connectors without a keyword in internal block diagrams could not be distinguished from normal Connectors. The keyword must be mandatory to avoid ambiguity.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

View constraint#3 is incorrect

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    the constraint#3 of the SysML::View stereotype states the following:

    The derived values of the stakeholder attribute shall be the names of the classifiers stereotyped by Stakeholder that are [...]

    However the View::stakeholder attribute is typed by SysML::Stakeolder[*] and not by String, as in SysML versions before 1.4. We probably missed it in 1.4.

  • Reported: SysML 1.5 — Thu, 3 Aug 2017 09:06 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Fix the text of the constraint

    Modify the constraint statement so that it refers to element of the right type

  • Updated: Mon, 1 Apr 2019 18:17 GMT

View and Viewpoint Limitations in support of auto-view generation

  • 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    View and Viewpoint for auto-view generation

    The View and Viewpoint elements were changed with SysML 1.4 to address the points mentioned in the issue.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-90
  • Legacy Issue Number: 17373
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merge with: "Change keyword of binding connector from "equal" to "=""

    see discussion in comment section

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors

  • Legacy Issue Number: 18758
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Duplicate of SYSML16-389

    The issue is a duplicate of SYSML16-389

  • Updated: Mon, 1 Apr 2019 18:17 GMT

UnitAndQuantityKind figure missing block keyword

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 8.11 (Model library for Unit and QuantityKind), Unit and QuantityKind are blocks (at least according to the XMI), but they don't
    have the block keyword showing.

  • Reported: SysML 1.5 — Fri, 18 Aug 2017 18:31 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    *Add the block keyword to Unit and QuantityKind *

    According to section 8.3.1.1.2 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.

    However, it is a good style to be very clear in a specification and the figure will be updated anyway (see SYSML16-334).

  • Updated: Mon, 1 Apr 2019 18:17 GMT

NestedConnectorEnd violates UML "roles" constraint

  • Legacy Issue Number: 19813
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UML's constraint "UML::Connector::role" specifies that ConnectorEnds need to point to roles/parts owned by the Connector's structuredClassifier (direct or inherited).

    The specification draft 1.0 contained an explicit statement that SysML relaxed a limited number of the UML constraints ("roles" being one of them). This was e.g. mentioned in 0.11 on page 4 of document ad/2006-03-01.

    In the current 1.4 beta, section 4.4 "Extension Mechanisms" doesn't mention contraint relaxation as one of the applied techniques.

    Moreover, the specification of NestedConnectorEnd (8.3.1.2.6, 8.3.2.11) does not mention this relaxation either.

    Without a formal statement about this relaxation, I would conclude that the SysML spec conflicts with the UML spec.

  • Reported: SysML 1.4 — Tue, 30 Jun 2015 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Contraint relaxed concerning nestedConnectorEnds

    This is described in SysML 1.5 so no change is required:
    8.3.2.4 Block
    [9]The following constraint under 9.3.7, “ConnectorEnd” in the UML 2 standard is removed by SysML: “[3] The property held in self.partWithPort must [sic] not be a Port.”

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML specification document cleanups


ParticipantProperty keyword

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    SysML spec says:
    The keyword «participant» before a property name indicates the property is stereotyped by ParticipantProperty.

    Why and how SysML can redefine how stereotype is represented?
    According the UML spec, stereotype is represented by showing its original name in <<>>.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 18:32 GMT
  • Disposition: Transfered — SysML 1.6
  • Disposition Summary:

    ParticipantProperty keyword

    Considering the pattern has been broken upstream, defer to UML.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML::Block constraint#3 containts an incorrect assertion about UML

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    SysML::Block constraint#3 states the following


    In the UML metamodel on which SysML is built, any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association must [sic] not have a name and may not be defined as a navigable owned end of the association. (While the Property has a “name” property as defined by its NamedElement superclass, the value of the “name” property, which is optional, must be missing.)

    However there is no constraint in UML requiring that ends owned by the association have empty names. SysML can possibly require it but the added value is not obvious. I suggest focusing this constraint on the link between navigability and end ownership:

    Any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association may not be defined as a navigable owned end of the association.

  • Reported: SysML 1.5 — Thu, 6 Jul 2017 11:49 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    To be merged with the formalization of SysML constraints (SYSML16-274)

    To be merged with the formalization of SysML constraint which includes adding them explicitly in the model of the SysML profile

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Remove [sic] in block constraints

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Remove the string "[sic] " in the constraints on Block.

  • Reported: SysML 1.5 — Mon, 5 Jun 2017 11:22 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Remove [sic] statements in block constraints

    see issue SYSML16-295

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-44
  • Legacy Issue Number: 14059
  • Status: closed  
  • Source: International Business Machines ( Mr. 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-50

    Can be merged with SYSML16-50

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Incorrect statement about UML n-aries

  • Key: SYSML16-69
  • Legacy Issue Number: 16093
  • Status: closed  
  • Source: NIST ( Mr. 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: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Incorrect statements about N-ary associations removed

    The incorrect statements are removed by the resolution of issue SYSML16-299.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Compartment labelling rules

  • Key: SYSML16-67
  • Legacy Issue Number: 16057
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. 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: Resolved — SysML 1.6
  • Disposition Summary:

    Add general notation rules for compartment headers

    Add general notation rules for compartment headers

  • Updated: Mon, 1 Apr 2019 18:17 GMT

AdjunctProperty constraint#8 can be simplified

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    AdjunctProperty constraint#8 is partly redundant with constraint#3 since both require that the Property on which this stereotype is applied has a composite aggregation when the principal is typed by a CallAction.

    Constraint#8 could be simplified by not requiring it again and by focusing on the type of AdjunctProperties that have CallActions as principals. Also, it should be reworded to avoid using parenthesis.

  • Reported: SysML 1.5 — Thu, 3 Aug 2017 13:45 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Merged with SYSML16-274

    Merged with SYSML16-311 in order to provide one unique, global and consistent resolution for all the issues about constraints defined for SysML stereotypes, as far as possible.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Behavior Diagram Element tables imply diagrams can be nodes

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for JD.
    The Diagram Element tables for the behavior chapters are captioned:
    "Graphical nodes included in <behavior> diagrams"
    and each have a row for an entire diagram, rather than just elements of the diagrams. This implies diagrams can be nodes in other diagrams, for example that an activity diagram can be in another activity diagram without an intervening call behavior action, which isn't true.

  • Reported: SysML 1.4 — Fri, 9 Oct 2015 12:55 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Behavior Diagram Element tables imply diagrams can be nodes

    Duplicated by:
    http://issues.omg.org/browse/SYSML16-202, which was merged into 236.

    Node Name -> Notation Name

    Activity -> ActivityDiagram Frame and Heading, keep only heading and frame in example (remove nodes)
    SequenceDiagram -> SequenceDiagram Frame and Heading
    StateMachineDiagram -> StateMachineDiagram Frame and Heading

    Graphical nodes included in <diagramKind> diagrams -> Graphical notation of <diagramKind> diagrams

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Update description about extension of UML

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description on page 12 how SysML extends UML is based on UML 2.4. The package structure of UML has changed from UML 2.4 to UML 2.5. The bullet list must be updated accordingly. For instance SysML::ModelElements does not extend UML classes, but beside others UML common structures.

  • Reported: SysML 1.4 — Thu, 17 Sep 2015 09:02 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    *Update description about extension of UML *

    The UML 2.5 spec says on p.752/E.2:
    "The metaclasses and associations in UML 2.5 are organized in a package structure that corresponds to the specification
    clause structure."
    The bullet list describes to which parts of the UML spec SysML makes extensions in an informal way.
    In the underlying model there are stereotype extensions, e.g. <<NoBuffer>> extends ObjectNode. ObjectNode appears in the clause Activities.
    The Fig 11.8 shows this extension.

    The origin of the new bullet list reflects the elements in UML 2.5 which SysML extends.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML stereotype constraints should be named rather than numbered

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In the current SysML specification, every constraint defined as part of a stereotype is identified by a number.

    However the ownedRule property is not ordered. So this numbering does not make sense. Using meaningful names for all those constraints - just like UML does - would be more appropriate.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 14:28 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    To be merged with the formalization of SysML constraints (SYSML16-274)

    To be merged with the formalization of SysML constraint which includes adding them explicitly in the model of the SysML profile: a meaningful name will be proposed for each of those constraints.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    EndPathMultiplicity constraint#2 states:

    {quotes}
    endPathLower shall be non-negative{quotes}

    However, there is no such property defined for the EndPathMultiplicity stereotype. Obviously, the intent is to constrain EndPathMultiplicity::lower

  • Reported: SysML 1.5 — Thu, 24 Aug 2017 07:36 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    To be merged with the formalization of SysML constraints (SYSML16-274)

    To be merged with the formalization of SysML constraint which includes adding them explicitly in the model of the SysML profile

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Compartment headers are missing in figure 8.10 and 8.11

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The figure 8.10 shows a compartment of the value type Complex without a compartment header. According to table 8.1, it should be labelled with "properties".

    Figure 8.11 shows two blocks with a unlabelled compartment. Add the compartment header "values".

  • Reported: SysML 1.5 — Thu, 31 Aug 2017 11:56 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Add compartment header

    Compartment should have a header like defined in table 8.1.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Incorrect diagram header in figure 8.11

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The diagram header should show the model element type and name.

    bdd [modelLibrary] UnitAndQuantityKind [Unit and QuantityKind library]

  • Reported: SysML 1.5 — Thu, 31 Aug 2017 11:46 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Update diagram header of figure 8.11

    The diagram header should show the model element type and name.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Initial values compartment header inconsistent with others

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    SysML compartment headers are usually all lower case with spaces separating words, but for initial values it's "initialValues". Suggest changing it to "initial values".

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:38 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Addressed by general compartment labelling rules

    http://issues.omg.org/browse/SYSML16-67

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML Provides Inadequate Support for Reuse of Requirements

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    SysML provides inadequate support for reuse of requirements. The «copy» relationship does not provide the flexibility necessary to support concepts like requirement archetypes and reusable requirement hierarchies.

    SysML supports reuse in other modeling areas by distinguishing the classier (definition of the concept) from the property (use of that concept in a composition context).

    • In structural modeling this is done with blocks that type part properties.
    • In parametric modeling this is done with constraint blocks that type constraint properties.
      This concept has already been extended in SysML to include activity modeling: activities (classifiers) called by call behavior actions, and depicting these called behavior actions as adjunct properties on a block definition diagram.

    In all three cases, the vehicle for reuse is a classifier that types or is called by a property of another classifier. It is appropriate to extend this approach to requirements, thus supporting requirement archetypes as classifiers, and requirements as properties of classifiers.

    • Requirement hierarchy can then follow the standard composition relationship, rather than the current containment relationship.
    • Requirements as properties are contextualized by the classifier owning them, yet inherit characteristics of the requirement archetype classifier typing them.
  • Reported: SysML 1.4 — Thu, 28 May 2015 04:04 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    SysML Provides Inadequate Support for Reuse of Requirements

    This is addressed in SysML 1.5 with property based requirements by allowing Blocks for requirements.
    This allows to contextualize the requirement and therefore re-use the requirement.

    See E.8.4 An Example Property Based Requirement based on Block

  • Updated: Mon, 1 Apr 2019 18:17 GMT

The type of ParticipantProperty

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    SysML spec says:

    The types of participant properties can be elided if desired.

    But constraints says:
    [5] A property stereotyped by ParticipantProperty must have the same type as the property referred to by the end attribute.

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

    Adjust text with contraint in ParticipantProperty

    Affects: SysML Specs 1.4, 1.5
    Section: 8.3.2.13
    Reason: "Elided" can be used to describe all properties /elements in diagrams and is not specific to ParticipantProperty.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

xmi:IDs are not convenient

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The xmi:IDs used in SysML related XMI files we publish are not convenient.
    They are too big and too sensitive to model change.

    We need to come back to something more compact and more robust

  • Reported: SysML 1.4 — Mon, 12 Sep 2016 13:44 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    in 1.5 the IDs have been changed to be convenient

    addressed by new algorithm to generate IDs

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Clarify if the usage of qualified associations is allowed

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It seems that the SysML specification wants to exclude the usage of qualified associations. However, it only says that it does not seem to be essential to use them:

    "Qualified associations, shown in SysML by an open box at the end of an association path with a property name inside, are a specialized feature of UML that specifies how a property value can represent an identifier of an associated target. This capability, while useful for data modeling, does not seem essential to accomplish any of the SysML requirements for
    support of systems engineering." (8.3.1.3, SysML 1.5)

    It is still unclear if qualified associations are allowed or not.

  • Reported: SysML 1.5b1 — Wed, 26 Apr 2017 07:35 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Explicitly exclude the usage of qualified associations

    Qualified associations are explicitly excluded by the second sentence in clause 8.3.1.3: "Notational and metamodel support for n-ary associations and qualified associations has been excluded from SysML.".

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Association arrowheads should not be forbidden

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML specification excludes the usage of association arrowheads:

    "The use of navigation arrowheads on an association has been simplified by excluding the case of arrowheads on both ends, and requiring that such an association always be shown without arrowheads on either end." (8.3.1.3, SysML 1.5).

    However, arrowheads are commonly used in SysML modeling. There are also examples of usages in the SysML specification itself, for example, figure D.15.

  • Reported: SysML 1.5b1 — Wed, 26 Apr 2017 07:31 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Association arrowheads at both ends at the same time are forbidden

    The specification only excludes the case of arrowheads at both ends of an association at the same time. The modeling scenarios mentioned by the reporter are still possible in SysML.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Incorrect multiplicity for base_xxx properties of most SysML Stereotypes

  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Incorrect multiplicity for base_xxx properties of most SysML Stereotypes

    multiplicity is empty in 1.5 XMI which means it defaults to 1 based on MOF/XMI/UML specification. This is correct unless there is more than one base in which case it is 0..1

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Wrong parameter for Operations in the SysML.xmi

  • Status: closed  
  • Source: Airbus Group ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Wrong parameter for Operations in the SysML.xmi

    addressed in SysML 1.5 XMI

  • Updated: Mon, 1 Apr 2019 18:17 GMT

RequirementRelated is present in the summary but no more in the document

  • 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Fixed in SysML 1.5 specification

    Fixed in SysML 1.5 specification

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Block constraint [4] contains a false statement

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Constraint#4 specified for the Block stereotype states the following:
    In the UML metamodel on which SysML is built, a Property that is typed by a block must [sic] 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.)

    However there is no such a constraint in UML metamodel. Firstly, the concept of "block" is not part of UML, and secondly there is not even an equivalent constraint for UML::Properties typed by a UML::Class. Typing a UML::StructuredClassifier::ownedAttribute with a Class is legal

  • Reported: SysML 1.5 — Thu, 26 Jan 2017 09:26 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Duplicated by SYSML16-154

    http://issues.omg.org/browse/SYSML16-154

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Activity should not be included as graphical node included in activity diagrams

  • Legacy Issue Number: 19836
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 11.1 includes a set of concrete syntax symbols that are "graphical nodes included in activity diagrams." One of these represents an Activity diagram. Activity diagrams do not include activities as one of the possible nodes in the meta-model. I suggest you remove that line of the table to make is clear that Activity Diagrams do not contain activities.

  • Reported: SysML 1.4 — Thu, 24 Sep 2015 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    To be merged with more general SYSML16-201

    duplicate of http://issues.omg.org/browse/SYSML16-201

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Port labels inside Port symbol

  • Key: SYSML16-87
  • Legacy Issue Number: 17251
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Port notation defined in table 9.2

    Table 9.2 shows that port can be represented with compartments, based on their Type, using corresponding block notation.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Section 9.3.1.7

  • Key: SYSML16-86
  • Legacy Issue Number: 17248
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Issue split

    There were eventually 3 unrelated issues in this one. They need to be split:

    • The typo was fixed in v1.5
    • issue about full port is now handled by SYSML16-263
    • issue about InterfaceBlock is now handled by SYSML16-264
  • Updated: Mon, 1 Apr 2019 18:17 GMT

AdjunctProperty principal should be a NamedElement

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    The specification says:

    Attributes
    • principal : Element [1]

    [2]Properties to which AdjunctProperty applied must have the same name as the principal.

    A name isn't mandatory for an UML Element.

    => principal type should be NamedElement

  • Reported: SysML 1.4 — Thu, 4 Aug 2016 14:25 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    AdjunctProperty principal should be a NamedElement

    Change constraint [2] to address none NamedElement,
    remove list of covered elements in attribute description because it is covered in the constraints

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML does not clearly defines how an association defines properties

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In section 8.3.1.3 the SysML specification excludes the dot notation of the association that shows the ownership of the defined properties.

    But the SysML specification does not specify how the ownership of properties is defined. There are different usages of the association relationship like composition in bdd, actor/use case relationship or in conceptual bdds. Different usages require different ownerships of the defined properties.

    Proposal:
    Define a default and allow the dot notation if the modeler wants to define it differently.

  • Reported: SysML 1.4 — Fri, 5 Feb 2016 12:17 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Association end ownership is defined according to the navigability

    In SysML the ownership of association ends is fully defined according to the navigability of those ends. If the classifier (e.g. a Block) has a navigable association to another classifier it owns the end corresponding to the role played by that other classifier. If the association end is not navigable it is owned by the association itself.

    This is enforced by SysML::Block constraint#3:

    In the UML metamodel on which SysML is built, any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association must [sic] not have a name and may not be defined as a navigable owned end of the association

  • Updated: Mon, 1 Apr 2019 18:17 GMT

BNF definitions have literals/terminals in italics, which seems to imply that the occurrences of these strings should be in italics, but they are not.

  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is probably occurs in many cases, but as an example, see page 40 section 8.3.

    <param -prop> ::= ‘ordered’ | ‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’

    This statement states the the literal "ordered" (and the rest of the list) should be in italics when used on diagrams throughout the spec It is not

  • Reported: SysML 1.4 — Mon, 23 Mar 2015 18:38 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    BNF definitions have literals/terminals in italics, which seems to imply that the occurrences of these strings should be in italics, but they are not.

    Per UML specification formatting conventions all BNF non-terminal symbols must be in italics. This means that terminals should not be in italics.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

ParticipantProperty stereotype is redundant

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ParticipantProperty is a property which duplicates and references an AssociationEnd. Reasoning of this duplication is not explained in the spec and creates issues for implementation and model users.

    Association ends can be represented in IBD diagram of AssociationBlock directly.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 18:30 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    ParticipantProperty stereotype is redundant

    The difference is that association end properties are for navigating from instances of one end class to
    instances of another, while participant properties are for navigating from instances of association classes to instances
    of the end classes. This covered in 8.3.2.12 ParticipantProperty.

    Association end properties can be represented in association block IBD only when they are owned by the
    association, which is only the case for non-navigable association end properties in SysML (non-navigable
    = properties that are not guaranteed to be efficiently navigable, see the paragraph above the last Note in UML
    11.5.3.1 Associations, but might be in some tools). Non-navigable association end properties can still be navigated
    from instances of one end class to instances of another, it's just not guaranteed to be efficient. In any case,
    they do not provide the same navigation as participant properties, see above.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

layout error for compartment name

  • Legacy Issue Number: 19858
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The "part" (name of the third compartment of the block Block1 in Table 8.1) exceeds its scope/space. Name: Jingang Zhou
    Employer: Neusoft
    mailFrom: zjg_robin@hotmail.com

  • Reported: SysML 1.4 — Wed, 25 Nov 2015 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    layout error

    already fixed in SysML 1.5

  • Updated: Mon, 1 Apr 2019 18:17 GMT

DeriveReqt constraints multiplicity of Client and Supplier

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    Here are the constraints for DeriveReqt

    [1]The supplier must be an element stereotyped by «requirement» or one of «requirement» subtypes.
    [2]The client must be an element stereotyped by «requirement» or one of «requirement» subtypes.

    DeriveReqt extends Abstraction and an Abstraction can have many NamedElement as Client and Supplier.

    7.3.12 Dependency (from Dependencies)
    client: NamedElement [1..*]
    supplier: NamedElement [1..*]

    Here are some options:

    • add a constraint to restrict to 1 NamedElement in Client and Supplier
    • Stereotype required only on the first NamedElement
    • Stereotype required on all NamedElement
  • Reported: SysML 1.4 — Fri, 20 May 2016 15:06 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Already constrained through trace stereotype specialization

    Already constrained because deriveReqt specializes Trace stereotype which constrains both the client and the supplier to be limited to one.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

ISO DIS 19514 (JTC1 Comments against SysML 1.4)

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    (cross posted email from Andrew Watson)
    Yves, Rick, SysML 1.5 RTF members,

    As I'm sure you remember, OMG used its PAS status to submit SysML 1.4 to ISO/IEC JTC1 for consideration as an International Standard. The ISO
    identifier is DIS 19514, and the specification was accompanied by this
    explanatory report:

    http://doc.omg.org/pas/15-04-01

    JTC1 Members have now finished voting on the proposal, and the results are available as ptc/16-06-01:

    http://doc.omg.org/ptc/16-06-01

    As you can see, the vote passed, but because there was one "No" vote, OMG is being asked to respond with a revision of the SysML specification that addresses some or all of the reviewers' comments, also contained in the above archive.

    Because the SysML 1.5 RTF is working on revising this specification,
    creating this revision falls to you.

    The JTC1 comments will need to be filed as OMG issues, and then addressed in a SysML revision. If you only address the JTC1 comments, then I suggest we make this the SysML 1.4.1 revision, and publish it within a couple of months via the Urgent Issue process. Alternatively, you may want to roll this into the SysML 1.5 revision, along with resolutions to other SysML
    issues.

    Once you've decided which approach you want to use, please let me know so that I can tell JTC1 within what time-frame they can expect the response to its members' comments.

    One other, related issue; the SysML 1.5 RTF expires just after the Orlando
    meeting, and we still need to decide how long an extension to put on the
    Orlando agenda. 3 months? Six? Please let me know.

    Thanks,

    Andrew

  • Reported: SysML 1.4 — Wed, 15 Jun 2016 12:45 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    ISO DIS 19514 (JTC1 Comments against SysML 1.4)

    resolved in 1.5

  • Updated: Mon, 1 Apr 2019 18:17 GMT

The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes

  • Status: closed   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes

    Resolved in SysML 1.5

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Spec document inconsistent with Normative profile XMI file ptc/2013-12-11

  • 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Spec document inconsistent with Normative profile XMI file ptc/2013-12-11

    eferring to http://www.omg.org/spec/SysML/20150709/SysML.xmi it is consistent with the spec:
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concern" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concern" xmi:type="uml:Property">
    <name>concern</name>
    <isDerived>true</isDerived>
    <type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#String"/>

    <name>concernList</name>
    <type href="http://www.omg.org/spec/UML/20131001/UML.xmi#Comment"/>

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Section: 9.3.2.5 FlowPort

  • Key: SYSML16-4
  • Legacy Issue Number: 10410
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Issue is obsolete

    This issue is about flow ports which are deprecated

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Flow port compatibility with behavior

  • Key: SYSML16-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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Issue is obsolete

    This issue is about flow ports which are deprecated.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Problems with 1.3 Enumeration Literals

  • Key: SYSML16-94
  • 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: Resolved — SysML 1.6
  • Disposition Summary:

    Enumerations shall follow the naming convention specified by in section 6.3

    Reporter is right that the naming of those enumerations is inconsistent with the directive given in section 6.3

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are

  • Legacy Issue Number: 18705
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    SysML restriction for behavior port is semantically consistent

    The semantic specialization that SysML provides with full and proxy ports is consistent with the restriction regarding the value of the "isBehavior" property of UML::Port and does not violate the UML specification at all.

    UML states that some ports can be behavior port and some other not. SysML introduces the concept of "full port", specifies that this specialization of UML::Port cannot be used for behavior port and explain why. Such a restriction in perfectly legal according to the semantics of UML::Stereotype that SysML uses for that purpose and the justification of the this restriction is semantically consistent.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Ports and Flows

  • Legacy Issue Number: 18458
  • Status: closed  
  • Source: NIST ( Mr. 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: Resolved — SysML 1.6
  • Disposition Summary:

    Revise title for section 9.4.2

    Replace the title of section 9.4.2 which is currently "Flow ports and Item Flows" by "Ports and Item Flows"

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Constraint clarification

  • Status: closed  
  • Source: Kenntnis ( Richard Welling)
  • Summary:

    SysML deviates significantly from the latest UML specification in its concept of constraint, and not in a bad way. But the resulting differences are not well defined in the SysML specification. The UML spec is quite explicit in restricting constraints only to ValueExpressions which not only evaluate to Boolean but, when evaluated, have no side effects on the model. From the UML 2.5 specification:

    7.6.3 Semantics. The specification of a Constraint is given by a ValueSpecification (see Clause 8) of type Boolean…A Constraint is evaluated by evaluating its specification. If the specification evaluates to true, then the Constraint is satisfied at that time. If the specification evaluates to false, then the Constraint is not satisfied, and the realization of the model in which the evaluation occurs is not valid.
    7.6.4 Notation. The Constraint may then be notated textually within braces ({}) according to the following BNF:
    <constraint> ::= ‘{‘ [ <name> ‘:’ ] <boolean-expression> ‘ }’
    7.8.3.6 Constraints (of Constraint Classifier).

    • boolean_value - The ValueSpecification for a Constraint must evaluate to a Boolean value.
    • no_side_effects - Evaluating the ValueSpecification for a Constraint must not have side effects.

    8.3.1 Expressions-Summary. Expressions are ValueSpecifications that specify values resulting from a computation.

    Moreover, the UML spec makes no qualification for the evaluation of OpaqueExpressions, i.e., they must evaluate to Boolean. This is clearly not the case for SysML-style constraints, which include mathematical expressions (i.e., ValueSpecification<OpaqueExpression) that can be evaluated to type real and can cause state transitions and other changes to a model. It is difficult to understand how one could execute a model without this capability. Perhaps the Boolean constraint on constraints is a holdover from the earliest days of UML. It is one thing to constrain the mere logic of code and quite another to constrain the reality of real world objects. Essentially, all constraints in SysML are expressed as OpaqueExpressions, with special cases (i.e., a<b) evaluating as Boolean. Since most tools make this SysML assumption, this difference needs to be formalized, or at least reconciled, in SysML Clause 10.

  • Reported: SysML 1.4 — Wed, 2 Dec 2015 04:09 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.6
  • Disposition Summary:

    Constraint clarification

    It appears more to be a conceptual change than a bug which we can fix in the RTF of 1.6. That's why we think it should go as requirement to SysML 2.

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Missing one right parenthesis in the constraint equation

  • Legacy Issue Number: 19862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The constraint "

    {v(n+1 = v(n)+a*32*3600/5280*dt}

    " for the containt block VelocityEquation in Figure D.34 lacks a right parenthesis, which results in error of the contraint.

  • Reported: SysML 1.4 — Thu, 26 Nov 2015 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    Missing one right parenthesis in the constraint equation

    already fixed in SysML 1.5

  • Updated: Mon, 1 Apr 2019 18:17 GMT

the use of <> is still unclear and inconsistent

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML: Generalizing Activites

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML: UML Qualified Associations

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML: Protocol State Machines needed

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Sample problem: Parts are added directly into package

  • Key: SYSML16-13
  • Legacy Issue Number: 11499
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-12
  • Legacy Issue Number: 11496
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Lack of notation for units and dimensions on values.

  • Key: SYSML16-11
  • Legacy Issue Number: 11493
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

BindingConnector end s multiplicity

  • Key: SYSML16-10
  • Legacy Issue Number: 11333
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Issue: Nested connector ends

  • Key: SYSML16-9
  • Legacy Issue Number: 11276
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

standard way to describe a flow of data in sequence diagrams

  • Key: SYSML16-8
  • Legacy Issue Number: 11117
  • Status: closed  
  • Source: International Business Machines ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Block namespace compartment: Are external relationships allowed

  • Key: SYSML16-7
  • Legacy Issue Number: 11011
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Timing diagrams

  • Key: SYSML16-6
  • Legacy Issue Number: 10642
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Annex B / Figure B27

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Annex B / Figure B.9

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Annex B / Figure B.10

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Annex B / B.4.8.3 Activity Diagram (in sample problem)

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

10.3.1.2 Parametric Diagram: square box notation

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Item Flows on Activity Diagrams

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Inferred Allocation on Allocate Activity Partitions

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Diagram interchange

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML: Interaction diagram and Data-based comm of SysML

  • Key: SYSML16-14
  • Legacy Issue Number: 11627
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML: Align SysML Activities with Foundational UML

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Figure B.34 and Figure B.35

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Annex B, Figure B.29

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Annex B / Figure B.38

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Annex B / Figure B.35


callout notation issues

  • Key: SYSML16-45
  • Legacy Issue Number: 14575
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Proposal to have a stereotype for reference nested property

  • Key: SYSML16-42
  • Legacy Issue Number: 14055
  • Status: closed  
  • Source: International Business Machines ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Allocations should not generate dependencies

  • Key: SYSML16-39
  • Legacy Issue Number: 13840
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-52
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML 1.2 Issue Viewpoint referencing other viewpoints properties

  • Key: SYSML16-51
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Flow properties and activity paramters

  • Key: SYSML16-50
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Inheriting Allocations

  • Key: SYSML16-49
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Ability for a binding connector to be typed

  • Key: SYSML16-48
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Do parametric bindings observe derived and read-only properties

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Binding to multiplicity in parametrics

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

AllocateActivityPartition and UML 2 semantics

  • Key: SYSML16-37
  • Legacy Issue Number: 13342
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Support BDD's for State Machines

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Binding Relationships require unit conversions

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Representation of nested object nodes in activity diagrams

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Requirements interchange issue

  • Key: SYSML16-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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Continuous flows in non-streaming situations with >1 multiplicities

  • Key: SYSML16-54
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML 1.2 Issues: DistributedProperties on Activates

  • Key: SYSML16-53
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Blocks cannot own items flows

  • Key: SYSML16-62
  • Legacy Issue Number: 15982
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Another issue with allocate

  • Key: SYSML16-61
  • Legacy Issue Number: 15884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML primitive value types

  • Key: SYSML16-60
  • Legacy Issue Number: 15882
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML Issue on Multiplicity of Use Case Communication Associations

  • Key: SYSML16-59
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML Issue representation of properties as associations

  • Key: SYSML16-58
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML Issue based on UML 15369

  • Key: SYSML16-57
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Figure B.35 object nodes


SysML 1.2 Issues: Optional with streaming

  • Key: SYSML16-55
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

TestCase should use PackageMerge

  • Key: SYSML16-73
  • Legacy Issue Number: 16286
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Association owning ends

  • Key: SYSML16-72
  • Legacy Issue Number: 16263
  • Status: closed  
  • Source: The MathWorks ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

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

  • Key: SYSML16-71
  • Legacy Issue Number: 16113
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Where have stereotypes been defined?

  • Key: SYSML16-70
  • Legacy Issue Number: 16112
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Definition of part

  • Key: SYSML16-68
  • Legacy Issue Number: 16058
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Item flows can have multiple types but item properties cannot

  • Key: SYSML16-66
  • Legacy Issue Number: 16042
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

SysML Issue on Refine limitations

  • Key: SYSML16-65
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Description of Item Flows

  • Key: SYSML16-64
  • Legacy Issue Number: 15985
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

IBD notation doesn't distinguish item properties from connector labels

  • Key: SYSML16-63
  • Legacy Issue Number: 15983
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

InstanceSpecification equality

  • Key: SYSML16-78
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSML16-77
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Content of Requirement::/tracedTo

  • Key: SYSML16-75
  • Legacy Issue Number: 16373
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Can Enumerations be used on parametric diagrams for typing constraint parameters

  • Key: SYSML16-74
  • Legacy Issue Number: 16304
  • Status: closed  
  • Source: MAHLE International GmbH ( 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Error in pending 1.3 diagram 15.6 and elsewhere

  • Key: SYSML16-83
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Question about the Activity decomposition in Block Definition Diagrams

  • Key: SYSML16-82
  • Legacy Issue Number: 16945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

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

  • Key: SYSML16-81
  • Legacy Issue Number: 16876
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Callout notation for port-specific types and initial values

  • Key: SYSML16-91
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

clarification, what "part property" is

  • Key: SYSML16-89
  • Legacy Issue Number: 17307
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

9.3.2.9 What is InterfaceBlock?

  • Key: SYSML16-88
  • Legacy Issue Number: 17255
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

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

  • Key: SYSML16-85
  • Legacy Issue Number: 17210
  • Status: closed  
  • Source: Adaptive ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Property Based Requirements

  • Key: SYSML16-84
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Missing type constraints for FullPort

  • Key: SYSML16-99
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Missing ownership constraints

  • Key: SYSML16-98
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Interface blocks and protocols

  • Key: SYSML16-97
  • Legacy Issue Number: 18169
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

How to refer to properties of an extension?

  • Key: SYSML16-96
  • Legacy Issue Number: 18168
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSML16-95
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

SysML: References to CreateEvent incorrect

  • Key: SYSML16-93
  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Inability to specify partial allocation and requriements satisfaction

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Figure 15.8 diagram type

  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

VerdictKind

  • Legacy Issue Number: 18312
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

SysML stereotype notation creates ambiguity about to which element is the stereotype applied

  • Legacy Issue Number: 18268
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

primitive types in SysML Activities

  • Legacy Issue Number: 18659
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Libraries package should be named "SysML Model Libraries"

  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Allocated notation on object nodes missing from diagram elements table

  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Allocation tabular notation normative?

  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Figures 15.5 and 15.6 diagram types

  • Legacy Issue Number: 18459
  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

9.3.2.4 direction of ports and their notation (second issue)

  • Legacy Issue Number: 18441
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

9.3.2.4 direction of ports

  • Legacy Issue Number: 18439
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Semantics of multiple Dependencies

  • Legacy Issue Number: 18623
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Clarification required for Copy relationship

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Diagram show inconsistent data

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Don't use the optional notation for Pins with Allocation

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Semantics clarification for removing a value from an out Flow Property

  • Legacy Issue Number: 18953
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Abstract syntax for the initial values

  • Legacy Issue Number: 19286
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT
  • Attachments:

Update to Trace Relationship’

  • Legacy Issue Number: 19284
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Legacy Issue Number: 19062
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

proxy and full port notation change request

  • Legacy Issue Number: 18993
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

classifierBehaviorProperty and adjunctProperty notation

  • Legacy Issue Number: 19326
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

URI for the SysML Profile given in section E.3 is wrong

  • Legacy Issue Number: 19321
  • Status: closed  
  • Source: PTC ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

ProxyPort with FlowProperties

  • Legacy Issue Number: 18676
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

About Rate, Continuous and Discrete

  • Legacy Issue Number: 18735
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

The SysML classification of properties is incomplete

  • Legacy Issue Number: 18709
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Legacy Issue Number: 18877
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Pull semantics for flow properties

  • Legacy Issue Number: 18876
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

SysML Issues on Item Property values in an IBD

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

SysML says nothing about how to deal with multiplicity for flow properties matching

  • Legacy Issue Number: 18783
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Missing property descriptions for Probability and Rate

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The stereotypes Probability and Rate in the Activities chapter have no description of their properties.

  • Reported: SysML 1.4 — Mon, 2 Jan 2017 13:01 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The ISO-80000 library has numerous instances of the SysML::ValueType stereotype applied on data types. They are intended to specify the corresponding units and quantity kinds.

    According to SysML, both unit and quantityKind properties of the ValueType stereotype shall be InstanceSpecifications.

    However in http://www.omg.org/spec/SysML/20150709/ISO-80000 all of them refer to the data type the stereotype is applied to rather than to the expected instance specifications. This could result from a bug in the ID generation algorithm used for SysML 1.4

    Example

    <SysML.Blocks:ValueType xmi:id="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029.stereotypeApplication_SysML.package_packagedElement_Blocks.stereotype_packagedElement_ValueType">
        <base_DataType xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <quantityKind xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <unit xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/></SysML.Blocks:ValueType>
    
  • Reported: SysML 1.4 — Tue, 9 Aug 2016 13:05 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Property path notation

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    SysML spec says:

    The name of the referenced property is built by a string of names separated by “.”, resulting in a form of path name that identifies the property in its local context.

    The problem is that in real-life models properties/parts are unnamed. In this case, it is not clear how property path should look like, or looks like this:
    name1…..value or vehicle….value where intermediate properties are unidentifiable.

    A proposed solution would be to use type name if part name is not specified.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:14 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property?

  • Legacy Issue Number: 19859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section E.4 (non-normative) defines the objectiveFunction stereotype to describe objective functions for use in trade studies. However, whereas Table E.5 defines the objectiveFunction stereotype to extend (or rather generalize) ConstraintBlock, this seems to be inconsistent with the parametric diagram on the same page where the objectiveFunction stereotype is (seems to be [*]) applied to the a constraintProperty instead.
    Given the fact that constraintProperty is only 'loosely' defined in the spec (i.e. it is not part of the xmi file), the only viable alternative seems to be that objectivefunction extends uml::Property and adds the necessary constraints in order to warrant the fact that the type of the uml::Property is (stereotyped by) a ConstraintBlock...

    Please clarify the definition of the objectiveFunction stereotype.

    [*] Since there is no formal notation defined for objectiveFunction, one can of course merely guess...

  • Reported: SysML 1.4 — Mon, 30 Nov 2015 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

specializations of requirement should specialize AbstractRequirement

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Inherit from a conjugated interface block

  • Legacy Issue Number: 19644
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

More than one View() operation allowed

  • Legacy Issue Number: 19623
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Table 12.1 has incorrect "int" typed arguments (4x)

  • 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

ElementGroup cannot be source or target of a dependency

  • Legacy Issue Number: 19595
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

[SysML] Semantic variation points

  • Legacy Issue Number: 19489
  • Status: closed  
  • Source: Airbus Group ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Can a SysML Full Port be typed by a ValueType?

  • Legacy Issue Number: 19412
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics

  • Legacy Issue Number: 19328
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

A discarded resolution still appears in the ballot

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Resolution SYSML-331 was discarded from ballot#8, replaced by SYSMLR-359 then added to ballot#9.

    However in ballot#9, SYSMLR-331 still appears beside SYSMLR-359 with all the votes casted in the ballot#8!

    It's rather confusing because, in addition, JIRA said that we already voted for this ballot, which is not true!

    Can we fix this?

    Thanks

  • Reported: SysML 1.4 — Fri, 21 Oct 2016 05:56 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

ConnectorProperty notation in wrong section.

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The diagram extension in the second paragraph of 8.3.2.6 (ConnectorProperty), should be in 8.3.1.2 (Internal Block Diagram).

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:47 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Expand use of rake symbol for all decompositions

  • Legacy Issue Number: 19783
  • Status: closed  
  • Source: University of Detroit Mercy ( Mr. Michael J. Vinarcik)
  • Summary:

    I’d like to advocate for rakes on Call Operation nodes (that have associated methods) in the next SysML rev. We’re using operations extensively because they inherit nicely and have inputs/output parameters. By moving to Call Operations from Call Behaviors, we lose the rake that’s a visible sign you can drill deeper…so by using Call Operations with methods instead of Call Behaviors, we lose that visual cue.
    I put a stereotype with icons on the nodes as a fix, but I’d love to see it as a native function.

    I suggest that rake symbols should be expanded to include call operations on activity diagrams with methods attached (or any other situation in which drill-down is available).

  • Reported: SysML 1.4 — Tue, 9 Jun 2015 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Requirement ID should be immutable

  • Legacy Issue Number: 19764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Requirement IDs, as currently specified by the standard and implemented by vendors, are not adequate to ensure robust traceability outside MBSE models. The standard describes ID as "The unique Id of the requirement”. I would suggest replacing this sentence with "The unique and immutable Id of the requirement." This immutable characteristic is key to ensure robust traceability throughout a project with external stakeholders and documents.

    The current practice of using a hierarchical number for the ID is bad practice that should be discouraged, because a hierarchical ID will necessary change when the hierarchy is refactored, which is almost guaranteed to happen. This breaks traceability. I recognize that there is also a need for a hierarchical ID, mainly to be used to sort requirement tables properly using this property. For that use case, I would suggest a new ID called HID with the following description: “A unique hierarchical identifier, used to organize requirements within a package”

    Since we now have two different IDs that serve two different purposes, we should give guidance for which one should be used as the prefix in front of the name, depending of the context. My suggestion is as follows:

    • In a traceability context, the ID should be the prefix shown in front of the name. For example, when showing the table column "Derived From", the ID should be the prefix shown, not the HID.
    • In a hierarchical context (for example, in the containment tree), the HID should be shown as the prefix in front of the name.
    • When in doubt, use the ID in preference over HID.
  • Reported: SysML 1.4 — Fri, 29 May 2015 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Derived attribute should also be read only

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    In the xmi file representing the profile, that can be found here:
    ptc/2015-07-05 http://www.omg.org/spec/SysML/20150709/SysML.xmi

    The derived attributes should also be set to read-only:
    <ownedAttribute xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Requirement_ownedAttribute.master" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Requirement_ownedAttribute.master" xmi:type="uml:Property">
    <name>master</name>
    <isDerived>true</isDerived>
    ...
    </ownedAttribute>

    In Papyrus SysML 1.1 version, the derived attributes have been set to read-only.
    It will be the same for SysML 1.4 implementation. See https://git.eclipse.org/r/#/c/71034/2/core/org.eclipse.papyrus.sysml14/resources/profile/SysML.profile.uml

    It would be good to provide for SysML 1.5 either the profile with readonly or specify in the norm what should be implemented for the write access

  • Reported: SysML 1.4 — Thu, 28 Apr 2016 10:42 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do.

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    An inconsistency has been noted among requirement dependencies. «copy» and «deriveReqt» are the only requirement dependencies that do NOT have an operation to 'get' the supplier end («refine», «satisfy», «verify») or the client end («trace») of the dependency. The reason for this inconsistency is not clear.

  • Reported: SysML 1.4 — Thu, 24 Mar 2016 16:30 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

AllocateActivityPartition should be more formaly related to allocation Relationship

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Assuming an AllocateActivityPartition is used to specify allocations, the element created in the model to represent it should be more formally linked to the corresponding Allocate relationships.

  • Reported: SysML 1.4 — Thu, 11 Feb 2016 15:33 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Causality of constraints in parametric diagrams

  • Status: closed  
  • Source: Kenntnis ( Richard Welling)
  • Summary:

    Having occasion to review all outstanding constraint block issues, I have read more closely the overview and find that the last paragraph on page 97 of the SysML 1.4 specification has significant problems. It also is the only mention in the SysML spec of constraint causality. This proposal is an attempt to clarify that paragraph while addressing concerns about constraint causality, affecting SYSMLR-99, SYSMLR-47, and SYSMLR-38. This is the paragraph as written:

    SysML identifies and names constraint blocks, but does not specify a computer interpretable language for them. The interpretation of a given constraint block (e.g., a mathematical relation between its parameter values) must be provided. An expression may rely on other mathematical description languages both to capture the detailed specification of mathematical or logical relations, and to provide a computational engine for these relations. In addition, 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.

    • The first sentence is not describing constraint blocks but rather a language for constraint expressions.
    • The second sentence again says, “block” when it is clearly referring to expressions, but then, says an “interpretation…must be provided.” By whom? Presumably by the tool provider but that's not clear.
    • The third sentence seems to say “An expression may rely on other mathematical description languages…to provide a computational engine for these relations.” It is clearly not the language that provides the computational engine but the tool implementing the language.
    • The treatment of causality is puzzling. Why was non-causality specified when causality is always at least implicit? In the F = m*a example, F is implicitly the dependent variable while a = F/m would indicate a as dependent. If the intent was to make causality non-mandatory to simplify the modeler’s task, then one could say parameters are assumed to be non-causal unless specified explicitly as such.
    • Michael Chonoles proposal (SYSMLR-47) to interpret parameters bound to derived values as dependent (output) and those bound to read-only values as independent (input) is not only useful but it should be noted that MagicDraw notates derived properties in recursive parametric diagram patterns and these clearly represent dependent variables. This is standard UML notation.

    Replace the above paragraph with the following:

    Constraint expressions may rely on any suitable mathematical description language to capture the detailed specification of mathematical or logical relations between parameters. The syntax and interpretation of the language and its associated computational engine are a tool responsibility. By default, constraints are assumed to be non-causal and do not necessarily specify dependent or independent variables, in which case specific dependent and independent variables may be defined by initial conditions and determined by the computational engine. Alternatively, dependent and independent variables (constraint parameters) may be expressed by designating their bound values as, respectively, derived ("/" prefix) or {read-only}.

    Move this paragraph to be the fourth paragraph on page 97, after paragraph starting with "Parametric diagrams include..." and before the paragraph starting with "Time can be modeled..." This places it in a logical flow that follows discussions of constraint blocks, constraints, and bindings.

  • Reported: SysML 1.4 — Sun, 22 Nov 2015 00:40 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

"Allocated From" should be "Allocated"

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The term "Allocated From" associated with the From end of an allocation relationship is confusing when it appears in compartment or callout notation. Nerijus mentions numerous user complaints about this. A more intuitive and meaningful term would be simply "Allocated", which when appearing in a compartment label implies that the subject element has the listed elements in the compartment allocated to it.

  • Reported: SysML 1.4 — Thu, 19 Nov 2015 15:49 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT
  • Attachments:

Shared parts are still parts

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The standard treats non-composite aggregation (white diamond) as the poor cousin of composite aggregation (black diamond) by lumping it into a group of block properties called “references”. (6th paragraph in section 8.3.2.3 Block.) So whilst parts (composite aggregation) have their own compartment, non-composite aggregates have to share a compartment with all of the reference block properties. This also occurs on the IBD with all the types of references being drawn with a dashed rectangular frame. At the very least I would propose that non-composite parts are called reference-parts (as opposed to “owned” parts for the composite ones) and are given their own compartment.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:10 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Specify a specific part from a collection of parts on an IBD

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    There is no way of saying which part from a collection (i.e. a plural cardinality/multiplicity) is being shown and hence there is no clear and unambiguous way of showing multiple parts from a collection separately on an IBD. E.g. the spokes on a wheel is easily modelled in a BDD as a collection of spokes, but not easily set out in an IBD, whereas, individually named (by role) spokes can be set out in an IBD, but, for more than a few, this becomes awkward to show on a BDD.
    For at least ordered collections (i.e. plural multiplicities) of parts (aggregate roles) the traditional use of square bracket array notation could be used, e.g. mypart[10] would refer to the 10th instance of part collection called "mypart". For unordered collections a selector (i.e. query) would be required.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 17:47 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Missing comment for some attributes

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

SysML XMI typos in UML StandardProfile XMI references

  • Status: closed  
  • Source: NIST ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

No support for dot notation in activity and sequence diagrams

  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Definition of SysML stereotypes: association ends versus attributes

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some properties of the SysML stereotypes are defined by associations and others by simple properties. It should be consistent and clearly defined how to define the stereotype properties.

    For example, propertyPath of ElementPropertyPath is defined by an association. boundEnd of BoundReference is defined by a simple property.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:19 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Description of model elements in generated document not consistent with specification

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The document that is generated from the model file defining the SysML profile contains descriptions of the model elements that are not consistent with the specification.

    Some description texts are completely missing, some are incomplete, and some have a different text than in the specification document.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:10 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Parts, references, values compartments in wrong section

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Parts, references, and values compartments are described in Subclause 8.3.2.3 (Block), but should with the diagram extensions for BDDs (Subclause 8.3.1.1) with the others.

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:52 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Hanging Clauses Throughout SysML 1.4

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    ISO/IEC Directives Part 2 2016 clause 22 states than each and every clause and subclause of the spec should be numbered, and hanging clauses should be avoided. Any numbered clause containing text or figures than that has a subordinate numbered clause becomes a hanging clause, because it does not have a unique number assigned to it.

    List of known hanging clauses in SysML 1.4 (exclusive of un-numbered ‘subpart’ text on pages 1, 19, 103, 145, and 185):
    6.2 page 17
    7.1 page 21
    7.3.2 page 26 (figure only)
    8.3.1.1 page 42
    8.3.1.2 page 44
    8.3.2 page 47 (figures only)
    8.3.3.1 page 59 (figure only)
    8.3.3.2 page 60 (figure only)
    9.1 page 71
    9.3.2 page 79 (figures only)
    10.3.2 page 100 (figure only)
    11.1 page 105
    11.3.1 page 114
    11.3.2 page 117 (both text and figure)
    11.3.3.1 page 121 (both text and figure)
    12.3.1 page 133
    15.3.2 page 150 (figure only)
    15.4 page 152 (both text and figure)
    15.4.2 page 153 (both text and figure)
    16.3.2 page 164 (figure only)
    16.4 page 168
    17.2.1 page 176 (figure only)
    17.2.2 page 178 (figure only)
    B.2 page 194 (figure only)
    C.1 page 203
    E.5.2 page 254 (both figures and text)
    E.6.5 page 286 (both figure and text)
    Annex F (no paragraph number)
    G.4 page 318

  • Reported: SysML 1.4 — Thu, 18 Aug 2016 15:39 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Some DirectedRelationshipPropertyPath constraint definitions assume that the relationship on which this stereotype is applied is binary but there is no formal constraint enforcing it.

  • Reported: SysML 1.5 — Thu, 10 Aug 2017 12:27 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Clarification of typing a binding connector


Replace all occurrences of "has been" by "is"

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In several places of the SysML specification document the term "has been" is used. It should be replaced by "is".

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 07:44 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT


The AdjunctProperty is not clearly described

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The benefit of the recently introduced Adjunct Property is not clearly stated in the standard. The current description is somewhat baffling and a recent discussion amongst learned members of the SysML RTF revealed further uncertainty.
    The standard's development needs to be sensitive to the general criticism that SysML is too complex. Thus language features that are described from their purely functional/implementation point of view neither inform the user community what they are for or, as seems to be the case here, make it clear that this part of the language that is a solution to a problem inherited from UML that modelling tools need to implement and end users need not be too concerned with.
    I would also question whether it was correct to change section 11.3.1.1 "Activity" by replacing the BDD representation of activity hierarchy (as per v1.3) with adjunct action properties (introduced in v1.4). Whilst the latter is possible with the AdjunctProperty facility, the prior method, inherited from UML, is still valid. That is, unless the UML activity hierarchy is expressly deprecated from SysML. Even then, it will leave end users with the question of what the additional benefit is of the adjunct property as applied to call behaviour actions.

  • Reported: SysML 1.4 — Fri, 28 Apr 2017 12:53 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Diagram formality confusion

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    Annex A "Diagrams", whilst /informative/, sets out a confusing definition of the diagram types.

    On the one hand, there are nine SysML diagram types that have "model elements and corresponding concrete syntax", with each diagram kind cross referenced to the specific clause defining a specific part of the SysML modelling language. So for example an activity diagram "represents" (by virtue of the appropriate nodes and paths) the model elements and connectors described in the Activities clause (clause 11).

    On the other hand, there is the weaselly statement "Although the [diagram]taxonomy provides a logical organization for the various major kinds of diagrams, it does not preclude the careful mixing of different kinds of diagram types". A similar remark can be found in UML 2.5 in the form of a note in it's Annex A "Diagrams" section:
    "NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioural elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced."

    So, despite Annex A being informative, it creates at least two possible interpretations for tools to implement:
    1. A diagram can present representations of any model element and connector, or
    2. On the specific model elements associated directly with a diagram kind (according to Annex A) can be represented on a diagram with a specific kind.

    Case 1 would allow all manner of diagrammatic mixing of model elements from the different semantic clauses, even when these clauses do not allow for any logical connection. However, it might allow an activity diagram to show a «Block» with an owed activity model. It would also allow a use case diagram to include a «Block» connected with a communications path to a use case node (since neither the use case or block clauses seem to set out a constraint to prevent this in the model).

    Case 2 would only allow the model elements from the directly associated clause along with the model elements that are common to all diagrams. This is a strict implementation, but may have consequences where more flexibility would have been desired. For example a modeller using Blocks, or user stereotyped classes, for stakeholder modelling would find that they cannot use these model elements directly on a use case diagram where only use case and actor model element types can be represented.

    The standard should also consider the practicalities of modelling tool design and usability considerations. Case 1 would imply just one diagram implementation and a large model element library (or tool bar) for the user to work with (in a model creation through the diagram paradigm). Whereas, case 2 requires distinct implementation of the diagram kinds along with their implied constraints of which model elements can be added to them, although it does mean that the model element library (or tool bar) is quite specific to each diagram kind.

    Without standardising what each diagram kind can contain, there will be no possibility of model interchange that includes the diagrams.

    On a final note, the explicit exclusion of the Profile diagram from UML seems strange because defining and working with Stereotypes is a common (albeit advanced) modelling concept in MBSE, but to do it requires specific modelling concepts (and their associated nodes and paths). Hence, the current suggestion that this is done with package diagram would seem to suggest that the aforementioned diagram case 1 was being implied.

    Suggested change (with a strict diagram syntax leaning):
    1. Make Annex A normative and remove the diagram mixing statement: "it does not preclude mixing different kinds of diagram types"
    2. Review each of the modelling clauses 8 through to 16 to check that they completely define the set of model elements and connectors that are useful to make available to modellers on the associated diagram kind. That is make explicit what is otherwise inferred by the lack of a constraint. E.g. that use case model elements can (or cannot) be connected to Blocks (or other forms of stereotyped classes) with a communication path connector.
    3. Add the UML Profile diagram to the list of SysML diagrams.

  • Reported: SysML 1.4 — Mon, 27 Feb 2017 12:56 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Numeric Literals as constraint block property parameter values

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    It would be very useful to have the ability to have literal values as parameter values to a constraint block property. (Helps with reuse of constraint blocks.) Even better, to be able to use named constants from a (shared) library package (i.e. a different namespace), which could combine a description of the value with quantity and unit attributes.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:26 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

SysML 1.6 should be based on UML 2.5.1

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    SysML should be based on the newest available UML specification. Current UML specification is version 2.5.1. SysML 1.5. is still based on UML 2.5.

  • Reported: SysML 1.5 — Fri, 23 Feb 2018 14:29 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Statements missing in the abstract syntax description

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description of stereotypes in the abstract syntax is missing all the "base_xxx" attributes that refer to the instances of extended elements. However this is required in order to specify the corresponding multiplicity and redefinition, if any.

    In addition, it should also be specified whether the corresponding stereotype is "required" or not. At that time, the only way to know it is to parse the normative XMI file.

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 07:18 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Owned properties of an InterfaceBlock

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Split from SYSML16-86:

    What are possible owned properties of the InterfaceBlock? Values, FlowProperties? other? In 9.1 InterfaceBlock it is not flow nor value

  • Reported: SysML 1.5 — Thu, 16 Mar 2017 07:43 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

FullPort type

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Split from SYSML16-86:

    What is the type of FullPort? Spec says nothing

  • Reported: SysML 1.5 — Thu, 16 Mar 2017 07:42 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Owning Block definition is unclear

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The definition of owning block for proxy port given in the description sub-section of 9.3.2.7 FlowProperty is unclear and misleading. It should be reworded and moved to the ProxyPort description

  • Reported: SysML 1.5 — Thu, 2 Mar 2017 15:41 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

DirectedFeature is confusing

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The intended use for the <<DirectedFeature>> stereotype is not at all clear from its specification in section 9.3.2.4 in SysML 1.5. To be clear, the current description describes what it is, but not why it is required, or how a modeller might use it. Moreover, it is not clear whether it specifically applies to ports (since its part of the section that specifies the language facilities for ports and flows (section 9), or whether it relates to features (properties?) of a block that are not ports.

    The issue was discussed at the RTF meeting of 2017-10-12 as a result of discussing issue http://issues.omg.org/browse/SYSML16-108. There was little consensus on what DirectedFeature is, although Conrad suggested the following (being my interpretation of what was said):
    A DirectedFeature of a block describes whether the block implements that feature (it's "provided") or that the feature is represents a conceptually virtualised feature as an "assumption" that something else in the model will provide it. The fulfilment of the required assumption with an actually provided realisation of that feature is by a connector between the required and the provided features.

    The problem with this interpretation is that it seems to have nothing to do with ports! There is of course further scope for confusion with the UML notation of provided and required interfaces on UML ports.
    At the very least, some examples that clearly illustrate what problem DirectedFeature solves and the types of model elements that it is to be applied to would help a lot.

  • Reported: SysML 1.5 — Thu, 12 Oct 2017 16:39 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Reference Properties do not reference properties

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    A reference property of a Block may only be typed by (i.e. "reference") another Block. There is no current mechanism for a reference property to explicitly reference a part property of a different block. See Figure D.16 for example; the PowerSubsystem Block is assumed to be referencing the part property of the BrakeSubsystem typed by BrakePedal. This is a logical conclusion since there is only one part property typed by BrakePedal, but if there were multiple part properties typed by BrakePedal, the reference property of the PowerSubsystem Block would be ambiguous.

    Practical use of reference properties has consistently implied that a particular part property CAN be referenced (i.e. "a part property owned by another block"), but no mechanism for this is explicitly provided in SysML. Also, there does not appear to be any constraint on instance semantics of reference properties that might clarify this ambiguity at the instance level.

    See also SYSML16-42 and SYSML16-228.

  • Reported: SysML 1.5 — Tue, 17 Oct 2017 00:17 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Excluded UML metaclasses are not formally defined

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 4.1. excludes several UML metaclasses from SysML. However, figure 4.2 shows that the SysML profile imports the whole UML. Instead, the SysML profile should use the metamodelReference and metaclassReference properties to import only the included elements.

  • Reported: SysML 1.5 — Fri, 9 Feb 2018 12:54 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Typos/editorials found in the SysML 1.5 specification document

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    This issue is dedicated to typos and editorials we find in the SysML1.5 specification document.

    Any finding has to be recorded as an annotation added to a shared PDF document available on the OMG SVN server at: http://www.omgwiki.org/repos/SysML/trunk/Documents/formal-17-05-01(annotated).pdf

    >>> Note to RTF Chairs: do not schedule this issue for vote before the last ballot of the RTF <<<

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 14:14 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    In SysML 1.5 pdf document ( p 147 Table 14.2- Graphical paths included in Use Case diagrams)

    Latest element in the table :

    • Path name: Generalization
    • Concrete Syntax : ->
    • Abstract Syntax Reference : UML4SysML::Kernel
      => it should be UML4SysML::Generalization

    Also present in SysML 1.4 pdf version

  • Reported: SysML 1.5 — Wed, 30 Aug 2017 15:13 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Inconsistency between xmi and pdf for Trace and Refine specializations

  • Status: closed   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    While generating code for a custom sub-profile of SysML 1.4, we got some issues (as far as I can tell the same apply for SysML 1.5)
    You can see the discussion here https://bugs.eclipse.org/bugs/show_bug.cgi?id=530565

    After some internal discussions (thanks Patrick and Jérémie for your time), here are our conclusions:

    In the normative SysML 1.4 XMI Refines and Trace stereotype are implemented as follows :

    1. Refine
    ­ Specializes SysML::Blocks::DirectedRelationshipPropertyPath.
    ­ Extends UML::Abstraction.

    • This extension is a specialization of Abstraction_Refine extension.
    • This extension is a specialization of DirectedRelationship_DirectedRelationShipPropertyPath extension.
      2. Trace
      ­ Specializes SysML::Blocks::DirectedRelationshipPropertyPath.
      ­ Extends UML::Abstraction.
    • This extension is a specialization of Abstraction_Trace extension.
    • This extension is a specialization of DirectedRelationship_DirectedRelationShipPropertyPath extension.

    [Issue 1] The profile design is not aligned with the content of the normative PDF for [SysML 1.4]. Indeed, in this latter:
    1. Refine specializes StandardProfile::Refine and SysML::Blocks::DirectedRelationshipPropertyPath.
    2. Trace specializes StandardProfile::Trace and SysML::Blocks::DirectedRelationshipPropertyPath.
    However, to the best of our knowledge, there are no indications regarding the specializations of the existing extensions relationships.

    [Issue 2] The profile design is not conformant to [UML 2.5]. Indeed, both Refine and Trace have a base_Abstraction property redefining :
    1. SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship and StandardProfile::Refine::base_Abstraction (Refine case).
    2. SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship and StandardProfile::Trace::base_Abstraction (Trace case).
    However, according to [UML 2.5] a property cannot be redefined if it is not inherited (see constraint “redefined_property_inherited” in section 9.9.17.7 in [UML 2.5]). Hence, it is not allowed to specify that StandardProfile::Refine::base_Abstraction or StandardProfile::Trace::base_Abstraction are redefined since Refine and Trace do not specialize StandardProfile::Refine and StandardProfile::Trace.

    [Remark] The usage of the “extension specialization” pattern used to define both Refine and Trace within SysML shall be rationalized. To us, the two main points for using that pattern were:
    1. To avoid the usage of multiple inheritance in Refine /Trace definitions.
    2. Enable the owned extension ends (i.e., the one owned by the newly defined extensions relationships) to redefine the owned extension ends for StandardProfile::Trace, StandardProfile::Refine and SysML::Blocks::DirectedRelationshipPropertyPath.

  • Reported: SysML 1.4 — Tue, 10 Apr 2018 14:04 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

ConnectorProperty is redundant

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The ConnectorProperty is redundant. The same feature is provided by AdjunctProperty.

    see slide 17: http://tinyurl.com/ybvdx6ew

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 18:26 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    While it is not possible to check if a value conforms to, for example, uniform or mean distribution, it is possible to check, if it conforms to constraints of the specified distribution. For example, the minimum and maximum values of a uniform distribution.

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 17:14 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

DistributedProperty should be abstract

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The DistributedProperty itself does not make sense. As specified in the specification specific distributions should be defined as subclasses of the DistributedProperty stereotype. Therefore, the stereotype should be abstract.

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 17:05 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

DistributedProperty should be abstract

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The DistributedProperty stereotype should be abstract since it needs to be specialized in order to be usable.

  • Reported: SysML 1.5 — Mon, 7 May 2018 12:45 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Description of AdjunctProperty

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The first sentence of the description of the Adjunct property stereotype does not make sense:
    "The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states"

  • Reported: SysML 1.5 — Mon, 7 May 2018 12:13 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Dubious UUIDs

  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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: Closed; No Change — SysML 1.6
  • Disposition Summary:

    UUIDs Removed in 1.5

    UUIDs were removed in 1.5

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Typo in revised text of issue SYSML16-289

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typos in revised text for Annex C

    • Change "C.1.1 and C.1.2" to "C.1.2 and C.1.3".
    • Change "C.5 through C.7" to "C.4 through C.7".
  • Reported: SysML 1.5 — Mon, 5 Mar 2018 20:42 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Add signal to constraint [1] for DistributedProperty

  • Status: closed  
  • Source: Bombardier Transportation ( Karsten Koechlin)
  • Summary:

    At the moment the stereotype distrubtedProperty is only allowed to be applied to properties of classifier stereotyped by Block or ValueType.
    We would like to apply the distributedProperty stereotype also to properties of classifier stereotyped by Signal.
    Reason: The properties of a block are transmitted by signal properties, the properties of the signal should also reflect the distribution.

  • Reported: SysML 1.5 — Mon, 22 Jan 2018 12:43 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Add Graphical notation for General Classifier

  • Status: closed  
  • Source: Sierra Nevada ( Mr. Chas Galey)
  • Summary:

    The usage of Generalization in SysML is a key part of establishing Domain Specific Languages and contexts for models. In particular it has great ability to establish reusability within our models. However, the only mechanism via which we can visually denote the nature of an object is via non-normative extensions to M2 via stereotypes such as <<Car>> or other examples. This is undesirable, we should have the ability (on classes and parts typed by those classes) to optionally display the General (or any General class of a Block) classifier of a Block on BDD's, IBD's and Parametric diagrams. This will, greatly enhance the readability of our diagrams, remove the complexity of implementing M2 stereotypes simply designed for visualization, and expose via the diagram usage of reusable libraries to make the foundation of our models.

    Example Format might be (in ASCII art):

    ------------
    <<Block>>
    [Car]
    Porsche
    --------------

  • Reported: SysML 1.5 — Fri, 20 Oct 2017 05:22 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Diagram header is not intuitively interpreted

  • Status: closed  
  • Source: INCOSE / SSI ( Troy Peterson)
  • Summary:

    The SysML diagram header is not easily interpreted. Suggest a new format that provides the same information and content but following the typical naming convention used in SysML - i.e. name:Type

    Suggestion/Example:

    From:
    req [Package] Auto_Specification [Automobile System Requirements]

    To:
    Automobile System Requirements:req | Auto_Specification:Package

    Optional format adds "[req]" as an option to turn on to in bold or white text on a black background filling the header box around the diagram kind "req" in this case. Image examples provided to Rick Steiner and Sandy Friedenthal in separate communications.

    [req] Automobile System Requirements:req | Auto_Specification:Package

  • Reported: SysML 1.5 — Thu, 13 Sep 2018 04:34 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Do not move deprecated elements

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    Between SysML 1.2 and SysML 1.3, some stereotypes were deprecated
    This deprecation was done by moving Stereotypes from their original package to a new "DeprecatedElements" package.

    Changing the qualified names of these stereotypes may break some code in tooling. Ideally the deprecation should be indicated without changing the element.

    SysML 1.3 : http://www.omg.org/spec/SysML/20120401/SysML.xmi
    SysML 1.2 :http://www.omg.org/spec/SysML/20100301/SysML-profile.uml

  • Reported: SysML 1.5 — Mon, 11 Sep 2017 15:08 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints

  • Key: SYSML13-12
  • Legacy Issue Number: 15876
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Today, during the SysML1.3 RTF, we discussed simplifying the definition of the SysML profile by referencing the UML metamodel directly instead of the UML4SysML construction and replace the UML4SysML construction with OCL constraints about the scope of UML that defines strict conformance to SysML in the context of the UML4SysML subset. The practical advantages include:

    • any UML tool can be used as the basis for implementing the SysML profile
    • the SysML profile can be easily combined with other profiles that extend UML; e.g., SoaML, etc... (i.e., this could simplify the construction of UPDM)
    • if users need to use more than the UML4SysML subset, they could simply disable the OCL constraints for strict UML4SysML conformance
  • Reported: SysML 1.2 — Mon, 6 Dec 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Prior to UML2.4.1, the OMG never published the merged UML metamodel as a
    normative machine-readable artifact nor specified compliance to UML in terms of
    it. From an OMG Specification Management point of view (i.e., OMG’s SMSC
    policy), it makes sense to require that the only dependencies a published
    normative machine-readable artifact might have should be to other published
    normative machine-readable artifacts.
    For SysML1.2, the published normative machine-readable SysML1.2 profile
    depended only on the published normative machine-readable UML4SysML
    merged metamodel constructed from the published normative machine-readable
    artifacts for UML2.3’s Infrastructure & Superstructure. Because the UML2.3
    StandardProfileL2 was never published, this also meant that the SysML1.2
    profile had to duplicate the definition of UML2.3’s StandardProfileL2::Trace
    stereotype in the SysML profile, i.e., SysML::Trace.
    The 2.4.1 series of UML, MOF and XMI made significant changes to the OMG
    metamodel/profile architecture. In particular, the merged UML2.4.1 metamodel
    and the UML2.4.1 StandardProfileL2 are both published as normative machinereadable
    artifacts, which simplifies greatly problems of model interchange across UML 2.4.1 compliant tools. By aligning the SysML1.3 profile as a simpler
    extension of the published, normative UML 2.4.1 metamodel rather than a
    complicated extension of a partial merge of the UML Superstructure, SysML1.3
    can also benefit from improvements in model interchange for UML 2.4.1
    compliant modeling tools.
    In SysML1.2, the UML4SysML subset served two distinct purposes:
    1. Specifying which UML elements can be used in compliance with the
    limited scope of the SysML language.
    2. Constructing and publishing SysML in terms of a normative published
    machine-readable artifacts, i.e., the UML4SysML metamodel.
    The second purpose, constructing and publishing SysML, resulted in a significant
    implementation complexity and caused significant problems for model
    interchange testing. The UML4SysML metamodel represents a significant
    disincentive for UML tool vendors to build a lesser capability metamodel, i.e.,
    UML4SysML, just to provide support for the SysML profile. In fact, some UML
    tool vendors used UML instead of UML4SysML to implement support for the
    SysML profile. The publication of a normative merged metamodel in UML2.4.1
    and the multi-vendor efforts in the Model Interchange Working Group (MIWG)
    provide compelling reasons to do away with the special-purpose construction and
    publication of UML4SysML as a merged metamodel just for defining SysML
    properly.
    The first purpose, specifying the scope of the SysML language as an extension
    of a limited subset of UML, was perfectly within the spirit of the metamodel
    architecture from UML2.0 until UML2.3 where the UML 2 Infrastructure &
    Superstructure provided the basis for package-level reuse in the family of UML
    languages. Since there was no published, normative, merged metamodel for
    UML 2, it was perfectly legitimate and recommended to use package merge
    techniques to construct special-purpose languages like the UML4SysML subset
    for defining domain-specific extensions like SysML. With the publication of a
    normative, merged metamodel in UML2.4.1 and the change in metamodel
    architecture where UML2.4.1 is defined as an instance of itself, it makes sense to
    define the SysML 1.3 profile as an extension of the UML 2.4.1 merged
    metamodel. Unfortunately, this creates a complication for specifying the limited
    reuse of UML in SysML.
    According to UML, a Profile must reference the metamodel it extends via a
    PackageImport relationship whose target is the referenced metamodel (see
    section 18.3.7 in UML2.4.1 Superstructure). Consequently, any profile
    referencing the merged UML2.4.1 metamodel potentially extends every
    metaclass defined in UML2.4.1. SysML 1.3 effectively extends only a subset of
    UML2.4.1 metaclasses. Whereas this subset was defined via a package merge
    construction in SysML 1.2 for each SysML compliance level, each compliance
    level subset is defined in SysML 1.3 via constraints specifying that there should not be any instances of metaclasses outside the scope of that subset in a
    compliant model. For example, UML::Component is outside the UML4SysML
    subset.
    The corresponding compliance constraint in OCL for excluding the use of
    UML::Component in a compliant SysML 1.3 model is:
    Component.allInstances()->isEmpty()
    For SysML1.3, the UML4SysML subset includes 213 of the 242 metaclasses in
    UML2.4.1. The UML4SysML subset is further broken down into the 3 compliance
    levels defined for SysML1.2 adjusted to ensure that the required classifier
    dependencies for each classifier at a given level are also at that level or below.
    All general classifiers and all of the classifiers typing a property with required
    multiplicity are considered required classifier dependencies for a given classifier.
    Specifying SysML1.3 as a profile referencing the UML2.4.1 metamodel provides
    tangible practical benefits:
    ? Any UML2.4.1-compliant tool can be used as the basis for a compliant
    implementation of SysML1.3.
    ? Model interchange for SysML1.3 reduces to the interchange of UML2.4.1
    models with the application of one or more profiles extending UML2.4.1.
    ? Verifying a UML2.4.1 model with the SysML1.3 profiled applied for a given
    level of SysML 1.3 compliance amounts to verifying an OCL constraint or
    equivalently a QVT Operational query or QVT Relational pattern on that
    model.
    As of UML 2.4.1, the specification does not explicitly indicate if it is legal for a
    profile (e.g., SysML) to be applied to a package defined within that profile (e.g.,
    ModelLibrary in SysML 1.2). This resolution adopts a conservative, pessimistic
    interpretation of UML 2.4.1 where the only capabilities that SysML can
    normatively depend from UML are those that are explicitly called out in the
    specification document. In this particular case, it means that the library of
    predefined value types – see 8.3.3 in SysML 1.2 – cannot be nested within the
    SysML profile itself since the UML::DataTypes in that library must have the
    SysML::ValueType stereotype applied to them. In SysML 1.3, the predefined
    library of such ValueTypes is moved outside of the SysML profile precisely to
    avoid relying on undocumented profile semantics (see figures 4.3 and 8.7) .

  • Updated: Thu, 28 Feb 2019 14:39 GMT

JTC1 JP3 023

  • Key: SYSMLR-278
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

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

Precise expression of requirements

  • Key: SYSMLR-155
  • Legacy Issue Number: 19591
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. 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: University of Arizona ( Mr. 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:

Property path with unnamed properties is unreadable

  • Key: SYSMLR-332
  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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

There is no notation for units on properties and values

  • Key: SYSMLR-330
  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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

TriggerOnNestedPort constraint [5] makes no sense

  • Key: SYSMLR-287
  • Status: closed  
  • Source: University of Arizona ( Mr. 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: University of Arizona ( Mr. 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

JTC1 JP20 016

  • Key: SYSMLR-271
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP18 015

  • Key: SYSMLR-270
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP19 014

  • Key: SYSMLR-269
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

JTC1 JP17 013

  • Key: SYSMLR-268
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP12 008

  • Key: SYSMLR-263
  • Status: closed  
  • Source: University of Arizona ( Mr. 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:

JTC1 JP16 012

  • Key: SYSMLR-267
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

JTC1 JP13 010

  • Key: SYSMLR-265
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

ParticipantProperty multiplicity

  • Key: SYSMLR-248
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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:

Add example of PBR using Block


update constraints to set sourceContext and targetContext of «DirectedRelationshipPropertyPath»

  • Key: SYSMLR-324
  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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:

JTC1 JP4 024

  • Key: SYSMLR-279
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP5 022

  • Key: SYSMLR-277
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP2 021

  • Key: SYSMLR-276
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP24 020

  • Key: SYSMLR-275
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP23 019

  • Key: SYSMLR-274
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

JTC1 JP22 018

  • Key: SYSMLR-273
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP9 005

  • Key: SYSMLR-260
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP7 004

  • Key: SYSMLR-259
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP8 003

  • Key: SYSMLR-258
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP21 017

  • Key: SYSMLR-272
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP10 007

  • Key: SYSMLR-262
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP11 006

  • Key: SYSMLR-261
  • Status: closed  
  • Source: University of Arizona ( Mr. 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 JP15 011

  • Key: SYSMLR-266
  • Status: closed  
  • Source: University of Arizona ( Mr. 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: University of Arizona ( Mr. 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

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 JP6 002

  • Key: SYSMLR-257
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

16.3.2.4 Requirement Operations OCL Inconsistent

  • Key: SYSMLR-231
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

JTC1 JP1 001

  • Key: SYSMLR-256
  • Status: closed  
  • Source: University of Arizona ( Mr. 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

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

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:

Forked association notation ill-formed

  • Key: SYSMLR-126
  • Legacy Issue Number: 18685
  • Status: closed  
  • Source: NIST ( Mr. 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

reception compartment not addressed

  • Key: SYSMLR-153
  • Legacy Issue Number: 19551
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 diagrams show only SysML-stereotyped elements

  • Key: SYSMLR-85
  • Legacy Issue Number: 16891
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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:

Multiassociation

  • Key: SYSMLR-74
  • Legacy Issue Number: 16170
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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

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

Parts are added directly into package

  • Key: SYSMLR-13
  • Legacy Issue Number: 11499
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

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

  • Key: SYSMLR-12
  • Legacy Issue Number: 11496
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

Lack of notation for units and dimensions on values.

  • Key: SYSMLR-11
  • Legacy Issue Number: 11493
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

BindingConnector

  • Key: SYSMLR-10
  • Legacy Issue Number: 11333
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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

Issue: Nested connector ends

  • Key: SYSMLR-9
  • Legacy Issue Number: 11276
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

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 ( Dr. 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

Section: 12. Interactions

  • Key: SYSMLR-8
  • Legacy Issue Number: 11117
  • Status: closed  
  • Source: International Business Machines ( Mr. 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

Block namespace compartment: Are external relationships allowed

  • Key: SYSMLR-7
  • Legacy Issue Number: 11011
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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 ( Mr. 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

Section: 9.3.2.5 FlowPort

  • Key: SYSMLR-4
  • Legacy Issue Number: 10410
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

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

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

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

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

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

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

Section: Generalization of stereotyped elements

  • Key: SYSMLR-26
  • Legacy Issue Number: 12255
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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.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

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 / Figure B.35


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

AllocateActivityPartition and UML 2 semantics

  • Key: SYSMLR-37
  • Legacy Issue Number: 13342
  • Status: closed  
  • Source: NIST ( Mr. 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

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

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

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

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

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

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

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

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

callout notation issues

  • Key: SYSMLR-45
  • Legacy Issue Number: 14575
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

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 ( Mr. 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

Proposal to have a stereotype for reference nested property

  • Key: SYSMLR-42
  • Legacy Issue Number: 14055
  • Status: closed  
  • Source: International Business Machines ( Mr. 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

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

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

Allocations should not generate dependencies

  • Key: SYSMLR-39
  • Legacy Issue Number: 13840
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

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

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

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

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

SysML primitive value types

  • Key: SYSMLR-62
  • Legacy Issue Number: 15882
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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 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

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

Definition of part

  • Key: SYSMLR-70
  • Legacy Issue Number: 16058
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

Figure B.35 object nodes

  • Key: SYSMLR-58
  • Legacy Issue Number: 15683
  • Status: closed  
  • Source: International Business Machines ( Mr. 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

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

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

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

Another issue with allocate

  • Key: SYSMLR-63
  • Legacy Issue Number: 15884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

Item flows can have multiple types but item properties cannot

  • Key: SYSMLR-68
  • Legacy Issue Number: 16042
  • Status: closed  
  • Source: NIST ( Mr. 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

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

Description of Item Flows

  • Key: SYSMLR-66
  • Legacy Issue Number: 15985
  • Status: closed  
  • Source: NIST ( Mr. 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

IBD notation doesn't distinguish item properties from connector labels

  • Key: SYSMLR-65
  • Legacy Issue Number: 15983
  • Status: closed  
  • Source: NIST ( Mr. 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 ( Dr. Nicolas F. 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

Association owning ends

  • Key: SYSMLR-75
  • Legacy Issue Number: 16263
  • Status: closed  
  • Source: The MathWorks ( Mr. 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

Where have stereotypes been defined?

  • Key: SYSMLR-72
  • Legacy Issue Number: 16112
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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

Incorrect statement about UML n-aries

  • Key: SYSMLR-71
  • Legacy Issue Number: 16093
  • Status: closed  
  • Source: NIST ( Mr. 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

Compartment labelling rules

  • Key: SYSMLR-69
  • Legacy Issue Number: 16057
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. 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

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 ( Dr. 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

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

Question about the Activity decomposition in Bloc Definition Diagrams

  • Key: SYSMLR-86
  • Legacy Issue Number: 16945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

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

  • Key: SYSMLR-84
  • Legacy Issue Number: 16876
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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

Issue on Block constraint#4

  • Key: SYSMLR-83
  • Legacy Issue Number: 16726
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

Can Enumerations be used on parametric diagrams for typing constraint parameters

  • Key: SYSMLR-77
  • Legacy Issue Number: 16304
  • Status: closed  
  • Source: MAHLE International GmbH ( 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

TestCase should use PackageMerge

  • Key: SYSMLR-76
  • Legacy Issue Number: 16286
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. 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

Problems with property-specific types

  • Key: SYSMLR-79
  • Legacy Issue Number: 16636
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. 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

Content of Requirement::/tracedTo

  • Key: SYSMLR-78
  • Legacy Issue Number: 16373
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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

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 ( Mr. 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

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

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

InstanceSpecification equality

  • Key: SYSMLR-81
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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

InstanceSpecifications for exactly one instance

  • Key: SYSMLR-80
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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

remove figure numbers from diagram frames

  • Key: SYSMLR-96
  • Legacy Issue Number: 17423
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. 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

Callout notation for port-specific types and initial values

  • Key: SYSMLR-95
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

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

  • Key: SYSMLR-94
  • Legacy Issue Number: 17373
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

Interface blocks and protocols

  • Key: SYSMLR-101
  • Legacy Issue Number: 18169
  • Status: closed  
  • Source: Airbus Group ( Mr. 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 ( Mr. 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

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSMLR-99
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. 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

clarification, what "part property" is

  • Key: SYSMLR-93
  • Legacy Issue Number: 17307
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

9.3.2.9 What is InterfaceBlock?

  • Key: SYSMLR-92
  • Legacy Issue Number: 17255
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

Port labels inside Port symbol

  • Key: SYSMLR-91
  • Legacy Issue Number: 17251
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

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

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

Section 9.3.1.7

  • Key: SYSMLR-90
  • Legacy Issue Number: 17248
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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 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

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

Figure 15.8 diagram type

  • Key: SYSMLR-109
  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Mr. 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

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

9.3.2.4 direction of ports and their notation (second issue)

  • Key: SYSMLR-113
  • Legacy Issue Number: 18441
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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: Dassault Systemes ( Mr. 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

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

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

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

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

VerdictKind

  • Key: SYSMLR-107
  • Legacy Issue Number: 18312
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

SysML stereotype notation creates ambiguity about to which element is the stereotype applied

  • Key: SYSMLR-106
  • Legacy Issue Number: 18268
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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

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

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 ( Dr. Nicolas F. 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

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

ProxyPort with FlowProperties

  • Key: SYSMLR-124
  • Legacy Issue Number: 18676
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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: Dassault Systemes ( Mr. 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

Semantics of multiple Dependencies

  • Key: SYSMLR-122
  • Legacy Issue Number: 18623
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

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

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

Ports and Flows

  • Key: SYSMLR-114
  • Legacy Issue Number: 18458
  • Status: closed  
  • Source: NIST ( Mr. 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

Libraries package should be named "SysML Model Libraries"

  • Key: SYSMLR-118
  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Mr. 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

Allocated notation on object nodes missing from diagram elements table

  • Key: SYSMLR-117
  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Mr. 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

Allocation tabular notation normative?

  • Key: SYSMLR-116
  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Mr. 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

Figures 15.5 and 15.6 diagram types

  • Key: SYSMLR-115
  • Legacy Issue Number: 18459
  • Status: closed  
  • Source: NIST ( Mr. 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

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 ( Mr. 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

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 ( Dr. Nicolas F. 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 ( Dr. 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

The SysML classification of properties is incomplete

  • Key: SYSMLR-128
  • Legacy Issue Number: 18709
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. 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

Semantics consistency of conjugated behavior ports

  • Key: SYSMLR-138
  • Legacy Issue Number: 18952
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

Proxy port “complete” specification (§ 9.3.2.12):

  • Key: SYSMLR-137
  • Legacy Issue Number: 18909
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

Flow property description: incorrect wording (§9.3.2.7)

  • Key: SYSMLR-136
  • Legacy Issue Number: 18907
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Key: SYSMLR-135
  • Legacy Issue Number: 18877
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

Pull semantics for flow properties

  • Key: SYSMLR-134
  • Legacy Issue Number: 18876
  • Status: closed  
  • Source: Airbus Group ( Mr. 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 to Trace Relationship’

  • Key: SYSMLR-144
  • Legacy Issue Number: 19284
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

Convention for enumeration not used for ControlValue

  • Key: SYSMLR-143
  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

Update SysML references to UML model library StandardProfileL2

  • Key: SYSMLR-142
  • Legacy Issue Number: 19123
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

classifierBehaviorProperty and adjunctProperty notation

  • Key: SYSMLR-147
  • Legacy Issue Number: 19326
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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

URI for the SysML Profile given in section E.3 is wrong

  • Key: SYSMLR-146
  • Legacy Issue Number: 19321
  • Status: closed  
  • Source: PTC ( Mr. 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

Abstract syntax for the initial values

  • Key: SYSMLR-145
  • Legacy Issue Number: 19286
  • Status: closed  
  • Source: Airbus Group ( Mr. 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 ( Dr. Nicolas F. 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: Dassault Systemes ( Mr. 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

Semantics clarification for removing a value from an out Flow Property

  • Key: SYSMLR-139
  • Legacy Issue Number: 18953
  • Status: closed  
  • Source: Airbus Group ( Mr. 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 ( Dr. Nicolas F. 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

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 ( Dr. Nicolas F. 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

[SysML] Semantic variation points

  • Key: SYSMLR-150
  • Legacy Issue Number: 19489
  • Status: closed  
  • Source: Airbus Group ( Mr. 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

More than one View() operation allowed

  • Key: SYSMLR-158
  • Legacy Issue Number: 19623
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

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

ElementGroup cannot be source or target of a dependency

  • Key: SYSMLR-156
  • Legacy Issue Number: 19595
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

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 ( Mr. 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 ( Mr. 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 ( Mr. 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: GfSE e.V. ( Mr. 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 ( Mr. 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

Missing comment for some attributes

  • Key: SYSMLR-238
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. 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

Dubious UUIDs

  • Key: SYSMLR-243
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Mr. 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

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: GfSE e.V. ( Mr. 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

specializations of requirement should specialize AbstractRequirement

  • Key: SYSMLR-247
  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Key: SYSMLR-328
  • Status: closed  
  • Source: GfSE e.V. ( Mr. 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: GfSE e.V. ( Mr. 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

09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port

  • Legacy Issue Number: 12222
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Experience modelling a wide range of heterogeneous systems has proven that the representation of logical channels as information flows across connections between flowports nested within standard ports is a very useful idiom. It would help if this possibility is explicitly stated in both 9.3.2.3 FlowPort, 9.3.2.7 Standard Port, and illustrated in specification figures. Example: a software application acquires encoded signals representing physical positon and rotation via a high-level software API to a low-level A./D card in a computer. The software application is connected to an A/D module subject to a contract represented by an Interface provided by a standard port (subject ot a protocol). The flow of information corresponding to logical acquired channels can be well represented as flowports nested within the standard port of the A/D module. This example is illustrated in detail at: http://school.nomagic.com/node/194 It is marked as 'significant' because without this idiom of nesting flowports on standard ports it is impossible or very difficult to model a wide range or real-world systems.

  • Reported: SysML 1.0 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 18:08 GMT

Invocations of required behavior features without going through ports

  • Key: SYSML13-61
  • Legacy Issue Number: 16264
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Invocations of required behavioral features on self should be forwarded along links from the executing object to external objects that provide those features. Currently this can only be done through ports.

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

    No Data Available

  • Updated: Sun, 8 Mar 2015 17:59 GMT

Metamodel error in 14447 and 18407

  • Key: SYSML14-49
  • Legacy Issue Number: 18987
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    In the resolution to issue 14447 and 18407 in SysML 1.4 ballot 4, the metamodel figure is out of synch with the element descriptions, in particular for the source and target properties. The resolution to 18407 doesn't have revised text explaining when sourceContext and targetContext are needed.

  • Reported: OCL 2.3.1 — Fri, 4 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Modify the metamodels figures to align with the element description for
    DirectedRelationshipPropertyPath, and replace references to source and target
    classifiers to source and target contexts. Explain when they are needed.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section: 11.3.2.2 ControlOperator

  • Legacy Issue Number: 11267
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    What happens if a control value from a control operator stops the following action and there are no more tokens left and no actions are active? Does this terminates the execution of the activity? What if the control value suspends the action? Who can resume the action? There are no more tokens and running actions.

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

    No Data Available

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

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp

  • Legacy Issue Number: 12163
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s There are at least three applications of the UML2 Component which I consider very beneficial to practical UML-based systems engineering: 1st: I make extremely heavy use of the technique of stereotyped <<composition>>, <<inhertance>>, <<specialisation>> "wrapper" Components to graphically and logically organise model elements in BDDs (and in class diagrams) "parastically", i.e. without stealing ownership of the contained elements. Especially the <<composition>> wrapper Component is very powerful for diagramming and organising hierarchical assemblies of complex systems. In such cases the wrapping Component has Realizations to the wrapped elements, which can be further leveraged to trace the logical groupings. The recipe is consistent with the UML2.1.1 superstructure (although it is not supported in all UML tools). I contend the wrapper Component strategy should be made officially available to those SysML users who wish to use it (at least as a permitted option). 2nd:If one permits the UML2.1.1 Component the SysML <<requirement>> stereotype can be applied to Components so that Requirements can be graphically nested, which is far more graphically stable than just diagramming Class <<requirement>> Dependencies, and can be consistently applied in combination with the existing relationship stereotypes between SysML requirements. 3rd: Components are far better suited to creating orthogonal, parasitic <<views>> of packaged elements than the Package or Model, which both steal ownership.

  • Reported: SysML 1.0 — Mon, 7 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s Discussion:
    SysML currently lacks capability to represent system views that define parts or
    other substructure differently than other system views. As noted by the issue,
    any declaration of ownership or other other model structure in one view cannot
    conflict with such declarations in other views. The View stereotype of Package
    defined in Chapter 7, Model Elements, only selects elements for inclusion in any
    one view, and does not support additional structure which may differ across
    views. The proposal to consider Component as a basis for “orthogonal, parasitic
    <<views>>” is an interesting possibility, but goes beyond the scope of
    incremental change that can be considered in an RTF. Addition of such a fundamental capability to SysML, and a UML profile which bases this capability
    on UML Component, could be considered in response to an RFP for a major new
    version of SysML.
    Disposition: Closed, no change

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

10.Constraint, Figure 10.3

  • Legacy Issue Number: 12159
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    In Figure 10.3: 'delta-t' is shown with solid-line (AggregationKind 'composite'), is 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: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Discussion:
    Figure 10.3 will be replaced with a reference to Figure B.29 as part of the
    resolution for Issue 13976, “Example figures in chapters are redundant with
    Annex B sample problem.” Issue 12160 raised this same issue on Figure B.29.
    Disposition: See issues 12160 and 13976 for disposition

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

Section: 8.3.2.1

  • Legacy Issue Number: 12157
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Clarify that a binding connector can have nested connector ends like a regular connector. In particular, clarify that a binding connector can bind to parameters of a nested constraint property, without having to bind to an intermediate parameter of the outer constraint property. A binding connector can clearly bind to a nested value property using the dot notation or directly to a value property nested within parts.

  • Reported: SysML 1.0 — Thu, 3 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Add sentences to provide the requested clarification. Also remove redundant language from 8.3.2.2 Block now that a separate BindingConnector stereotype has been defined.

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

10.3.2.2 ConstraintProperty

  • Key: SYSML11-86
  • Legacy Issue Number: 12130
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    10.3.2.2 ConstraintProperty: rewrite constraint [2] so does not refer to 'a SysML Block that is typed by a ConstraintBlock' SysML1.0, 10.3.2.2 ConstraintProperty: 'A constraint property is a property of any block that is typed by a constraint block. .. [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock.' These may both be misinterpreted as applying to "any block that is typed by a constraint block" and "a SysML Block that is typed by a ConstraintBlock" rather than a constraint property typed by a constraint block. Rewrite so that the type condition clearly applies to the owned constraint property, not the owning block, thus: 'A constraint property is a property that is typed by a constraint block and is owned by a block. . [2] The ConstraintProperty stereotype must be applied to any property that is typed by a ConstraintBlock.' (Note that the first constraint already makes it clear that a constraint property is owned by a SysML Block: '[1] A property to which the ConstraintProperty stereotype is applied must be owned by a SysML Block'.)

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

    The ConstraintProperty stereotype expresses a condition that can be entirely derived
    from other information in the metamodel, in this case a property of a block that is
    typed by a ConstraintBlock. Property stereotypes are not defined for other categories
    of property, such as part, reference, or value properties.
    The constraints which currently appear under Section 10.3.2.2 ConstraintBlock, only
    serve to define the ConstraintProperty category. A definition of the term “constraint
    property” can be provided by language under 10.3.2.1 ConstraintBlock, similar to
    how categories of part, reference, and value properties are defined under Section
    8.3.2.2 Block.
    OMG Issue No: 12130 Disposition: Resolved
    SysML 1.4 RTF Report Page 25 of 341
    Discussion in previous RTF's suggested that a consistent policy be adopted for
    “calculated stereotypes” which only classify existing elements. Tools are still free to
    establish internal stereotypes or other means to carry such information, but since no
    other such calculated stereotypes remain in SysML, the consistent policy is to
    remove the ConstraintProperty stereotype from the normative specification. Impact
    on existing implementations should be minimal since they may still preserve such a
    stereotype if it is useful to their implementation, but this specific stereotype would no
    longer be required by the specification.
    In the stereotypes for measures of effectiveness defined in Table D.5, require that
    the base element for the «objectiveFunction» stereotype be a ConstraintBlock, as
    stated in the immediately preceding text: "The objective function is a stereotype of a
    ConstraintBlock and the measure of effectiveness is a stereotype of a block
    property."

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

10.3.2.2 ConstraintProperty

  • Key: SYSML11-85
  • Legacy Issue Number: 12129
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    10.3.2.2 ConstraintProperty: add constraint that the AggregationKind must be 'composite' Add a constraint: [3] A property to which the ConstraintProperty stereotype is applied must have AggregationKind 'composite'

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

    Issue 12130, “clarify constraint with OCL as well as text”, drops the
    ConstraintProperty stereotype altogether, after analysis of potential OCL
    indicated that the constraints added no new information but only served to define
    the constraint property category of block properties. A constraint specifying the
    AggregationKind of a constraint property (defined simply as any property of a
    block typed by a ConstraintBlock) is still appropriate to add, but can no longer
    placed under the ConstraintProperty stereotype as recommended by this issue.
    Instead, this constraint is being added under the ConstraintBlock stereotype
    under Section 8.3.2.1.

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

10 Constraint Blocks, 10.3.2.1 ConstraintBlock

  • Key: SYSML11-87
  • Legacy Issue Number: 12132
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    10 Constraint Blocks and 10.3.2.1 ConstraintBlock: parameters never clearly defined SysML1.0, 10 Constraint Blocks: 'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint.' The above does not make clear that parameters are properties that can be typed by a ValueType (yet are not value properties), and it does not exclude nested contraints, which are properties typed by a <<ConstraintBlock>> (although other sentences elsewhere in the specification do make that clearer). Also, it is not clear whether a constraint parameter can be typed by a block (although there are no examples of such in the figures). Rewrite to specify what constraint parameters are: 'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block typed by a ValueType, Unit, or DataType define the parameters of the constraint.' SysML1.0, 10.3.2.1 ConstraintBlock: '.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.' Rewrite to explain what constraint parameters are: '.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used. Constraint parameters are properties of a Constraint Block that are typed by either a ValueType, a Unit, or a DataType.' (NB: the resolutions suggested here depends on the unit, value, dimension metamodel being changed to admit the application of Unit as a type.) This matter could be greatly simplified by including a ConstraintParameter stereotype as a point of documentation and specification

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

    SysML does not restrict the type of parameters to which constraint blocks may be
    applied. Even though the typical examples apply parametric constraints to value
    parameters, such as mathematical expressions that constrain numeric property
    values, constraint blocks may also be applied to structural properties such as parts or
    reference properties.
    Reword the explanatory sentence referenced by the issue from the final introduction
    paragraph to avoid suggesting that constraint parameters are the only kind of
    property a constraint block may contain. Also, avoid language that excludes recursive
    definition of constraint blocks, in which a nested constraint property references the
    same constraint block being defined.

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

Annex B/B.4.1.2 Package Diagram

  • Key: SYSML11-95
  • Legacy Issue Number: 12140
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    B.4.1.2 Package Diagram: <<access>> should be <<import>> SysML1.0: 'B.4.1.2 Package Diagram - Showing Package Structure of the Model .. The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «access» relationship.' In fact Figure B.3 shows <<import>> relationships.

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

    No Data Available

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

15.3.2.3 AllocateActivityPartition

  • Key: SYSML11-94
  • Legacy Issue Number: 12139
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    15.3.2.3 AllocateActivityPartition(from Allocations): /supplier (from) /client (to) wrong way round >From SysML1.0 15.3.2.3 AllocateActivityPartition(from Allocations): 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (from) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (to) end of the same «allocate» dependency.' Should read: 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (to) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (from) end of the same «allocate» dependency.' Note that a similar mixup was reported for 15.3.2.2 Allocated(from Allocations): 'Issue 11501: Wrong ends of Allocate relationship used in Allocated definition (sysml-rtf) Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")'

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

    Above suggestion is incorrect; the action should be the client (from) end. Revise
    text consistent with resolution to issue #11501.

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

11 Activities, Figure 11.10

  • Key: SYSML11-92
  • Legacy Issue Number: 12137
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure 11.10 Suggest use output Pin from <<controlOperator>> 'Enable On Brake Pressure > 0' typed by ControlValue The <<controlOperator>> action ':Enable on Brake Pressure > 0' does not show an output Pin corresponding to an output Parameter of type ControlValue that must exist for the Behavior Enable on Brake Pressure > 0. From SysML1.0: '11.3.2.2 ControlOperator ,, Constraints [1] When the «controlOperator» stereotype is applied, the behavior or operation must have at least one parameter typed by ControlValue. If the stereotype is not applied, the behavior or operation may not have any parameter typed by ControlValue.' It would make sense (and be clearer) if the «controlOperator» had an output Pin typed by ControlValue. Below we see the diagram adapted to use an output Pin typed by ControlValue: http://school.nomagicasia.com/node/109 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png

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

    Revise as suggested.

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

11.Activities, Figure11.10

  • Key: SYSML11-91
  • Legacy Issue Number: 12136
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure11.10 suggest use anonymous, typed Pins for clear indication of flowing information type and to support

    {stream} Parameter t is difficult and/or inconsistent to show the {stream}

    indication of the Action ':Driving' without an output Pin corresponding to an underlying output Parameter of Behavior 'Driving' satisfying the 'isStream=true' condition. Indeed Table 11.1 - Graphical nodes included in activity diagrams shows only Actions with Pins and the

    {stream}

    indicator for UML4SysML::Parameter.isStream The following image shows Figure 11.10 adapted to use Pins throughout (except for ControlValue input to the controller Action 'Monitor Traction'): http://school.nomagicasia.com/node/108 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png NB: this issue submissions is marked as 'significant' because the I consider it extremely important that the SysML effort advertises the clear advantages of Pins whereever possible to the benefit of tool vendors and end users.

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

    No Data Available

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

11.Activities/11.3.2.8 Rate/Figure 11.8

  • Key: SYSML11-89
  • Legacy Issue Number: 12134
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    The «rate» stereotype has a property 'rate' of type ValueSpecification 11.3.2.8 Rate yet InstanceSpecification in Figure 11.8 SysML1.0, 11.3.2.8 Rate: 'The «rate» stereotype has a rate property of type ValueSpecification.' However Figure 11.8 shows 'rate' with type InstanceSpecification. (Also, the 'rate' property should be clearly defined as an Attribute of <<rate>> in 11.3.2.8 Rate.)

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

    The has a rate property of type ValueSpecification. The values of properties stereotyped by "rate" must be instances, see next to last sentence of Section 11.3.2.8 (Rate). The metamodel is enough to show "rate" is an attribute of "rate".

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

11 Activities, 11.2.1 Activity Diagram

  • Key: SYSML11-88
  • Legacy Issue Number: 12133
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Table 11.1 and Table 11.2: appear to contradict constraint that <<discrete>> and <<continuous>> should not be both applied SysML 1.0, 11.3.2.3 Discrete: '[1] The «discrete» and «continuous» stereotypes cannot be applied to the same element at the same time.' However Table11.1 and Table 11.2 Rate examples appear to show both «discrete» and «continuous» applied to the same element at the same time, and Table 11.1 appears to show overloaded tagged values

    {rate=constant}

    and

    {rate=distribution}

    . Resolution: change Table11.1 and Table 11.2 to show dedicated examples of «discrete» and «continuous» stereotype usage.

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

    No Data Available

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

11. Activities

  • Key: SYSML11-93
  • Legacy Issue Number: 12138
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    I suggest general policy for SysML: prefer Pins over ObjectNodes in all possible cases Use of ObjectNodes is problematic for many reasons, including: - In UML2.1.1 ObjectNode is abstract ! Tool vendors are thus forced to choose an arbitrary concrete placeholder (like <<CentralBufferNode>>, which is invalid). Use of Pins avoid this problem. - ObjectNodes are graphically less stable than Pins, as on has to manage the placement of ObjectNodes between Actions and two paths. - It is easier to trace type compatibility of connections between between Pins representing typed Parameters than across two paths via an ObjectNode with no binding to Parameters. - The placement of ObjectNodes on swimlanes boundaries (like in Figure B.35) is contrived and graphically unstable. Experience has shown that Pins are far easier to read, verify, and manage, and they correspond well to the idioms of signal processing known to engineers. I recommend that they be used in ALL SysML diagrams wherever possible, and that this be adopted as SysML policy, to the advantage of systems engineers, educators, and tool vendors alike.

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

    No Data Available

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

Annex B, B.4.4.3 Requirement Diagram

  • Key: SYSML11-96
  • Legacy Issue Number: 12141
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    SysML1.0, p.188: 'B.4.4.3 Requirement Diagram - Acceleration Requirement Relationships Figure B.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. The “refineReqt” relation, introduced in Figure B.12, ..' Should read '"refine" relation'.

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

    No Data Available

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

11 Activities, Figure 11.10


Missing tags in XMI

  • Legacy Issue Number: 12548
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XMI is missing the tags for declaring the namespace and prefix for serializing instances of the stereotypes

  • Reported: SysML 1.0 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue is resolved by using the same procedures for preparing the published
    artifacts for SysML1.3 as the procedures used for preparing the published
    artifacts for UML2.4.1, including StandardProfileL2/L3.
    Disposition: See issue 15876 for disposition

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

The href should reference the URI for the UML elements

  • Legacy Issue Number: 12547
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The href should reference the URI for the UML elements. This may need the namespace for UML4SysML to match that of UML

  • Reported: SysML 1.0 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    SysML1.3 follows the same process used for publishing the artifacts in the 2.4.1
    series of UML, MOF and XMI where references to elements defined in external
    artifacts use the full document URL of the external artifact. Moreover, there is no
    longer a separate UML4SysML artifact – all references to UML metaclasses are
    in terms of the full document URL to the UML2.4.1 metamodel.
    Disposition: See issue 15876 for disposition

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

type should be cmof:Class not uml:Class

  • Legacy Issue Number: 12546
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    1. The XMI for the SysML has references to the metamodel as follows:

    <packagedElement xmi:type="uml:Stereotype" xmi:id="Rate" name="Rate">
    <ownedAttribute xmi:type="uml:Property" xmi:id="Rate-base_Parameter" name="base_Parameter" association="Parameter_Rate">
    <type xmi:type="uml:Class" href="UML4SysML-metamodel.xmi#Parameter"/>

    The type should be cmof:Class not uml:Class

  • Reported: SysML 1.0 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue is no longer relevant for SysML1.3 since SysML1.3 extends UML2.4.1
    which, altough still a CMOF metamodel, is nonetheless represented as a
    UML2.4.1 model. Therefore, in the SysML1.3 XMI, all references to UML
    metaclasses are in terms of their UML representation, not CMOF.
    Disposition: See issue 15876 for disposition

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

4.2: StandardProfileL2 uses elements not supported by SysML

  • Legacy Issue Number: 12510
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    SysML imports the UML StandardProfileL2. It contains useful stereotypes like modelLibrary. But it also includes stereotypes that extend UML elements that are not supported by SysML like artifact or component. Some stereotypes extend Class. From the viewpoint of SysML they should be an extension of stereotype Block. That's a conflict in the SysML language architecture. Proposal: Remove import of StandardProfileL2 and define a SysML specific standard profile.

  • Reported: SysML 1.0 — Thu, 22 May 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Since SysML1.3 extends UML2.4.1 whose StandardProfileL2 library is published
    as a normative artifact, it is no longer necessary for SysML to define its own
    Trace stereotype; SysML can use StandardProfileL2::Trace instead. However,
    except for StandardProfileL2::Metaclass which is used to denote classes that are
    part of a metamodel, the SysML specification does not specifically identify any
    other stereotype from StandardProfileL2 in its scope.
    Within the strict definition of SysML where only the metaclasses in the
    UML4SysML subset are allowed, several stereotypes from StandardProfileL2
    cannot be used with SysML because they extend classes outside the
    UML4SysML subset. Thus, File, Document, Executable, Library, Script and
    Source are excluded because they extend Artifact, and Entity, Implement,
    Process, Service and Subsystem are excluded because they extend Component.
    See resolution to issue 15876 for further details.
    Disposition: See issue 15876 for disposition

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

Section: 08 Blocks, Annex B, Annex C

  • Legacy Issue Number: 12435
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    It is not enough to refer simply to (p.180): 'The «system» and «external» stereotypes are user defined, not specified in SysML,' Although already raised as Issue 12257, this new Issue submission (by a different submitter) makes the constructive suggestion that the 'user defined' stereotypes by defined in non-normative extension Section in the Annex C. It is not acceptable that a specification dedicated to systems engineering does not even have at least a well-defined non-normative definition of a <<system>> and <<system context>> ! These need to be upgraded to a non-normative Annex, and then introduced properly through the example. I see no reason why the figures should not use non-normative stereotypes as long as they are defined in an Annex and clearly. This is not the case for <<system context>>, <<system>>, <<external>>, <<domain>>, <<subsystem>>, yet these are truly crucial for even basic systems engineering, and the examples (which use them well) make little sense without them. There is a very nice summary of C.2 Requirements Diagram Extensions. and those requirement categories have proved very useful already. I have made a small summary and guide here: http://school.nomagic.com/node/396 Block extensions (non-normative) As recommended through SysML1.0 examples: * «system» top-level block to be used in a system context * «subsystem» grouping (usually physical) within a system * «external» outside the top-level system (yet affecting it) * «domain» provides a common context for a system and externals * «system context» a particular context for a system and externals Note my definitions for <<domain>> vs. <<system context>>. I suggest that at least «system context» should have a tag: system:<<system>>[1] <<domain>> could then extend <<system context>>. Visit also: http://school.nomagic.com/node/415

  • Reported: SysML 1.0 — Sat, 10 May 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    As noted by the issue,Section B.4.2.1, Internal Block Diagram - Setting Context,
    includes the following sentence:
    The «system» and «external» stereotypes are user defined, not specified
    in SysML, but help the modeler to identify the systemof interest relative to
    its environment.
    Many forms of non-normative stereotypes could be developed to distinguish
    particular user modeling distinctions and practices. The issue itself notes possibly
    different stereotypes (such as «domain») than those used in the example. The
    availability of user-defined stereotypes to make such distinctions is clearly
    indicated by the example.Rather than incorporating a particular set of
    stereotypes directly in the SysML specification, the original submission
    deliberately left these open-ended to support possibly different modeling needs.
    Multiple sets of these stereotypes could be developed as part of separately
    distributed model libraries. Since the SysML specification is primarily concerned
    with the definition of the core SysML language, the omission of further detailed
    specification of user-model stereotypes is in keeping with the scoping decisions
    of the material to be maintained as a direct part of the SysML specification.
    Disposition: Closed, no change

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

Section: 08 Blocks: suggest need Quantity stereotype and definition

  • Legacy Issue Number: 12219
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    stereotype for a Quantity is required. The current Unit, Value, Dimension system in SysML is incomplete without the crucial concept of Quantity. A physical or industrial Quantity is independent of a choice of unit and value as measured or stated. A Quantity has a Dimension, which can be fundamental (as in the SI system), or derived (according to industrial needs). A Quantity DOES NOT have a Unit, and it DOES NOT have a relationship to a given unit systems, although it may be allocated a default unit within a given system. The statement/measurement of a Quantity is given as a value relative to a chosen Unit. A Quantity is represented in SysML by a value property (typed currently by a ValueType, although a strong case can be made for typing by a value property directly by a Unit).

  • Reported: SysML 1.0 — Tue, 12 Feb 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue points out that Quantity is a distinct concept from either Unit or
    Dimension, even though SysML currently defines stereotypes only for Unit,
    Dimension, and a ValueType to type values that may have a unit and/or
    dimension.
    To resolve these issues, and to clarify terminology to be used in a consistent way
    not only for SysML, but for its alignment and close partnership with MARTE, an
    extensive effort has been made to model the underlying concepts as defined by
    the most recent and authoritative sources. A new Annex C.5 provides a
    comprehensive model, expressed in terms of SysML blocks, for the interrelated
    concepts pertaining to quantities, units of measure, conversions among units,
    and dimensional analysis within systems of quantities.
    The new Annex C.5 is non-normative and is intended to fill two basic roles. One
    is a detailed conceptual model of the quantities domain, that, with the aid of
    examples built as instances of the blocks in this model, thoroughly expresses
    and defines the concepts which the SysML quantities-related stereotypes were support for capturing and documenting systems of units and quantities
    comprehensively in a form suitable for dimensional analysis.
    SysML 1.0 deliberately provided only minimal stereotypes to identify and name
    units and/or dimensions associated with value types. It did not provide further
    support for defining and documenting them including their relationships to each
    other. Practical use of this modest capability has shown that comprehensive
    documentation of units and related concepts is an important requirement for
    quantity values to be defined unambiguously and used in consistent ways.
    Although Annex C.5 provides much more comprehensive support for defining
    and organizing unit and quantity-related concepts in reusable domain-specific
    libraries than SysML 1.0 did, minimal changes are made to the normative parts of
    SysML 1.x for incorporating the new concepts. The principal change is to
    rename the current SysML stereotype “Dimension” to “QuantityKind.” The
    current definition of Dimension in SysML 1.1 as ”a kind of quantity that may be
    stated by means of defined units,” closely matches the QuantityKind concept in
    Annex C.5, while Dimension is reserved for a more specialized relationship
    between quantity kinds in the context of a system of quantities. To align with this
    terminology and avoid any misleading implications of the current name, this
    resolution makes a single name change from the SysML 1.1 Dimension
    stereotype to QuantityKind and relaxes the restrictive constraints on Dimension
    that no longer apply to the QuantityKind concept.
    In addition to issue 12219, this resolution addresses two issues previously
    deferred in SysML 1.1:
    Issue 11600, “SysML dimensions,” pointed out inconsistencies in Unit,
    Dimension, and ValueType constraints and statements. The relaxation of
    constraints on Dimension (now renamed QuantityKind), Unit, and ValueType,
    and related changes to the text included in the resolution for this issue should
    resolve those inconsistencies. The resolution for Issue 11600 is therefore being
    merged into the resolution for this issue.
    Issue 12128, “8.3.2.9 Unit, 8.3.2.10 ValueType,” proposed a new metamodel
    based on a class hierarchy for Unit and ValueType to express “the underlying
    physical and mathematical principles of a dimensioned quantity represented by a
    value subject to chosen units.” Since the resolution for this issue includes an
    overall roadmap for the same goals and includes changes to Unit, ValueType,
    and QuantityKind with optional support for defining systems of units and
    quantities, the resolution of this issue encompasses a resolution for Issue 12128
    as well. Although the present resolution does not adopt the solution proposed in Issue 12128, the scope of issue 12219 subsumes that of 12128 and provides
    multiple ways to support the key concepts requested in 12128, as part of
    incremental and compatible changes for SysML 1.x.

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

08. Blocks: The 'values' compartment for a part Property in an IBD

  • Legacy Issue Number: 12363
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    There should be a definition of the role of the 'values' compartment for display of "current values" (for representing the entire value state of a system within a unique value context) and/or "deep configuration" values indepedendent of the PropertySpecificType concept, which may be seen as only one possible way of carrying values for assignment to the 'values' compartment in and IBD. Another strategy employing values in Slots of InstanceSpecifications that are related to targeted part Properties by a Property[*] path and then mapped to the targeted part Properties would achieve the same 'values' idiom in and IBD without indication of the implied subtype using [brackets]. When the 'values' are carried by redefined defaultValue : ValueSpecification[0.1] of redefined properties of an implied [PropertySpecificType] the bracket notation should still be used (inviting also indication of other redefinitions that can't be achieved using mapping of InstanceSpecifications, such as operation and constraint redefinitions). In particular, the following paragraph from p.53 (illustrated in Figure 8.11 - SUV EPA Fuel Economy Test) should be rewritten to admit other solutions: "In SysML, one approach is to capture system configurations by creating a context for a configuration in the form of a context block. The context block may capture a unique identity for the configuration, and utilizes parts and part-specific types to express property design values within the specification of a particular system configuration. Such a context block may contain a set of parts that represent the block instances in this system configuration, each containing specific values for each property. This technique also provides for configurations that reflect hierarchical system structures, where nested parts or other properties are assigned design values using property-specific types. The following example illustrates the approach.": While Figure 8.11 - SUV EPA Fuel Economy Test could remain with [PropertySpecificType] notation as an indication of that strategy, there should be an equivalent figure showing the same 'values' compartment and a similar top-level value context block, however without the [brackets] notation on part types, and without any reference to the PropertySpecificType solution. The title of Figure 8.11 should be clearly marked to indicated use of the PropertySpecificType solution and notation. Visit also: http://school.nomagic.com/node/331

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

    No Data Available

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

08.Blocks: compartment for property-specific defaultValue should be renamed

  • Legacy Issue Number: 12361
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    As discussed at the OMG TM SysML RTF on Th 13Mar2008. The 'defaultValue' compartment should be renamed 'initialValue' (or perhaps 'initialValues'). The static (class level) default values of a given Block's properties may be overridden on instantiation and initialization of a part Property usage of that Block by the using context. The concept of "initial values" is more consistent with the programmatic practice, and it serves to highlight the difference between the UML2 defaultValue (of a Property within a class) and the (re)initialisation of a SysML value Property on usage of its Block as a part Property within a higher context, by assignment of a property-specific initial value. The label 'initial values' is also consistent with the UML2.1.1 specification description of the role of the defaultValue attribute of 7.2.44 Property: "If there is a default specified for a property, this default is evaluated when an instance of the property is created in the absence of a specific setting for the property or a constraint in the model that requires the property to have a specific value. The evaluated default then becomes the initial value (or values) of the property." Further, the concept of "initial values" emphasises the evolving value state of a system. The "initial value" is then merely a single value slice within a series of values states. Configuration is a special case of "initial value". Example: when a Car leaves a factory it is "initialised" to a luxury, sports, or family configuration. The concept of "initial value" compartment is complemented by the suggestion of a "current values" or simply "values" compartment for recording the value state of an evolving system. (See related issues submitted by Darren Kelly.) This suggestion promotes support of animation of SysML systems, and also encompasses aspects of static configuration consistently.

  • Reported: SysML 1.0 — Mon, 31 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

08.Blocks, 8.2.2 Internal Block Diagram:

  • Legacy Issue Number: 12353
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    As discussed at the OMG TM SysML RTF on Th 13Mar2008. Assumes the property-specific 'defaultValue' compartment has been renamed to 'initialValue' (or perhaps 'initialValues'), as suggested in a previous issue submission. The case of a property-specific 'initialValues" compartment (as in Table 8.3 - Graphical nodes defined in Internal Block diagram) and also deeply nested "initial values" is well complemented by a "values" or "currentValues" compartment, as illustrated for the test results in Figure 8.11 - SUV EPA Fuel Economy Test. Together, the "initialValues" and "values" compartments illustrate usefully the evolution of the value state of a system used within an additional top-level "value slice" context. Tool vendors would be free to show one, both, or none of these two complementary compartment in part Properties of an IBD. This strategy promotes progress towards animation of systems, and also enables comparison of special configurations with an "initial" configuration/state. This suggestion represents a useful unification of concepts already present in the SysML specification.

  • Reported: SysML 1.0 — Fri, 21 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue was raised prior to the SysML 1.1 adoption of the "initialValues"
    compartment on properties on an ibd to specify context-specific initial property
    values, and the SysML 1.2 adoption of UML instance specifications to specify
    current or sample property values of specific block instances. Full support of
    UML instance specifications was chosen by SysML 1.2 to support more complete
    specification of instances, including links between instances, than a
    "currentValues" compartment could directly support. The suggested capability
    would be redundant with the capability already adopted by SysML 1.1 and
    SysML 1.2.
    Disposition: Closed, no change

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

SysML needs instance specs

  • Legacy Issue Number: 12277
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML needs instance specs capabilities for several reasons

    1) compatibility with UML and many users' expectations
    2) ability to do animation
    3) ability to show particular values at a time
    4) educational value / illustration value

    No need for a new diagram type, instances can appear on block and sequence diagrams.

  • Reported: SysML 1.0 — Thu, 13 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No practical substitute has been found for the use of instance specifications to
    specify examples, test cases, and other occurrences of blocks defined in SysML
    user models. Because SysML tool implementations are based on UML
    implementations, diagram support for instance specifications can be simply a
    matter of relaxing any constraints that would disable access to these elements
    from within a strict SysML subset. Instance specifications are already included in
    the SysML metamodel to support other elements of SysML such as the Unit
    stereotype and the initial values compartment.
    Because SysML already defines a taxonomy of its standard diagram types
    (summarized in Annex A and defined in the specification chapters), use of
    instance specifications in SysML must be identify a diagram context where they
    could appear. While they might appear in more than one diagram context, the
    simplest approach for uniformity in user models is to rely on a single context
    where they could be shown. Instead of defining an entirely new diagram context,
    the block definition diagram is a natural place to show either the definitions of
    blocks or instances specifications of these blocks, or any mixture of both. Since all the required metamodel elements for instance specifications are already
    present in SysML, the inclusion of their existing UML-based notation can be
    specified merely by including their diagram elements in the table of graphical
    elements which can be shown on block definition diagrams

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

Section: annex A.1, Activities

  • Legacy Issue Number: 12253
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Designating a Diagram Frame with a the name of a Stereotyped Model Element Type: Annex A (Diagrams) is not explicit on how to designate a diagram frame with a model element type that has a stereotype applied. If, for example, a diagram is intended to represent a package which has been stereotyped as a model library, one would expect the diagram header to reflect the model library as the designated model element type. The naming of diagram header is defined beginning on pg 173 in Annex A.1, and does not clarify this. The proposed resolution is to allow the name of the stereotype or the name of the base class to be used as the name of the model element type in the diagram header. For the previous example, the name of the model element type could either be [package] or [model library].

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

    Update text per below to allow a stereotype name to appear in the diagram header as the name of the model element type. Also, ensure consistency with this notation throughout the spec. The control operator in the activities chapter needs to be modified in table 11.1 and in the usage example in Figure 11.2.

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

Section: Chapter 7: Viewpoint

  • Legacy Issue Number: 12239
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The viewpoint should use a Behavior element to describe the construction of the view instead of methods and languages. Concrete behaviors could be SysML elements like Activity or Interaction. Or construction rules specified in any language using a OpaqueBehavior element

  • Reported: SysML 1.0 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 9.3.2

  • Legacy Issue Number: 12156
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    NAME - JUNCTION PORT Limited ability to model certain typs of physical interfaces in SysML such as mechanical, electrical, optical, and thermal, where the interface does not explicitly represent a flow or a service. An example is the mechanical interface between two parts at their mating surface. An approach was included in a recent paper called "Modeling Continuous System Dynamics in SysML" by Thomas Johnson, Jonathan Jobe, Christiaan Paredis, Roger Burkhart, Proceedings of the IMECE 2007, Nov ' 2007, which is available on the omg sysml website. A stereotype for a junction is introducted to model a mechanical interface (Flange in Fig 4). This concept can be applied more generally to model a mechanical interface. The proposal is to stereotype a port as a <<junction port>> that is typed by a Junction, which would also be a stereotype. The junction would have properties such as a position, and force, and include constraints on its properties such as conservation of mass flow, energy flow, etc. Several subclasses of junction can be defined for mechanical, electrical, thermal, optical, other electromagnetic interfaces, each of which may have different constraints applied. The concstraints can be used in parametrics.

  • Reported: SysML 1.0 — Thu, 3 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11628 for resolution

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

Annex B, Figure B.18, Figure B.19

  • Legacy Issue Number: 12155
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    The composing owner of FrontWheel is never made clear It is clear from Figure B.18 - Defining Structure of Power Subsystem (Block Definition Diagram) and Figure B.19 - Internal Structure of the Power Subsystem (Internal Block Diagram) that ChassisSubsystem.FrontWheel is shared by PowerSubsystem, and that FrontWheel is a specialisation of WheelHubAssembly.. However nowhere is it made clear which block is the composing owner of FrontWheel (although we may guess that it is ChassisSubsystem). The polymorphic substitution of FrontWheel for WheelHubAssembly is never explained.

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

    Discussion:
    Polymorphic substitution is not implied, and elaboration of composing ownership
    of frontWheel would add unnecessary complexity to the example without specific
    benefit.
    Disposition: Closed, no change

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

Annex B / B.4.8.3 Activity Diagram

  • Key: SYSML11-98
  • Legacy Issue Number: 12143
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    B.4.8.3 Activity Diagram (EFFBD): refers incorrectly to objectFlows in BDD Figure B.34 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' In fact Figure B.34 is a BDD, so it can't show 'objectFlows'. It shows the Blocks that type the ObjectFlows.

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

    No Data Available

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

Annex B / B.4.5.4 Block Definition Diagram

  • Key: SYSML11-97
  • Legacy Issue Number: 12142
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    B.4.5.4 Block Definition Diagram: Should say 'white diamond (shared AggregationKind)' not 'white diamond (composition)' SysML1.0: 'B.4.5.4 Block Definition Diagram - Power Subsystem .. Note how the of white diamond (composition) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.' The choice of the word 'composition' in combination with the white diamond is unfortunate, as it implies 'composite' AggregationKind. Rewrite to say 'white diamond (shared AggregationKind)' rather than 'white diamond (composition)': 'Note how the of white diamond (shared AggregationKind) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.'

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

    No Data Available

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

Annex / Figure B.37

  • Legacy Issue Number: 12153
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B.37: the elements allocated from are of type Action, not Activity In table Figure B.37 allocations are made from the following Actions (activity usages): a1:ProportionPower a2:ProvideGasPower a3:ControlElectricPower a4:ProvideElectricPower The 1st column shows them incorrectly as of type Activity. NB: this issue relates to and/or duplicates: Issue 11497: Mixed action and activity concepts (sysml-rtf)

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B36

  • Legacy Issue Number: 12151
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B36: ice:InternalCombustionEngine should be allocated from ProvideGasPower, not ConvertGasToPower Figure B36 shows 'ice:InternalCombustionEngine' allocated from '<<activity>> ConvertGasToPower'. Figure B35 shows Action 'a2:ProvideGasPower' allocated to '<<block>> InternalCombustionEngine'. The table in Figure B37 shows Action 'a2:ProvideGasPower' (incorrectly typed as an Activity) allocated to '<<block>> InternalCombustionEngine'. For consistency Figure B36 should show 'ice:InternalCombustionEngine' allocated from Action 'a2:ProvideGasPower'.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B.36

  • Legacy Issue Number: 12150
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B36: ecu:PowerControlUnit should be allocated from ProportionPower, not ProportionPowerLoad Figure B36 shows 'ecu:PowerControlUnit' allocated from '<<activity>> ProportionPowerLoad'. Figure B.35 shows Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'. Figure B.37 table shows 'a1:ProportionPower ' allocated to part Property 'ecu:PowerControlUnit'. For consistency Figure B.36 should show Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B36

  • Legacy Issue Number: 12149
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B.36: shows allocations to part Properties, not to Blocks as in Figure B.35 Figure B.35 shows allocations of actions to swimlanes representing blocks. Figure B.36 shows allocations of activities to part properties. Figure B.35 should probably shows allocations of actions to part properties. Figure B.36 should probably show the same allocations of actions to part properties.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B.36

  • Key: SYSML11-99
  • Legacy Issue Number: 12148
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B.36 emg:ElectricalMotorGenerator should be allocated from a4:ProvideElectricPower not ConvertElectricToPower Figure B.36 shows 'emg:ElectricalMotorGenerator' allocated from <<activity>> ConvertElectricToPower Figure B.35 shows Action 'a4:ProvideElectricPower' allocated to '<<block>> ElectricalMotorGenerator'. The table in Figure B.37 shows 'a4:ProvideElectricPower' (incorrectly typed as an Activity) allocated to '<<block>> ElectricalMotorGenerator'. For consistency Figure B.36 should show 'emg:ElectricalMotorGenerator' allocated from Action 'a4:ProvideElectricPower'.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11497 for disposition

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

NestedConnectorEnd multiplicity typo in Fig 8.5

  • Legacy Issue Number: 12377
  • Status: closed  
  • Source: Georgia Institute of Technology ( Dr. Russell Peak)
  • Summary:

    There appears to be a typographical error in Fig 8.5 re: the multiplicity of a NestedConnectorEnd propertyPath. This figure says [2..*], whereas Section 8.3.2.6 says [1..*]. === Specifics: In the SysML 1.0 document (formal/2007-09-01), Fig 8.5 entitled "Abstract syntax extensions for SysML connector ends" shows this for NestedConnectorEnd: - propertyPath: Property [2..*] (ordered) However, Section 8.3.2.6 NestedConnectorEnd has a different multiplicity: - propertyPath: Property [1..*] (ordered) Section 8.3.2.6 seems to be the correct version, as it provides further explanation including stating "The connector end property is not included in the propertyPath list, but instead is held by the role property of the UML ConnectorEnd metaclass.", which is consistent with a multiplicity of [1..*]. The severity of this issue is deemed "Significant" because tool implementations that follow the figure versus ones that follow the section text (which has already occurred) will be incompatible. === Proposed Resolution: Change the multiplicity in Fig 8.5 from [2..*] to [1..*].

  • Reported: SysML 1.0 — Thu, 10 Apr 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Correct the multiplicity in Fig 8.5.

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

p.46 under 8.3.2.4 DistributedProperty

  • Legacy Issue Number: 12365
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    On p.46 under 8.3.2.4 DistributedProperty it is stated that: '[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.' There are however, as far as I can tell, no examples of a DistributedProperty or specialisation thereof applied to a value property that is not within a block. A candidate examp[le might include a variation on a Complex <<ValueType>> (cf. Figure 8.7 - Model Library for Blocks) with distributions applied to the real and imaginary parts (being represented by value properties, and thus admitting application of DistributedProperty stereotype, or substereotype).

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

    Following is the discussion from a previous deferred resolution by the SysML 1.1
    RTF:
    There are many specialized cases of SysML diagram and model elements
    which are not currently covered either by usage examples in the
    specification chapters or in Annex B, Sample Problem. A candidate
    example as suggested, either by itself or included in other examples,
    could be considered in future revisions of the specification.
    This is one of many specialized usage cases not covered by examples in the
    SysML specification. Examples of DistributedProperty stereotypes applied to
    elements of a structured ValueType raise no inherent difficulties of notation or
    usage, and so do not cross a threshold of priority to be included in the
    specification itself. Such examples would be entirely appropriate to include in
    tutorial materials about the SysML language.
    Disposition: Closed, no change

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

DistributedProperty

  • Legacy Issue Number: 12364
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    On p.46 under 8.3.2.4 DistributedProperty it is stated that: '[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.' It does not however state whether a DistributedProperty [Property] may only be applied to a value property (a "block property" typed by a ValueType or DataType) or other Property variations. All examples of the application of DistributedProperty show it applied to a value property. This has implications for sorting into block compartments in BDDs; if a DistributedProperty [Property] may only be applied to a value property then it will always be sorted into the 'values' compartment. It also has implications for aggregation; since a value property must have AggregationKind 'composite', a DistributedProperty will also have AggregationKind 'composite'.

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

    As the issue states, examples of DistributedProperty are shown only for ValueType. Since all details of a probability distribution are left to a user-defined subtype of the DistributedProperty stereotype, however, such a stereotype could be applied to a stereotype typed by a block, such as a part or reference property. Such a stereotype could be defined, for example, to express probabilities of different cases of the block instances referenced by the property. For example, a distribution on the expected number of occurrences could be specified for a property with multiplicity greather than one.
    By not restricting the kind of property to which the DistributedProperty may be applied, the current text does not limit its application. A statement limiting it to a value property would contradict the lack of restriction intended by the current stereotype. The constraint does not refer to the type of the property itself but to the Block or ValueType which must own the property.
    The issue further states the implications that properties with a DistributedProperty stereotype could appear in different compartments or could have different values of AggregationKind. All these implications flow naturally from the lack of any restriction on the kind of property to which the stereotype can be applied.
    The Blocks chapter currently lacks any reference to Annex C.5, Distribution Extensions. Section 8.3.2.4 is the natural place in the Blocks chapter where such a reference could be added. This reference can also indicate that the annex defines distributions only on value properties, without suggesting that DistributedProperty stereotypes are necessarily limited to value properties. Such usage is currently the main expected use of DistributedProperty, but there is no need to restrict it from other possible uses. Moreover, it relies only on standard stereotype extension mechanisms, with no custom notation, so all its implications are those which flow naturally from an independent stereotype.

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

SysML unnecessarily restricts aggregation of datatypes

  • Legacy Issue Number: 12270
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The 6th constraint on blocks is written as follows:

    [6] If the aggregation attribute of a property owned by a SysML block is equal to “composite” or “shared,” then the type of the property must be a block

    This constraint, as written, limits the use of solid or hollow diamond aggregation relationships from a block to "own" only other blocks.

    1) This is not what the original intent was. Apparently it was to prevent the use of aggregation relationships from a block to own dataTypes or valueTypes.
    As written, it is overly restrictive for its intent

    2) Even the intent is overly restrictive. UML modelers have (for years) modeled the relationship between a class and its attributes as an aggregation relationship.True, software developers have occasionally used the distinction between composite/shared as implementation clues which are unimportant to SysML concerns. However, even though the SysML distinction between an association, aggregation, or composition relationship to a property is irrelevant, the variation of notation allows modelers to use the style they are most familiar with. In addition, for models that move from SysML to UML and back, it allows the preservation of the software hints. It also leverages existing training and educational material on models.

    I recommend dropping this constraint completely. At the most, add a sentence in the description section explaining that using the composite/shared relationship to properties has no implementation meaning.

  • Reported: SysML 1.0 — Mon, 10 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: More constraints for flow ports

  • Legacy Issue Number: 12269
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The flow port and the flow specification need more constraints and clarification statements. What does it mean to type a flow port with a block that realizes many flow specifications? What does it mean to type a port with block that realizes many interfaces including some flow specifications? Is it allowed that a flow specification is part of a realization relationship? How to define a complex flow port that uses more than one flow specification?

  • Reported: SysML 1.0 — Mon, 10 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Any property (including flow ports) that are typed by a classifier that realizes
    multiple interfaces (including flow specifications) means the value will support the
    features of all the interfaces. This is UML semantics that is not necessary to
    restate in SysML. Flow specifications are based on interfaces, and participate in
    realization relationships like any other interface. A classifier can realize multiple
    interfaces, including flow specifications. This is UML syntax that is not necessary
    to restate in SysML.
    Disposition: Closed, no change

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

Section: 8.3.2.1

  • Legacy Issue Number: 12268
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    1) The definition of Constraint [5] for Block in section 8.3.2.2 is defined as "The following constraint under section [...] in the UML Superstructure Specification is removed by SysML: [...]". 2) The UML 2.1.2 Superstructure Specification states in section 18.1.2 under 'Extensibility': "It is not possible to take away any of the constraints that apply to a metamodel such as UML using a profile, [...]". 3) In Section 6 of the SysML-Specification, it is stated that "The SysML specification is defined by using UML 2 specification techniques. These techniques are used to achieve the following goals in the specification. Correctness [...] The specification technique used in this specification describes SysML as a UML extension that is defined using stereotypes and model libraries." The points 1), 2) and 3) together are a contradiction.

  • Reported: SysML 1.0 — Mon, 10 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The referenced text from the introductory section of Chapter 6 is incorrect.
    SysML is defined using not only stereotypes and model libraries, but additional
    techniques including diagram extensions as well as the removal of a specific
    existing UML constraint, as noted by the issue. The initial statement that "The
    SysML specification is defined by using UML 2 specification techniques" is
    incorrect since some of these extension techniques are not provided by UML 2.
    The second statement that "These techniques are used to achieve the following
    goals in the specification" is incorrect since the specification techniques used are
    not sufficient to achieve the listed goals. Remove this introductory section entirely
    to avoid misleading statements and to eliminate the contradition noted by the
    issue.

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

Icons for FlowPort

  • Legacy Issue Number: 12256
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I would suggest changing the icons you have chosen for FlowPort. Hence, in the following picture extracted from the spec., ac and dc are understood respectively as input and output flow port.

    But, if I move dc on left hand side of the rectangle denoted Transformer, ac on the right, dc becomes an input and ac becomes an output. I suggest you to adopt the ones defined within MARTE (see following picture).

  • Reported: SysML 1.0 — Mon, 3 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Chapter 2: UML version

  • Legacy Issue Number: 12254
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    OMG SysML 1.0 is an extension of UML 2.1.1. The next version OMG SysML 1.1 should be an extension of UML 2.2 to avoid a gap between these two closely related standards. According to UML 2.2 SysML should support OMG XMI 2.2 instead of XMI 2.1.

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

    Since the RTF of the UML 2.2 has not finished its work, it is too early to define OMG SysML as an extension of UML 2.2. It is not possible to analyse the impact.
    However, there is a minor mistake in the UML4SysML definition. UML4SysML imports the UML StandardProfileL1 which doesn't exist in UML. It should be the StandardProfileL2.

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

moe should be removed from section 7.4 or added to the standard

  • Legacy Issue Number: 12258
  • Status: closed  
  • Source: Northrop Grumman ( Darin Supel)
  • Summary:

    Section 7.4, part of the standard, utilizes the <<moe>> stereotype. <<moe>> is not part of the standard. Annex C, where <<moe>> is defined, states "This annex describes useful non-normative extensions to SysML that may be considered for standardization in future versions of the language." The standard should not be infected with non-standardized stereotypes. <<moe>> should be removed from section 7.4 or added to the standard.

  • Reported: SysML 1.0 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

remove homemade stereotypes

  • Legacy Issue Number: 12257
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Darin J. Supel)
  • Summary:

    Don't the authors find it embarrassing that their solution to a sample problem isn't even compliant with their own specification? In section B.4.2.1, its states "The «system» and «external» stereotypes are user defined, not specified in SysML,...". I don't care what excuse the authors come up with, "user defined" stereotypes should not be used. The concept of "user defined" or just "making up" stereotypes is inconsistent with the concept of profiles. By standard, «system» and «external» must be in a profile since they are not standard UML keywords nor stereotypes. The authors need to remove homemade stereotypes from their example or add them to the profile. The removal of the homemade stereotypes will likely prove the current specification inadequate.

  • Reported: SysML 1.0 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

08 Blocks, 8.3.2.9 Unit, 8.3.2.10 ValueType

  • Key: SYSML11-84
  • Legacy Issue Number: 12128
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute This strategy provides a compact and elegant metamodel for units and values, and expresses well the underlying physical and mathematical principles of a dimensioned quantity represented by a value subject to chosen units. Value properties can then be sensibly typed by either a Unit or a ValueType. In the case where a ValueType has a Unit, the constraint still applies that the dimension of the ValueType must be the same as the dimension of the Unit. See also analysis image and commentary at: http://school.nomagicasia.com/node/126

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 12219 for disposition

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

8.3.1.2 Internal Block Diagram

  • Key: SYSML11-83
  • Legacy Issue Number: 12127
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    .3.1.2 Internal Block Diagram: p.40: assert that value properties must be owned with AggregationKind 'composite' This would be consistent with the following from 8.3.1.2 Internal Block Diagram, Property types: ".. A part or value property is always shown on an internal block diagram with a solid-outline box. A reference property is shown by a dashed-outline box, consistent with UML .." Rewrite to include assertion that value properties must always be owned with AggregationKind 'composite': ".. A part or value property has AggregationKind 'composite' and is always shown on an internal block diagram with a solid-outline box. A reference property has AggregationKind 'none' or 'shared' and is shown by a dashed-outline box, consistent with UML .." (Please note also that this case also illustrates why it would be useful to have a clear stereotypes like ValueProperty throughout the SysML specification, as it affords a canonical point of documentation for such assertions and constraints.)

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

    No Data Available

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

Requirements are abstract

  • Key: SYSML11-48
  • Legacy Issue Number: 11490
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Requirements are abstract (isAbstract must be true). However name of the requirement are not displayed in italic as defined in UML notation

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    (This discussion is elaborated from RTF Telecon Minutes 2008-02-13 &
    2008-02-13)
    This issue asks that the name of a requirement be in italics, in keeping with the rules on UML classes when isAbstract is True. This raises the following questions:
    1. Do requirements need to be abstract? In order to answer this, we need to address the following.
    2. Do requirements need subclasses? SysML does not currently support any form of subclassing of requirements.
    3. How robustly do requirements need to support properties? Are static properties necessary?
    One philosophy considers that if requirements had any features such as properties, they could be only static features that applied to the entire requirement class and not to any instance, which was part of the rationale for the isAbstract = True constraint.
    If static properties were supported on SysML requirements, along with adding specialization (subclassing) relationships between requirements, they could support a more complete form of property-based requirements in addition to their current support for text-based requirements. This would more closely parallel the requirements capability in STEP AP233, which has support for both text- and property-based requirements. It would also allow performance requirements to be stated by defined property values that could participate in parametrics or other analysis.
    In the original submission, however, the SysML model of requirements has been left deliberately simple without further detail for modeling the system itself, in part so SysML would more closely match the scope and structure of typical requirements specifications which have simple containment models of text-based statements. Associating properties with requirements relied on linking requirements to highly abstract models of system structure, built using SysML blocks, and providing a skeleton model of system structure to which properties would belong. This is appropriate because the properties are typically of the system, rather than of the requirement, e.g. "the car shall weigh less than 3000lb" implies that weight is a property of the car. This approach also provides a more extensive means to capture properties and other details of an evolving system very early in its specification process. This option remains available in SysML to model greater detail about requirements that need to go to a greater level of detail or precision.
    This remains a clear and consistent approach to SysML requirements, and should not be reconsidered at this time. The decision of this resolution is not to add any additional support for requirements subclassing or properties in this revision of SysML. Separate issues could be raised for future revisions of SysML to consider adding requirements subclassing or properties, but such an addition is outside the scope of this issue, which seeks only to make the font of requirement names consistent with the isAbstract attribute.
    Given the lack of subclassing for SysML requirements, the constraint on isAbstract has no added semantics and could be constrained either way. The main issue at this point is simply whether the names of requirements should be in italics or not. Forcing the names into italics, to be consistent with the current constraint, would change the notation defined by the current specification and used in all the current requirements examples. Removing the current constraint will allow tools to keep the name consistent with the setting of the isAbstract attribute. The same resolution should apply to Viewpoint in Chapter 7, which has the same constraint on the isAbstract attribute.

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

Question on PropertySpecificType

  • Key: SYSML11-47
  • Legacy Issue Number: 11308
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Can anybody elaborate on the following definition of PropertySpecificType : “The PropertySpecificType stereotype is automatically applied to a classifier created by the notation for a property-specific type for a property belonging to a SysML Block or ValueType. It identifies these classifiers so that they may be managed along with the property that they type.”

    It is quite obscure to me to understand its meaning?

  • Reported: SysML 1.0 — Tue, 28 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Association branching is not defined in UML

  • Key: SYSML11-51
  • Legacy Issue Number: 11494
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Association branching is not defined in UML. Mapping is not clear. Composition tree is not defined in UML, mapping is not clear.

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Uppercase/lowercase problems

  • Key: SYSML11-50
  • Legacy Issue Number: 11492
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Uppercase/lowercase problems. Stereotype names are defined in upper case, but in diagrams are displayed in lower case (e.g. Block and <<block>>). Attributes(tags) are displayed in uppercase in diagrams, but are defined in lower case in the specification.

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Annex A: Diagrams

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

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

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

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

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

Section: 16 Requirements

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

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

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

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

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

Section: 8.3.2 Unit/Dimension Notation

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

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

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

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

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

Mixed action and activity concepts

  • Key: SYSML11-53
  • Legacy Issue Number: 11497
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Mixed action and activity concepts. B.35, B.36, B.37 - concepts of activity and action are mixed (action is allocated, but activity is in tabular notation)

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Update referenced figures to represent allocation of usage (Action to Part).
    Update figure B.35 to use colon notation for the part represented by the
    AllocateActivityPartitions. Note that this proposal also resolves issues #12148,
    12149, 12150, 12151 and 12153

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

Constraint parameter notation conflicts with UML private ports notation

  • Key: SYSML11-52
  • Legacy Issue Number: 11495
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Constraint parameter notation conflicts with UML private ports notation. How to distinguish between part and ports if notation is the same?

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue is being deferred because no proposed resolution was voted on during
    the schedule of the SysML 1.3 RTF.
    Disposition: Deferred The private port notation, in which a port located inside a containing rectangle had
    more restricted visibility than ports placed on the boundary of the rectangle, was
    included in UML 2.0 but removed in subsequent UML revisions. SysML specifies that
    all ports be placed on the rectangle boundary.
    SysML specifies its own specific notation for constraint properties and their constraint
    parameters within a parametric diagram, in which the constraint parameter must be
    shown flush inside the boundary of a constraint property.
    The constraint property also has its own specific notation as a round-cornered
    rectangle. No conflict with any UML notation is present within this specific diagram
    context.
    Disposition: Closed, no change

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

Section: 8.3.2.8 ValueType

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

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

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

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

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

Section: 16 Requirements

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

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

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

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

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

<> is displayed as dependency (in examples)

  • Key: SYSML11-49
  • Legacy Issue Number: 11491
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    <<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used)

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Discussion:
    A resolution for this issue was never completed during the SysML 1.1 RTF, but
    the issue raised was resolved by Issue 11269 in SysML 1.1. Issue 11269 had
    the identical title, «satisfy» is displayed as dependency, and had the following
    description:
    It is not explicitly mentioned that SysML changes the notation for the
    satisfy relationship. It is a stereotyped realization relationship and should
    be notated as a dashed line with a triangular arrowhead. But SysML uses
    a simple arrowhead.
    The change made by resolution of 11269 was to change «satisfy» to be a
    stereotype of Trace rather than Realization (the same as the DeriveReqt, Verify,
    and Copy dependencies), which resolved the discrepancy in the notation.
    This issue should have been resolved by the SysML 1.1 RTF as
    Duplicate/merged with Issue 11269. To correct the oversight, this resolution will
    close the issue as part of the SysML 1.2 RTF.
    Disposition: See issue 11269 (in the SysML 1.1 RTF Report) for
    disposition

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

View as Package extension is very bad idea

  • Key: SYSML11-55
  • Legacy Issue Number: 11500
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    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, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 11.3.1.1

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

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

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

    No Data Available

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

Section: 8/3

  • Key: SYSML11-63
  • Legacy Issue Number: 11622
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Mapping of PropertySpecificType to the UML metamodel requires further explanation Chapter 8 introduces the notion of property-specific type to assign values to parts inside an ibd. Section 8.3.1.1 defines a notation for property-specific types. Section 8.3.2.8 provides a definition of the <<propertySpecificType>> stereotype and gives elements on how this concept maps to the UML metamodel. However, this section does not explicitly define: 1) where are stored the actual values? One may understand that a default value of a property owned by a class, which is stereotyped as <<propertySpecificType>>, is considered as a property-specific value. This property-specific value may be considered as an instance of a property owned by the refrenced block. It is not clearly stated though. 2) how does a property-specific type relate to the referenced block ? In other words, if a class is stereotyped as <<propertySpecificType>>, which feature of this class points to the referenced block? We may need to add a paragraph in section 8.3.2.8 that provides answers to questions.

  • Reported: SysML 1.0 — Thu, 18 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    A property-specific type defines a new specialization of a single existing classifier, which was used to type a single property in the definition of a block which owns that property. The PropertySpecificType stereotype is used in the SysML metamodel to distinguish a classifier created by this mechanism from classifiers created by all other forms of user definitions.
    Within the property-specific type, new or redefined properties or other features such as operations may be defined. Within a property defined within a property-specific type, one option is to specify a default value. As the resolutions for issues 10473 and 11502 indicate, however, an initialValues compartment may be used instead of a property-specific type if all that is needed are context-specific values and not a more customized definition of the classifier that types a property.
    If the property-specific type is used to define a feature that carries its own default value, that default value is specific to that property. The default value of a property owned by a classifier carries its value by means of a UML ValueSpecification. It is not considered as an instance of the property, and the classifier provides only the definitions of its properties and not any instance to be referenced.
    The suggestion to add a paragraph to Section 8.3.2.8 to better explain the PropertySpecificType stereotype is valid, and Issue 11308 also requested somewhat less obscure explanation of the meaning of this stereotype. A full explanation of the representation of the metamodel representation of a property-specific type would benefit from examples of metaclass instances that could be represent specific example models, but the SysML specification does not currently include such metamodel instance examples. The revised text below is intended as an initial start toward a somewhat less opaque explanation, but falls short of full metamodel examples or other forms of explanations which could still be considered for future revisions of the spec.

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

SysML specification for containment relationship

  • Key: SYSML11-62
  • Legacy Issue Number: 11612
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    this about the interpretation of the the containment
    relationship and its
    implementation on the tool side.

    We are using MagicDraw 14.0 and SysML 1.1sp2.

    As soon as a containment relationship is created between two
    requirements the
    contained requirement is automatically relocated to the package
    of the container. This prevents distribution of requirements
    in different
    packages, in particular if a contained requirement belongs to
    a subsystem.
    I would like to properly distribute them.

    We have a requirement A which contains requirement B and C.
    A is a requirement on very high level of the system which is decomposed into
    requirements B and C on a subsystem level.
    To avoid to have all requirements together (because B and C
    belong to the
    subsystems) we want to put A, B and C in different packages
    but still have
    the containment relationship (as foreseen by the SysML spec.)
    that's why I think it is different from a package containment. They
    are not the same.

  • Reported: SysML 1.0 — Mon, 15 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

SysML dimensions

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

    Inconsistency among valuetype/unit/dimension

    In Figure 8.4 p 43, the following multiplicities are given

    A valutype may (0..1) have a unit and may have a (0..1) dimension

    A unit may (0..1) have a dimension.

    On page 49. there is a constraint

    Constraints

    [1]If a value is present for the unit attribute, the dimension attribute must be equal to the dimension property of the referenced unit.

    This would mean that if the unit’s dimension is null, then the valutype’s dimension must also be null. This seems overly constraining.

    In 8.4.2, it says

    Because a unit already identifies the type of quantity, or dimension, that the unit measures, a value type only needs to identify the unit to identify the dimension as well.

    This statement seems to say the unit must have a dimension, and the valuetype’s dimension can be null even though the unit’s is not. This statement therefore disagrees with the Figure 8.4 and the constraint on page 49

  • Reported: SysML 1.0 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Discussion:
    This issue is being deferred as part of the same overall discussion and
    consideration noted under the resolution for Issue 12128, “8.3.2.9 Unit, 8.3.2.10
    ValueType.” As noted there, the scope of any potential changes to the current
    ValueType, Unit, and Dimension metamodel has ended up beyond the workload
    that could be completed during this RTF. Relaxing the current constraints, as well
    as extensions or changes to the current model, should continue to be evaluated
    for future versions of SysML. In the meantime, a workaround could be to define
    new units if necessary to carry different dimensions. The statement in Section 8.4.2 is in a usage example for the definition of value
    types with SI units. It is not intended to imply that a unit must have a dimension,
    just that if a unit does already identify a dimension, the dimension need not also
    be specified. This language could be further clarified if needed in future updates
    of the specification.
    Disposition: See issue 12219 for disposition

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

SysML -- Fix for Fig 9.4 p70.

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

    On Fig 9.4 p 70. the I_ICEData I/F has the following services defined on the cntrl (the engine)

    getRPM():Integer

    getTemperature():Real

    isKnockSensor():Boolean

    These names make sense if the interface was a provided interface on the engine.

    However, the I_ICEData interface on the engine is a REQUIRED interface.

    The interface should be defined something more along the lines of…

    hereIsRPM(:Integer)

    hereIsTemperature(:Real)

    hereIsKnockSensor(:Boolean)

    as the engine is using this interface to tell the PowerControlUnit the current values of those properties.

    This problem is duplicated later in Figure B.20 on p 194

  • Reported: SysML 1.0 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

SysML:Ports can't be blocks

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

    Apparently from 9.3.2.3 while you can type a flowport by a block, that block indicates the things that flow over the port.

    A more intuitive interpretation would be that the flowport is a block. Most flowports appear to be physical things that may convey blocks.

    Without the ability to indicate the physical thing that is the block, you lose the ability to specify it, reuse it, define it, etc.

    It’s much more intuitive to indicate that the flowport is a

    US-110voltACmale

    In addition, for example, in Figure B.19. There are flowpoints named

    Port:FuelTankFitting

    Port:ICEFuelFitting

    Based on section 9.3.2.3, these flowports convey Fittings, not Fuel.

    There needs to be a way, preferably graphically, that would indicate that the type of Flowport is a block, and in that block, allow for the definitiaojn of what flows.

  • Reported: SysML 1.0 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Ports are properties, so cannot be blocks, but the resolution of issue 13178
    clarifies that some ports represent a new, potentially physical, element in the
    system (full ports). These can be typed by blocks that have flow properties as
    well as other kinds of properties, as suggested above. Some ports do not
    represent a new element in the system (proxy ports). Flow specifications and
    non-atomic flow ports are deprecated.as redundant.

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

Section: Appendix E

  • Key: SYSML11-65
  • Legacy Issue Number: 11626
  • Status: closed  
  • Source: ( Fred Waskiewicz)
  • Summary:

    The following text cites two OMG documents: "The OMG SysML requirements traceability matrix traces this specification to the original source requirements in the UML for Systems Engineering RFP (ad/2003-03-41). The traceability matrix is included by reference in a separate document (ptc/2007-03-09)." Someone unfamiliar with the OMG process has no way of knowing how to obtain these two documents. They should be cited by URL; e.g., http://doc.omg.org/ptc/2007-03-09

  • Reported: SysML 1.0 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Use URL references as suggested.

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

Wrong ends of Allocate relationship used in Allocated definition

  • Key: SYSML11-56
  • Legacy Issue Number: 11501
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Writer of this issue correctly points out an inconsistency between the text in section 15.3.1.1, 15.3.2.1, and 15.3.2.2, with respect to the client and supplier ends of the allocation relationship. Text will be modified to resolve this inconsistency.

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

Address potential points of convergence between MARTE and SysML

  • Key: SYSML11-64
  • Legacy Issue Number: 11623
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Address potential points of convergence between MARTE and SysML The MARTE profile supports modeling and analysis of real-time and embedded systems. Some of the concepts defined in this specification are applicable to Systems Engineering practices and can be of interest to SysML users. Early interactions between the SysML and MARTE partners have allowed to identify convergence points: - support for value expressions and constraint expressions using a dedicated language - formalisation of a time model, including the notion of clock to measure time - definition of metamodel elements for units and dimensions As discussion goes on, other convergence points may be identified and added to this list. Working on an alignment between MARTE and SysML has been identified as an important opportunity for both groups.

  • Reported: SysML 1.0 — Thu, 18 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Following is the discussion from a previous deferred resolution by the SysML 1.1
    RTF:
    Much useful interaction and review of material from both MARTE and
    SysML has occurred within the RTF, especially on topics such as
    definition of quantity types, models of time, the need for value
    specifications, and the need to align allocations. Some opportunities for
    alignment can continue to be addressed in resolutions to other, more
    specific issues. This more general issue, however, will also be deferred,
    so that many remaining opportunities for alignment can continue to be
    pursued. Some specific areas of possible alignment, such as support for
    expressions in the MARTE Value Specification Language (VSL), are
    premature until the MARTE specification has completed its finalization.
    Ongoing discussion and development of potential common elements is
    continuing to occur between the SysML and MARTE RTF's. This generic
    placeholder issue should now replaced by specific issues that address specific
    points of alignment between the two specifications.
    Disposition: Closed, no change

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

8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagram

  • Key: SYSML11-59
  • Legacy Issue Number: 11591
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    "An “X” on a single end of an association to indicate that an end is “not navigable” has similarly been dropped, as has the use of a small filled dot at the end of an association to indicate an owned end of an association."

    In this text I see two mistakes:

    1. "filled dot" notation is used for ends owned by associated classifier, not owned by association (an opposite situation).

    2. "owned end of an association" does not mean it is not navigable. Association has "navigableOwnedEnds" property for navigable owned ends.

  • Reported: SysML 1.0 — Tue, 2 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Correct the descriptions of the UML notations which SysML excludes.
    The statement about an "X" on the end of an association does seem consistent with this statement from the UML Superstructure spec, under 7.3.3 Association, "Notation" subsection:
    A small x on the end of an association indicates the end is not navigable.

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

optional parameter section

  • Key: SYSML11-58
  • Legacy Issue Number: 11523
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Is it allowed to attach the optional stereotype to outgoing parameters? The definition mentions only ingoing parameters: "This means the parameter is not required to have a value for the activity or any behavior to begin execution."

  • Reported: SysML 1.0 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Amend the cited sentence to indicate optional out parameters do not need to have values to end execution.

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

PropertySpecificType concept is highly ineffective and suboptimal

  • Key: SYSML11-57
  • Legacy Issue Number: 11502
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    PropertySpecificType concept is highly ineffective and suboptimal. It requires to redefine all structure from very root context if some deep nested part should use different configuration. So one should redefine all car internal structures if one bolt should be changed or color should be different

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 5.1

  • Key: SYSML11-67
  • Legacy Issue Number: 11629
  • Status: closed  
  • Source: ( Fred Waskiewicz)
  • Summary:

    Replace horrific long UML URL with short form: http://doc.omg.org/formal/2007-02-03

  • Reported: SysML 1.0 — Tue, 23 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Implement the requested form of URL reference.
    For consistency with references elsewhere in the spec, include the URL form of reference only in Chapter 2 Normative References, and refer to specifications only by name elsewhere in the spec

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

Section: 9.4

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

    The outline indenture for the Atomic Flow Ports (9.4.1.1) and non Atomic Flow Ports (9.4.1.2)usage examples is incorrect. They should be 9.4.2 and 9.4.3 respectively.

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

    Update indentures per above

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

SysML Interactions

  • Key: SYSML11-68
  • Legacy Issue Number: 11648
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the notation table for sequence diagrams there is no reference to interaction parameters, or to arguments of interaction uses.

  • Reported: SysML 1.0 — Thu, 15 Nov 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Supply identified missing notation in table 12.1.

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

SysML: Interfaces on Flow Ports

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

    Interfaces on Flow Ports

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

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

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

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

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

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

SysML: Use Cases

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

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

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

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

    Please clarify with this use at the SE level

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

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

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

Section: Requirements - Figure 16.1

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

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

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

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

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

Section: Ports and Flows - Behavioral flow ports

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

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

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

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

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

Section: Blocks - BOM properties

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

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

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

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

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

Section 16.3.1.1

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

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

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

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

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

constraints section 9.3.2.4

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

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

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

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

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

SysML:Architecture

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

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

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

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

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

SysML: << and >> vs < and >

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

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

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

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

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

Page 16

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

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

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

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

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

Section 16.4.2

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

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

    .

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

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

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

SysML: Missing arrow on figure 16.8

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

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

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

    Replace figure 16.8 with attached figure. Caption is unchanged

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

Section: Chapter 7-17

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

    Add clarification and precision to the specification by replacing the natural language constraints with OCL constraints. This is a general issue that applies to constraints on stereotypes within Chapters 7-17 of the specification. It is appropriate to address this on a priority basis to selected constraints that are ambigous due to their natural language representation, and where OCL can reduce their ambiguity.

  • Reported: SysML 1.0 — Wed, 6 Jun 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    In keeping with the request to “address this on a priority basis to selected
    constraints,” SysML 1.2 is beginning to include its first limited set of OCL
    constraints to supplement the current natural language statements of constraints.
    In addition to an OCL constraint included in the resoluton of Issue 12129 in
    Chapter 10 Constraint Blocks, this resoluton includes an OCL constraint for one
    more existing constraint.
    Since continuing to supply OCL versions of constraints will be an ongoing effort
    over multiple revisions of SysML, new versions of this issue should continue to
    be raised for consideration by future RTF’s. This issue number, however, is
    being resolved so that it can provide a place to provide the statement of a
    specific OCL constraint not included in any other issue resolution.

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

Namespace compartment for blocks

  • Key: SYSML11-39
  • Legacy Issue Number: 11066
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    We build the structure of a system on the block definition level by composition
    and not by namespace containment. We also use this approach in the sample problem.
    Therefore I would like to use a block compartment to show a bdd of all owned elements
    by composition and not by namespace containment. I don't know any good example where to
    use the namespace compartment or the namespace containment relationship.

    Should we change the namespace compartment to a owned element compartment?
    Do you know good examples when to namespace containment vs. composition?

    By the way the concrete syntax of the namespace containment in the sysml spec isn't
    defined in the uml specification

  • Reported: SysML 1.0 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Appendix B

  • Key: SYSML11-37
  • Legacy Issue Number: 10602
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

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

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

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

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

SysML doesn't explicitly support the modeling of alternative models

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

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

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

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

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

15.2.1Representing Allocation on Diagrams

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

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

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

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

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

7.1 Overview

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

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

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

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

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

Figure 17.4.2

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

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

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

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

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

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

Section: figure 17.6

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

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

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

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

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

Section: 17.4.2

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

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

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

    Disposition: See issue 10517 for disposition

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

Section: 11 Activities

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

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

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

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

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

Section: Annex A

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

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

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

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

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

Constraint parameter stereotype

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

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

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

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

    To quote again:

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

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

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

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

    No Data Available

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

Section 16.3.2.3

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

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

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

    Agreed. Propagation rule is unnecessary and should be deleted

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

Section: 11.3.2.2

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

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

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

    No Data Available

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

Chapter 8, Blocks, instance specifications for default values

  • Key: SYSML11-25
  • Legacy Issue Number: 10473
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

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

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

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

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

Section: 6.1 Levels of Formalism

  • Key: SYSML11-24
  • Legacy Issue Number: 10472
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

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

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

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

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

Section: 16.3.2.4 RequirementRelated (from Requirements)

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

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

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

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

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

Section: 9.3.2.8 ItemFlow

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

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

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

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

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

Semantic of default value in the scope of a DistributedProperty

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

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

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

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

    {min=0,max=2}

    p:Real=2.3

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

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

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

Section: 7.3.2.5 Viewpoint

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

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

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

    No Data Available

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

Section: Annex G

  • Key: SYSML11-20
  • Legacy Issue Number: 10380
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

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

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

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

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

Section: 9, 16, C

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

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

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

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

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

SysML: nout-->inout

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

    In SysML 9.3.2.4, the possible flow directions include

    nout

    based on later usage, this is incorrect for

    inout.

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

    No Data Available

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

constraints on viewpoint, 7.3.2.5

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

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

    Constraints

    …

    [2]The property ownedOperations must be empty.

    [3]The property ownedAttributes must be empty.

    …

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

    The submitter is correct

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

Table 14.1 Use Case Diagram

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

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

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

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

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

How to use property specific types for atomic flow ports?

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

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

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

    out:[Volt]

    Where can I show the value 12,5?

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

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

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

Section: Appendix B.4.5

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

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

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

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

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

Section: 11 Actibities

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

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

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

    No Data Available

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

8 Blocks, 8.3.1.2 Internal Block Diagram, 8.3.2.2 Block

  • Key: SYSML11-82
  • Legacy Issue Number: 12126
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    There are at least 4 kinds of properties of blocks: parts, references, values, constraints Constraint properties do not take part in the assembly hierarchy of blocks. Although they are of type Block via ConstraintBlock and have AggregationKind 'composite' they should not be considered "parts". SysML1.0, 8 Blocks: 'A block can include properties to specify its values, parts, and references to other blocks.' Rewrite to include constraint properties: 'A block can include properties to specify its values, parts, references to other blocks, and constraint properties.' SysML1.0, 8.3.1.2 Internal Block Diagram, Property types: 'Three general categories of properties are recognized in SysML: parts, references, and value properties' Rewrite to include constraint properties: 'Four general categories of properties are recognized in SysML: parts, references, value properties, and constraint properties.' SysML1.0, 8.3.2.2 Block, Description: 'SysML establishes three standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classifed as a part property. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, and value properties may be shown in block definition compartments with the labels “parts,” “references,” and “values” respectively. Properties of any type may be shown in a “properties” compartment.' Rewrite to include constraint properties: 'SysML establishes four standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classified as a part property (excluding constraint properties, which are typed by a Constraint Block). A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, value properties, and constraint properties, may be shown in block definition compartments with the labels “parts,” “references,” “values”, and "constraints" respectively. Properties of any type may be shown in a “properties” compartment.' Note also minor spelling correction: classifed -> classified.

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

    Rewrite to include constraint properties as a fourth kind of property of a SysML Block, and to refer to Chapter 9 and Chapter 10 for more detail about ports and constraint properties. Include properties owned by a SysML ValueType within these classifications, so that uniform rules will apply to them on internal block diagrams. Change the aggregation attribute of a value property to composite aggregation to be consistent with their solid box notation on an internal block diagram. Update constraint [6] on Block to reflect the composite aggregation of a value property. Fix an incorrect internal section reference and correct minor spelling corrections.

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

Allocation Callout to Item Flow is Ambiguous

  • Key: SYSML11-81
  • Legacy Issue Number: 12124
  • Status: closed  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    An allocation callout, when anchored to an Item Flow on an Internal Block Diagram, is unclear. If the Item Flow has an Item Property, then the allocation could be to the Item Flow itself, the Item Property, or the Item Property type (Conveyed Classifier). Recommendation: develop a compact graphical notation to distinguish the target of the allocation when a callout is used with any graphical depiction of an Item Flow.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Per resolution on issue #13945, an item flow supports only one item property, not
    multiple item properties. The ambiguity presented above thus becomes
    academic, there is no practical distinction between allocating to the item flow and
    allocating to the item property.
    Disposition: Closed, no change

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

Section: 8.3.1.2 Internal Block Diagram Extensions

  • Key: SYSML11-77
  • Legacy Issue Number: 11819
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Please provide a notation variant that allows to show block stereotypes at property elements typed by those blocks in an ibd. Similar to the notation variant that CallBehaviorActions can show the stereotypes of the called Behavior element. For example a common approach is to define stereotypes for discipline specific elements like <<hardware>>, <<software>>, <<mechanic>>, and so on. It is important to see the information in a bdd and ibd. It is circumstantial and superfluous to define two stereotypes for blocks and properties.

  • Reported: SysML 1.0 — Fri, 14 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The internal block diagram already allows any compartment of a block or value type that types a property to be shown within the property box on the diagram. Section 8.3.1.2 Internal Block Diagram, subsection "Compartments on internal properties" specifies, "SysML permits any property shown on an internal block diagram to also show compartments within the property box. These compartments may be given standard or user-customized labels just as on block definitions."
    A valid use of this option is to show a stereotype compartment, with or without any stereotype properties, as one of the compartments on the property box. This provides an existing graphical option to display the stereotype for a block or value type that types a property on an ibd.
    While the specifications places no restrictions on the compartments from the property type that may be shown on the property, in practice this could lead to confusion or ambiguity as to whether a compartment shown belongs to the property or to the type. The potential for such ambiguity is even higher if the property were to specify a property-specific type, since then the compartment could be used to define or redefine new features specific to the definition of the property itself.
    To remove any ambiguity for a compartment shown on a property, a graphical convention can be established to clearly mark and indicate a compartment whose contents are entirely the contents of the type of the property.
    Such a convention takes advantage of the customizability of compartment labels, and their definition as purely notational options on diagrams which are not defined formally anywhere in the SysML metamodel, is to use a special form of compartment label for these "type-derived" labels.
    For consistency with other aspects of ibd syntax, in which a ":" character separates a property name from its type, or which can precede the type when no property is shown, the recommended convention is to precede the "type-derived" compartments shown on an ibd with a colon.
    The revised text below establishes the colon prefix convention on a compartment label for any compartment which only displays contents of its type.
    Issue 11496, "It is not allowed in UML to display stereotypes of related elements," also noted the use of "secondary references" on both activities and blocks, including allocations on parts. Chapter 11 Activities already provides specific diagram extensions to display stereotypes of a defining element on a CallBehaviorAction, ObjectNode, or parameter. The colon prefix can also be used on an "allocatedFrom" or "allocatedTo" compartment label, as defined in Chapter 15 Allocations, to distinguish an allocation already established on the type of property from the property itself. At least some of the cases itemized by Issue 11496 are covered either by the explicit diagram extensions on activities or the use of compartments from a property type on an ibd.

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

Section: 8.3.2.2

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

    A block stereotype should be applied to any subclass of a block. Add a constraint to the block stereotype in 8.3.2.2 to reflect this.

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

    Add the suggested constraint not only to Block, but also to ValueType and ConstraintBlock.
    Issue 12255 is also being closed as duplicate with this one. It referred more generally to "Generalization of stereotyped elements" but all the examples it raised were within Blocks or related stereotypes, which is within the scope of this resolution

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

Section: 11.4

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

    There is reference to timelines in 11.1.5. This is widely considered a critical capability for SysML, but there is not example in the spec. Add a usage example of an activity diagram with timing constraints and the corresponding timing diagram as referred to in 11.1.5.

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

    Revise to show an example if timing constraints on activity diagrams. The portion of the issue concerning timing diagrams is not addressed by this resolution. It can be refiled as a separate issue.
    A specialized notation for time and duration constraints (e.g., straight lines and arrows associated with the constraints) and more sophisticated examples (e.g., illustration of the time and duration Observation concepts of the Simple Time Model) in Activity diagrams, as supported by UML sequence diagrams, can be considered in separated issues.

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

Section: 9.3.2.

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

    In 9.3.2.7, the Standard Port is listed as a stereotype, yet it is not shown as an extension in Figure 9.1. The Standard Port should either be included in Figure 9.1 as a stereotype or removed from the list of stereotypes in 9.3.2.7. Since the only change is a change of name, I propose leaving it in as a stereotype, but clarifying that the only extension is a name change.

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

    1) Remove StandardPort from the list of stereotypes in 9.3.2.7. The content of section 9.3.2.7 already exist in section 9.1.1 albeit phrased differently. The text of section 9.3.2.7 is merged with section 9.1.1 with no loss of information.
    2) As a side-effect, all references to the abstract syntax element "SysML::Ports&Flow::StandardPort" are changed to "UML4SysML::Port" in Table 9.1 and 9.2
    3) Finally, a section 9.3.2.5 is added to explain that the name change from "Port" to "StandardPort". This section is also used to explain the "StandardPort" compartment introduced in Table 9.1

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

Section: 16.3.2.7

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

    The verify relationship currently constraints one of its ends to be a test case. There have been several cases where this is too restrictive. In particular, sometimes it is useful to verify a requirement via analysis and leverage parametrics. In this case, it one may want to verify the reuqirement using a constraint block, block, or constraint property. The proposal is to delete the constraint that a requirement can only be verified with a test case which reads as follows: [2]The client must be an element stereotyped by «testCase» or one of the «testCase» subtypes. In addition, the description should be changed as follows: From: A Verify relationship is a dependency between a requirement and a test case that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) test case to the (supplier) requirement. To: A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) to the (supplier) requirement. There were two changes to the above description text. add 'or other model element', delete 'test case'

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

    Accept the proposal to delete the constraint.

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

Chapter Blocks/Section 8.3.2.6

  • Key: SYSML11-79
  • Legacy Issue Number: 11895
  • Status: closed  
  • Source: EmbeddedPlus Engineering Inc ( Kumar Marimuthu)
  • Summary:

    I am trying to support PropertySpecificType in our SysML Toolkit and I hit some road block while trying to implement the same. I have had some discussion with Sandy last week regarding the same but I quiet don’t get how this can be supported without some additional constructs to the PropertySpecificType stereotype. Below are the lists of questions I have: When a default value is provided for the property type, then a type derived from the original type should be created and its default value should be set as the new deafult value of the property. The property type should be displayed in square brackets which would indicated that the type is a specialized type. There can be more than one specialization of the same class, in such case there is no construct to store which specialization is associated with which property? This additional construct is very much needed because there is no way to know whether the specialization is created by SysML for PropertySpecificType or whether it is created by user? What happens in case of multi-level hierarchy? (If Class2 inherits Class1, and property1 is typed by Class2 & the default value at property1 is changed the resultant propertyspecifictype is Class3. Should the tool show property1:[Class2] or property1:[Class1]). Why is the PropertySpecificType extends UML2::Classifier and not UML2:Type? PropertySpecificType was introduced to provide specific default values to properties in Internal Block Diagram. Why not use the InstanceSpecification from UML2? Below Diagram shows how this is supported in UML2.

  • Reported: SysML 1.0 — Wed, 26 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Stakeholder and Concern

  • Key: SYSML11-78
  • Legacy Issue Number: 11823
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    Stakeholder and Concern should be first class elements.
    This is needed for UPDM modelers, that will likely will be reusing SysML View/Viewpoint structure.

  • Reported: SysML 1.0 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Now that UPDM has completed finalization, it has no specific requirements for
    reuse of these SysML elements. SysML relies on informal documentation strings
    to define a viewpoint, including not only stakeholder and concern but also
    purpose, languages, and methods. For consistency, these supporting elements
    of a viewpoint can continue to rely on the current string-based approach.
    Disposition: Closed, no change

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

Section 7.1

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

    The current paragraph describes comments as follows: "Comments can be associated with any model element and are quite useful as an informal means of documenting the model. The comment is not included in the model repository." If comments and their extensions (e.g., rationale, problem, etc) are not stored in the model repository, then they would not be retrievable when the model is next opened. This would make filling them out a waste of time. Please determine what is meant here and correct it.

  • Reported: SysML 1.0 — Wed, 12 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The sentence "The comment is not included in the model repository." is not correct. The comment element is part of the metamodel and it's instantiations are stored in the repository.

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

Rate stereotype attribute

  • Key: SYSML11-75
  • Legacy Issue Number: 11691
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Figure 11.8, page 98, defines a "rate" stereotype attribute typed as InstanceSpecification.
    In section 11.3.2.8, page 101, one can read "The rate stereotype has a rate property of type ValueSpecification".
    There seems to be an inconsistency here.

    I assume the relevant type for the "rate" stereotype attribute is ValueSpecification. Please can you confirm?

  • Reported: SysML 1.0 — Tue, 27 Nov 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 16.2.1

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

    The callout notation used in the Diagram Elements tables in 16.2.1 of the Requirements Chapter (pg 144-146)is inconsistent with the callout noation in the Diagram Elements tables in 15.2.1 of the Allocation chapter (pg 130). The text in the callout in Requirements starts with a capital letter and the text in the callout in Allocations starts with lower case. Make them consistent.

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

    No Data Available

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

Section: 9.3.2

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

    in Figure 9.1 Port Stereotypes,the Flow Specification that extends UML4SysML::Property should be a Flow Property and not a Flow Specification.

  • Reported: SysML 1.0 — Mon, 31 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Fix the diagram to the below figure.

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

Expanded Usage Examples for Viewpoints

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

    The resolutions to issues 18719 and 18653 have provided some refinements to viewpoint modeling. The current usage examples in appendix C for viewpoint modeling provide only a limited demonstration of viewpoint modeling. Some of the refinements such as ordered view hierarchies, expose relationships methods and concerns.

  • Reported: SysML 1.3 — Fri, 4 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution adds to previous resolutions made in response to issue (18653). A
    summary of the proposed changes in this resolution include:
    4. Expansion of the examples of modeling viewpoint stakeholders, concerns and
    methods
    5. View expose elements modeling
    6. View hierarchy modeling
    The current examples need to be expanded and corrected to be consistent with
    these other resolutions.

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

Concern Relation Limitations

  • Key: SYSML14-45
  • Legacy Issue Number: 18986
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    SysML 1.3 supports the description of concerns for stakeholders and viewpoints. When modeling stakeholders and viewpoints and their respective concerns the viewpoint identifies the sub-set of the stakeholders concerns that are addressed by the viewpoint. The issue is that since these properties are currently typed by strings in the stereotype for stakeholder and viewpoint, they must be redundantly stated in both stakeholder and viewpoint description. This allows the description text to potentially diverge or conversely burden the model developer with having to change the model in 2 places.

  • Reported: SysML 1.3 — Fri, 4 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution adds to previous resolutions made in response to issue 18653. A
    summary of the proposed changes in this resolution is simply to type concern with
    the meta-class “comment” rather than string. This allows the concerns to be reusable
    but still be a simple string.

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

SysML DI

  • Key: SYSML14-43
  • Legacy Issue Number: 18983
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    UML 2.5 added support for diagram interchange. The SysML specification does not talk about diagram interchange, although modifications and extensions of the UML DI are needed.

  • Reported: SysML 1.3 — Thu, 3 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This issue is addressed by adding an informative annex for SysML DI that extends
    UML DI to support modeler options introduced by SysML, including in Annex A, and
    to explain how to apply SysML DI as needed.

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

Any notation available for internal parts should apply to ports

  • Key: SYSML14-42
  • Legacy Issue Number: 18949
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    There is a need to apply the additional notation to ports that is used for other internal properties. In particular, we need to add compartments to represent the internal properties of ports so they can be connected to.

  • Reported: SysML 1.3 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution adds notation to ports, nested ports, and their definitions to be
    consistent with other property and type notations, that includes compartments with
    graphical and textual representations of structure and behavior. This also includes
    the extensions used in parametric diagrams to represent value properties as
    rectangles so they can be bound to.

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

Deprecated Elements update for Views and U&QK

  • Key: SYSML14-48
  • Legacy Issue Number: 19078
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The Deprecated Elements Annex should not imply deprecation of Views and Viewpoints, even though it has a transition procedure to SysmL 1.4. It should include a transition procedure for U&QK.

  • Reported: SysML 1.3 — Sun, 10 Nov 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    In the Deprecated Elements Annex, remove Views and Viewpoints from the Diagram
    Elements tables added by the resolution of 18719. Add transition procedure for
    SysML 1.4 Units and QuantityKinds. In the introduction, clarify that the Annex
    contains transitions procedures for elements that are not deprecated.

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

Align initial clauses with UML 2.5

  • Key: SYSML14-47
  • Legacy Issue Number: 19077
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Clauses 2-5 should be aligned with UML 2.5 and updates in SysML 1.4. For example, references to UML 2.4, compliance levels, Diagram Definition, and SysML DI.

  • Reported: SysML 1.3 — Sun, 10 Nov 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    remove references to “Superstructure” and update UML clause references for UML
    2.5. Replace StandardProfileL2 in Architecture package diagrams with
    StandardProfile, and add diagram for non-normative packages, including SysML DI

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

Annex A corrections

  • Key: SYSML14-44
  • Legacy Issue Number: 18984
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex A contains the following statements, which conflict with the UML notation:

    • a rake symbol may appear in call behavior actions. In UML, the rake symbol is mandatory.
    • a rake symbol on a state indicates that it references a state machine defined in another diagram. In UML, a “state composition” symbol is used for this purpose.

    Moreover, Annex A does not reflect the fact that the SysML DI can be used for diagram usages.

  • Reported: SysML 1.3 — Thu, 3 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This issue is addressed by removing references to call behavior actions and state machine
    references in A.2, and removing the note stating that there is no diagram metaclass in UML

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

Owning block terminology

  • Key: SYSML13-54
  • Legacy Issue Number: 16351
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The resolutions of issues 16227 and 16221 sometimes use the term "owning block" for proxy ports differently than UML ownership. For flow direction it is the block items are flowing in or out of, and for behavioral ports and directed features, it is the block the proxy port is standing in for. These uses should have different terms than "owning block".

  • Reported: SysML 1.2 — Tue, 28 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    New terminology might be more confusing, but the text can be clearer when
    using “owning block”, see revisions below.

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

Internal and external connectors undefined

  • Key: SYSML13-34
  • Legacy Issue Number: 16226
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The terms internal and external connector are used in v1.2 and the resolution of 13178, but are not defined.

  • Reported: SysML 1.2 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Define the terms internal and external connector and use them to disambiguate
    “connector” where necessary

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

onNestedPort should enable sending directly to target

  • Key: SYSML13-33
  • Legacy Issue Number: 16225
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML's onPort property on invocation actions enables invocations to be sent to ports of the target objects directly. The nested port extension to onPort in 13178 does not have this capability, but it should, since it is meant as an extension of onPort

  • Reported: SysML 1.2 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove constraints against full ports for InvocationOnNestedPortAction, and
    explain the two invocation semantics

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

Binding connectors may not have constraint parameters on any end

  • Key: SYSML13-46
  • Legacy Issue Number: 16332
  • Status: closed  
  • Source: InterCAX ( Dr. Manas Bajaj)
  • Summary:

    On pg 74 (section 10.4.2) of the SysML 1.2 spec, it is stated that:

    "A parametric diagram is similar to an internal block diagram with the exception that the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end."

    One may have binding connectors, whether or not they are shown in par diagrams, that have neither of their ends as constraint parameters. A binding connector may have both ends as value properties of the owning block or any of the nested part/ref/shared properties (at any depth).

  • Reported: SysML 1.2 — Mon, 13 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove the overly restrictive language in the referenced sentence. A binding
    connector directly between two properties can be considered as a simple form of
    parametric constraint specifying equality of the two properties

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

Full ports should not be conjugated

  • Key: SYSML13-45
  • Legacy Issue Number: 16293
  • Status: closed  
  • Source: International Business Machines ( Mr. Eldad Palachi)
  • Summary:

    he types of full ports have behaviors defined independently of the ports they type. They cannot switch the direction of flows and invocations based on the port they type.

  • Reported: SysML 1.2 — Mon, 30 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Add constraint that full ports cannot be conjugated

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

Association decomposition in diagram element tables

  • Key: SYSML13-49
  • Legacy Issue Number: 16335
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:


    In Section 9.2.1 (Extensions to Block Definition Diagram), as modified by Issue 16217, the row for item flows has an internal structure for the association class that does not match its end classes. Similar examples should also be in Section 9.2.1 (Extensions to Internal Block Diagram), and in Section 8.2.2 (Internal Block Diagram).

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change association classes in ports and flows diagram element tables to be
    consistent with the end classes of the association, and add examples of
    connector properties typed by association classes. Section 8.2.1 (Block
    Definition Diagram) and in the water delivery example already have examples of
    connector properties typed by an association class.

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

Item flow property values

  • Key: SYSML13-48
  • Legacy Issue Number: 16334
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In Section 9.3.2.7 (ItemFlow), Issue 13178 modified the last sentence of second paragraph ungrammatically. It should say the values of the item property are the flowing instances of water.

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revised as suggested above

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

Sample problem using deprecated conjugated port notation

  • Key: SYSML13-31
  • Legacy Issue Number: 16220
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    Figure B.36 (Flow Allocation to Power Subsystem (Internal Block Diagram)) uses black-filled rectangles for ports.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change black-filled port rectangles to white-filled in figure cited.

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

Ownership of item flow properties

  • Key: SYSML13-30
  • Legacy Issue Number: 16219
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The description of item flow properties refers to owner of source and target, which might not be the same. Fourth constraint should refer to realization.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Modify the item property owner to be common (possibly indirect) owner of the
    source and target of the corresponding item flow. Clarify the fourth constraint by
    referring to realization.

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

Owning block undefined

  • Key: SYSML13-35
  • Legacy Issue Number: 16227
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The term owning block is used in v1.2 and the resolution of 13178, but is not defined.

  • Reported: SysML 1.2 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Ownership is defined in UML, and blocks in SysML, so the term is not
    ambiguous, but it is sometimes used incorrectly, and it needs a special definition
    for proxy ports. The revised text corrects these cases, and adds the definition.

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

Clarifications to flow port resolution

  • Key: SYSML13-29
  • Legacy Issue Number: 16218
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Chapter 9 (Flow Ports), as revised by issue 13178, should clarify what "expressively" means in the overview, how textual notation flow direction in compartments is determined, and what the term "behavioral port" means in UML.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Add clarifications for the areas cited

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

Connectors should not link ports in block definition diagram elements

  • Key: SYSML13-28
  • Legacy Issue Number: 16217
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The subfigure added to the block definition diagram elements table by issue 13178 in the item flow row has a connector between ports. So does Figure B.23 (Elaborating Definition of Fuel Flow. (Block Definition Diagram)).

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Move the connectors in the cited figures to link blocks instead of ports

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

Internal fanout from proxy ports should be clarified

  • Key: SYSML13-44
  • Legacy Issue Number: 16285
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    he semantics of multiple internal connectors from proxy ports should be clarified. For example, what is the value of the port? Issue 13178 refers to a "virtual aggregate" that is not explained.

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

    Clarify the cited case.

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

Proxy ports should not have connectors

  • Key: SYSML13-43
  • Legacy Issue Number: 16284
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Proxy ports in the resolution of 13178 should have a constraint preventing them from owning connectors.

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

    Connectors on interface block typing proxy port might be useful for some
    applications, such as applying parametrics to interfaces.
    Disposition: Closed, no change

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

InvocationOnNestedPortAction and TriggerOnNestedPort notation not extended

  • Key: SYSML13-39
  • Legacy Issue Number: 16254
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Issue 13178 extends UML's onPort abstract syntax for InvocationAction and Trigger, but not the notation.

  • Reported: SysML 1.2 — Wed, 18 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    See issue 16255 for disposition

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

Ports that have behavior ports should be behavioral

  • Key: SYSML13-38
  • Legacy Issue Number: 16234
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:


    The resolution of issue 13178 only requires ports of behavioral ports to be behavioral, but should also require ports owning behavioral ports to be behavioral.

  • Reported: SysML 1.2 — Fri, 13 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This would prevent proxy ports bound to internal parts from having nested
    behavior ports that direct flows and invocations to those internal parts. This is
    useful for grouping features of the internal part type in various ways on nested
    behavioral ports, without adding nested ports to the internal part type.
    Disposition: Closed, no change

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

Provided / required operations & receptions

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

    It would simplify the use of required / provided interfaces if operations and receptions could be required and provided instead. It would enable provided and required ops/recs to be defined on the same block, including InterfaceBlock introduced by resolution of 13178.

  • Reported: SysML 1.2 — Mon, 9 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Extend Feature to indicate whether they are provided, required, or both (limited
    to behavioral features and non-flow properties).

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

Merge UML DataType into SysML ValueType

  • Key: SYSML12-16
  • Legacy Issue Number: 13345
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Even though SysML ValueType includes all the capabilities of UML DataType, plus its own optional extensions, SysML currently both of these separately in its diagram elements and abstract syntax. This adds unnecessarily to the complexity of the specification (where both DataType and ValueType must be mentioned in multiple places) and to the language that the SysML user must learn. It's inconsistent with other renaming of UML elements by SysML, in which the neutral SysML term (e.g. Block) replaces the UML term (e.g. Class). Just as SysML Block replaces the UML term Class, there's no reason the SysML term ValueType can't replace the UML term DataType. Statement of OCL constraints and metamodel and diagram syntax specifications can be simplified as a result.

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

    Because ValueType includes all capabilities UML DataType, plus its own optional
    extensions, no user need for keeping them both was identified during discussions
    within the RTF. In SysML user models, there’s no reason that the SysML term
    ValueType can’t replace the UML term DataType, in the same way that the
    SysML term Block replaces the UML term Class. In both cases, the substitute
    terms were chosen to be less software-specific than possibly appropriate for use
    by system modelers. Regardless of this rationale, consolidating to just ValueType
    simplifies the language including the specification of diagram elements and
    constraints.

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

Lack of Structured Activity Node and other Activity features Discussion

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

    Certain activity constructs were left out of UML4SysML to reduce complexitiy of the language, butBased on usage of activity diagrams, some of these constructs are now viewed as useful. One example is structured activity nodes. Others include the parameter affect. Proposed Resolution: Update Fig 4.2 andd Table 4.1 to include additional packages in UML4SysML that support the useful constructs such as structured activity node which is included in "CompleteStructuredActivities". Also, update the diagram element tables in Table 11.1 to reflect these new constructs.

  • Reported: SysML 1.1 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Table 4.1 (Detail of UML Reuse) says StructuredActivities is included in SysML,
    but Figure 4.2 (SysML Extension of UML) should be updated to include it (the
    figure includes the Composite Structures package for StructuredActivities), and
    structured activities should be included in the Activities chapter diagram elements
    table.

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

SysML/Modelica Integration Discussion

  • Key: SYSML12-10
  • Legacy Issue Number: 13179
  • Status: closed  
  • Source: Georgia Institute of Technology ( Chris Paredis)
  • Summary:

    In order to begin to more fully leverage SysML, it must be integrated with various execution languages. Modelica is a highly expressive execution language to support physics based analysis and simulation, which has been standardized through the Modelica Association. Initial feasibility indicates a high degree of compatibility between SysML and Modelica. A standard mapping between SysML and Modelica is needed to enable this capability. In addition, it is expected that some refinement/extensions of SysML may be required to more fully integrate with Modelica. Recommendation: Perform an initial mapping between SysML and Modelica. Identify any refinements/extensions to SysML to support the mapping. Prepare a non-normative annex to the SysML specification that captures this mapping.

  • Reported: SysML 1.1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    A separate specification for a "SysML-Modelica Transformation" is currently
    being finalized by OMG. This specification has taken over the specification of a
    mapping between the two languages and goes far further than originally
    suggested by this issue. The working groups for SysML and the SysML-Modelica
    Transformation are continuing to work together, and will raise specific issues
    against SysML as necessary to support the transformation capability.
    Disposition: Closed, no change

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

Port Decomposition of a Flow Specification Discussion

  • Key: SYSML12-9
  • Legacy Issue Number: 13178
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Port Decomposition of a Flow Specification Discussion. There has been continued need to be able to decompose ports. One approach is to decompose a flow specification. In order to more readily accomplish this, a flow specification steretoype should subclass block instead of extending interface. This would enable many of the block constructs to be used, such as nested connector ends, the dot notation, and other features. A nested connector ends would allow direct connections to the flow properties of flow specifications. Dot notation could be applied to refer to the flow properties. In addition, to enable further levels of decomposition, a flow property should be able to be typed by a Flow Specification. The notation should also be clarified to allow for flow ports typed by flow specifications to show the port with the nested flow properties, and futher levels of nesting as required. As an additional comment, a connector to the port that is typed by the flow specification can be allocated to sub connectors that connect directly to the flow properties to support the concept of connector decomposition. Recommendation. 1. Modify Figure 9.1 to show the Flow Specification stereotype subclassing block rather than extending Interface. 2. Modify Flow Property in 9.3.2.4 to allow it to also be typed by a Flow Specification. This should be reflected in the Description and Constraint 1. 3. Modify Flow Specification in 9.3.2.5 to note that Flow Specifications can be decomposed (not sure this is necessary, but it might be good to clarify). 4. Modify the text for the diagram extension to flow port in 9.3.1.1 to describe that a flow port that is typed by a flow specification can be notated with the port symbol that nests the flow properties. Also note that a connector can connect directly to these flow properties using nested connector ends, and that the dot notation can be applied to refer to the flow properties. Finally, note that flow properties can be nested more than one level.

  • Reported: SysML 1.1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This issue is resolved by loosening UML constraints on connectors to enable
    thems to connect to ports nested on ports, recursively, and provide a notation for
    nested ports. It clarifies that item flows can be typed by association blocks
    containing connectors between nested ports. Issues 10059, 11628, 12914, and 14086 are also resolved, see those issues for
    more information.

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

Section: 11.3.2 Inability to name interruptible activity regions

  • Key: SYSML12-8
  • Legacy Issue Number: 13157
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Inability to name interruptible activity regions. Discussion. Interruptible regions are useful constructs in SysML to enable termination of activity nodes. This is useful in a variety of cases, such as when one wants to terminate actions with streaming and continuous flows. In more complex behaviors with multiple interruptible regions, it is desired to be able to identify these regions by name. This may be useful when defining the owned behavior of a block with an activity that has multiple interruptible regions that represnt behavior in a similar way to state machines, where an accept event action may cause the behavior of the block to transition to another interruptible region of its behavior. Proposed resolution: An interruptible region in UML and SysML is currently an activity group which subclasses element. Create a stereotype of interruptible region called name interruptible region that subclasses Named Element (a similar approach is applied to activity partitions in UML

  • Reported: SysML 1.1 — Sun, 14 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This is addressed in UML 2.3. Assume this revision of SysML will be based on
    UML 2.3, and update the Activities diagram table in SysML.

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

Section: 4.2, 11.2.1

  • Key: SYSML12-7
  • Legacy Issue Number: 13156
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: SysML support for Foundational UML to support execution of activities Discussion. Need to include the foundational subset of UML in the UML4SysML to support activity execution. This includes constructs suchas structured activity nodes in complete structured activities, which is a capability that is a useful addittion to SysML. Proposed Resolution. Update Figure 4.2 and Table 4.1 to included structured activities, extra structured activities and complete structured activities along with any other packages in UML4SysML needed to support the Foundational UML Subset. In addtion, update the diagram elements in Tables 11.1-11.3 to reflect the additional activity constructs including the structured activity node.

  • Reported: SysML 1.1 — Sun, 14 Dec 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    Resolution:
    If the modeler stays within fUML, the model will execute. Some of SysML is not
    in fUML (eg, streaming), and some of fUML is not in SysML (expansion regions),
    but if the modeler stays with the intersection of fUML and SysML, the model will
    be executable and SysML-compliant.
    Disposition: Closed, no change

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

Parametrics and Depletable Stores

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

    Though we recently changed SysML to allow depletable stores, there appears to be some open issues about what they are and how to handle them with Parametrics properly.

    Is the name of the depleteable store that property of the owning block whose values change? (and can be used in Parametrics) Or does the depleteable store have a property (perhaps with a standard name) that is the changing value. Is the depleteable store a variable property or a part with a variable property?

  • Reported: SysML 1.1 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

SysML synchronization with UML/XMI version updates Discussion

  • Key: SYSML12-12
  • Legacy Issue Number: 13196
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: SysML synchronization with UML/XMI version updates Discussion: Since SysML was originally published, both UML and XMI specifications have been updated. It is important to maintain synchronization between SysML and these specifications since SysML leverages both of them. Proposed Resolution: Update Section 2 to reflect the current version of UML and XMI. An assessment of the changes to UML and XMI should be made, and a determination of the impact on the SysML specification. The SysML specification should be updated accordingly.

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

    Specific issues continue to be raised to address specific points of dependence of
    SysML on UML. The SysML specification itself has replaced specific version
    references to UML to simply "UML 2" so that references do not have to be
    changed to reflect the dependencies on which any given version of SysML
    depends, with the exception of material in Chapter 4, Language Architecture.
    This generic issue should be replaced by more specific ones that raise known
    issues in which future versions of SysML may need further revision to address
    dependencies on UML.
    Disposition: Closed, no change

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

Use cases in SysML are more similar to Requiremetns than Behavioral diagrams

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

    There is a non-normative diagram indicating a hierarchy of SysML diagram types. In this diagram we follow the UML convention of treating Use Cases as behavioral diagrams. The exact reason for this is unclear, and appears to be tied up with collaborations.

    However, in SysML system engineers (and many s/w eng in UML) treat use cases as a way of capturing goals, capabilities, purposes, and as a technique to organize (and find) requirements. In this way, it is more understandable to the typical SysML user to treat both Use case Diagrams and Requirements Diagrams as belonging to the same category. I have verified this by teaching SysML to students both ways – and the common UCD/REQ approach is thought to be more understandable.

    One approach would be to consider the new category Requirement Diagrams, and Use Case and Text-base Requirements as the individual requirements. Another would be to make a new category of Specification Diagrams and use Use Case and Requirements as the individual types.

  • Reported: SysML 1.1 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The above approach represents a reasonable approach to restructuring this
    Diagram Taxonomy. However, this taxonomy is intended to be more of a
    conceptual organization of the SysML diagrams, and is not a precise
    representation. There may in fact be many ways to categorize the diagrams in a
    conceptual and informal diagram taxonomy. As a result, this resolution will add a
    clarification to the non-normative Diagram Annex that other diagram taxonomies
    can be included, and include the categorizing of the use case diagram and
    requirements diagram as an example.

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

Section: 9.3.2.4 Constraint about "in" flow properties

  • Key: SYSML12-5
  • Legacy Issue Number: 12914
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Constraint [2] says: [2]An “in” FlowProperty value cannot be modified by its owning block. What is the owning block of the flow property? The flow property is owned by the flow specification which is a type of a flow port which is owned by a block. Is this block the "owning block"? Why is the owning block not allowed to change a in flow property? Shouldn't that be defined by the readOnly property instead of the direction?

  • Reported: SysML 1.1 — Tue, 7 Oct 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This is addressed in the resolution of issue 13178 with clarified wording in the
    description of flow properties

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

More than one constraint block of the same type in a parametric diagram

  • Key: SYSML12-4
  • Legacy Issue Number: 12853
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I'm just experimenting with the parametric diagram and detected a problem. I'm not sure
    if it is a SysML problem or if I am the problem.

    A block A has a composition relationship to a constraint block with multiplicity * and property name cstr.
    I like to use the constraint property cstr in a parametric diagram of block A multiple times.
    That doesn't work, because the constraint property occurs only once in the diagram.

    I don't like to define a constraint property for every usage of the constraint in the parametric
    diagram, because it's not two or three times, but really many many times I want to use the constraint.
    I think of something like the selector in sequence diagrams, i.e. the name of the constraint
    property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on.

    What do you think? Am I completely wrong?

  • Reported: SysML 1.1 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

Section: 11.3.1.1, 11.3.1.4, 11.4

  • Key: SYSML12-6
  • Legacy Issue Number: 13155
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Ability to capture performance properties of activities and bind to parameters in parametrics. Discussion. Need to clarify that performance properties of activities and other behaviors, such as the time, reliability, and accuracy associated with performing an activity, can be captured as part of the definition and use of an activity or the types of its object nodes in a way similar to value properties of blocks. Further clarification should be provided that these properties can be bound to parameters in parametric diagrams to support performance analysis. Activities (and other behaviors) can be captured on a bdd as shown in Figures 11.1, 11.5, 11-13 and 11-14. In section 11.3.1.1 and 11.3.1.4, the interpretation of activities and object nodes on bdd's is defined, and in section 11.3.1.4. Proposed resolution: Additional clarification should be provided in the above sections, that properties of activities and other behaviors can also be represented on their definitions on a bdd, and that the value properties are like any other value property, enabling them to be bound to parameters in parametric diagrams.

  • Reported: SysML 1.1 — Sat, 13 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Add clarifications for Activities, as indicated above. The clarification for Object
    Nodes is already in the Object Node section of Diagram Extensions.

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

Ambigous line crossings

  • Key: SYSML12-11
  • Legacy Issue Number: 13190
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Ambigous line crossings Discussion: When two lines cross, there can be ambiguity associated with the line path. This applies to any line including flows, associations, and connectors and other relationships represented by edges. A solution to remove ambiguity that is used in various schematic diagrams to address the same issue is to add include a curve in the lline path at the intersection. Proposed Resolution: In the Diagram Appendix on pgs 175-176, and a diagram guideline to include the curve to a crossing line path to avoid ambiguity. Consider making this a normative requirement. This will require an additional clarification statement for the Non Normative annexes.

  • Reported: SysML 1.1 — Tue, 23 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Update the Guidelines in the Diagram Annex in Section A.2 to include an
    alternative. ”jumping over “ notation for line crossings to avoid ambiguity, similar
    to what has been used in electrical schematics. This is indicated by a small
    semicircle at the line crossing. This can be applied to any edge in any SysML
    diagram including flows, associations, connectors, and other relationships. It
    should be noted that this is currently a presentation option for UML associations
    as specified in the UML Superstructure specification (formal/09-02-02 pg 43).

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

"trigger[guard]\activity" should be "trigger[guard]/activity"

  • Key: SYSML12-17
  • Legacy Issue Number: 13465
  • Status: closed  
  • Source: Logica ( Tis Veugen)
  • Summary:

    "trigger[guard]\activity" should be "trigger[guard]/activity"

  • Reported: SysML 1.1 — Sun, 8 Feb 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

Appendix F out of date

  • Key: SYSML13-13
  • Legacy Issue Number: 15905
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Appendix F refers to a glossary and other documents that are out of sync with the SysML spec. Suggest removing the appendix.

  • Reported: SysML 1.2 — Mon, 3 Jan 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove Annex F from the specification. There are no references to this Annex
    from elsewhere in the specification. The glossary referenced is from 2006 and
    would still require considerable work to be complete and correct even for the
    original version of SysML.

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

SysML 1.2 Issues: Definition of Overwrite

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

    Page 92 Overwrite

    The description of how overwrite works is wrong. The rule given in the spec is to replace the token that would be last to be selected according to the node rules.

    For example, let us imagine a node with 1..3 FIFO tokens when overwrite is applied.

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B B A

    C C B A

    D D B A

    E E B A

    Probably desired behavior

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B B A

    C C B A

    D D C B

    E E D C

    The recommended behavior is the standard behavior for real-time systems (usually implemented as a circular buffer, with the most recently arrived element the oldest element

    For LIFO queues

    For example, let us imagine a node with 1..3 LIFO tokens when overwrite is applied.

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B A B

    C A B C

    D D B C

    E E B C

    Probably desired behavior

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B A B

    C A B C

    D B C D

    E C D E

    The recommended approach makes both LIFO/FIFO queues always having the freshest elements to work from.

    Recommended

    “For upper bounds greater than one, when the queue is full, an arriving token replaces the oldest token in the queue, leaving a FIFO queue with the remaining earliest arriving token at the head of the queue and leaving a LIFO queue with the latest arriving token at the head of the queue.

    Also, consider giving an example as above.

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Agreed, but use wording reflecting the examples, rather than the recommended
    wording

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

SysML 1.2 Issues: Activity's sub-activities should be able to have mandatory multiplicity

  • Key: SYSML13-4
  • Legacy Issue Number: 15297
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Activity's sub activities should be able to have mandatory multiplicity

    Page 86, 3rd paragraph and page 86 constraint 3

    Original Text

    Combining the two aspects above, when an activity invokes other activities, they can be associated by a composition association, with the invoking activity on the whole end, and the invoked activity on the part end. If an execution of an activity on the whole end is terminated, then the executions of the activities on the part end are also terminated. The upper multiplicity on the part end restricts the number of concurrent synchronous executions of the behavior that can be invoked by the containing activity. The lower multiplicity on the part end is always zero, because there will be some time during the execution of the containing activity that the lower level activity is not executing.

    p87 [3] The lower multiplicity at the part end must be zero.

    Comment

    While this is technically true, it is not in the spirit of UML. We can have classes/blocks with mandatory components, because the, even though there is always a delay between the creation of the owner and the part, because we assume the time is

    1) small, and

    2) the situation can be made undetectable by normal UML means.

    The same situation can occur here, that we should allow the lower multiplicity to exclude zero, if the component activity is the first sub behavior to run (or tied for first) and that it is the last sub-behavior to end (or tied for last)

    Type: Fix

    Rewrite constraint

    [3]) The lower multiplicity of the part end must be zero, if

    a) An instance of the part is not always the first thing started (or concurrently initialized with the first thing stared) or

    b) An instance of the part is not always the last thing terminated (or terminated concurrently terminated with the last thing terminated), or

    c) It is possible at some point, for no instances of the part to exist.

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Agreed, but the constraint can just be removed

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

SysML Issue based on UML 15370 -- Package has optional URI

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

    UML issue 15370 added an optional URI field to packages. This has several potential usages, including unique identification, federated models, etc. There appears to be no reason not to include this change into SysML

  • Reported: SysML 1.2 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    SysML is an extension of the UML Superstructure. Since SysML 1.3 extends UML
    2.4.1 the requested change by this issue is already incorporated in SysML in the
    UML4SysML package. The SysML specification defines the complete concrete
    syntax including the elements from UML.

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

SysML Issue based on UML 14062 -- Stereotypes/keywords and upper/lowercase

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

    UML issue 14062 now attempts (though is not completely successful) in begin Stereotypes with uppercase and keywords with lowercase, though the old stuff will still work. Effectively, this is a style recommendation for the specification and for later methodologist.

    SysML should probably for sake of consistency adopt this as a guideline for our spec and developers

  • Reported: SysML 1.2 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Discussion:
    In the UML 2.4 Superstructure specification, under the subsection "Notation" in
    Section 18.3.9, Stereotype (from Profiles), the following statement appears:
    Normally a stereotype's name and the name of its applications start with
    upper-case letters, to follow the convention for naming classes. Domainspecific
    profiles may use different conventions. Matching between the names
    of stereotype definitions and applications is case-insensitive, so naming
    stereotype applications with lower-case letters where the stereotypes are
    defined using upper-case letters is valid, although stylistically obsolete.
    SysML consistently follows the lower-case keyword convention for stereotype
    applications, which the UML specifications now indicates is a valid convention for
    domain-specific profiles. The less-obtrusive lowercase keywords are valid according
    to the case-insenstive matching of stereotype names, and is preferred by many users
    based on long-standing practice in SysML and because the many uses of such
    keywords in SysML are less obtrusive than uppercase names would be.
    Disposition: Closed, no change

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

SysML 1.2 - Blocks

  • Key: SYSML13-9
  • Legacy Issue Number: 15600
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    It’s not clear whether the notation for static is part of SysML or not.

  • Reported: SysML 1.2 — Sun, 19 Sep 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Restore the version of the diagram in the "Block" row of Table 8.1, "Graphical nodes
    defined in Block Definition diagrams" which was adopted by a resolution of Issue
    10381 by the SysML 1.0 FTF.
    See the SysML 1.0 FTF Report, published as OMG document ptc/2007-03-19, for the
    original resolution of Issue 10381. This issue included an updated version of the
    diagram in the "Block" row of Table 8.1, specifically modified to include an example
    of a static feature.
    In the SysML 1.0 FTF convenience documents, OMG documents ptc/2007-02-03 and
    ptc/2007-02-04, this diagram appeared as adopted by Issue 10381, but in the final
    SysML 1.0 formal specification, published as OMG document formal/2007-09-01, and
    in all subsequent SysML revisions, the underline of the newly added "property5"
    property, which indicates a static feature, no longer appears.
    Restore the underline of "property5" in this diagram as originally adopted by the
    resolution of Issue 10381.

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

Test Context appears in XMI but not in Profile Spec

  • Key: SYSML13-20
  • Legacy Issue Number: 16061
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The stereotype TestContext appears in the SysML profile XMI file http://www.omg.org/spec/SysML/20100301/SysML-profile.uml , but is not in the SysML v1.2 profile specification. It should be removed from the xmi file and anywhere else it may have inadvertently been introduced.

  • Reported: SysML 1.2 — Wed, 16 Mar 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Discussion:
    The stereotype TestContext no longer appears in the SysML profile XMI file
    generated by the SysML 1.3 RTF and published as OMG document ptc/2011-08-11
    and under the URL http://www.omg.org/spec/SysML/20110801/SysML.xmi. No
    change to the specification itself is required.
    Disposition: Closed, no change

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

Clarification when Allocated Stereotype is applied

  • Key: SYSML13-19
  • Legacy Issue Number: 16046
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocated stereotype is applied to an element at either end of an allocate relationship. This enables the use of the compartment and callout notations to identify what element is on the other end of the allocate relationship. The specification does not explictly state that the allocated stereotype is applied to the elements when the allocate relationship is established. This should be specified as a constraint for the allocated stereotype. This should not imply that the stereotype name must be displayed, but only that the stereotype is applied.

  • Reported: SysML 1.2 — Tue, 1 Mar 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    The intent of the derived properties provided by the Allocated stereotype is to enable
    the end of the allocation relationship to be identified by the other end, whatever it is.
    The approach is similar with derived properties like the “/satisfied” or the “/traceFrom”
    from the RequirementRelated stereotype.
    The drawback is that requiring these stereotypes to be applied when the
    corresponding relation is created implies modifying the elements at one (requirement
    related relations) or both (Allocation relation) of its ends. Modification of the elements
    involved in the relationship is not possible when one or both of those elements is
    read-only and this is likely during the modeling of allocation relationships or of
    requirements traceability.
    These stereotypes do not actually hold any information by themselves, they only
    provide a way to query information owned by directed relationships which may have
    been established between the elements they are applied to. The stereotypes
    specified that the corresponding derived properties (i.e. the corresponding queries)
    shall be available for any model element which is involved in one an allocation or in a
    requirement related relationship. The proposed solution consists in adding to the
    definition of each relationship the necessary queries in order to provide this facility.
    These queries are specified “static” so that they can be used independently of any
    relationship instance.
    Both the Allocated and RequirementRelated stereotypes can then be suppressed
    from the SysML specification. Example of usage with OCL:
    Assume “getAllocatedFrom(ref: NamedElement) : Set(NamedElement)” is the static
    query defined by the Allocate stereotype to retrieve any named element to which a
    given named element has been allocated.
    If “X” is a named element “X”, then:
    Allocate::getAllocatedFrom(X)
    Will give the set of any element to which X is allocated.
    Note that the call will not fail even if there is no allocate relationship at all. In this case
    or if X is not allocated it will simply return an empty set.

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

Flow property semantics only defined for external connectors

  • Key: SYSML13-37
  • Legacy Issue Number: 16231
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The flow property semantics in the second paragraph of Section 9.3.2.3 (FlowProperty) only gives semantics for out to in flow properties, which does not work for internal connectors to proxy ports as introduced in issue 13178.

  • Reported: SysML 1.2 — Thu, 12 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    The current semantics of flow properties also works for internal connectors of full
    ports, but should not apply to internal connectors of proxy ports, as the filer says.
    The flow property semantics for internal connectors of proxy ports is implied by
    the semantics of proxy ports, but this should be clarified.

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

Block shown as metaclass

  • Key: SYSML13-36
  • Legacy Issue Number: 16230
  • Status: closed  
  • Source: MAHLE International GmbH ( Andreas Korff)
  • Summary:

    Figure 9.1, as modified by issue 13178 shows block as a metaclass instead of a stereotype.

  • Reported: SysML 1.2 — Thu, 12 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Show block as stereotype in Figure 9.1.

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

SysML 1.2 Issues: Structure compartment wrong in spec

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

    Page 31

    There is an example of the Structure Compartment.

    As this compartment follows the ibd format, it should contain parts not blocks

    Type: Formatting/Clarification

    Change Block2 and Block3 to :Block2 and :Block3

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    The original SysML submission document, published as OMG document ptc/2006-
    05-04 as the Final Adopted Specification, and the SysML 1.0 FTF convenience
    documents, all had the following version of the diagram in the Structure
    Compartment row of Table 8.1, "Graphical nodes defined in Block Definition
    diagrams":
    Block1
    structure
    p1: Type1 p2:
    Type2
    1
    e1
    c1:
    The current but incorrect version, of this diagram, however, appeared in the final
    SysML 1.0 formal specification, published as OMG document formal/2007-09-01,
    apparently as a result of reauthored graphics after Visio version incompatibilities.
    Replace the current, incorrect version of this diagram by its original version, with
    slight cleanup of its formatting.

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

SysML 1.2 Section 16.4.4

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

    Several errors in this section that need to be fixed.

    1) Figure 16.8. Type of diagram should be "stm" not "sm"
    2) Figure 16.7 and Figure 16.8. The relation between the testCase and the Requirement should be «verify» not «refine»
    3) The paragraph mentions Figure 16.7, but actually describes Figure 16.8.
    4) No description of Figure 16.7 appears.

  • Reported: SysML 1.2 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Resolve as follows:
    1) Fig 16.8 diagram type was already fixed in SysML 1.2.
    2) The callouts in Fig. 16.7 and Fig. 16.7 were already changed to "VerifiedBy" and
    "Verifies" in SysML 1.2.
    3) & 4). Replace text for section 16.4.4.

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

properties allocatedFrom and allocatedTo should be capitalized

  • Key: SYSML13-1
  • Legacy Issue Number: 15078
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    The properties allocatedFrom and allocatedTo should be capitalized as shown here, and are so in SysML 1.1 pp 133 and following, but they are incorrect in the text on pp 131 and 132. (They are always capitalized correctly in figures; the errors occur in the text.)

  • Reported: SysML 1.2 — Sat, 20 Feb 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change capitalization on page 131 and 132 to be consistent with remaining
    document.

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

Structure Compartment shows blocks instead of parts

  • Key: SYSML13-8
  • Legacy Issue Number: 15355
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The structure compartment shows two blocks connected with a connector. It should be two parts.

  • Reported: SysML 1.2 — Tue, 6 Jul 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Disposition: See issue 15294 for disposition

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

SysML 1.2, ch 12

  • Key: SYSML13-7
  • Legacy Issue Number: 15302
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Table on page 110 – Creation Event should be shown as a dashed arrow to be consistent with UML.

  • Reported: SysML 1.2 — Tue, 22 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Correct notation

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

SysML 1.2 Issues: Missing constraint on Rationals

  • Key: SYSML13-6
  • Legacy Issue Number: 15301
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 214, C.5.2.14 Rational

    Current description of the Rational value type is missing a constraint that prohibits the denominator from being 0.

    Type: Fix

    Add constraint [1]) The denominator must not be 0

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Disposition: See issue 16396 for disposition

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

Including Behavior Port Notation

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

    The behavior port notation to support the isBehavior=true condition on a port is needed to more explicitly model parts that execute the behavior directly. Refer to Figure 9.17 of the UML Superstructure Specification (v2.3).

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

    Agree with the need

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

Streamlined notation for representing system variance

  • Key: SYSML12-39
  • Legacy Issue Number: 14827
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    System variants are often required to modify a system in order to satisfy evolving needs, and to support product lines with varying applications and environments. System variants have some components in common and some components that may be unique for each variant. SysML currently includes some capability to address variants, such as a property-specific type for specifying a variant usage of a component (i.e., block) in a local context, redefinition for redefining the type of the component, and generalization sets for specifying alternative components. However, what it lacks is a convenient mechanism and notation for describing variations that occur in deeply nested contexts within blocks.

    Issue
    System Variants
    Classical product configuration management evaluates whether the change to an assembly affects the next higher assembly in terms of its form, fit, or function. If there is no change to its form, fit, or function, the modification does not propagate up the hierarchy (Note: This should be confirmed). In order to ensure there is no adverse impact to the next higher assembly, one must establish criteria to evaluate the impact of the change on the next higher assembly, and then evaluate the impact of the change against the criteria.

    Figure 1 describes the baseline block hierarchy for a Vehicle; in the following paragraphs we will discuss how to address variants of this baseline system.

    Figure 1 - Definition of the baseline configuration for a vehicle
    In considering variance, one first checks to see if the change to a component affects the interface of the next higher level assembly. For example, in Figure 1, if the number of lugbolts is changed from 6 to 8, this could impact the interface to the braking disc. In addition, one must evaluate other potential impacts due to form, fit, and function. For example, if the weight of the bolt changes, the impact may propagate up the hierarchy to affect the overall vehicle weight. Or if the modified bolt has a lower stress rating, it may impact the safety of the vehicle. These impacts need to be understood to make a determination of whether the modification to the lugbolt impacts the next higher assemblies and the vehicle as a whole. If the change propagates up the system level, then each higher level of the assembly that is impacted must be subclassed (e.g., this may correspond to a new model number) to represent the variant assembly.
    Representing Variants using Block Definition Diagrams

    When a system variant results from changes in its components, the variant system model must include representations of the variations at each level of the system hierarchy from the system level down to the component level where the changes occur. The example in Figures 2 illustrates the SysML solution when a modification to a lugbolt results in a variant to the automobile at each level of the system hierarchy. In Figure 2, a change to the lug bolt (i.e. LugBolt A) propagates up the system hierarchy resulting in a variant to the wheel, to the chassis (or equivalent next assembly), and to the vehicle. The variant system hierarchy includes Vehicle A, Chassis A, Wheel A, and LugBolt A as subclasses of the baseline system elements.

    Figure 2 ­ Varying all levels of the system hierarchy

    The following reference provides further information on a general approach to capturing variants: “Extended Generic Product Structure: An Information Model for Representing Product Families by Sean Callahan.” This short paper can be found at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_published.pdf and a longer version at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_extended.pdf.

    System Variants Using Property-Specific Types

    In Figure 2, 4 new types were introduced. If there is no impact to the form, fit, or function of the higher elements in the assembly, then modeling these intermediate assemblies using new types can be very cumbersome. There is a need for a more streamlined approach to capturing variations in deeply nested parts that do not affect intermediate level assemblies.

    At first glance, the property-specific type concept in SysML seems to fit the bill. As shown in Figure 3, using property-specific types, the replacement part is shown using dot notation on the IBD for Vehicle A, without the need for the user to explicitly represent Chassis A, etc. on the corresponding BDD.

    Figure 3 - Use of property-specific types to capture variants

    However, as can be seen, the redefinition clause in the part symbol does not give a clear indication of the location of the part being redefined, nor is there a notation on a BDD for showing this replacement part.

    Note: Figures were not able to be included with this posting but are available on the SysML v1.2 RTF Wiki

  • Reported: SysML 1.1 — Tue, 1 Dec 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This RTF declines to add specialized notation for variants.
    Disposition: Closed, no change

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

Ambiguous Block Hierarchy

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

    There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies.

  • Reported: SysML 1.1 — Sun, 4 Oct 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The figures above have only one (unambiguous) underlying model, but directed
    relationships, such as dependencies, linked to c1 (or c2) would be ambiguous. It
    would not be possible from the underlying model alone (without the notation) to tell
    whether the directed relationship was referring to values of c1 properties on
    instances of B that are values of the b1 property on instances of A, or values of the b2 property on instances of A, because directed relationships do not currently
    support property paths, as connector ends do when NestedConnectorEnd is applied.
    Introduce an abstract stereotype of DirectedRelationship with property paths for their
    sources and targets, that generalizes SysML Stereotypes based on
    DirectedRelationship or its specializations

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

Non-atomic flow ports use property type incorrectly

  • Key: SYSML12-37
  • Legacy Issue Number: 14424
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Non-atomic flow ports use the type of
    the port for an interface with
    properties specifying the type of things
    that flow. If the various types of
    things flowing are intended to flow at
    the same time, then flow specifications
    aren't needed. This can be done with an
    atomic port flowing objects supporting
    the interface. If the the various types
    of things flowing are meant to flow at
    different times, this is isn't UML
    semantics, or at least is very
    unintuitive from an engineering point.
    This can be done either with 1) an
    atomic port flowing a supertype of the
    various types of things that flow 2) the
    association mentioned in in the first
    paragraph having multiple types, which
    the semantics defined to be union of the
    types.

  • Reported: SysML 1.1 — Wed, 16 Sep 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Ports typed by flow specifications do not mean that items supporting the interface
    are flowing. This is clarified in the resolution to issue 13178.
    Disposition: Closed, no change

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

Wrong type in fig. 15.11

  • Key: SYSML12-35
  • Legacy Issue Number: 14238
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The type in the allocation matrix must be action instead of activity.

  • Reported: SysML 1.1 — Mon, 31 Aug 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Discussion:
    Fig. 15.11 was deleted in SysML 1.2, removing redundancy with Annex B.
    Fig. B.37 (Fig. C.37 in SysML 1.3) is the same figure, but the issue noted here was
    fixed in the resolution to Issue 11497 in SysML 1.2.
    Disposition: Closed, no change

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

Ports use property type incorrectly

  • Key: SYSML12-34
  • Legacy Issue Number: 14086
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Ports use property type incorrectly. Atomic flow ports use the type of the port for the type of thing flowing. This doesn't fit common usage in engineering design, for example, a port that is a faucet through which water flows. The type of thing flowing isn't the type of the port, it should be associated to the ports by the stereotype. Non-atomic flow ports use the type of the port for an interface with properties specifying the type of things that flow. If the various types of things flowing are intended to flow at the same time, then flow specifications aren't needed. This can be done with an atomic port flowing objects supporting the interface. If the the various types of things flowing are meant to flow at different times, this is isn't UML semantics. This can be done either with 1) an atomic port flowing a supertype of the various types of things that flow 2) the association mentioned in in the first paragraph having multiple types, which the semantics defined to be union of the types.

  • Reported: SysML 1.1 — Sun, 19 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The atomic port portion of this issue is addressed in the resolution of issue 13178
    by deprecating atomic flow ports. See resolution of issue 14424 regarding nonatomic
    flow ports.

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

Constraining a decomposition hierarchy

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

    There is a need for a robust mechanism to constrain a system decomposition hierarchy to reflect only selected groupings of parts as motivated by the following example. In particular, assume a rack assembly is composed of a chassis and a set of circuit cards. The rack assembly is constrained by which cards can be inserted in which slots. This includes an optical card in an optical slot, an ethernet card in an ethernet slot and a general slot that can accommodate either an ethernet card or an optical card (source is Nathan Sowatskey example). In addition, a particular rack configuration may include a specific number of each type of slot and card. The need is to constrain the hierarchy to only allow these combinations parts. Generalization sets, redefinition, and other mechanisms can help, but require considerable modeling that is cumbersome. The desired capability is to be able to include a constraint in the rack assembly that constrains the allowable instances of the rack assembly. It is also desirable to specify constraints on nested parts using the dot notation. (Refer to related issue 14998 binding to multiplicity in parameterics).

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

    No Data Available

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

15.3.2.2 Allocated(from Allocations)

  • Key: SYSML12-36
  • Legacy Issue Number: 14239
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Although explicitly stated that other designations may be used the list should contain at least <<action>>, <<operation>> and <<property>>. Allocation with actions and properties as related elements are shown in the examples in the specification.

  • Reported: SysML 1.1 — Mon, 31 Aug 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The proposed change is not required, but adds clarity.

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

Extending Ports to Support Non-flow Properties

  • Key: SYSML12-42
  • Legacy Issue Number: 15076
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is a need to model a broader range of interfaces which extend beyond the current capability of standard ports and flow ports in SysML. One example is the physics based interfaces that are found in Modelica referred to as across and through variables. An example is in an electrical circuit where the interface can be defined in terms of the current and voltage parameters at each input and output node of a circuit. In Modelica, the interface between two components enables Kirchoffs Laws to be imposed on these interfaces such that the voltage on the on the connecting ports are equal, and the sum of the currents on the connecting ports sum to zero. SysML needs to be able to accommodate this type of interface more directly. One possible approach is to extend the concept of a Flow Specification to accommodate other types of properties, such as across and through variables, and not be limited to flow properties.

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

    Disposition: See issue 11628 for resolution

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

Overly restrictive statement regarding ports in blocks chapter

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

    Overly restrictive statement regarding ports in blocks chapter. The following statement in section 8.3.2.2 in the Blocks Chapter is overly restrictive. "A port that is typed by a Block is a special case of a part property, as further defined in Chapter 9, Ports and Flows.". A port is a special class of property that can be typed by classifiers other than blocks. The recommendation is to generalize the wording as follows: A port is another category of property, as further defined in Chapter 9, Ports and Flows.

  • Reported: SysML 1.1 — Sat, 18 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

Including Property Notation for Redefinition and Subsetting

  • Key: SYSML12-41
  • Legacy Issue Number: 15075
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The property notation from UML to support redefinition and subsetting should be included in SysML explicitly. This notation is not currently included in the diagram element tables in the Blocks Chapter. Refer to property notation in Section 7.3.44 of the Superstructure Specification (v2.3).

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

    Include property subsetting and redefinition in the Block Definition diagram element
    tables.

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

Typing Flow Properties and Item Properties as Enumerations

  • Key: SYSML12-44
  • Legacy Issue Number: 15117
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is an inability to type a flow property or item property by an enumeration. This issue surfaced when Nathan Sowatskey was attempting to model a VLAN network.

  • Reported: SysML 1.1 — Wed, 3 Mar 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Flow properties can be typed by enumerations. They can be typed by
    ValueTypes, which is a stereotype based on UML Datatype, a generalization of
    UML Enumerations.
    Disposition: Closed, no change

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

Broadcasting along connectors

  • Key: SYSML13-53
  • Legacy Issue Number: 16345
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    It is not possible to send out invocations along untyped connectors to parts. Flow properties can be changed on self and broadcast along connectors to neighbors that support them, but invocations cannot. Extend invocation action semantics to send invocations out connectors to neighbors that support them.

  • Reported: SysML 1.2 — Wed, 22 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Specify the above semantics for required behavioral features.

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

Events for property value changes

  • Key: SYSML13-52
  • Legacy Issue Number: 16344
  • Status: closed  
  • Source: International Business Machines ( Mr. Eldad Palachi)
  • Summary:

    Extend ChangeEvent and AcceptEventAction to detect and changes in property values.

  • Reported: SysML 1.2 — Wed, 22 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Extend ChangeEvent for changes in values of structural features, and extend
    AcceptEventAction to handle these events.

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

InvocationOnNestedPortAction and TriggerOnNestedPort

  • Key: SYSML13-56
  • Legacy Issue Number: 16391
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In InvocationOnNestedPortAction and TriggerOnNestedPort, in the path attribute description, replace "until a port is reached" with "ending in a port", to support nonuniqueness

  • Reported: SysML 1.2 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revised as suggested above

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

Provided and required feature abbreviations

  • Key: SYSML13-55
  • Legacy Issue Number: 16352
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The provreq abbrevation for providedrequired should be provreqd, to be consistent with the reqd abbrevation for required. The block diagram elements table in the ports and flows chapter should use the abbreviations.

  • Reported: SysML 1.2 — Wed, 29 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested

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

Proxy port owning block definition should refer to internal structure

  • Key: SYSML13-50
  • Legacy Issue Number: 16336
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Section 9.3.2.8 (ProxyPort), first paragraph, as modified by Issue 16227, should refer to internal structure instead of diagrams, because multiple diagrams can describe the internal structure of the same class.

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested above.

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

Clarify open and closed meaning of port types vs other property types

  • Key: SYSML13-47
  • Legacy Issue Number: 16333
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Clarify that connectors use port types in a closed way, rather than open, as described in Block, unless specialized

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Untyped properties should be described as not constraining their values. This
    will be clearly different from the additional functionality ports types have in
    restricting which features are available to external connectors of the port.

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

Contextualized item flows

  • Key: SYSML13-51
  • Legacy Issue Number: 16337
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Item flows are based on dependencies, which cannot be contextualized in an internal structure, but many of the use cases are for item flows realizing connectors.

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Item flows are contextualized by realizing connectors.
    Disposition: Closed, no change

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

Rate does not support the examples

  • Key: SYSML13-58
  • Legacy Issue Number: 16406
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    There is an inconsistency w.r.t. the definition of SysML Rate with the notation & examples.

    According to figure 11.8, SysML Rate extends only 2 metaclasses: Parameter and ActivityEdge.
    By generalization, SysML Continuous and Discrete also extend these two metaclasses.

    According to the notation in Table 11.1, <<rate>>, <<continuous>> and <<discrete>> also apply to ObjectNodes.
    The examples in figure B.33 and B.35 show applications of <<continuous>> to CentralBufferNodes and ActivityParameterNodes, both are direct specializations of ObjectNode.
    Some examples in the Practical Guide to SysML do the same – see figure 8.17 on p. 196; figure 15.14 on p. 373

    Both SysML 1.2 Figure 11.8 and the published profile http://www.omg.org/spec/SysML/20100301/SysML-profile.uml are incomplete.

    The resolution is fairly simple: Add an extension from Rate to ObjectNode in figure 11.8 and update the SysML profile accordingly.

    I propose to include this resolution in ballot 5 for sysml 1.3.

  • Reported: SysML 1.2 — Sat, 30 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This the same issue as 11498 (closed), but add clarification for Figure C.33 and C.35
    about the notation.

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

Improvements to QUDV for SysML v1.3

  • Key: SYSML13-57
  • Legacy Issue Number: 16396
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    There are mistakes and inconveniences in the model and model library of quantities, units, dimensions and values (QUDV) in SysML v1.2 as defined in Annex C. Furthermore the ordering of the sections in Annex C can be made more logical to improve the readability.

  • Reported: SysML 1.2 — Mon, 25 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove Quantity from Annex C.5. The reason is that the concept of quantity is
    fully implemented by a value property typed by a ValueType. Therefore an
    additional class/block Quantity is superfluous and confusing.
    The QUDV model can be simplified by merging DimensionFactor and
    QuantityKindFactor into one concept QuantityKindFactor.
    Remove property definition for symbolicExpression, since this is only an
    informational (presentation) property that can be derived from the ordered set of
    factor : DimensionFactor.
    In SysML 1.2, Figure C.8, a SystemOfUnits had a many-to-many relationship
    with SystemOfQuantities. This precluded aligning SysML 1.2 QUDV tightly with
    ISO 80000-1:2009 where the notion of ‘system of units’ (ISO 80000-1:2009, 3.13)
    is defined for a single ‘system of quantities’ (ISO 80000-1:2009, 3.3).
    Furthermore, Section C.5.2.22 Unit did not define the property Unit::quantityKind
    : QuantityKind[0..1] shown in Figure C.8 even though this property is extensively
    used for the specification of coherence analysis in section C.5.2.21
    SystemOfUnits, Constraints [1,2].
    The meaning of the undocumented association between Unit and QuantityKind
    should be revised to support the capability specified in ISO/IEC Guide 99:2007
    about a coherent system of units (item 1.14), Note 1:
    A system of units can be coherent only with respect to a system of
    quantities and the adopted base units. The adoption of a Unit as the base measurement unit for a given QuantityKind is
    understood to be a distinguished subset among the set of all QuantityKinds that
    are the measurementUnits for a particular Unit. A Unit can be the measurement
    unit of many QuantityKinds and a given QuantityKind can have many
    measurement Units per Note 2 of ISO 80000-1:2009, 3.9:
    NOTE 2 Measurement units of quantities of the same quantity dimension
    may be designated by the same name and symbol even when the
    quantities are not of the same kind. For example, joule per kelvin and J/K
    are respectively the name and symbol of both a measurement unit of heat
    capacity and a measurement unit of entropy, which are generally not
    considered to be quantities of the same kind. However, in some cases
    special measurement unit names are restricted to be used with quantities
    of specific kind only. For example, the measurement unit ‘second to the
    power minus one’ (1/s) is called hertz (Hz) when used for frequencies and
    becquerel (Bq) when used for activities of radionuclides. As another
    example, the joule (J) is used as a unit of energy, but never as a unit of
    moment of force, i.e. the newton metre (N · m).
    The above makes sense in the context of a particular relationship between a
    SystemOfUnits and a SystemOfQuantities. It would be more difficult to express
    the above in a more generalized context like that of SysML1.2 with many-tomany
    possible relationships between SystemOfUnits and SystemOfQuantities.
    Consequently, the QUDV model is revised to focus on the most common case in
    practice where a SystemOfUnits is defined for up to a single SystemOfQuantities.
    The reduced generality of the QUDV model is intended to simplify the use of
    QUDV in practice and is explicitly conveyed via new invariants (see below for
    new constraints added for C.5.2.20 and C.5.2.21).
    In SysML 1.2, Figure C.10 is not consistent with the text which includes OCL for
    deriving the non-derived property SystemOfQuantities::dimension :
    Dimension[0..*] (see C.5.2.20 SystemOfQuantities, Constraint [1])
    Since SysML 1.2 was published, the major parts of ISO/IEC 80000 have been
    published with definitions for the International System of Quantities (ISQ) and the
    International System of Units (SI). Annex C.4 is revised to be based on this
    authoritative source rather than the NIST special publication it formerly
    referenced. The SysML QuantityKind and Unit definitions in Annex C.4 are
    revised to follow the naming and organization of the quantity and unit definitions
    from Part 1 of ISO 80000, which cover the same base and derived units as
    before. Unit symbols have also been added to the SysML Unit definitions.
    The text in Annex C.4 is revised to indicate how the definitionURI strings of its
    QuantityKind and Unit definitions could be used to refer to corresponding QUDV
    definitions in a separately published model library. Figures C.10 and C.11 in
    Section 5.4.1 continue to provide examples of such QUDV definitions that could
    be expanded to the full set of quantities and units from ISO 80000-1.
    Specific definitionURI string values for reference to QUDV definitions have not
    been included in Annex C.4, not only because they would clutter the diagrams,
    but because they could be automatically supplied as part of the publication of
    more complete, machine-readable versions of both model libraries.
    Because Annex C.4 continues to define a model library consisting only of SysML
    QuantityKind and Unit definitions, without any direct dependence on QUDV or
    other QUDV model libraries, there is no inherent problem with the ordering or
    logical dependence of the current Annexes. No change is made to the current
    Annex C sections other than a new name for the ISO 80000-1 model library in
    Section C.4.

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

use of derived in Requirements

  • Key: SYSML12-3
  • Legacy Issue Number: 12751
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    16.3.2.3:

    (2) /derived: Requirement [0..1]
    Derived from all requirements that are the client of a «deriveReqt»
    relationship for which this requirement is a supplier.

    I don't think we can write OCL to derive this value, at least not
    without knowledge of the population of Requirements in which this
    instance is situated. How would we navigate from this object, a
    Requirement, to that population? I note that the version of the
    profile XMI I am using doesn't declare this property as derived. It
    appears that at least one SysML tool provider didn't derive it, but
    maintains it in their tool and XMI.

    I think something like the above criticism can be leveled against all
    of the
    attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master
    that are declared derived in the spec 08-05-16. Perhaps we ought to
    remove the '/' and use a word other than "derived" in describing
    these attributes.

    Likewise 16.3.2.4 RequirementRelated attributes should not be declared
    derived.

    It may be the case that the OMG needs to be clearer regarding what it
    means by "derived." There are attributes whose definition can be
    expressed in OCL and there are attributes whose value can only be
    found by some (perhaps vaguely specified) analysis of the Model (if
    Model is the correct context!). The latter notion is, I think, what
    you intend throughout Clause 16. That's fine, except I don't think
    the attributes for which this notion applies should be annotated with
    the slash. Further, it may be useful to identify what population is
    being considered when using terms like "all requirements."

  • Reported: SysML 1.1 — Thu, 7 Aug 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    RelatedRequirement properties are actually derived since their values are calculated
    from existing relationships linking requirements with other kinds of model elements.
    The intent of such derived properties is to specify how some characteristics of
    interest can be queried from their owner. For instance a requirement can be property is to model that, given a specific requirement, it is possible to know the
    element linked to it through a <<satisfy>> relationship.
    Nevertheless, the way to retrieve the actual value of those derived property is
    currently specified in an informal manner only. This part of the specification can be
    improved by adding the corresponding OCL queries.
    Since many of those derived values require getting data across non navigable
    association end in the metamodel, the practical way to compute them is to browse all
    possible candidate instances and select those of interest. When OCL is used for that
    purpose we rely on the allInstances() operation that is predefined for each class. The
    Annexe A: “Semantics” of the OCL v2.3.1 specifies the scope to be considered:
    • “Object models provide information used as context for OCL expressions and
    constraints” (§A.1, p193)
    • Object models are defined as structures gathering a set of classes and for
    each of those classes sets of: attributes, operations, associations and
    generalizations (cf. §A.2.1, p193 and following pages)
    • A system state is defined as the snapshot of a system at a particular moment
    in time. Given an object model M (as defined above), a system state for that
    object model has a finite set of objects sCLASS with sCLASS(c) representing the
    subset of all objects of a given class c. Such a system provide the complete
    context for evaluating an OCL expression (except post and pre conditions, see
    §A.3.1.3, p201)
    • In such a context, the interpretation of the allInstances() called on a class c is
    specified to be equal to sCLASS(c) (cf. §A.4.4.2, p208)
    From a practical point of view, the object model on which a tool shall scope the
    evaluation of an OCL expression is the one resulting from loading the topmost
    UML::Model element that ultimately contains the context defined for that OCL
    expression.

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

11.4 Activity Usage Sample: ControlOperator has regular pins

  • Key: SYSML12-2
  • Legacy Issue Number: 12576
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Output pin of a control operator is not a control pin as shown in fig. 11.10. It should be a regular pin typed by ControlValue.

  • Reported: SysML 1.1 — Wed, 16 Jul 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Agreed, and the control flow in Monitor Traction should be a control pin.

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

Section: 11.3.1.1 Activity in bdd

  • Key: SYSML12-1
  • Legacy Issue Number: 12560
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The semantics of composition between activities refers to synchronous calls. What happens if the activity is called asynchronously? Is it possible to show that activity in the bdd, too? What is the relationship to the calling activity?

  • Reported: SysML 1.1 — Fri, 27 Jun 2008 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    Resolution:
    Asynchronous calls start a new execution of the called behavior, but there is
    usually no link between the new execution and the calling execution (the caller
    invokes, but after that doesn't communicate with the called behavior execution).
    If this is needed for some applications, the caller execution can instantiate the
    called activity as a class/block, and link the new instance (the new called
    execution) to the caller execution via an association. This association would be
    composite if the called execution is started synchronously, and non-composite if
    it is started asynchronously (using StartObjectBehaviorAction in both cases).
    This seems like too much detail of UML to cover in the SysML spec for an
    uncommon usage scenario. The filer agrees to close with no change.
    Disposition: Closed, no change

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

Flow properties on blocks typing internal parts

  • Key: SYSML13-42
  • Legacy Issue Number: 16280
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Issue 13178 prevents flow properties from being defined on blocks that type internal parts. Flow properties specify the kind of things that flow into and out of a block, regardless of how the block is used. In v1.2 they are related to receptions, which also do not restrict how the block owning the flow property is used. The constraint also causes an unnecessary difference between full ports and internal parts.

  • Reported: SysML 1.2 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Loosen the restriction that block owning flow properties cannot type internal
    parts.

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

Claify partWithPort vs. NestedConnectorEnd

  • Key: SYSML13-18
  • Legacy Issue Number: 16045
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Add a constraint to Section 8.3.2.5 NestedConnectorEnd that the stereotype is applied only to connector ends that violate Constraint [3] of Section 9.3.6 Connector in the UML Superstructure specification. Replace the existing Constraint [4] of 8.3.2.5 NestedConnectorEnd (that the partWithPort property must be must be equal to the property at the last position of the propertyPath list) with a constraint that partWithPort must be empty for any ConnectorEnd to which the stereotype is applied. Also, add clarifications to the SysML specification to make it explicit that SysML goes beyond extending UML entirely by UML stereotypes by also removing an existing constraint of the UML metamodel.

  • Reported: SysML 1.2 — Mon, 28 Feb 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove Constraint [4] of 8.3.2.5 NestedConnectorEnd so that partWithPort can
    continue to be set in accordance with constraints 1-4 of Section 9.3.7
    (ConnectorEnd) in the UML Superstructure specification.
    Also correct wording to refer to the connector end itself rather than the
    ConnectorEnd metaclass, as suggested by issues 15918 and 15984. Clarify the
    descriptive text under propertyPath stereotype property that contains a similar
    reference to the ConnectorEnd metaclass.
    A separate resolution for issue 12268, "not possible to take away constraints in a
    profile," removes text from Chapter 6 that incorrectly stated that SysML is
    specified entirely by UML 2 specification techniques. Constraint 5 under 8.3.2.2
    Block already makes clear that SysML removes an existing constraint of the UML
    metamodel.

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

Non-behavioral ports on behavioral ports

  • Key: SYSML13-41
  • Legacy Issue Number: 16265
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Issue 13178 added a constraint requiring ports of behavioral ports to be behavioral. This prevents nested proxy ports from being bound to internal parts.

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

    Remove the cited constraint

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

TriggerOnNestedPort refers to onPort instead of port

  • Key: SYSML13-40
  • Legacy Issue Number: 16255
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    TriggerOnNestedPort introduced by issue 13178 refers to UML's onPort property, but it's actually called port. It should constrain that property to have exactly one value.

  • Reported: SysML 1.2 — Wed, 18 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change references to UML Trigger’s onPort property to port, and constrain it to
    have exactly one value. Also address 16254 by extending the UML textual
    notation for onPort/port on InvocationAction and Trigger for nested ports.

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

Flow property compatibility rules should not be dependent on item flow

  • Key: SYSML13-26
  • Legacy Issue Number: 16215
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The flowFlow property compatibility rules introduced by issue 13178 assume item flow is present. They should be applicable when item flow is not present.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Update flow property compatibility rules to be independent of item flow

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

Clarify that item flow decomposition examples are not methodology

  • Key: SYSML13-25
  • Legacy Issue Number: 16214
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Clarify that item flow decompositions examples introduced by issue 13178 are not rules for item flow decomposition.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested and clarify in the title that the examples are about
    decomposition

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

NestedConnectorEnd propertyPath should be non-unique

  • Key: SYSML13-17
  • Legacy Issue Number: 16041
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The same property might appear more than once
    in the path.

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

    Blocks can have properties that are typed by the same block that owns them, or
    a specialization, so property paths can contain the same property multiple times.

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

partWithPort change from UML needs to be clearly stated

  • Key: SYSML13-16
  • Legacy Issue Number: 16008
  • Status: closed  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    From discussion within the MIWG (raised at Sandy's request).

    In UML 2.3 partWithPort is clearly only valid for a connector connected to a Port. SysML appears to expect this to be used when a connector is connected to any nested Property. This breaks the UML constraint and needs to be stated clearly in the SysML specification.

  • Reported: SysML 1.2 — Fri, 4 Feb 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This issue overlaps with issue 16045, which was raised in response to the
    same MIWG discussions. SysML NestedConnectorEnd does apply to any nested
    property, but the resolution for 16045 removes the specific SysML constraint that
    conflicts with UML constraints for partWithPort. SysML nested connector ends
    and partWithPort, under all its UML constraints, can both be present and be
    given values for nested connector ends that satisfy both their conditions.
    Disposition: See issue 16045 for disposition

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

Missing cross references in Deprecated Elements Annex

  • Key: SYSML13-23
  • Legacy Issue Number: 16212
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The annex added for deprecated elements by issue 13178 has cross referencing errors. It should also be marked as informative.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested, and clarify step cross references

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

Deprecated elements package

  • Key: SYSML13-22
  • Legacy Issue Number: 16211
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Elements deprecated in issue 13178 should have a package in the language architecture and be noted in the compliance chapter.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Add deprecated elements package to SysML profile. Do not require it for
    compliance.

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

NestedConnectorEnd constraints

  • Key: SYSML13-15
  • Legacy Issue Number: 15984
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Blocks, NestedConnectorEnd, Constraints 3 and 4, replace all occurrences of "ConnectorEnd metaclass" with "connector end".

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

    This is an exact duplicate of issue 15918. The wording changes suggested by
    both 15918 and 15984 are included in the resolution for issue 16045, which also
    removes the existing Constraint 4.
    Disposition: See issue 16045 for disposition

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

NestedConnectorEnd constraints refer to metaclass

  • Key: SYSML13-14
  • Legacy Issue Number: 15918
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Blocks, NestedConnectorEnd, Constraints 3
    and 4, replace all occurrences of "ConnectorEnd
    metaclass" with "connector end".

  • Reported: SysML 1.2 — Fri, 7 Jan 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This is an exact duplicate of issue 15984. The wording changes suggested by
    both 15918 and 15984 are included in the resolution for issue 16045, which also
    removes the existing Constraint 4.
    Disposition: See issue 16045 for disposition

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

Water association decomposition example should be in ports

  • Key: SYSML13-24
  • Legacy Issue Number: 16213
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue 13178 updated the Water association decomposition example in the blocks chapter to use ports. It should be in the ports chapter.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Move the water association decomposition to the ports chapter, with a forward
    reference from the blocks chapter.

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

Remove colons from item flow classifiers in decomposition examples

  • Key: SYSML13-27
  • Legacy Issue Number: 16216
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Remove colons from item flow classifiers in item flow decompositions examples introduced by issue 13178. Colons are for item properties, not item flow classifiers.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revised as suggested, and include all blocks in the block definition diagrams

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

typo in diagram C. 15

  • Key: SYSML13-21
  • Legacy Issue Number: 16114
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I think there is a typo error in the diagram C.15. The stereotype <<normal>> should be shown on the property force of the class Canon.

  • Reported: SysML 1.2 — Thu, 31 Mar 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Insert the missing «normal» keyword into the diagram.

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

Notation for multiple item flows

  • Key: SYSML12-24
  • Legacy Issue Number: 13945
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Notation for multiple item flows. The UML specification provides a compact notation for multiple information items flowing in the same direction. A similar notation should be provided in SysML, but this is not explicitly called out. Recommendattion. Add a sentence at the end of section 9.3.1.4 which describes diagram extensions for item flows consistent with the UML approach that reads "When several item flows having the same direction are represented, only one triangle is shown, and the list of item flows, separated by a comma is presented." Also, include the multiple item flow notation in the Item Flow entry in Table 9.1.

  • Reported: SysML 1.1 — Mon, 1 Jun 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Accept proposed resolution with text that describes diagram extensions for
    multiple item flows consistent with the UML approach, and with some additional
    constraints on ItemFlow. Note that an item flow can have only one conveyed
    classifier. A future revision should consider a constraint that “An ItemFlow must
    have a single item property” since the item flow and item property should be
    viewed as a single concept in SysML

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

Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct

  • Key: SYSML12-23
  • Legacy Issue Number: 13928
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype <<partition> with the model elements enclosed, or it could leverage the SysML callout notation as an example.

  • Reported: SysML 1.1 — Sat, 9 May 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    It is convenient to be able to group model elements based on modeler-defined
    criteria. Simple examples are groups of elements that may be associated with a
    particular release, or with a legacy design. Unfortunately, there is no metaclass in
    UML that supports such a concept of collection. The word “group” is preferred to
    “partition” in the resolution since the concept of partition would suggest that
    participations in those groups are mutually exclusive while this limitation is not
    desirable.
    UML packages are a means to organize model elements. They have the convenient
    semantics except that they imply ownership, whereas it is requested to have no
    limitation on the number of groups an element can belong to. Instead, this proposal
    extends the UML::Comment metaclass for that purpose. The provided mechanism is
    intended to specify groups of model artifacts and should not be extrapolated for
    representing groups of runtime elements.
    A Comment may be owned by any kind of element and has no semantic side-effect.
    It can designate grouped elements using its annotatedElement association, and the
    criterion applicable to any element of the group can be defined via its body property. Annotated elements are not owned by the Comment. Thus, built on a
    UML::Comment, an ElementGroup does not own its members. There is no limitation
    on the number of Comments that can annotate a given element. Thus, any element
    can participate in an unlimited number of groups.
    Adding an element to a group does not modify it. Then, an element cannot hold any
    information about the groups it is member of. Instead a static query
    allGroups(e:Element) is provided for that purpose. It returns the set of
    ElementGroups a given element is member of.
    Note that a group may have some groups among its elements (annotated elements
    may be any kind of element, including UML::Comment).
    The members of an ElementGroup may optionally be ordered.
    The resolution to issue #18653 provides through the concepts of “View and
    Viewpoint” the means to compute collections of element as the result of an arbitrary
    query applied to a model or to a part of a model. An element group is distinct from
    view and viewpoint in that a) element groups provide a means to create persistent
    collections of elements, and b) membership of an ElementGroup is asserted rather
    than computed. The ElementGroup::member property is derived from the collection
    of annotated element. The way this property is derived cannot be modified by the
    modeler. Thus, View/Viewpoints and ElementGroup are disjoint concepts. However,
    View/Viewpoints can leverage ElementGroup for constructing views.
    Since an element group is expected to have a name, and the proposed base class
    (i.e., comment) is not a named element, an ElementGroup::name property is added
    to the ElementGroup stereotype.

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

Example figures in chapters are redundant with Annex B sample problem

  • Key: SYSML12-25
  • Legacy Issue Number: 13976
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    Example figures in chapters are redundant with Annex B sample problem. This creates document maintenance issues. Figures 7.3, 8.11, 9.5, 9.6, 10.2, 10.3, 12.1, 12.2, 12.3, 13.1, 14.1, 14.2, 15.9, and 15.10 are all duplicated in Annex B. It is recommended that these diagrams are removed from chapters in part II and IV of the spec, and instead specifically reference the appropriate diagrams out of Annex B, thus making the specification easier to maintain.

  • Reported: SysML 1.1 — Wed, 10 Jun 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Delete redundant figures, but leave captions to act as notes referencing figures in
    Appendix B. This conveniently avoids extensive changes to the body text.

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

SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s)

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

    The SysML specification does not define the correct namespace URI for the standard profile(s) - it should.

  • Reported: SysML 1.1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A

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

    UML 2.1 added a new structural diagram type, Profile Diagram for the purposes of containing the profile-defining elements. SysML either should be made consistent or should explicitly indicate that the diagram is not part of SysML

  • Reported: SysML 1.1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The Profile Diagram was proposed as a new SysML diagram since it was added
    to UML to support profile definitions. However, the Superstructure Specification,
    Table 18.1 and Table 18.2, does not require that profiles be defined on a profile
    diagram. The diagram elements needed to specify a profile can be represented
    on any structure diagram. As a result, it is recommended not to add a profile
    diagram in SysML to limit the number of diagram kinds, and that profile
    definitions be represented on package diagrams.
    The following text was originally proposed as part of the resolution for this issue,
    but did not fit as part of the scope of Annex A. It could be considered as part of a
    future revision of SysML, for example as part of Chapter 17, Profiles and Model
    Diagrams:
    ... extra caution is warranted regarding the intent of a profile diagram as
    explained below. ...
    As far as UML is concerned, a profile can extend the UML metamodel
    instead of the UML4SysML subset of UML metamodel. However, a profile
    extending the UML may not be compatible with the SysML profile that
    extends the UML4SysML subset of the UML. For example, a stereotype
    called <<AssociationWithNavigableEnds>> extending UML::Association
    with a constraint to the effect that the association ends are navigable and
    also owned directly by the association would clearly be incompatible with
    the <<Block>> stereotype of SysML per 8.3.2.2. For such cases where the
    user intent is clearly in extending the UML4SysML subset of the UML in a
    manner that is compatible with the SysML stereotypes and their
    constraints, it is important that a SysML tool provides support for
    distinguishing user-defined profiles extending the UML metamodels and user-defined profiles extending the UML4SysML subset of the UML in a
    manner that is compatible with respect to the SysML stereotypes and their
    constraints.
    Revised Text:
    On p. 171, Annex A.1, change the third paragraph, currently:
    SysML does not use all of the UML diagram types such as the object
    diagram, communication diagram, interaction overview diagram, timing
    diagram, and deployment diagram. This is consistent with the approach
    that SysML represents a subset of UML. In the case of deployment
    diagrams, the deployment of software to hardware can be represented in
    the SysML internal block diagram. In the case of interaction overview and
    communication diagrams, it was felt that the SysML behavior diagrams
    provided adequate coverage for representing behavior without the need to
    include these diagram types. Two new diagram types have been added to
    SysML including the requirement diagram and the parametric diagram.
    with the following:
    SysML does not use all of the UML diagram types such as the object
    diagram, communication diagram, interaction overview diagram, timing
    diagram, deployment diagram, and profile diagram. This is consistent with
    the approach that SysML represents a subset of UML. In the case of
    deployment diagrams, the deployment of software to hardware can be
    represented in the SysML internal block diagram. In the case of interaction
    overview and communication diagrams, it was felt that the SysML
    behavior diagrams provided adequate coverage for representing behavior
    without the need to include these diagram types. In the case of the profile
    diagram, profile definitions can be captured on a package diagram, which
    is also allowed in SysML. Two new diagram types have been added to
    SysML including the requirement diagram and the parametric diagram.

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

Using composite association between activities

  • Key: SYSML12-22
  • Legacy Issue Number: 13924
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Using composite association between activities. The actual nature of the properties corresponding to the association end is not clear. Either it is a CallBahaviorAction and then it is not an instance of associated activity, or it is an activity execution and then the association should be derived beacause it depends on the CallBehaviorActions owned by the activity. Proposed resolution: State that composite associations between activities are always derived from the CallBehaviorAction owned by the activity.

  • Reported: SysML 1.1 — Thu, 7 May 2009 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    Resolution:
    When an Activity property corresponds to a CallBehaviorAction of another
    Activity, the value at “runtime” is an instance of the called activity (it can’t be an
    instance of the CallBehaviorAction, since Actions are not Classifiers). This value
    is not derived from anything else, it’s a new instance of the activity, a new
    execution (associations themselves are not derived, only their instances/links).
    This information is in the section on CallBehaviorAction. At the time the section
    on CallBehaviorAction was written, it was decided not to require a one-to-one
    correspondence between property names and CallBehaviorActions, even though
    that would typically be true.
    Comment from filer:
    Except if i miss something, the only way to create an instance of an
    activity from another activity is to execute an invocation action. That is: an
    activity execution won't instanciate any other activity if it doesn't own the
    corresponding invocation action, and conversely any execution of an
    CallBehaviorAction will instantiate the corresponding behavior. Then, for a
    given Activity, owned invocation action (e.g. CallBehaviorAction) and
    activity instance owned by composition are actually not independent. If no
    constraint is defined between these two properties the activity definition
    can be inconsistent. That's why I suggest that composite associations
    between activities should be derived. The two composition associations
    you describe above are at different metalevels. The link between Activity
    and CallBehaviorAction is specified by an M2 (metamodel) association
    and the link itself exists at M1 (user model). The link between Activity and Activity (due to invocation) is specified at M1 and
    the link itself exists at M0 (runtime). The constraints between these two
    associations is semantics, in the mathmatical sense, and is described in
    UML/SysML in natural language (see Executable UML for a mathematical
    specification of semantics). The constraints in the UML/SysML spec in the
    Constraints sections are syntactic, that is, between M2 and M1.
    Disposition: ClosedNoChange

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

Chapter 7.3.1.1 Update comment stereotype diagram extension

  • Key: SYSML12-21
  • Legacy Issue Number: 13854
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML 2.2 defines a presentation option for stereotypes for comments. There is no need to repeat that option in SysML. There is no need for a tool vendor to support a UML presentation option to be compliant with the specification. Since SysML depends on the presentation option the chapter 7.3.1.1 should be updated to state that the presentation option is required.

  • Reported: SysML 1.1 — Sun, 5 Apr 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    UML 2.2 defines the presentation option for stereotypes for comments. SysML
    also defines it as a diagram extension, because it wasn’t mentioned in UML 2.1
    which is the basis for SysML 1.1. Due to the update of UML there is no longer a
    need to keep the diagram extension in SysML.
    It is not necessary to explicitly mention that the presentation option isn’t optional
    in SysML. The notation of the affected model elements rationale and problem is
    clearly defined in table 7.1.

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

SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2)

  • Key: SYSML12-32
  • Legacy Issue Number: 14079
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Summary:

    This issue is a complement to issue #12576 that deal only with the output pin.
    A control operator should have a regular input pin typed by ControlValue in fig. 11.10.

  • Reported: SysML 1.1 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Control operators typically output control values to affect other actions, based on
    inputs that are not control values. In Figure 11.10, the input is Brake Pressure, which
    the control operator uses to determine whether the enable to disable Monitor
    Traction.
    Disposition: Closed, no change

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

UML4SysML: Architecture & Compliance with UML subset

  • Key: SYSML12-31
  • Legacy Issue Number: 14056
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The compliance levels defined for UML 2.1.1 and UML 2.2 merge UML::CommonBehaviors::Communications at L1 instead of at L2 in SysML 1.1 as specified in table 5.2 (Metamodel packages added in Level 2). With UML::CommonBehaviors::Communications at L2, it is not possible to properly define UML::Actions::BasicActions at L1 because UML::Actions::BasicActions::SendSignalAction::signal : UML::CommonBehaviors::Communications::Signal [1] becomes ill-formed at L1.
    The UML::CommonBehaviors::Communications package is also absent from table 4.1 (Detail of UML Reuse) in SysML 1.1, clause 4.2 (Architecture).

  • Reported: SysML 1.1 — Sat, 4 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Update clauses 4.2 (Architecture) and 5.1 (Compliance with UML subset) to
    reflect merging UML::CommonBehaviors::Communications at SysML’s L1.
    It is not clear what is the purpose of Figure 4.2 as it shows a combination of L2
    and L3 content from Table 5.2 and 5.3.

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

Participant Property constraint #6 not correct.

  • Key: SYSML12-19
  • Legacy Issue Number: 13666
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Participant Property constraint #6 not correct. In Blocks, UML Extensions, Stereotypes, Participant Property, remove constraint 6 (the one resrtricting the upper multiplicity of the end property). End properties of associations can have any multiplicity. See example in Figures 8.13 and 8.14, where the deliveredTo end of a participant property has multiplicity 1..*.

  • Reported: SysML 1.1 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The constraint is misstated. The ParticipantProperty is a property of the
    association block, and it is this property to which the multiplicity constraint should
    apply. Each link of the association block has a value of the participant property
    which refers to one instance contained in the referenced end of the association.

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

Fig. 11.10: Pin of ControlOperator

  • Key: SYSML12-18
  • Legacy Issue Number: 13503
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The outpin of the control operator in fig. 11.10 is a control pin. But pins of control operators must be normal pins. The action Monitor Traction has no input pin.

  • Reported: SysML 1.1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.2
  • Disposition Summary:

    Resolution:
    This is a duplicate of 12576.
    Disposition: See issue 12576 for disposition

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

Representing multiple item flows on the same connector

  • Key: SYSML12-27
  • Legacy Issue Number: 14033
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Representing multiple item flows on the same connector. The specification should clarify the notation for representing multiple item flows with the same direction on a connector. In particular, UML allows for multiple information items to be represented with a single triangle, along with the list of the information item names spearated by a comma (refer to Figure 17.6 of the Superstructure Spec). A similar notation should be provided to represent multiple items flows in SysML. Proposal resolution: Recommend adding the following sentence at the end of section 9.3.1.4. " When several item flows having the same direction are represented, one triangle can be shown, along with the list of item flows separated by a comma." Also, add a constraint to 9.3.1.4 as follows" 1. If the ItemFlow has an itemProperty, there must be one conveyed classifier which matches the type of the item property.

  • Reported: SysML 1.1 — Sun, 28 Jun 2009 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.2
  • Disposition Summary:

    Disposition: See issue 13945 for disposition

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

The information in Annex D regarding AP233 needs to be updated

  • Key: SYSML12-26
  • Legacy Issue Number: 14032
  • Status: closed  
  • Source: NIST ( Ms. Allison Barnard Feeney)
  • Summary:

    Out of Date Annex D.4: The information in Annex D regarding AP233 needs to be updated. AP233 to be released as DIS and this section needs to be revised to reflect changes to AP233.

  • Reported: SysML 1.1 — Fri, 26 Jun 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    see ptc/2009-08-13 for details

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

Connector Property value text.

  • Key: SYSML12-20
  • Legacy Issue Number: 13667
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Connector Property value text. In Blocks, UML Extensions, Stereotypes, Connector Property, Description, first paragraph, last sentence, the current text implies all instances of association blocks will be values of the connector property. The value is actually the subset of those due to the connector. Suggestion: - remove "exactly those" - replace "that are instances" with "(instances)".

  • Reported: SysML 1.1 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Simplify the wording of this sentence further to refer directly to instances of the
    association block. Association blocks are blocks with regular instances, not
    merely links. Links cannot ordinarily be referenced by properties of a class, but
    because association classes in UML specialize both Association and Class, they
    can be referenced like all other class instances. Also modify the wording “that
    exist due to instantiation of the block” to allow creation as part of a block at any
    time during its lifetime, not merely at the time of instantiation.

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

SysML Issues based on UML 13080 New proposal for conjugate types for port

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

    The UML rtf’s response to this issue was to add an “isConjugated:Boolean” to the Port definition. This renders superfluous the SysML addition of the conjugated flag on flow ports. The SysML flag needs to be removed. In addition, the notation has changed to use a ~

  • Reported: SysML 1.1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    1. Remove isConjugated:Boolean from SysML since it is not needed anymore.
    2. Deprecate (but still maintain for backward compatibility) the current notation
    of conjugated flow ports and add the same notation as the new UML
    suggests.

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

SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit

  • Key: SYSML14-22
  • Legacy Issue Number: 18269
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind.

    There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK.
    Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself.
    This notation could suggest that one could change the tag/values shown on the value property itself.

    It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself.
    This tool-specific practice in fact suggests that there is a missing capability; that is:

    QUDV unit and quantityKind could be specified on
    the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them)
    The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind)
    A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property)
    However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit.
    Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property.
    This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType)

    Suggest the following:

    Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind
    Add a new stereotype: ValueProperty extending UML::Property with:
    ValueProperty::unit : QUDV::Unit[0..1]
    ValueProperty::/effectiveUnit : QUDV::Unit[0..1] – it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type
    ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] – it is derived from the ValueType::quantityKind of the type of the ValueProperty.
    Add a new stereotype: QuantityValue extending UML::ValueSpecification with:
    QuantityValue::unit : QUDV::Unit[0..1]
    QuantityValue::/unitConstraint : QUDV::Unit[0..1] – if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit
    Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue

  • Reported: SysML 1.3 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution addresses the issue of the duplication of the concepts of Unit and
    QuantityKind between the SysML profile and the QUDV library by introducing a new,
    3rd model library called UnitAndQuantityKind. A separate resolution will address the
    issue of the notation for ValueType, including TypedElements (e.g. Property,
    ValueSpecification) typed by a ValueType.
    Since the SysML Architecture figures 4.2 and 4.3 need to be updated to reflect the
    addition of a new model library, this resolution also addresses the inaccuracies
    reported in issue 18456 where these figures only showed one of the 2 model
    libraries, PrimitiveValueTypes, omitting the 2nd library, ControlValues. Also, part of
    18456 involves showing the <<ModelLibrary>> stereotypes that should have been
    applied to each of SysML’s model libraries. As indicated in SysML 1.3, section 17.2,
    a SysML Model Library is a UML Package with the UML
    StandardProfileL2::ModelLibrary stereotype applied. Due to tool limitations, the BDD
    diagrams for the 2 SysML model libraries in this resolution show the UML notation for
    StandardProfileL2::ModelLibrary, that is <<ModelLibrary>> rather than the SysMLspecific
    notation which would be <<modelLibrary>> or “bdd [modelLibrary]” in the
    diagram frame. These notation details may change editorially without affecting the
    substance of the resolution.
    Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of
    Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the
    new ISO 80000-1 standard and a new conceptual model of Quantities, Units,
    Dimensions and Values (QUDV) was introduced only in the document as Annex C.5.
    The specification-level duplication became a practical problem in SysML 1.3 where
    the QUDV conceptual model became available as a non-normative machinereadable
    XMI artifact. With SysML 1.3, users and tool vendors have several options
    for modeling definitions of Units and QuantityKinds:

    • use the normative SysML stereotypes from the Blocks chapter
    • use the non-normative QUDV libraries from Annex D.4
    • use both in combination (e.g., apply the <<Unit>> stereotype to
      InstanceSpecifications classified by QUDV::Unit)
      These options multiply the cost of developing and maintaining libraries of Unit and
      QuantityKind definitions. The 3 different options above apply for defining a Unit or a
      QuantityKind. This means that there are 9 different options for defining the same pair
      of Unit/QuantityKind. Within the International System of Units alone, there are 20
      decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has
      14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table
      5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of
      Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed
      units and quantity kinds. It would be counter-productive and prohibitively expensive
      to attempt supporting nearly 10x different options of defining the same 1,260 pairs for
      just ISO 80000-1. SysML needs to adopt one option. Which one?
      Since the SysML Unit and QuantityKind stereotype provide a strict subset of the
      functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively
      replaces the SysML::Blocks:: {Unit,QuantityKind} stereotypes with their QUDV Block
      counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being
      a Class stereotyped by SysML’s Block. Similarly, SysML::Blocks::QuantityKind
      changes from being a Stereotype to being a Class stereotyped by SysML’s Block.
      Having changed the nature of Unit and QuantityKind from a Stereotype to a Class
      means that Unit and QuantityKind are M1-level classes, not M2-level stereotype
      extensions of metaclasses, it is important to clarify how the new Class-based Unit
      and QuantityKind concepts are intended to be used for defining particular Units and
      QuantityKinds.
      In principle, there are three ways to define Units and QuantityKinds:
      1. as M1-level InstanceSpecifications classified by
      SysML::Blocks::{Unit,QuantityKind}

      2. as M1-level Classes specializing SysML::Blocks::

      {Unit,QuantityKind}

      3. as M1-level Classes that are instances of M2-level metaclasses Unit and
      QuantityKind The third approach is outside the scope of the nature of SysML as a profile (a profile
      cannot define new metaclasses).
      The second approach requires fairly sophisticated tool support for specializing the
      associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind.
      Modeling association specialization is a challenging topic in UML because the
      mechanisms involved (i.e., generalization, redefinition, subsetting) have subtle
      distinctions (e.g., subsetting and redefinition are, respectively, in the domain of
      extensional vs. intentional semantics respectively) and the consequences of their
      combinations are difficult to analyze (e.g., disjoint vs. overlapping specialization).
      These modeling challenge carry over to definitions of new ValueTypes where the
      associations between ValueType and Unit/QuantityKind have to be specialized as
      well. The specialization approach is particularly challenging to understand because it
      inherently leads to asking questions about the meaning of the class-based
      specializations of Unit/QuantityKind and about the existence and meaning of
      instances of these classes.
      The first approach based on InstanceSpecifications approach avoids the complexity
      of the Class-based specialization of the 2nd approach. However, this
      InstanceSpecification-based approach requires careful attention about the UML tool
      support for modeling link instances of associations. In particular, such links must be
      fully specified with slots for each association’s end property regardless of its
      ownership by the association or classifier typing the opposite end. This tool support is
      important for the unambiguous interpretation of an InstanceSpecification classified by
      an Association as a representation of an instance of that Association between the
      InstanceSpecifications interepreted as representations of instances of the related
      Classifiers typing the ends of that Association.
      This resolution adopts the first approach, i.e., the M1-level InstanceSpecification
      based paradigm for defining Units and QuantityKinds. To maintain the separation
      between the normative SysML profile and the non-normative QUDV conceptual
      model, this resolution splits the QUDV::Unit and QuantityKind in two parts:

    • the part corresponding to the SysML 1.3 Unit/QuantityKind stereotypes that
      will be refactored into Block definitions in a new UnitAndQuantityKind model
      library
    • the rest that is unique to QUDV and that will be refactored as a specialization
      of the corresponding blocks from the UnitAndQuantityKind model library
      Because this resolution effectively promotes the QUDV concepts of Unit and
      QuantityKind into the normative SysML profile, the normative specification of these
      concepts is aligned to the publicly available VIM3 document instead of the non-public
      ISO-80000-1 document.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

N-ary Allocation needs better definition, or deletion

  • Key: SYSML14-21
  • Legacy Issue Number: 17562
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    An unnumbered constraint on the Allocate relationship states: "A single «allocate» dependency shall have only one client (from), but may have one or many suppliers (to)."

    The use or meaning of this n-ary relationship is not described. An informal survey of RTF members indicated that this n-ary allocation capability has not been implemented in any tool, nor has it been used by practitioners.

    Note that Satisfy relationship (see 16.3.2.6) serves a similar purpose to Allocate, but does not require an n-ary implementation.

    Removal of the n-ary requirement on Allocate would simplify efforts to unify SysML relationship dependencies. This requirement should either be 1) rationalized, elaborated and applied consistently across similar SysML relationships, or 2) deleted to facilitate ongoing SysML improvements.

  • Reported: SysML 1.3 — Thu, 23 Aug 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    To simplify SysML, the 1.4 RTF resolved to remove n-ary allocations from the
    specification. The functionality that might be enabled by n-ary allocations can be
    supported by constraints across multiple binary allocations.

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

9.3.2.8 FullPort

  • Key: SYSML14-10
  • Legacy Issue Number: 17254
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.8 FullPort - in description it says it cannot be conjugated. 1. Why? 2. Why there is no constraint for that?
    what constraint 2 means? when binding connector is connector to proxy port?

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    See Issue 18278 (Conjugation of full ports question) for the answer to the question
    about full port conjugation.
    The reason for constraint 2 is that if we have a binding connector between a full port
    and a part of the owning block that is not a port, it means the full port is no longer a
    separate element of the system. Fulls ports bound to proxy ports are still separate
    elements of the system because proxy ports do not specify separate elements of the
    system. Constraint 2 should be generalized to cover all cases.

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

9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???

  • Key: SYSML14-9
  • Legacy Issue Number: 17253
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all?
    constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???
    what does it mean "the meaning of direction"?? how direction is visible on port? what happens on nested ports when owning port is conjugated? example is needed.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The text of this issue was split into issues 18438, 18439, and 18441 so that the
    multiple issues raised could be addressed in separate resolutions. All the text in this
    issue is contained in one of these newer issues, so this original source issue is no
    longer needed.
    Disposition: See issues 18438, 18439, and 18441 for resolution

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

ControlOperator stereotype should also extend the CallBehaviorAction metaclass

  • Key: SYSML14-20
  • Legacy Issue Number: 17549
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    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). However, the metamodel fragment on pg. 104 and the stereotype description on pg. 105 do not support that. Currently the spec. states that SysML::ControlOperator only extends UML4SysML::Behavior and UML4SysML::Operation, not UML4SysML::CallBehaviorAction. This would be appropriate, though, and seems to be in keeping with the original intent of the SysML Development Team given that it appears in Table 11.1

    Proposed Resolution: Add another extension relationship from SysML::ControlOperator to UML4SysML::CallBehaviorAction.

  • Reported: SysML 1.3 — Fri, 10 Aug 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    This diagram extension is illustrated in Figure 11.2 (CallBehaviorAction notation) and
    explained in the text above it. The metamodel is not extended.
    Disposition: Closed, no change

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

Requirements should be disallowed from typing other elements

  • Key: SYSML14-19
  • Legacy Issue Number: 17529
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The concept of Requirement, as intended in the original SysML specification, included the notion that textual requirements only have meaning in their original context. Requirements thus should not provide a source of inheritance. This precludes their use as classifiers for typing other Requirements or any other model elements. The 5 constraints listed at the end of section 16.3.2.3 are currently insufficient to enforce this concept.

    Recommend adding a 6th constraint, precluding a class stereotyped by <<requirement>> from typing any other model element.

  • Reported: SysML 1.3 — Thu, 26 Jul 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Add a 6th constraint to the text as recommended in the summary.

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

SysML Issue Lower bounds on multiplicity not consistent with diagram

  • Key: SYSML14-16
  • Legacy Issue Number: 17443
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In SysML 1.3

    11.3.1.1 Activity constraints

    “The lower multiplicity at the part end must be zero.”

    The diagram above Figure 11.1 on the previous page does not indicate 0 as the lower end. The default for a composition relationship at the part end is 1..1 and does not include 0.

    However, as you fix the diagram consider eliminating the constraint 3.

    I believe this constraint has been eliminated from UML 2.5 (in the works). The proper constraint is something like. (Conrad will know what’s in the UML spec). If the part end action starts running when the parent activity is started, and continues until the parent activity is ended, then the minimum multiplicity is non-zero. Otherwise, the lower multiplicity at the part end must be zero.

    Whether the constraint is fixed or not, the diagram must include a lower end of zero.

    Recommended fix, eliminate the constraint and fix the diagram

    11.3.1.4.1 Constraint 3

    Similar to above. The BDD in Figure 11.5 would need to explicitly be marked to allow for 0.

    This constraint was not changed in UML. Recommend the diagram be fixed

  • Reported: SysML 1.3 — Mon, 18 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Remove Constraint [3] in 11.3.1.1.1 (Notation) for the reasons filed. Figures 11.1 and
    11.5 show generic notation. They aren’t examples, so do not need to have
    multiplicities.

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

SysML Issue: State Machine Notation

  • Key: SYSML14-18
  • Legacy Issue Number: 17445
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    13.1 Table 13.1

    The state machine decomposition symbol (which looks like eyeglass – not a rake) is not given

    13.2 Table 13.2

    The notation that comes from transition-focused state machines is included in the table. However, the notion that looks like:

    (via entry point name)

    is not indicated.

  • Reported: SysML 1.3 — Mon, 18 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Supply identified missing notation in table 13.1 and table 13.2 In addition, supply
    missing notation for StateMachineDiagram and cleanup composite state notation in
    table 13.1 (so that lines leave on axis).

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

SysML Issue: SysML Issue: Activitiy Switched on diagrams

  • Key: SYSML14-17
  • Legacy Issue Number: 17444
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In SysML 1.3 C.4.8.2

    Diagram C.34

    The «activity» ProvideElectricPower is switched with «activity»ControlElectricPower. If you switch them now, you’ll be consistent with Figure C.35

  • Reported: SysML 1.3 — Mon, 18 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Switch the two activities names and association end names.

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

Wrong compartment names

  • Key: SYSML14-15
  • Legacy Issue Number: 17372
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Compartments "part" and "reference" must be renamed to "parts" and "references" in Figure 9.7 Usage example of proxy and full ports

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

    Discussion:
    Figure 9.7 in the formal SysML 1.3 specification was already corrected to use the
    standard compartment names.
    Disposition: Closed, No Change

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

Full ports compartment

  • Key: SYSML14-14
  • Legacy Issue Number: 17371
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Spec says: "Full ports can appear in block compartments labeled “full ports.” The keyword «full» before a property name indicates the property is stereotyped by FullPort. "
    a) "full ports." should be changed to "full ports". (without dot inside)
    b) does it say that even in full ports compartment keyword <<full>> is used? Or it is used near port symbol, when NOT in compartment? It should be clarified.
    c) there is no single example of this notation - nor in Table 9.1 - Graphical nodes defined in Block Definition diagrams nor in any other diagram example in spec.
    d) the same issues with "proxy ports" compartment.

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

    No Data Available

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

Conjugation of full ports question

  • Key: SYSML14-23
  • Legacy Issue Number: 18278
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Clause 9.3.2.8, FullPort - in description it says it cannot be conjugated. 1. Why?

    This issue is a portion of issue 17254 (9.3.2.8 FullPort) and is filed to allow it to be addressed separately from the rest of 17254, and for the resolution of 17254 to ignore this portion of issue

  • Reported: SysML 1.3 — Fri, 23 Nov 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The reason for constraining the full port from being conjugated is mentioned in
    9.3.2.8 – first paragraph last sentence:
    Full ports also cannot be conjugated, because behaviors defined on their
    types are defined independently of the ports these types might be used on.
    Constraint [4] reflects this (“Full ports cannot be conjugated (isConjugated=false).”).
    The wording of the text above could be improved.

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

Figure 9.8 - can roles be ports??

  • Key: SYSML14-13
  • Legacy Issue Number: 17258
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Figure 9.8 - can roles be ports?? or ports be association ends???? Is it new SysML notation? Where it is described??? Did we voted?
    Tools does not support that.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    No Data Available

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

Figure 9.7

  • Key: SYSML14-12
  • Legacy Issue Number: 17257
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    reference properties "sp" in all subtypes must redefine "sp" from block P.
    also, p1, p2, p3 in Plug Design 1 - are they redefining or not? if yes, must be

    {redefines}

    used, if not, how <<proxy>> appears there?

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Add the suggested redefinition notations

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

9.3.2.10 InvocationOnNestedPortAction

  • Key: SYSML14-11
  • Legacy Issue Number: 17256
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Constraint [2] is incorrect. What does it mean "owned by the target object" ?what is object? Also, target is always the context of activity. Port can be not only owned, but inherited too.
    [3] incorrect too - it can be inherited, not owned only.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Revise the text as indicated

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

Part 1 of the specification

  • Key: SYSML14-4
  • Legacy Issue Number: 17246
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Part 1, there is a paragraph that says, in the context of describing the origins of SysML

    Currently it is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers.

    This is not currently correct. It should be changed to.

    It was then common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML has started to unify the diverse modeling languages currently used by systems engineers.

  • Reported: SysML 1.3 — Mon, 19 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    In SysML 1.3, the time-relative reference of "Currently" in the first sentence was
    removed as an editorial change, so that this sentence now begins simply, "It is
    common practice ..." The sentence that follows, stating that SysML is intended to
    unify diverse modeling languages, in a manner similar to UML, does not accurately
    reflect the variety of ways that SysML can help integrate languages in a Model Based
    Systems Engineering environment. The recently completed SysML-Modelica
    Transformation Specification is an example of the use of SysML to provide a systems
    engineering context for the content expressed by another language, but not to unify
    the full content of such a language.
    Change the text of this paragraph to indicate that the goals of SysML are both to
    unify languages used by systems engineers and to support a wider range of
    discipline- and domain-specific languages.

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

Issues with XMI for SysML 1.3

  • Key: SYSML14-3
  • Legacy Issue Number: 17161
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I am working through some examples for MEF as you suggested.

    When I look at the XMI for SysML 1.3, I find the following anomalies:

    1. The model library PrimitiveValueTypes is a Package owned by the SysML Profile. This is what the XMI says but it is not shown as such in figure 4.3 in the SysML specification.

    2. The PrimitiveValueTypes Package does have the SysML profile applied to it, but it does not have any stereotypes applied to the various DataTypes. Surely there should be elements of the following form in there:

    <sysml:ValueType xmi:id="Stereotype1" base_DataType="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-Real" />

    In order for such elements to be legal, the sysml xmlns needs to be declared. Also it’s somewhat unclear to me whether those elements should be children of the outer XMI element, or of the contained SysML package element.

  • Reported: SysML 1.3 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    These issues were raised on a draft version of proposed XMI for SysML 1.3. They
    were already resolved in the final, published version of SysML 1.3 XMI.
    Disposition: Closed, no change

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

Constraint Blocks cannot have parameters

  • Key: SYSML14-1
  • Legacy Issue Number: 16594
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in others it says they do not need to be. I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If not, how are constraint parameters represented?

    Specifically (in the beta2, inherited from 1.2):

    • Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock."
    • Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties.
    • Section 10.3.2.1 (ConstraintBlock):

    Constraints Compartment subsection, says "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks"

    Constraints, "[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, ..."

  • Reported: SysML 1.3 — Thu, 13 Oct 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    The removal of the ConstraintProperty stereotype by the resolution for Issue 12130
    eliminates one of the references raised by this issue. As noted by the issue,
    properties of a constraint block may be either constraint parameters or constraint properties that hold nested usages of constraint blocks. The remaining language is
    consistent with these two basic categories for the properties of a constraint block.
    Disposition: See issue 12130 for disposition

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

Addition of derived property notation

  • Key: SYSML14-2
  • Legacy Issue Number: 17120
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The derived property notation was originally included in SysML and removed. This notation is very helpful and should be restored. An example of how this is used can be found in Figure 7.2.1 of the 2nd edition of "A Practical Guide to SysML".

  • Reported: SysML 1.3 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Several notations on features of blocks were left out of the original SysML
    submission and addressed by subsequent issues. During the original SysML FTF,
    Issue 10381 listed several of these additional notations to be considered. Following is
    the original text of this issue originally received October 3, 2006:
    Include examples of additional feature notations in the diagram elements table
    for Blocks. Examples of UML notations that have not been excluded by SysML
    include a "/" for derived features, underline for static features, and optional
    visibility characters "+" "-" "#" "~".
    Voting on a resolution of this issue was completed by the original SysML FTF on
    February 23, 2007, as documented in the SysML FTF final report (OMG document
    ptc/2007-03-19). This resolution added the underline notation for static features to
    Table 8.1 in the Blocks chapter, but explicitly excluded the additional notations raised
    by the issue. From the issue resolution in the FTF report, "After discussion by the
    FTF, the “/” notation for derived features and visibility characters "+" "-" "#" "~" are not
    being included in SysML V1.0."
    This resolution was based on email discussion and a straw poll that occurred on the
    original FTF mailing list, in which there was debate as to which of these notations
    stemmed from software engineering practices and which belonged in a systems
    engineering context.
    Experience since then has clearly indicated that systems engineering modelers find
    the derived notation useful to indicate properties that can be fully calculated based on
    other properties. For example, they can indicate performance measures or other
    objective criteria that can be rolled up from subsystems to a higher system level, or to
    indicate dependent vs. independent values in a network of constraints. To reflect the uses of this UML notation in SysML models, and the expectation that it
    be available even though it was excluded the last time it was directly considered, add
    an example of the "/" derived property notation to Table 8.1 in the Blocks chapter.

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

ports with flow properties are displayed the same as flow ports in SysML 1.1?

  • Key: SYSML14-8
  • Legacy Issue Number: 17252
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ports with flow properties are displayed the same as flow ports in SysML 1.1? Can we say this clearly?
    is <> notation based on flow properties only? How about directed features? Can we use the same notation to show direction?
    <> notation is used on WHAT port types? proxy ? or full or even simple ports?
    What notation (reversed?) is on conjugated port? How about nested port, when parent is conjugated?

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    The arrows only relate to flow properties (just like flow ports) – they do not relate to
    required/provided. We don't need to say "like flow ports" since flow ports were
    removed from the chapter and shifted to Annex B. According to table 9.1, any port
    typed by a type with a flow property can have this notation (since it is shown for Port).
    Disposition: Closed, no change

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

9.1 InterfaceBlock - unnamed compartment

  • Key: SYSML14-7
  • Legacy Issue Number: 17250
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.1 InterfaceBlock - unnamed compartment?? why not "operations"? What is "void" ??? no such primate type in sysml. Better example needed.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    SysML compartments can be unnamed, but should not be used in the specification
    for clarity. The void type should be removed.

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

Table 9.1

  • Key: SYSML14-6
  • Legacy Issue Number: 17249
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:
    • why Integer property is under "properties" compartment? why not "value properties"?
  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    This is consistent with chapter 8 – value properties can appear in properties
    compartments.
    Disposition: Closed, no change

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

Section 9.3.1.6

  • Key: SYSML14-5
  • Legacy Issue Number: 17247
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.1.6 The fill color of port rectangles is white and the line and text colors are black. - Notation CAN'T be related to colors

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Remove the following sentences from §9.3.1.6:
    The fill color of port rectangles is white and the line and text colors are black.

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

QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit

  • Key: SYSML14-36
  • Legacy Issue Number: 18724
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML issue 18692 raised the problem of reuse of definitions of Units and QuantityKinds across SystemOfUnit and SystemOfQuantities respectively.
    For example, the SI SystemOfUnits has 7 base units: meter, kilogram, second, ampere, kelvin, mole and candela.
    These base units are in 1-1 correspondence with base quantity kinds in the ISQ: length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. (See SysML 1.3, Figure D.5).

    The association between Unit and QuantityKind where a QuantityKind is the Unit::primaryQuantityKind for a given Unit is redundant with the choice of SystemOfUnits::baseUnit and SystemOfQuantities::baseQuantityKind.
    For example, in the context of the SI, length as a baseQuantityKind of the ISQ is the "primary quantity kind" for metre as a baseUnit in the SI.
    Conversely, length as a baseQuantityKind of the ISQ is not the "primary quantity kind" for kilometre in the SI because kilometre is not a baseUnit of the SI.

    From a reuse perspective, it should be possible to define a coherent, non-SI SystemOfUnit whose baseUnits are the same as those of the SI except for replacing metre with kilometre.
    This non-SI SystemOfUnit would be coherent with respect to the ISQ because length, as a baseQuantityKind of the ISQ would still be the "primary quantity kind" for kilometre as a baseUnit of this non-SI SytemOfUnit.
    To support this flexibility of reuse of Unit and QuantityKind definitions, it is necessary to eliminate the Unit::primaryQuantityKind association from QUDV and instead derive the "primary quantity kind" of a given Unit in the context of a particular SystemOfUnit.

    Furthermore, such a non-SI SystemOfUnit could define "inch" as a QUDV::LinearConversionUnit by reference to metre. In SysML 1.3 QUDV, this would require "inch" to specify that its Unit::quantityKinds are length.
    This is redundant with the fact that metre already specifies length as its Unit::quantityKinds.
    This redundancy could lead to inconsistencies if users define derived units and forget to specify their Unit::quantityKind or do so differently than the Unit::quantityKind of their referenced unit.
    The only kind of Unit where it is logically necessary to specify Unit::quantityKind is for QUDV::SimpleUnit. In all other cases, the Unit::quantityKind collection can be derived.
    For example, for any kind of ConversionBasedUnit, it can be derived by following ConversionBasedUnit::referenceUnit and querying that Unit for its quantityKind collection.
    For a DerivedUnit, it can be derived by following DerivedUnit::factor and UnitFactor::unit and querying the Units for their quantityKind collections.

  • Reported: SysML 1.3 — Fri, 17 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    see pages 255 - 258 of ptc/2013-12-08 for details

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

View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g))

  • Key: SYSML14-35
  • Legacy Issue Number: 18719
  • 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 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.
    b) 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.
    c) 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 included below.

    In the above example, different subviews correspond to the different sections of the 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 the example above, 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.
    d) 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.

    e) 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 — Wed, 15 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    summary of the proposed changes in this resolution include:
    1. Extend View from Class instead of Package to enable means for referencing
    views.
    2. Add a presentation property to Viewpoint whose value(s) is/are the presentation
    format for the view.
    3. Establish a relationship between an instance of a view and an instance of the
    model that the view is intended to represent.
    General Background
    It should be noted that SysML’s choice of Viewpoint and View is consistent with
    industry standard definitions, and should be maintained. The intent of this resolution
    is to preserve the basic view and viewpoint concepts, and only make changes
    needed to refine the modeling elements based on industry experience applying these
    concepts.
    Expose
    The expose relationship was added to address scalability issues with package import
    as described in part b of this issue. Package import is not sufficient for dealing with
    large models because it may require a large number of import relationships to identify
    the imported elements in the package serving as a view.
    The expose relationship resolves this issue by relating the view only to model
    elements that correspond to access points to initiate the model queries performed by
    the viewpoint method. The viewpoint method determines what additional elements or
    other data will actually be part of the view relative to this access point.
    The expose relationship extends generalization. This enables the viewpoint method
    to be inherited by the view so that it represents the constructor of the view.
    View Class
    The change of view from a package to a class resolves part c of this issue. It may be
    necessary or desirable to reference other views in order to construct a view that
    conforms to a viewpoint. This results in a hierarchy of views that provides an ordered
    traversal through the views. This ordering is necessary to understand the story the
    views tell about the model.With view as a class, properties can be made for these
    view references allowing the distinction of the different view trees within the hierarchy. Additionally, view as a class supports the concept that a view instance is a
    specific artifact that is presented to the stakeholder.
    Presentation Attribute
    The presentation property was added to address issue a). In many organizations,
    stakeholders or internal standards may require explicit rules for presentation such as
    specific styles, colors and fonts defined in a stylesheets, file formats, and other
    specifications. This property is intended to provide a flexible approach that supports
    this need..

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

SysML ISO-80000-1 libraries need update per 18269, 18435 and 18681

  • Key: SYSML14-34
  • Legacy Issue Number: 18707
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The ISO-80000-1 libraries need to be updated according to the resolutions of issues 18269, 18435 and 18681 in SysML 1.4 ballots 4 and 5.

  • Reported: SysML 1.3 — Sat, 11 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Prior to resolving 18269, there was a duplication of Unit and QuantityKind in SysML
    1.3 that had a corresponding duplication of non-normative libraries for a subset of
    ISO 80000-1:
    http://www.omg.org/spec/SysML/20120401/ISO-80000-1-QUDV.xmi
    http://www.omg.org/spec/SysML/20120401/ISO-80000-1-SysML.xmi
    As explained in the discussion of 18269, the duplication of Unit and QuantityKind
    makes completing these libraries expensive due to the combinations implied in ISO-
    80000-1: Within the International System of Units alone, there are 20 decimal
    prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has 14 parts;
    part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table 5 and 6
    in Table 6). Thus, a complete library of all legitimate pairs of Unit/QuantityKind in
    scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed units and quantity
    kinds.
    Following the resolution of 18269, the two ISO 80000-1 libraries from SysML 1.3 are
    merged into a single ISO 80000 library based on the non-normative QUDV model;
    that is, definitions of ISO 80000 units and quantity kinds are modeled as M1-level
    InstanceSpecifications classified by a kind of QUDV::Unit and QUDV::QuantityKind
    respectively.
    The name of the library is changed from ISO 80000-1 to just ISO 80000 to reflect the
    fact that the tables from which the SysML 1.2 and 1.3 ISO 80000-1 libraries came
    from are in fact summaries of units and quantities defined across several ISO 80000
    parts. For example, Table 1 in ISO 80000-1 shows the 7 base units and base
    quantities of the SI and ISQ respectively. These units and quantities come from ISO
    80000 parts 3,4,5,6,7 and 9. Annex D.4 previously showed diagrams for the ISO-80000-1-SysML library. D.4 is
    updated to show the library of units, prefixes and quantities referenced in ISO-80000-
    1 Tables 1 through 5 and from parts of Table 2 from the SI Brochure, which is not
    included in ISO 80000-1, but the contents of which was included in previous versions
    of SysML. Altogether, previous versions of SysML included definitions of units and
    quantities traceable to a small subset of ISO 80000 parts: 3,4,5,6,7,9 and 10. For
    SysML 1.4, the coverage is expanded to include all of the normative definitions of
    parts 3,4,5,6. The coverage of parts 7,9,10 remains the same. This resolution also
    includes the definition of units for bit, byte and octet and related quantities and binary
    prefixes from ISO 80000-13.
    This resolution addresses a problem reported by Hans-Peter de Koning about the
    typing of Linear and AffineConversionUnit factors and offset which were previously
    typed by Rational but should be typed by Number. This problem affects the precise
    definition of the degree as a unit of plane angle, which is not representable as a
    Rational (1 degree = Pi/180 radian).
    This resolution depends on the resolution of 18692 and 18724 in ballot 6; however,
    this resolution adds a capability for distinguishing derived units whose factors are
    reduced (e.g., joule) or not (e.g., kelvin joule per kelvin). Mathematically, a nonreduced
    derived unit is equivalent to a reduced derived unit (e.g., joule = kelvin joule
    per kelvin). This is used rarely (there are 152 derived units in total; 140 are reduced;
    only 12 are non-reduced). For the few cases where it’s been used, the justification
    stems from two general principles:

    • Ensure that all the QUDV-based derived units and quantities are
      mathematically derived in the same way as the derivations shown in their
      corresponding ISO 80000 definitions.
    • Ensure that the dependencies among the QUDV-based models of ISO 80000
      parts reflect the normative dependencies from the corresponding ISO 80000
      documents.
      The only exception to the dependency principle stems from the dual definition of a
      unit, watt per square metre, in two ISO 80000 parts (5 and 6) that have no normative
      dependency to one another (parts 5 and 6 normatively depend on ISO 80000 parts 3
      and 4). The QUDV-based model has part 6 depend on part 5.
      In SysML 1.3, Figure D.7 showed the definition of a unit named ‘catalytic activity’ for
      a quantity kind named ‘katal’. Even though this appears in ISO 80000-1, Table 3,
      there is no indexed definition of this unit or quantity kind in any ISO 80000 part. Since
      all the units and quantity kind definitions in SysML 1.4 have an indexed definition in
      some part of ISO 80000, SysML 1.4 does not include ‘catalytic activity’ nor ‘katal’.
      Note about the tables of units and quantity kinds (Figure tables D8 and D11 through
      D23): The complete details pertaining to the QUDV-based definition of each unit and each
      quantity kind are available in the machine-readable file for the ISO 80000 library. The
      symbols for these units and quantity kinds have been reproduced in Presentation
      MathML on a best-effort basis according to the ISO 80000 documents.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigation through non-properties

  • Key: SYSML14-33
  • Legacy Issue Number: 18704
  • Status: closed  
  • Source: NASA ( Mr. Chris Delp)
  • Summary:

    Many UML elements are semantically equivalent to properties, but are not properties in the abstract syntax, such as behavior parameters, activity variables and call behavior actions. This means they cannot be used with deep nested connectors and other elements requiring property navigation. Add stereotypes based on properties that have "runtime" instance values for these elements.

  • Reported: SysML 1.3 — Thu, 9 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Revise as suggested

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

SysML: Unts and QualityKind

  • Key: SYSML14-32
  • Legacy Issue Number: 18692
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Currently, QuanttiyKind can only be part of 1 SystemOfQuantities.

    This seems wrong. For example, wouldn’t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities.

    This exclusive association would prevent reusing existing definitions of Units & QuantityKinds for custom systems.

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

    This issue involves three problems related to reuse:
    1) Currently, multiplicities between Unit (resp. QuantityKind) and SystemOfUnits
    (resp. SystemOfQuantities) prevent reusing the same definitions of Units and
    Quantities across multiple systems of these.
    2) Defining units and quantity kinds as specializations of others is an important
    reuse use case.
    3) Defining units for quantities of dimension one due to such quantities
    representing a number of entities or a ratio of two quantities of the same kind.
    In both cases, Per ISO 80000-1 and VIM, the coherent derived unit for such
    quantities is the number one. This raises the question whether there is a unit
    “one” or not.
    (1) Enabling reuse:
    The resolution of issue 18681 in ballot 5 showed an updated Figure D.8 where the
    association-owned end multiplicities made it clear that, as of SysML 1.3, a Unit and a
    QuantityKind can be associated to at most one SystemOfUnits and
    SystemOfQuantities respectively even though these associations are non-composite.
    In practice, the 0-1 multiplicity on these associations precludes reusing existing
    model library definitions of Units and QuantityKinds such as ‘metre’ and ‘length’ from
    SysML’s ISO 80000-1 model library. There are three forms of reuse:
    a) reusing the same definition in different systems b) defining a system to include all the definitions from another system
    c) defining a system to reuse selected definitions from another system
    For the first form of reuse, the 0-1 association-owned end multiplicities need to be
    relaxed to 0..*. For the second and third form of reuse, it is necessary to introduce
    new associations for a system of units or quantities to include or reuse zero or more
    other system of units or quantities.
    (2) Reuse and specialization for general quantities and units
    Currently, QUDV provides limited support for defining a quantity kind as a
    specialization of another (see ISO 80000-1, 3.1 and 3.2 Notes for examples).
    Unfortunately, this capability is only available for a SpecializedQuantityKind. This
    means that, for example, it is not possible to define a DerivedQuantityKind as a
    specialization of another QuantityKind. A similar capability is needed for Units: for
    two quantity kinds QK1 and QK2, if QK1 is a specific quantity kind for the generic
    quantity kind QK2, then the unit U1 corresponding to QK1 ought to be a specific unit
    for the generic unit U2 corresponding to QK2.
    (3) Reuse and specialization related to quantities of dimension one
    This involves two cases:
    a) Derived quantities of dimension one
    Derived quantities that are intrinsically defined as indexes, levels, numbers or
    ratios all have dimension one (see ISO 80000-1, 3.8 and Annexes A3, A4).
    Specializing quantities of dimension one motivates adding a capability for
    specializing the corresponding units. For example, ISO 80000-1 3.8 and 3.9
    mention radian as an example of a derived unit for a quantity of dimension 1
    (i.e., plane angle whose dimension is length/length). However, it is also
    possible to define a SystemOfUnits/ Quantities in which radian is defined as a
    base unit for plane angle, a base quantity. In such a system, there is no
    UnitFactor nor any QuantityKindFactor available to determine that plane angle
    is a quantity with dimension one unless it is explicitly asserted.
    b) Quantities representing a number of entities
    Quantities that intrinsically represent a number of entities have dimension one;
    however such quantities carry more information than just a number per ISO
    80000-1, 3.8 Note 4. Accounting for this information requires adding a
    capability for designating a particular Unit as the unitary value for quantity
    representing a number of entities.
    This resolution addresses all 3 aspects of reuse described above by refactoring
    QUDV to:

    • enable defining a Unit or QuantityKind as a specialization of possibly multiple
      Units or QuantityKinds respectively, designate a Unit as representing a unit count of entities,
    • designate a QuantityKind as representing a number of entities,
    • designate a QuantityKind as representing a quantity of dimension one.
      This refactoring helps avoid defining a unit “one” explicitly as the unit for all quantities
      of dimension one. Doing so would have resulted in a widely reused unit “one” that
      would carry no useful information (ISO 80000-1, 3.8 Note 2). Instead, the explicit
      “quantity of dimension one” designation capability puts the emphasis on defining a
      meaningful unit for such a quantity.
      See the resolution to issue 18724 which addresses the potential problems involved in
      reusing systems of units and quantity kinds as well as the need for refactoring the
      modeling of Unit::primaryQuantityKind. For changes pertaining to
      Unit::primaryQuantityKind, see the resolution to issue 18724
  • Updated: Fri, 6 Mar 2015 20:58 GMT

QUDV's support for measurement scales is impractical

  • Key: SYSML14-31
  • Legacy Issue Number: 18681
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales:

    D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM))

    D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale)

    D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high".

    In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property.

    Unfortunately, this requires defining the "priority" measurement scale twice:

    Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition
    For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to “low”, “medium” and “high”
    From a metrology standpoint, both definitions of “priority” can be related to a definition of a Unit and a definition of a QuantityKind:

    • The QUDV-based definition of “priority” can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV “priority” scale (See SysML 1.3, Figure D.8 in section D.5.2)
    • The ValueType-based definition of “priority” can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2)

    From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of “priority” is clearly useful for typing value properties and specifying their values.

    Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since:

    • A SysML::ValueType Enumeration really defines a “scale”, thereby alleviating the need for a separate QUDV::Scale concept.
    • The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a “scale”, thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept.

    Nicolas.

  • Reported: SysML 1.3 — Sun, 21 Apr 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Follow the proposed suggestion except that providing explanations for modeling
    “scales” using SysML ValueTypes and SysML Enumeration ValueTypes is
    postponed until after peer review.
    This resolution builds on the resolution to issue 18269 from SysML 1.4 Ballot 4 and
    issue 18435 from SysML 1.4 Ballot 5.

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

View and Viewpoint Property Limitations (from Issue 18391 a) and f))

  • Key: SYSML14-30
  • Legacy Issue Number: 18653
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Source:

    Jet Propulsion Lab (Chris Delp – Christopher.L.Delp@jpl.nasa.gov)

    INCOSE (Sanford A. Friedenthal – safriedenthal@gmail.com)

    Summary:

    This issue represents issues a) and f) from Issue 18391 – View and Viewpoint Limitations in Support of Auto-View Generation. 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.)

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

  • Reported: SysML 1.3 — Thu, 11 Apr 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The following resolution is proposed for ballot 5. The other issues will be addressed
    in a separate ballot.
    Relative to issue a), the current viewpoint property for method is typed by string. The
    following changes are intended to enable the viewpoint method to be specified by a
    Behavior.
    Relative to issue b), the current viewpoint property for stakeholder is typed by a
    string. The following changes are intended to enable stakeholder to be represented
    by a Stakeholder stereotype that extends classifier, so that it can be reused.
    In addition, the current viewpoint property for language is typed by a string. The
    following change types language by string, but adds clarification that this string
    represents the language metamodel or profile URI.

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

Wrong quantityKind for unit radian

  • Key: SYSML14-41
  • Legacy Issue Number: 18910
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In fig D.6 the quantityKind of the unit radian should be plane angle instead of radian

  • Reported: SysML 1.3 — Sat, 14 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    It seems that due to a copy&paste error the unit radian has a wrong quantityKind
    value.
    Disposition: See issue 18707 for resolution

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

Signal flow property description (§9.3.2.7)

  • Key: SYSML14-40
  • Legacy Issue Number: 18908
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    description of Signal flow property has the sentence: “ […] imply sending and/or receiving of a signal usage”. It seems that the word “usage” is not convenient here and is confusing. It should be removed.

  • Reported: SysML 1.3 — Thu, 12 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Subclause 9.3.2.7, Description subsection, third paragraph, relates flow properties
    typed by signals to sending signals as follows:
    Flow properties of type Signal imply sending and/or receiving of a signal
    usage. [snip] An “out” FlowProperty of type Signal means that the owning
    Block may send the signal via connectors and an “in” FlowProperty means
    that the owning block is able to receive the Signal.
    The text above does not require implementations to do anything special for flow
    properties typed by signals beyond what is normally done for flow properties,
    because it says “may”. Removing the text would not prevent implementations from
    adding semantics as the text describes, because the specification would not disallow
    it. However, the text implies alternative conforming implementations that should be
    called out, but with more specific language referring to signal events. The revised text
    should not require or prevent signals from being sent due to flow properties, because
    this would invalid existing implementations unnecessarily.

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

notation for inherited features

  • Key: SYSML14-39
  • Legacy Issue Number: 18891
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Notation for inherited features. UML 2.5 has introduced a notation for inherited features. This notation is completely relevant to SysML, and should be added to the diagram elements tables. It applies to blocks, value types, signals, and other classifiers

  • Reported: SysML 1.3 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution includes provisions to add the UML 2.5 inherited features to SysML
    1.4. The following text is from the UML 2.5 specification (ptc/13-08-16) section 9.2.4:
    Members that are inherited by a Classifier may be shown on a diagram of that Classifier by
    prepending a caret ’^’ symbol to the textual representation that would be shown if the
    member were not inherited. Thus the notation for an inherited Property is defined like this:
    <inherited-property> ::= ’^’ <property>
    where <property> is specified in 9.5.4.
    Similarly, the notation for an inherited Connector is defined like this:
    <inherited-connector> ::= ’^’ <connector>
    where <connector> is specified in 11.2.4.
    Analogous notations may be used for all NamedElements that are inheritedMembers of a
    Classifier to indicate that they are inherited.
    Inherited members may also be shown in a lighter color to help distinguish them from noninherited
    members. A conforming implementation does not need to provide this option.

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

Addign a Behavior Compartment for Blocks

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

    SysML blocks currently include additional compartments labeled namespace and structure. This provides significant value to present various aspects of a block on a block definition diagram.

    It would be very valuable to extend the standard compartments to enable representation of behavior. The request is to include a labeled compartment called 'behavior' to contain the classifier behavior and/or any other owned behaviors in this compartment.

  • Reported: SysML 1.3 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution includes provisions to add labeled behavior compartments to blocks
    and parts that can include textual representations of classifier and owned behaviors.

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

Missing/wrong elements in diagram table (InformationFlows)

  • Key: SYSML14-37
  • Legacy Issue Number: 18846
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 9.1, ItemFlow: The concrete syntax shows elements from an ibd. But table 9.1. is about bdd.

    SysML also includes the concept of InformationFlows from UML (compliance level 3). The concrete syntax for an InformationItem or InformationFlow is missing.

  • Reported: SysML 1.3 — Thu, 1 Aug 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The concrete syntax column in the Table 9.1 row for Item Flow was a copy and paste
    mistake in the final published version of SysML 1.3. It did not correctly implement the
    resolution for Issue 16635 in ballot 4 of the SysML 1.3 RTF. The correct figure
    appears in the SysML 1.3 RTF Final Report (ptc/2011-11-08), but not in the beta
    specification (convenience) documents that accompanied this final report (ptc/2011-
    11-09 and ptc/2011-11-10).
    Correct the concrete syntax column which appears in the ItemFlow row of Tables 9.1
    and 9.2 to contain the figures already approved by the SysML 1.3 RTF in its
    resolution of Issue 16635.
    This resolution only corrects the error in producing the correct version of SysML 1.3,
    as raised by the first paragraph of this issue. This urgent fix should not be delayed by
    the question raised by the second paragraph of this issue, on whether the UML
    concept and concrete syntax for InformationFlows is included in SysML.
    The second paragraph of the issue is correct that SysML specification does not show
    all forms of UML concrete syntax for UML InformationItem and InformationFlow. In
    particular, UML has dashed-line notations for information flows and items, as well as
    «flow» , «information», and «representation» keywords, which were never included in
    SysML from its original submission.
    A separate issue can be raised to address support for UML information flows, or to
    update the contents of Clause 5, which contains the tables that define the current
    SysML 1.3 compliance levels.
    Note that the compliance definitions in Clause 5 will need to be updated in any event
    to reflect the change in UML 2.5 that “The compliance levels L0, L1, L2, and L3 have been eliminated, because they were not found to be useful in practice.” (UML 2.5
    FTF convenience documents, ptc/2013-09-05 and ptc/2013-09-06.) Again, separate
    issues can be filed to address the need for these additional changes

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

QUDV Unit/QuantityKind name redundancy

  • Key: SYSML14-25
  • Legacy Issue Number: 18435
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind:

    <Unable to render embedded object: File (--[if !supportLists]-->a) <) not found.-[endif]->by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification)

    <Unable to render embedded object: File (--[if !supportLists]-->b) <) not found.-[endif]->by the property Unit::name and QuantityKind::name

    This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind

  • Reported: SysML 1.3 — Sun, 10 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The duplication is indeed unnecessary. In fact, the none of the definitions of Units
    and QuantityKinds in the ISO-80000-1-QUDV library have slots for the Unit::name or
    QuantityKind::name properties. Remove Unit::name and QuantityKind::name.
    This duplication also applies to:

    • QUDV::Prefix
    • QUDV::SystemOfUnits
    • QUDV::SystemOfQuantities
      This resolution builds on the resolution to issue 18269 from SysML 1.4 Ballot 4.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

propertyPath property should be defined once and reused

  • Key: SYSML14-24
  • Legacy Issue Number: 18407
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction have exactly the same property (propertyPath). It should be defined once in a generalization of NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction

  • Reported: SysML 1.3 — Sun, 3 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Introduce an abstract stereotype for propertyPath that generalizes
    NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction.
    Constrain the specialized stereotypes to apply to connector ends, triggers, and
    invocation actions, respectively.

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

9.3.2.4 direction of ports and their notation

  • Key: SYSML14-27
  • Legacy Issue Number: 18440
  • Status: closed  
  • Source: Dassault Systemes ( Mr. 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.3 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Disposition: See issue 18439 for resolution

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

Use of "inherited method" in section 9.3.2.4

  • Key: SYSML14-26
  • Legacy Issue Number: 18438
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.4 DirectedFeature, constraint [2] - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all?

    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.3 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Constraint [2] should be reworded

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

Refine relationship contextualization

  • Key: SYSML14-29
  • Legacy Issue Number: 18561
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    We need a specialization of the UML standard <<refine>> stereotype within SysML in order to be able to contextualize the corresponding relationships instances just like the resolution to issue #14447 specifies for the <<trace>> stereotype.

  • Reported: SysML 1.3 — Thu, 14 Mar 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Do as suggested. For in-deep discussion about contextualization, refer to issue
    #14447.

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

Activity model library package

  • Key: SYSML14-28
  • Legacy Issue Number: 18456
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The model library for Activities should be in a new package inside the SysML::Activities package. Figure 11.9 (Control values) does not have a frame, but Figure 8.7 (Model library for primitive value types) does. They should be consistent.

  • Reported: SysML 1.3 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Disposition: See issue 18269 for resolution

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

sentence introduced in §9.1 by the resolution to issue #16280 is confusing

  • Key: SYSML13-60
  • Legacy Issue Number: 16608
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The following sentence introduced in §9.1 by the resolution to issue #16280 is confusing: "Default compatibility rules are defined for connecting blocks used in composite structure, including parts and ports [...]" since it is not "blocks" (SysML sense), which are not connectable elements, that are connected in composite structure but parts and ports. In addition the rules we are speaking about deal with "matching/mapping" (i.e. routing) rather than with "compatibility" since one can have several possible solutions (mapping) to connect two compatible ports.

    I suggest replacing this sentence by the following one: "Default matching rules are defined for connecting parts or ports in composite structure but specific mappings can be specified thanks to association blocks".

  • Reported: SysML 1.2 — Tue, 28 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change the wording to indicate that association blocks can override the default
    compatibility rules

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

Wrong multiplicity for Requirement in stereotype description

  • Key: SYSML13-59
  • Legacy Issue Number: 16407
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Both Figure 16.1 and the SysML 1.2 profile http://www.omg.org/spec/SysML/20100301/SysML-profile.uml define Requirement::/derived : Requirement[*]
    but in 16.3.2.3, the attribute is described incorrectly as: /derived : Requirement[0..1]

    It's obvious that the specification in 16.3.2.3 is incorrect; the property description should be changed from:

    /derived : Requirement[0..1]

    to:

    /derived : Requirement[*]

    I propose to include this resolution in ballot 5 for sysml 1.3.

  • Reported: SysML 1.2 — Sat, 30 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    No Data Available

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