OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

  • Acronym: SysML
  • Issues Count: 55
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML16-382 Allow a Requirement to be contained on Any Diagram SysML 1.5 open
SYSML16-366 Constraints for Refine and Trace can be improved SysML 1.5 open
SYSML16-353 The constraint#6 of TriggerOnNestedPort could be replaced by a redefinition SysML 1.5 open
SYSML16-352 The statement of TriggerOnNestedPort constraint#5 is wrong SysML 1.5 open
SYSML16-348 ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation SysML 1.5 open
SYSML16-357 Allocate constraint#1 could be replaced by a redefinition SysML 1.5 open
SYSML16-351 The statement of TriggerOnNestedPort constraint#4 is not appropriate SysML 1.5 open
SYSML16-343 Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition SysML 1.5 open
SYSML16-345 SysML stereotype constraints should be named rather than numbered SysML 1.5 open
SYSML16-274 Most constraints are missing their OCL statement SysML 1.5 open
SYSML16-337 Compartment headers are missing in figure 8.10 and 8.11 SysML 1.5 open
SYSML16-334 Incorrect diagram header in figure 8.11 SysML 1.5 open
SYSML16-331 UnitAndQuantityKind figure missing block keyword SysML 1.5 open
SYSML16-332 EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property SysML 1.5 open
SYSML16-310 SysML::Block constraint#3 containts an incorrect assertion about UML SysML 1.5 open
SYSML16-323 AdjunctProperty constraint#8 can be simplified SysML 1.5 open
SYSML16-303 References to UML specification in block constraints are not correct SysML 1.5 open
SYSML16-300 Remove sentences about qualified associations in clause 8.3.1.3 SysML 1.5 open
SYSML16-299 Remove the statement about N-ary associations from 8.3.1.3 SysML 1.5 open
SYSML16-295 Remove [sic] in block constraints SysML 1.5 open
SYSML16-344 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 open
SYSML16-329 Constraints redundancy in DirectedRelationshipPropertyPath SysML 1.5 open
SYSML16-341 Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid SysML 1.5 open
SYSML16-326 BoundReference constraint#3 is unclear SysML 1.5 open
SYSML16-325 Typo in AdjunctProperty Constraint#10 SysML 1.5 open
SYSML16-371 Reference Properties do not reference properties SysML 1.5 open
SYSML16-373 Add Graphical notation for General Classifier SysML 1.5 open
SYSML16-372 DirectedFeature is confusing SysML 1.5 open
SYSML16-367 Constraints on Satisfy and Verify should refer to AbstractRequirement SysML 1.5 open
SYSML16-365 Copy constraints #2 and #3 shoud be merged together SysML 1.5 open
SYSML16-364 Statements missing in the abstract syntax description SysML 1.5 open
SYSML16-355 Probability constraint#1 is ambiguous SysML 1.5 open
SYSML16-350 Do not move deprecated elements SysML 1.5 open
SYSML16-349 ItemFlow constraint#3 does not make sense in every case SysML 1.5 open
SYSML16-264 Owned properties of an InterfaceBlock SysML 1.5 open
SYSML16-358 Allocate constraint#3 does not make sense SysML 1.5 open
SYSML16-356 Rate constraint#2 is ambiguous SysML 1.5 open
SYSML16-354 The OCL statement of ConstraintBlock constraint#3 is wrong SysML 1.5 open
SYSML16-294 Parameter direction typo in XMI SysML 1.5 open
SYSML16-342 The statement of InvocationOnNestedPortAction constraint#3 is not appropriate SysML 1.5 open
SYSML16-321 View constraint#3 is incorrect SysML 1.5 open
SYSML16-339 2017-08-31 Weekly meeting minutes SysML 1.5 open
SYSML16-333 Replace UML4SysML::Kernel by UML4SysML::Generalization SysML 1.5 open
SYSML16-319 Clarification of typing a binding connector SysML 1.5 open
SYSML16-328 Inconsistency in the DirectedRelationshipPropertyPath specification SysML 1.5 open
SYSML16-281 Clarify if the usage of qualified associations is allowed SysML 1.5b1 open
SYSML16-280 Association arrowheads should not be forbidden SysML 1.5b1 open
SYSML16-211 Block constraint [4] contains a false statement SysML 1.5 open
SYSML16-318 2017-07-20 Weekly meeting minutes SysML 1.5 open
SYSML16-314 The association-like notation is ambiguous SysML 1.5 open
SYSML16-298 Replace all occurrences of "has been" by "is" SysML 1.5 open
SYSML16-253 Owning Block definition is unclear SysML 1.5 open
SYSML16-263 FullPort type SysML 1.5 open
SYSML16-254 Clarify port usage patterns SysML 1.5 open
SYSML16-232 2017-02-22 Weekly meeting minutes SysML 1.5 open

Issues Descriptions

Allow a Requirement to be contained on Any Diagram

  • Status: open  
  • Source: MITRE ( 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
  • Updated: Thu, 7 Dec 2017 00:44 GMT

Constraints for Refine and Trace can be improved

  • Status: open  
  • 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
  • Updated: Thu, 30 Nov 2017 16:52 GMT

The constraint#6 of TriggerOnNestedPort could be replaced by a redefinition

  • Status: open  
  • 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
  • Updated: Thu, 30 Nov 2017 16:34 GMT

The statement of TriggerOnNestedPort constraint#5 is wrong

  • Status: open  
  • 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
  • Updated: Thu, 30 Nov 2017 16:33 GMT

ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation

  • Status: open  
  • 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
  • Updated: Thu, 23 Nov 2017 16:57 GMT

Allocate constraint#1 could be replaced by a redefinition

  • Status: open  
  • 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
  • Updated: Thu, 23 Nov 2017 16:31 GMT

The statement of TriggerOnNestedPort constraint#4 is not appropriate

  • Status: open  
  • 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
  • Updated: Thu, 23 Nov 2017 16:30 GMT

Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition

  • Status: open  
  • 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
  • Updated: Thu, 23 Nov 2017 16:18 GMT

SysML stereotype constraints should be named rather than numbered

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Most constraints are missing their OCL statement

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Compartment headers are missing in figure 8.10 and 8.11

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Incorrect diagram header in figure 8.11

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

UnitAndQuantityKind figure missing block keyword

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

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

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

AdjunctProperty constraint#8 can be simplified

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

References to UML specification in block constraints are not correct

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Remove sentences about qualified associations in clause 8.3.1.3

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Remove the statement about N-ary associations from 8.3.1.3

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Remove [sic] in block constraints

  • Status: open  
  • 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
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Typos/editorials found in the SysML 1.5 specification document


Constraints redundancy in DirectedRelationshipPropertyPath

  • Status: open  
  • 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
  • Updated: Thu, 16 Nov 2017 17:11 GMT

Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid

  • Status: open  
  • 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
  • Updated: Thu, 16 Nov 2017 17:09 GMT

BoundReference constraint#3 is unclear

  • Status: open  
  • 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
  • Updated: Thu, 16 Nov 2017 16:36 GMT

Typo in AdjunctProperty Constraint#10

  • Status: open  
  • 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
  • Updated: Thu, 16 Nov 2017 16:23 GMT

Reference Properties do not reference properties

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Tue, 7 Nov 2017 23:42 GMT

Add Graphical notation for General Classifier

  • Status: open  
  • Source: Lockheed Martin ( 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
  • Updated: Tue, 31 Oct 2017 13:57 GMT

DirectedFeature is confusing

  • Status: open  
  • 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
  • Updated: Wed, 18 Oct 2017 10:57 GMT

Constraints on Satisfy and Verify should refer to AbstractRequirement

  • Status: open  
  • 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
  • Updated: Mon, 25 Sep 2017 21:27 GMT

Copy constraints #2 and #3 shoud be merged together

  • Status: open  
  • 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
  • Updated: Mon, 25 Sep 2017 21:25 GMT

Statements missing in the abstract syntax description

  • Status: open  
  • 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
  • Updated: Mon, 25 Sep 2017 21:20 GMT

Probability constraint#1 is ambiguous

  • Status: open  
  • 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
  • Updated: Thu, 21 Sep 2017 15:48 GMT

Do not move deprecated elements


ItemFlow constraint#3 does not make sense in every case

  • Status: open  
  • 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
  • Updated: Thu, 21 Sep 2017 15:32 GMT

Owned properties of an InterfaceBlock

  • Status: open  
  • 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
  • Updated: Thu, 21 Sep 2017 14:42 GMT

Allocate constraint#3 does not make sense

  • Status: open  
  • 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
  • Updated: Thu, 21 Sep 2017 07:24 GMT

Rate constraint#2 is ambiguous

  • Status: open  
  • 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
  • Updated: Thu, 21 Sep 2017 07:23 GMT

The OCL statement of ConstraintBlock constraint#3 is wrong

  • Status: open  
  • 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
  • Updated: Thu, 21 Sep 2017 07:22 GMT


The statement of InvocationOnNestedPortAction constraint#3 is not appropriate

  • Status: open  
  • 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
  • Updated: Wed, 13 Sep 2017 06:25 GMT

View constraint#3 is incorrect

  • Status: open  
  • 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
  • Updated: Thu, 7 Sep 2017 14:20 GMT

2017-08-31 Weekly meeting minutes

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

    Attendees: Julio, Laura, Dave, Conrad, Tim, Rick, Yves
    Agenda:

    • Ballot#5
    • Ballot#6
    • Issue/Resolution discussions

    1 Ballot#5
    Will close Sep 2nd 02:00am CEST. 14 votes out of 20 so far.

    2 Ballot#6
    Will be created: Sep 7th
    Will Open for vote: Oct 5th
    Will Close: Oct 21t

    3 RTF Deadline Extension
    We would like to propose extending this RTF by two cycles (i.e. up to June 2018). We need a motion for that to be voted by the AB at the New Orleans meeting. @Yves-> to send an email to the RTF mailing list to inform about it to see whether there are objections about.

    4 Issue resolutions review
    The following issues (and corresponding resolution proposals) were presented and discussed during this meeting (follow corresponding links for details):
    SYSML16-337, SYSML16-334, SYSML16-331, SYSML16-299, SYSML16-300

    @Yves -> to create a global issue for gathering typos and editorial that will be voted in the last RTF ballot.

    5 Next meeting

    • Online- Thursday Sep 7th, 11am ET.
  • Reported: SysML 1.5 — Thu, 31 Aug 2017 16:05 GMT
  • Updated: Thu, 31 Aug 2017 16:05 GMT

Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: open  
  • 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
  • Updated: Wed, 30 Aug 2017 15:17 GMT

Clarification of typing a binding connector


Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: open  
  • 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
  • Updated: Thu, 10 Aug 2017 12:44 GMT

Clarify if the usage of qualified associations is allowed

  • Status: open  
  • 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
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Association arrowheads should not be forbidden

  • Status: open  
  • 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
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Block constraint [4] contains a false statement

  • Status: open  
  • 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
  • Updated: Wed, 2 Aug 2017 00:51 GMT

2017-07-20 Weekly meeting minutes


The association-like notation is ambiguous

  • Status: open  
  • 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
  • Updated: Wed, 12 Jul 2017 06:53 GMT
  • Attachments:

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

  • Status: open  
  • 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
  • Updated: Tue, 6 Jun 2017 07:44 GMT

Owning Block definition is unclear

  • Status: open  
  • 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
  • Updated: Fri, 2 Jun 2017 15:19 GMT

FullPort type

  • Status: open  
  • 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
  • Updated: Tue, 30 May 2017 14:21 GMT

Clarify port usage patterns

  • Status: open  
  • 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
  • Updated: Mon, 1 May 2017 00:28 GMT

2017-02-22 Weekly meeting minutes

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

    Attendees: Nicolas, Yves

    From Nicolas' notes:

    We discussed Steve’s approach for generating DocBook documents from ontologies via a small library (in Ruby) of helper methods for constructing well-formed chunks of DocbBook.

    In the TIWG, we had been following a model-based approach based on distinguishing between:

    • The input model(s) – e.g. a metamodel like UML, a profile like SysML, a library like QUDV or ISO80K, an ontology like JPL’s
    • The document model whose organization reflects the organization of the output document in some format (e.g., LibreOffice, DocBook, LaTeX, PDF, …)

    Generating the output document from the document model should be a simple transformation because the document metamodel is designed to be easily mapped to document formats like DocBook, LibreOffice, LaTeX, … In the TIWG, we had been using the Eclipse-based GenDoc templating language for doing this generation. JPL’s DocGen uses a kind of UML Activity diagram-based language for a similar purpose.
    To accommodate the needs of specification documents, these templating languages allow invoking functions written in a programming language of some kind.
    Instead of using a template language as a programming language, we discussed using Scala in a restricted way to get compact, readable code where the type signature of a function
    provides a useful compact specification of what a function does.

    Looking at Steve’s jpl/docbook.rb library of helper methods for constructing chunks of well-formed DocBook, we discussed the idea of extracting the typology
    of document structures involved in OMG’s specifications (UML and SysML) as a document metamodel that could be easily mapped to an output document in some document
    format using a library of helper functions for assembling documents in that document format.

    For example, this document metamodel could look like this (in Scala):

    class SpecDocument(title: String, version: String, sections: Seq[Section], …)
    class Section(title: String, number: String, para: Seq[SubSection])
    trait SubSection
    class Metaclass(title: String, description: Seq[Paragraph], href: URL extends SubSection
    class Stereotype(title: String, description: Seq[Paragraph], href: URL) extends SubSection

    Here’s a sketch of a document model for SysML 1.4:

    SpecDocument(“SysML”, …
    ...

    // 9.3.2
    Stereotype("BLock", Seq(...), url("http://www.omg.org/spec/SysML/1.4/Block"))
    ...
    )

    Yves volunteered to extract a document metamodel from the typology of document templates he had developed in GenDoc for OMG’s UML & SysML specification documents.

  • Reported: SysML 1.5 — Wed, 1 Mar 2017 16:05 GMT
  • Updated: Wed, 1 Mar 2017 16:15 GMT