OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

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

Issues Descriptions

Section: Generalization of stereotyped elements

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

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

  • Reported: SysML 1.0 — Sun, 2 Mar 2008 05:00 GMT
  • Updated: Thu, 14 Dec 2017 16:50 GMT

Section: 9.3.2.5 FlowPort

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

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

  • Reported: SysML 1.0 — Fri, 13 Oct 2006 04:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

Figure B.34 and Figure B.35

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

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

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Updated: Tue, 21 Feb 2017 15:55 GMT

Annex B, Figure B.29

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

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

  • Reported: SysML 1.0 — Sun, 6 Jan 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:55 GMT

Annex B / Figure B.38

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

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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:54 GMT

Annex B / Figure B.35


Annex B / Figure B27

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

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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:54 GMT

Annex B / Figure B.9

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

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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:53 GMT
  • Attachments:

Annex B / Figure B.10

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

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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:53 GMT

10.3.1.2 Parametric Diagram: square box notation

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

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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Fri, 3 Feb 2017 01:56 GMT

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

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

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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Fri, 3 Feb 2017 01:21 GMT

Diagram interchange

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

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

  • Reported: SysML 1.0 — Mon, 19 Nov 2007 05:00 GMT
  • Updated: Thu, 2 Feb 2017 13:54 GMT

standard way to describe a flow of data in sequence diagrams

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

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

  • Reported: SysML 1.0 — Wed, 4 Jul 2007 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:46 GMT

Timing diagrams

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

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

  • Reported: SysML 1.0 — Mon, 5 Feb 2007 05:00 GMT
  • Updated: Thu, 2 Feb 2017 13:45 GMT

the use of <> is still unclear and inconsistent

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

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

  • Reported: SysML 1.0 — Mon, 4 Dec 2006 05:00 GMT
  • Updated: Thu, 2 Feb 2017 13:44 GMT

Section: Activities

  • Key: UMLR-140
  • Legacy Issue Number: 12434
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Activity regions and their contents should be redefinable

  • Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Chapter: 7.3.2.4 View

  • Key: UMLR-104
  • Legacy Issue Number: 10411
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Although it is mentioned in the text it isn't 100% clear that a view has only one conforming viewpoint. Define a constraint for a view that only one conform relationship to a viewpoint is allowed.

  • Reported: SysML 1.0 — Fri, 13 Oct 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Callout notation for many clients/suppliers

  • Key: UMLR-141
  • Legacy Issue Number: 12511
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    It is allowed that for example a trace relationship has more than one client or supplier. It is unclear how the callout notation looks like for such a relationship.

  • Reported: SysML 1.0 — Tue, 27 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT