OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

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

Issues Descriptions

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

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

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

  • Reported: SysML 1.1 — Wed, 8 Jul 2009 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Ability for a binding connector to be typed

  • Key: SYSML16-48
  • Legacy Issue Number: 15079
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

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

  • Reported: SysML 1.1 — Sat, 20 Feb 2010 05:00 GMT
  • Updated: Fri, 28 Jul 2017 08:16 GMT

Allocations should not generate dependencies

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

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

  • Reported: SysML 1.1 — Fri, 27 Mar 2009 04:00 GMT
  • Updated: Thu, 1 Jun 2017 16:13 GMT

Flow port compatibility with behavior

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

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

  • Reported: SysML 1.1 — Tue, 7 Jul 2009 04:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

Parsing Text in Requirements

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

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

  • Reported: SysML 1.1 — Wed, 27 May 2009 04:00 GMT
  • Updated: Sat, 4 Mar 2017 02:34 GMT

Binding to multiplicity in parametrics

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

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

  • Reported: SysML 1.1 — Thu, 21 Jan 2010 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:01 GMT

Proposal to have a stereotype for reference nested property

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

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

  • Reported: SysML 1.1 — Sun, 5 Jul 2009 04:00 GMT
  • Updated: Tue, 21 Feb 2017 15:59 GMT

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

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

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

  • Reported: SysML 1.1 — Fri, 29 May 2009 04:00 GMT
  • Updated: Tue, 21 Feb 2017 15:59 GMT

Inability to represent dependent, independent parameters on constraint properties

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

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

  • Reported: SysML 1.1 — Mon, 26 Jan 2009 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:59 GMT

AllocateActivityPartition and UML 2 semantics

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

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

  • Reported: SysML 1.1 — Mon, 26 Jan 2009 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:58 GMT

Section: 8/8.3.2 Inability to efficiently capture datasets

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

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

  • Reported: SysML 1.1 — Mon, 12 Jan 2009 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:57 GMT

Representation of nested object nodes in activity diagrams

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

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

  • Reported: SysML 1.1 — Wed, 31 Dec 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:56 GMT