OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML17-162 Add signal to constraint [1] for DistributedProperty SysML 1.5 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-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-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-185 Sample problem diagrams are inconsistent, need to refactor from integrated model SysML 1.5 SysML 1.7 Resolved closed
SYSML17-173 Combined call-out notation not allowed SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-255 BDD representation of activity hierarchy SysML 1.5b1 SysML 1.7 Closed; No Change closed
SYSML17-172 ConnectorProperty is redundant SysML 1.5 SysML 1.7 Resolved closed
SYSML17-148 Owning Block definition is unclear SysML 1.5 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-160 DirectedFeature is confusing SysML 1.5 SysML 1.7 Resolved closed
SYSML17-159 Reference Properties do not reference properties SysML 1.5 SysML 1.7 Closed; No Change 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-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-174 Connectors are not allowed in bdd SysML 1.5 SysML 1.7 Resolved closed
SYSML17-158 Statements missing in the abstract syntax description SysML 1.5 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
SYSML16-468 The constraint#3 of NestedConnectorEnd could be replaced by a redefinition SysML 1.5 SysML 1.6 Duplicate or Merged 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-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-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-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-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-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-314 The association-like notation is ambiguous SysML 1.5 SysML 1.6 Duplicate or Merged 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-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-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-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-331 UnitAndQuantityKind figure missing block keyword SysML 1.5 SysML 1.6 Resolved 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-323 AdjunctProperty constraint#8 can be simplified SysML 1.5 SysML 1.6 Duplicate or Merged 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-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-211 Block constraint [4] contains a false statement SysML 1.5 SysML 1.6 Duplicate or Merged 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-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-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-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

Issues Descriptions

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

Clarification of typing a binding connector


Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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: NASA ( Charles 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 ( 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

Excluded UML metaclasses are not formally defined

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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 ( 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

DistributedProperty should be abstract

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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

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

  • Status: closed  
  • Source: University of Arizona ( 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

Combined call-out notation not allowed

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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

BDD representation of activity hierarchy

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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:

ConnectorProperty is redundant

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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

Owning Block definition is unclear

  • Status: closed  
  • Source: Airbus Group ( 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

Parameter direction typo in XMI


Owned properties of an InterfaceBlock

  • Status: closed  
  • Source: Airbus Group ( 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

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

Reference Properties do not reference properties

  • Status: closed  
  • Source: University of Arizona ( 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

Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( 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 ( 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 ( 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

Typos/editorials found in the SysML 1.5 specification document

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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

Connectors are not allowed in bdd

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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:

Statements missing in the abstract syntax description

  • Status: closed  
  • Source: Airbus Group ( 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

Typo in revised text of issue SYSML16-289

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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

The constraint#3 of NestedConnectorEnd could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( 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

Error in the revised text for SYSML16-132

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

    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 ( 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 ( 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:

Setting flow properties on blocks with multiple behavioral ports

  • Status: closed  
  • Source: NASA ( Nicolas 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 ( 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 ( 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 ( 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: NASA ( 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

Diagram guidelines uses excluded UML element

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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

Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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

BoundReference constraint#3 is unclear

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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

Allocate constraint#1 could be replaced by a redefinition

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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 ( 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

The association-like notation is ambiguous

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

    In our discussion about SYSML16-308, 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:

Nested diagrams in SysML

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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

Allow a Requirement to be contained on Any Diagram

  • Status: closed  
  • Source: Lockheed Martin ( Laura 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 ( 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

References to UML specification in block constraints are not correct

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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

Binding connectors in internal block diagrams must always show the keyword

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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

UnitAndQuantityKind figure missing block keyword

  • Status: closed  
  • Source: NIST ( 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

SysML::Block constraint#3 containts an incorrect assertion about UML

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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

AdjunctProperty constraint#8 can be simplified

  • Status: closed  
  • Source: Airbus Group ( 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

SysML stereotype constraints should be named rather than numbered

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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 ( 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 ( 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

Clarify if the usage of qualified associations is allowed

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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

Block constraint [4] contains a false statement

  • Status: closed  
  • Source: Airbus Group ( 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

Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: closed  
  • Source: Airbus Group ( 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 ( 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


SysML 1.6 should be based on UML 2.5.1

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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

ConnectorProperty is redundant

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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 ( 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 ( 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

Typo in revised text of issue SYSML16-289

  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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: NASA ( Charles 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 ( 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