OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML16-139 Abstract syntax for the initial values SysML 1.4 open
SYSML16-90 Is <> keyword (or stereotype) on binding connectors is part of SysML notation? SysML 1.4 open
SYSML16-181 Binding Connector should not be typed SysML 1.4 open
SYSML16-143 Can a SysML Full Port be typed by a ValueType? SysML 1.4 open
SYSML16-132 Semantics consistency of conjugated behavior ports SysML 1.4 open
SYSML16-201 Behavior Diagram Element tables imply diagrams can be nodes SysML 1.4 open
SYSML16-198 Most diagram headers in document are not consistent with Appendix A, p 189. SysML 1.4 open
SYSML16-183 SysML specification document cleanups SysML 1.4 open
SYSML16-182 NestedConnectorEnd violates UML "roles" constraint SysML 1.4 open
SYSML16-67 Compartment labelling rules SysML 1.4 open
SYSML16-50 Flow properties and activity paramters SysML 1.4 open
SYSML16-108 9.3.2.4 direction of ports SysML 1.4 open
SYSML16-109 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 open
SYSML16-130 Flow property description: incorrect wording (§9.3.2.7) SysML 1.4 open
SYSML16-186 The type of ParticipantProperty SysML 1.4 open
SYSML16-203 Update description about extension of UML SysML 1.4 open
SYSML16-188 ParticipantProperty keyword SysML 1.4 open
SYSML16-165 Initial values compartment header inconsistent with others SysML 1.4 open
SYSML16-154 Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous SysML 1.4 open
SYSML16-148 Inherit from a conjugated interface block SysML 1.4 open
SYSML16-191 Keyword signal in reception compartment is superfluous SysML 1.4 open
SYSML16-192 SysML does not clearly defines how an association defines properties SysML 1.4 open
SYSML16-202 Activity should not be included as graphical node included in activity diagrams SysML 1.4 open
SYSML16-177 Incorrect multiplicity for base_xxx properties of most SysML Stereotypes SysML 1.4 open
SYSML16-180 AdjunctProperty principal should be a NamedElement SysML 1.4 open
SYSML16-168 DeriveReqt constraints multiplicity of Client and Supplier SysML 1.4 open
SYSML16-171 xmi:IDs are not convenient SysML 1.4 open
SYSML16-173 Wrong parameter for Operations in the SysML.xmi SysML 1.4 open
SYSML16-166 RequirementRelated is present in the summary but no more in the document SysML 1.4 open
SYSML16-179 Hanging Clauses Throughout SysML 1.4 SysML 1.4 open
SYSML16-131 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 open
SYSML16-185 Instance for Initial values SysML 1.4 open
SYSML16-228 Shared parts are still parts SysML 1.4 open
SYSML16-229 Constant Block Value Properties SysML 1.4 open
SYSML16-204 Requirement ID should be immutable SysML 1.4 open
SYSML16-226 Arbitrary diagram linkage to model elements SysML 1.4 open
SYSML16-230 Numeric Literals as constraint block property parameter values SysML 1.4 open
SYSML16-172 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 open
SYSML16-167 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 open
SYSML16-227 Specify a specific part from a collection of parts on an IBD SysML 1.4 open
SYSML16-231 Diagram formality confusion SysML 1.4 open
SYSML16-275 Typo in xmi file for orderedMember SysML 1.4 open
SYSML16-288 The AdjunctProperty is not clearly described SysML 1.4 open
SYSML16-174 Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 SysML 1.4 open
SYSML16-87 Port labels inside Port symbol SysML 1.4 open
SYSML16-178 The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes SysML 1.4 open
SYSML16-86 Section 9.3.1.7 SysML 1.4 open
SYSML16-127 SysML Issues on Item Property values in an IBD SysML 1.4 open
SYSML16-170 No support for dot notation in activity and sequence diagrams SysML 1.4 open
SYSML16-196 layout error for compartment name SysML 1.4 open
SYSML16-205 SysML Provides Inadequate Support for Reuse of Requirements SysML 1.4 open
SYSML16-199 BNF definitions have literals/terminals in italics, which seems to imply that the occurrences of these strings should be in italics, but they are not. SysML 1.4 open
SYSML16-193 Constraint clarification SysML 1.4 open
SYSML16-195 Missing one right parenthesis in the constraint equation SysML 1.4 open
SYSML16-184 ISO DIS 19514 (JTC1 Comments against SysML 1.4) SysML 1.4 open
SYSML16-187 ParticipantProperty stereotype is redundant SysML 1.4 open
SYSML16-94 Problems with 1.3 Enumeration Literals SysML 1.4 open
SYSML16-122 SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are SysML 1.4 open
SYSML16-126 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 open
SYSML16-120 ProxyPort with FlowProperties SysML 1.4 open
SYSML16-97 Interface blocks and protocols SysML 1.4 open
SYSML16-61 Another issue with allocate SysML 1.4 open
SYSML16-169 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 open
SYSML16-88 9.3.2.9 What is InterfaceBlock? SysML 1.4 open
SYSML16-159 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 open
SYSML16-158 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 open
SYSML16-134 proxy and full port notation change request SysML 1.4 open
SYSML16-133 Semantics clarification for removing a value from an out Flow Property SysML 1.4 open
SYSML16-129 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 open
SYSML16-128 Pull semantics for flow properties SysML 1.4 open
SYSML16-123 The SysML classification of properties is incomplete SysML 1.4 open
SYSML16-34 Requirement constants should be integrated into Model-centric vision of SysmL SysML 1.4 open
SYSML16-175 Dubious UUIDs SysML 1.4 open
SYSML16-176 Missing comment for some attributes SysML 1.4 open
SYSML16-149 <> should be a reference (dashed box) SysML 1.4 open
SYSML16-56 Figure B.35 object nodes SysML 1.4 open
SYSML16-125 Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors SysML 1.4 open
SYSML16-145 ElementGroup cannot be source or target of a dependency SysML 1.4 open
SYSML16-124 About Rate, Continuous and Discrete SysML 1.4 open
SYSML16-119 primitive types in SysML Activities SysML 1.4 open
SYSML16-93 SysML: References to CreateEvent incorrect SysML 1.4 open
SYSML16-89 clarification, what "part property" is SysML 1.4 open
SYSML16-83 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 open
SYSML16-82 Question about the Activity decomposition in Block Definition Diagrams SysML 1.4 open
SYSML16-189 Derived attribute should also be read only SysML 1.4 open
SYSML16-206 Expand use of rake symbol for all decompositions SysML 1.4 open
SYSML16-164 ConnectorProperty notation in wrong section. SysML 1.4 open
SYSML16-163 Parts, references, values compartments in wrong section SysML 1.4 open
SYSML16-162 Description of model elements in generated document not consistent with specification SysML 1.4 open
SYSML16-161 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 open
SYSML16-160 Cannot navigate and represent deep nested defining feature in a slot SysML 1.4 open
SYSML16-157 specializations of requirement should specialize AbstractRequirement SysML 1.4 open
SYSML16-156 A discarded resolution still appears in the ballot SysML 1.4 open
SYSML16-152 Property path notation SysML 1.4 open
SYSML16-147 More than one View() operation allowed SysML 1.4 open
SYSML16-146 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 open
SYSML16-144 [SysML] Semantic variation points SysML 1.4 open
SYSML16-142 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 open
SYSML16-141 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 open
SYSML16-140 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 open
SYSML16-138 Update to Trace Relationship’ SysML 1.4 open
SYSML16-135 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 open
SYSML16-118 Semantics of multiple Dependencies SysML 1.4 open
SYSML16-103 VerdictKind SysML 1.4 open
SYSML16-102 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 open
SYSML16-101 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 open
SYSML16-96 How to refer to properties of an extension? SysML 1.4 open
SYSML16-85 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 open
SYSML16-81 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 open
SYSML16-80 Issue on Block constraint#4 SysML 1.4 open
SYSML16-75 Content of Requirement::/tracedTo SysML 1.4 open
SYSML16-74 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 open
SYSML16-71 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 open
SYSML16-70 Where have stereotypes been defined? SysML 1.4 open
SYSML16-65 SysML Issue on Refine limitations SysML 1.4 open
SYSML16-58 SysML Issue representation of properties as associations SysML 1.4 open
SYSML16-57 SysML Issue based on UML 15369 SysML 1.4 open
SYSML16-55 SysML 1.2 Issues: Optional with streaming SysML 1.4 open
SYSML16-54 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 open
SYSML16-53 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 open
SYSML16-52 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 open
SYSML16-51 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 open
SYSML16-49 Inheriting Allocations SysML 1.4 open
SYSML16-59 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 open
SYSML16-60 SysML primitive value types SysML 1.4 open
SYSML16-47 Do parametric bindings observe derived and read-only properties SysML 1.4 open
SYSML16-45 callout notation issues SysML 1.4 open
SYSML16-36 Support BDD's for State Machines SysML 1.4 open
SYSML16-35 Binding Relationships require unit conversions SysML 1.4 open
SYSML16-31 Requirements interchange issue SysML 1.4 open
SYSML16-30 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 open
SYSML16-29 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 open
SYSML16-28 SysML: Align SysML Activities with Foundational UML SysML 1.4 open
SYSML16-14 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 open
SYSML16-11 Lack of notation for units and dimensions on values. SysML 1.4 open
SYSML16-10 BindingConnector end s multiplicity SysML 1.4 open
SYSML16-155 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 open
SYSML16-151 Provide support to capture engineering quantities and support intricate calculations SysML 1.4 open
SYSML16-153 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 open
SYSML16-190 2016-03-31 Online meeting minutes SysML 1.4 open
SYSML16-200 2015-10-15 Online meeting minutes SysML 1.4 open
SYSML16-197 "Allocated From" should be "Allocated" SysML 1.4 open
SYSML16-150 Missing property descriptions for Probability and Rate SysML 1.4 open
SYSML16-194 Causality of constraints in parametric diagrams SysML 1.4 open
SYSML16-17 Item Flows on Activity Diagrams SysML 1.4 open
SYSML16-16 Inferred Allocation on Allocate Activity Partitions SysML 1.4 open
SYSML16-13 Sample problem: Parts are added directly into package SysML 1.4 open
SYSML16-12 It is not allowed in UML to display stereotypes of related elements SysML 1.4 open
SYSML16-9 Issue: Nested connector ends SysML 1.4 open
SYSML16-7 Block namespace compartment: Are external relationships allowed SysML 1.4 open
SYSML16-3 SysML: Generalizing Activites SysML 1.4 open
SYSML16-2 SysML: UML Qualified Associations SysML 1.4 open
SYSML16-1 SysML: Protocol State Machines needed SysML 1.4 open

Issues Descriptions

Abstract syntax for the initial values

  • Legacy Issue Number: 19286
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The abstract syntax supporting the specification of initial values for properties of SysML block has to be clarified and aligned with the intended semantics.

    In SysML 1.4, §8.3.1.2.8 says: “A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block.

    These values override any default values that may have been previously specified on these properties on their originally

    defining block”

    While §8.3.2.3 says: “An entire tree of context-specific values can be specified on a containing block to carry values of nested

    properties as shown on an internal block diagram”, then: “If a property belonging to a block has a specification of initial values for any of the properties belonging to its type, then

    the default value of that property must be a UML InstanceValue element. This element must reference a UML

    InstanceSpecification element created to hold the initial values of the individual properties within its usage context. The

    instance specification must be unnamed and owned by the same package that owns the outermost containing block for

    which the initial values are being specified”

    If the specification of an initial value is “context specific”:

    · It cannot be specified using the default value of a property

    · It should be possible to distinct initial value depending on the context, i.e. we need a resolution mechanism to know which initial value has to be used

  • Reported: SysML 1.4 — Fri, 21 Mar 2014 04:00 GMT
  • Updated: Wed, 17 Jan 2018 16:12 GMT
  • Attachments:

Is <> keyword (or stereotype) on binding connectors is part of SysML notation?

  • Key: SYSML16-90
  • Legacy Issue Number: 17373
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Is <<equal>> keyword (or stereotype) on binding connectors is part of SysML notation? Figure 9.7 Usage example of proxy and full ports

  • Reported: SysML 1.4 — Thu, 17 May 2012 04:00 GMT
  • Updated: Wed, 17 Jan 2018 15:56 GMT

Binding Connector should not be typed

  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The Specification says

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.

    What would be the meaning of an Association used as a type for this Connector? I fail to see one. Should there be a Constraint, that doesn't allow a type for a Binding Connector?

    Suggestion
    Add following Constraint to the Binding Connector definition
    inv: type = null

  • Reported: SysML 1.4 — Fri, 26 Feb 2016 17:33 GMT
  • Updated: Tue, 19 Dec 2017 12:09 GMT

Can a SysML Full Port be typed by a ValueType?

  • Legacy Issue Number: 19412
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Several users at JPL have been asking me about this particular combination.
    I can't find anything in the 1.4 spec precluding typing a full port by a value type.

    Have I missed anything?

  • Reported: SysML 1.4 — Mon, 12 May 2014 04:00 GMT
  • Updated: Thu, 14 Dec 2017 16:46 GMT

Semantics consistency of conjugated behavior ports

  • Legacy Issue Number: 18952
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Per the definition of behavior proxy ports, they have their owner for value. This implies that a classifier typing a port is a classifier for the owner of the port as well. However, when that classifier specifies directed features or flow properties, these feature specifications shall be interpreted so that their directions are reverted if the port is conjugated (isConjugated=true). The point is that, if the owner is not itself a port, there is no means to specify that such an interpretation applies. Thus, assuming one needs to refer to the owner as the instance realizing the port, it will be required to explicitly use (and then model) a classifier specifying the corresponding feature in the opposite direction. This makes the useful conjugation concept unusable in practice.

    The implementation of the conjugation concept should be modified so that it is not limited to port and applicable to block definitions as well.

  • Reported: SysML 1.4 — Wed, 25 Sep 2013 04:00 GMT
  • Updated: Thu, 14 Dec 2017 13:13 GMT

Behavior Diagram Element tables imply diagrams can be nodes

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Filed for JD.
    The Diagram Element tables for the behavior chapters are captioned:
    "Graphical nodes included in <behavior> diagrams"
    and each have a row for an entire diagram, rather than just elements of the diagrams. This implies diagrams can be nodes in other diagrams, for example that an activity diagram can be in another activity diagram without an intervening call behavior action, which isn't true.

  • Reported: SysML 1.4 — Fri, 9 Oct 2015 12:55 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Most diagram headers in document are not consistent with Appendix A, p 189.

  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The majority of diagrams with frames have problems with their headers.
    The types of problems are as follows:
    1) Just the diagram type (no element name, type, diagram type)
    2) Stereotypes in the header (not in the diagramusage field)
    3) Use of element type not listed in the Appendix (e.g., activity)
    4) Can't tell if the text field is an element name or a diagram name
    5) All text, not just the diagram type, is bold.
    6) Non-obvious element type (block, package, ?)

    These problems make the spec look like it was carelessly made. When the results are ambiguous or unclear, it encourages sloppy modeling by users.

  • Reported: SysML 1.4 — Thu, 5 Nov 2015 22:02 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT


NestedConnectorEnd violates UML "roles" constraint

  • Legacy Issue Number: 19813
  • Status: open  
  • Source: Anonymous
  • Summary:

    UML's constraint "UML::Connector::role" specifies that ConnectorEnds need to point to roles/parts owned by the Connector's structuredClassifier (direct or inherited).

    The specification draft 1.0 contained an explicit statement that SysML relaxed a limited number of the UML constraints ("roles" being one of them). This was e.g. mentioned in 0.11 on page 4 of document ad/2006-03-01.

    In the current 1.4 beta, section 4.4 "Extension Mechanisms" doesn't mention contraint relaxation as one of the applied techniques.

    Moreover, the specification of NestedConnectorEnd (8.3.1.2.6, 8.3.2.11) does not mention this relaxation either.

    Without a formal statement about this relaxation, I would conclude that the SysML spec conflicts with the UML spec.

  • Reported: SysML 1.4 — Tue, 30 Jun 2015 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Compartment labelling rules

  • Key: SYSML16-67
  • Legacy Issue Number: 16057
  • Status: open  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Suggest these compartment rules:

    • Italics
    • Plural
    • All lower case
    • Words separated by spaces
  • Reported: SysML 1.4 — Fri, 11 Mar 2011 05:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Flow properties and activity paramters

  • Key: SYSML16-50
  • Legacy Issue Number: 15176
  • Status: open  
  • Source: Françse ( Caron)
  • Summary:

    The SysML flow properties specify elementary flows (nature and direction) that can cross the boundary of a block through a port.

    According to the functional approaches of systems engineering, an entering flow when getting over the boundary of a block is handled as an input by at least one function of the block. An outgoing flow getting out the boundary of the same block is produced as an output by at least one function.

    Activity diagrams are used for carrying out functional graphs with SysML. Inputs and outputs of SysML activities are specified by parameters. Nevertheless SysML does not seem to provide any mean to relate activity input / output parameters to the flow properties. This entails that the unfortunate SysML developers, after having made careful and strenuous efforts for specifying the block interfaces with flow properties and ports, have no other solution than to redo exactly the same work for specifying the inputs / outputs of the functional architecture as activity parameters (or vice-versa). Moreover, there is no mean to ensure consistency in the SysML model between the flow properties and the activity parameters and neither between the ports and the activity pins.

    A solution would be to enable to use flow properties like parameters as activity inputs / outputs.

  • Reported: SysML 1.4 — Fri, 16 Apr 2010 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

9.3.2.4 direction of ports

  • Legacy Issue Number: 18439
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port?
    This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

  • Reported: SysML 1.4 — Mon, 11 Feb 2013 05:00 GMT
  • Updated: Thu, 12 Oct 2017 08:48 GMT

9.3.2.4 direction of ports and their notation (second issue)

  • Legacy Issue Number: 18441
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???

    More specifically – can port be stereotyped as directed feature/flow property, what types of properties can be stereotypes with these stereotypes?

    This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

  • Reported: SysML 1.4 — Mon, 11 Feb 2013 05:00 GMT
  • Updated: Thu, 21 Sep 2017 14:29 GMT

Flow property description: incorrect wording (§9.3.2.7)

  • Legacy Issue Number: 18907
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The description of the semantics related to the direction (in, ou, inout) incorrectly refers to contained “blocks” instead of properties and the description for “inout” is inconsistent (cannot be instantiated )

  • Reported: SysML 1.4 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Thu, 21 Sep 2017 13:59 GMT

The type of ParticipantProperty

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:

    The types of participant properties can be elided if desired.

    But constraints says:
    [5] A property stereotyped by ParticipantProperty must have the same type as the property referred to by the end attribute.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:11 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

Update description about extension of UML

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The description on page 12 how SysML extends UML is based on UML 2.4. The package structure of UML has changed from UML 2.4 to UML 2.5. The bullet list must be updated accordingly. For instance SysML::ModelElements does not extend UML classes, but beside others UML common structures.

  • Reported: SysML 1.4 — Thu, 17 Sep 2015 09:02 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

ParticipantProperty keyword

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:
    The keyword «participant» before a property name indicates the property is stereotyped by ParticipantProperty.

    Why and how SysML can redefine how stereotype is represented?
    According the UML spec, stereotype is represented by showing its original name in <<>>.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 18:32 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

Initial values compartment header inconsistent with others

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    SysML compartment headers are usually all lower case with spaces separating words, but for initial values it's "initialValues". Suggest changing it to "initial values".

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:38 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Constraint [4] of a Block says:

    [4] In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association.
    (An inverse end of this association, whether owned by another block or the association itself, must always be
    present so there is always a metamodel element to record the inverse multiplicity of the reference.)

    The referenced constraint in the UML metamodel does not exist. The UML specification says:

    A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.

    I propose to remove the constraint [4], i.e. to allow to model part properties without an association. The reduces the number of model elements (1 property versus 2 properties + 1 association), makes the model simpler for the model builder and user, and reduces the effort for model maintenance.

    In particular it is valuable when using generalization and redefinition. Without an association an inherited property could simply be redefined. An inherited property defined by an association that should be redefined, requires to create a new association that specializes the association and lots of redefinitions. That makes modeling very cumbersome.

  • Reported: SysML 1.4 — Fri, 12 Feb 2016 09:41 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT
  • Attachments:

Inherit from a conjugated interface block

  • Legacy Issue Number: 19644
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Figure 9.7 shows that the types of parts that are connected with binding connectors with proxy ports inherit from the proxy port types. That assures that all the features of the interface block type of the proxy port are implemented by the part.

    However in practice you typically have for most proxy ports also a connected conjugated proxy port. You can't inherit from a conjugated interface block and therefore must manually define a conjugated version of the interface block. In summary that supersedes the concept of conjugation.

  • Reported: SysML 1.4 — Fri, 17 Oct 2014 04:00 GMT
  • Updated: Thu, 3 Aug 2017 08:00 GMT

Keyword signal in reception compartment is superfluous

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The resolution of issue SYSMLR-153 describes the reception compartment of blocks that was not yet covered by SysML. The notation of SYSMLR-153 is identical with the notation defined in the UML specification.

    The signal keyword before the reception is superfluous. The reception compartment already unambiguously depicts that only receptions are shown.

    I propose to remove the keyword <<signal>> from the notation.

  • Reported: SysML 1.4 — Sun, 28 Feb 2016 16:36 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

SysML does not clearly defines how an association defines properties

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    In section 8.3.1.3 the SysML specification excludes the dot notation of the association that shows the ownership of the defined properties.

    But the SysML specification does not specify how the ownership of properties is defined. There are different usages of the association relationship like composition in bdd, actor/use case relationship or in conceptual bdds. Different usages require different ownerships of the defined properties.

    Proposal:
    Define a default and allow the dot notation if the modeler wants to define it differently.

  • Reported: SysML 1.4 — Fri, 5 Feb 2016 12:17 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Activity should not be included as graphical node included in activity diagrams

  • Legacy Issue Number: 19836
  • Status: open  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Table 11.1 includes a set of concrete syntax symbols that are "graphical nodes included in activity diagrams." One of these represents an Activity diagram. Activity diagrams do not include activities as one of the possible nodes in the meta-model. I suggest you remove that line of the table to make is clear that Activity Diagrams do not contain activities.

  • Reported: SysML 1.4 — Thu, 24 Sep 2015 04:00 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Incorrect multiplicity for base_xxx properties of most SysML Stereotypes

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

    In the current version of SysML.xmi, all the stereotype properties referring to the element to which the stereotype is applied (the so-called "base_xxx" ones) have [0..1] multiplicities, except for the following stereotypes: FlowSpecification (deprecated), FlowPort (deprecated) and TriggerOnNestedPort.

    Basically, these multiplicities shall be [1..1] except for stereotypes that may be applied to more than one metaclass. That is for SysML: TestCase, Rate, Probability and ControlOperator

  • Reported: SysML 1.4 — Wed, 10 Aug 2016 11:01 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

AdjunctProperty principal should be a NamedElement

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

    The specification says:

    Attributes
    • principal : Element [1]

    [2]Properties to which AdjunctProperty applied must have the same name as the principal.

    A name isn't mandatory for an UML Element.

    => principal type should be NamedElement

  • Reported: SysML 1.4 — Thu, 4 Aug 2016 14:25 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

DeriveReqt constraints multiplicity of Client and Supplier

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

    Here are the constraints for DeriveReqt

    [1]The supplier must be an element stereotyped by «requirement» or one of «requirement» subtypes.
    [2]The client must be an element stereotyped by «requirement» or one of «requirement» subtypes.

    DeriveReqt extends Abstraction and an Abstraction can have many NamedElement as Client and Supplier.

    7.3.12 Dependency (from Dependencies)
    client: NamedElement [1..*]
    supplier: NamedElement [1..*]

    Here are some options:

    • add a constraint to restrict to 1 NamedElement in Client and Supplier
    • Stereotype required only on the first NamedElement
    • Stereotype required on all NamedElement
  • Reported: SysML 1.4 — Fri, 20 May 2016 15:06 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

xmi:IDs are not convenient

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

    The xmi:IDs used in SysML related XMI files we publish are not convenient.
    They are too big and too sensitive to model change.

    We need to come back to something more compact and more robust

  • Reported: SysML 1.4 — Mon, 12 Sep 2016 13:44 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Wrong parameter for Operations in the SysML.xmi

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

    In the current version of SysML.xmi, none of the operation parameter is serialized with its direction. Which means that they all have the default direction, i.e.: "in". This is of course wrong for all the return parameters. By the way, as serialized, the operations have no return parameter and so no type.

  • Reported: SysML 1.4 — Thu, 11 Aug 2016 13:53 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

RequirementRelated is present in the summary but no more in the document

  • Legacy Issue Number: 19757
  • Status: open  
  • Source: Anonymous
  • Summary:

    RequirementRelated is present in the summary (16.3.2.4) but no more in the document

    => The problem put all the section 16.3.2 in disorder

    Also RequirementRelated is still present (as Deprecated) in the profile I'm working with
    (The one that will be used in eclipse-Papyrus).

  • Reported: SysML 1.4 — Mon, 11 May 2015 04:00 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Hanging Clauses Throughout SysML 1.4

  • Status: open  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    ISO/IEC Directives Part 2 2016 clause 22 states than each and every clause and subclause of the spec should be numbered, and hanging clauses should be avoided. Any numbered clause containing text or figures than that has a subordinate numbered clause becomes a hanging clause, because it does not have a unique number assigned to it.

    List of known hanging clauses in SysML 1.4 (exclusive of un-numbered ‘subpart’ text on pages 1, 19, 103, 145, and 185):
    6.2 page 17
    7.1 page 21
    7.3.2 page 26 (figure only)
    8.3.1.1 page 42
    8.3.1.2 page 44
    8.3.2 page 47 (figures only)
    8.3.3.1 page 59 (figure only)
    8.3.3.2 page 60 (figure only)
    9.1 page 71
    9.3.2 page 79 (figures only)
    10.3.2 page 100 (figure only)
    11.1 page 105
    11.3.1 page 114
    11.3.2 page 117 (both text and figure)
    11.3.3.1 page 121 (both text and figure)
    12.3.1 page 133
    15.3.2 page 150 (figure only)
    15.4 page 152 (both text and figure)
    15.4.2 page 153 (both text and figure)
    16.3.2 page 164 (figure only)
    16.4 page 168
    17.2.1 page 176 (figure only)
    17.2.2 page 178 (figure only)
    B.2 page 194 (figure only)
    C.1 page 203
    E.5.2 page 254 (both figures and text)
    E.6.5 page 286 (both figure and text)
    Annex F (no paragraph number)
    G.4 page 318

  • Reported: SysML 1.4 — Thu, 18 Aug 2016 15:39 GMT
  • Updated: Thu, 27 Jul 2017 21:15 GMT

Proxy port “complete” specification (§ 9.3.2.12):

  • Legacy Issue Number: 18909
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    if a proxy port P1 has a nested proxy port P1::P2 and both are non-behavioral, does it mean that both P1 and P1::P2 must be explicitly connected to internal parts? If P1 is just a logical group of nested proxy ports, there may be no sense to connect P1 per se internally (but it makes sense to connect P1 externally).

  • Reported: SysML 1.4 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Tue, 4 Jul 2017 00:38 GMT
  • Attachments:

Instance for Initial values

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:
    The instance specification must be unnamed and owned by the same package that owns the outermost containing block for which the initial values are being specified.

    There is no reason why instance should be unnamed or must be owned in particular package, the same as blocks are defined in. Opposite, it would be very useful to use named instances and other packages for ownership.

    Proposal : remove both redundant constraints from the text.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:17 GMT
  • Updated: Tue, 13 Jun 2017 09:03 GMT

Shared parts are still parts

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

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

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:10 GMT
  • Updated: Mon, 5 Jun 2017 14:35 GMT

Constant Block Value Properties

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

    It would be very useful to have the ability to distinguish between value properties that are constants and those that are situational/dynamic. This may be more a case of allowing block property values to be declared as constants (or constraint values) – perhaps because they formalise values stated in requirements. Whereas the remaining block property values are derived from evaluation of the parametric constraints.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:18 GMT
  • Updated: Mon, 5 Jun 2017 14:04 GMT

Requirement ID should be immutable

  • Legacy Issue Number: 19764
  • Status: open  
  • Source: Anonymous
  • Summary:

    Requirement IDs, as currently specified by the standard and implemented by vendors, are not adequate to ensure robust traceability outside MBSE models. The standard describes ID as "The unique Id of the requirement”. I would suggest replacing this sentence with "The unique and immutable Id of the requirement." This immutable characteristic is key to ensure robust traceability throughout a project with external stakeholders and documents.

    The current practice of using a hierarchical number for the ID is bad practice that should be discouraged, because a hierarchical ID will necessary change when the hierarchy is refactored, which is almost guaranteed to happen. This breaks traceability. I recognize that there is also a need for a hierarchical ID, mainly to be used to sort requirement tables properly using this property. For that use case, I would suggest a new ID called HID with the following description: “A unique hierarchical identifier, used to organize requirements within a package”

    Since we now have two different IDs that serve two different purposes, we should give guidance for which one should be used as the prefix in front of the name, depending of the context. My suggestion is as follows:

    • In a traceability context, the ID should be the prefix shown in front of the name. For example, when showing the table column "Derived From", the ID should be the prefix shown, not the HID.
    • In a hierarchical context (for example, in the containment tree), the HID should be shown as the prefix in front of the name.
    • When in doubt, use the ID in preference over HID.
  • Reported: SysML 1.4 — Fri, 29 May 2015 04:00 GMT
  • Updated: Mon, 5 Jun 2017 13:24 GMT

Arbitrary diagram linkage to model elements

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

    Most modelling tools provide some means of connecting a model element to any of the diagrams in the model and then provide a means of (tool users) navigating through the linked diagrams by opening the linked diagrams directly from the nodes representing these model elements on a diagram. (The means for doing this is tool specific, although common conventions for following links exist in many GUI environments.) In general this is a very useful feature. Is it not time that the SysML standard acknowledged this and standardised it?
    Two further considerations arise:
    1. XMI support for denoting the model element diagram linkage, and
    2. The standardised means of indicating that a diagram node has linked diagrams, perhaps by the adornment with a defined glyph in a specified location on the nodes shape.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 17:10 GMT
  • Updated: Mon, 5 Jun 2017 11:06 GMT

Numeric Literals as constraint block property parameter values

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

    It would be very useful to have the ability to have literal values as parameter values to a constraint block property. (Helps with reuse of constraint blocks.) Even better, to be able to use named constants from a (shared) library package (i.e. a different namespace), which could combine a description of the value with quantity and unit attributes.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:26 GMT
  • Updated: Mon, 5 Jun 2017 11:03 GMT

SysML XMI typos in UML StandardProfile XMI references

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    http://www.omg.org/spec/SysML/20150709/SysML.xmi, I think when SysML specializes UML's standard profile, uses "_base" instead of "-base" in the reference. Here are a couple examples, might be more:

    1) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine_base_Abstraction"/>
    should be :
    <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine-base_Abstraction"/>

    2) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace_base_Abstraction"/>
    should be:
    <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace-base_Abstraction"/>

  • Reported: SysML 1.4 — Sun, 21 Feb 2016 15:01 GMT
  • Updated: Tue, 30 May 2017 16:18 GMT

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

  • Status: open  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

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

  • Reported: SysML 1.4 — Thu, 24 Mar 2016 16:30 GMT
  • Updated: Tue, 30 May 2017 15:17 GMT

Specify a specific part from a collection of parts on an IBD

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

    There is no way of saying which part from a collection (i.e. a plural cardinality/multiplicity) is being shown and hence there is no clear and unambiguous way of showing multiple parts from a collection separately on an IBD. E.g. the spokes on a wheel is easily modelled in a BDD as a collection of spokes, but not easily set out in an IBD, whereas, individually named (by role) spokes can be set out in an IBD, but, for more than a few, this becomes awkward to show on a BDD.
    For at least ordered collections (i.e. plural multiplicities) of parts (aggregate roles) the traditional use of square bracket array notation could be used, e.g. mypart[10] would refer to the 10th instance of part collection called "mypart". For unordered collections a selector (i.e. query) would be required.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 17:47 GMT
  • Updated: Tue, 30 May 2017 14:54 GMT

Diagram formality confusion

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

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

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

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

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

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

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

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

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

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

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

  • Reported: SysML 1.4 — Mon, 27 Feb 2017 12:56 GMT
  • Updated: Tue, 30 May 2017 14:30 GMT

Typo in xmi file for orderedMember

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

    There is a typo in the xmi file for ElementGroup orderedMember

    See http://www.omg.org/spec/SysML/20150709/SysML.xmi
    <ownedAttribute
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber" xmi:type="uml:Property">
    <name>orderedMemeber</name>
    <isOrdered>true</isOrdered>
    <lowerValue
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_lowerValue" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_lowerValue" xmi:type="uml:LiteralInteger">
    </lowerValue>
    <upperValue
    xmi:id="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_upperValue" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber_upperValue" xmi:type="uml:LiteralUnlimitedNatural">
    <value>*</value>
    </upperValue>
    <type href="http://www.omg.org/spec/UML/20131001/UML.xmi#Element"/>
    <subsettedProperty xmi:idref="SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.member"/>
    </ownedAttribute>

    Task replace orderedMemeber by orderedMember to be compliant with the pdf norm.

  • Reported: SysML 1.4 — Tue, 21 Mar 2017 08:39 GMT
  • Updated: Tue, 30 May 2017 14:17 GMT

The AdjunctProperty is not clearly described

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

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

  • Reported: SysML 1.4 — Fri, 28 Apr 2017 12:53 GMT
  • Updated: Tue, 30 May 2017 14:14 GMT

Spec document inconsistent with Normative profile XMI file ptc/2013-12-11

  • Legacy Issue Number: 19817
  • Status: open  
  • Source: Anonymous
  • Summary:

    Spec document says:
    7.3.2.6 Stakeholder

    Description

    A stakeholder represents a role, group or individual who has concerns that will be addressed by the View of the model.

    Attributes

    • concernList: Comment [*]

    The interests of this stakeholder.

    • /concern: String [*]

    The interests of this stakeholder displayed as the body of the comments from concernList.


    XMI file says something completely different

    Stereotype Stakeholder
    concern: Comment [1..*]
    /concernlist : Comment

  • Reported: SysML 1.4 — Fri, 17 Jul 2015 04:00 GMT
  • Updated: Mon, 1 May 2017 00:28 GMT

Port labels inside Port symbol


The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes

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

    The pdf is that Refine and Trace have 2 specializations but have only one generalization in the xmi file
    (http://www.omg.org/spec/SysML/20150709/SysML.xmi)

    Some elements extracted from the pdf and the xmi

    16.3.2.3 Refine
    Description
    The Refine stereotype specializes UML4SysML Refine and DirectedRelationshipPropertyPath to enable refinements to
    identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and
    targets.

    <name>Refine</name>
    <generalization
    xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Refine._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Refine._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:type="uml:Generalization">
    <general xmi:idref="SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath"/>
    </generalization>
    <ownedAttribute ....

    16.3.2.7 Trace
    Description
    The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify
    their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.

    <name>Trace</name>
    <generalization
    xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Trace._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Trace._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:type="uml:Generalization">
    <general xmi:idref="SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath"/>
    </generalization>
    <ownedAt

    For information, the bug has been raised for the Papyrus SysML implementation
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=497650

  • Reported: SysML 1.4 — Mon, 11 Jul 2016 13:16 GMT
  • Updated: Mon, 1 May 2017 00:28 GMT

Section 9.3.1.7

  • Key: SYSML16-86
  • Legacy Issue Number: 17248
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    9.3.1.7. The keyword “full” before a property name indicates the property is stereotyped by ProxyPort . Copy/paste bug? <<full>> is for FullPorts.

    What is the type of FullPort? Spec says nothing.

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

  • Reported: SysML 1.4 — Tue, 20 Mar 2012 04:00 GMT
  • Updated: Mon, 1 May 2017 00:28 GMT

SysML Issues on Item Property values in an IBD

  • Legacy Issue Number: 18805
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The SysML spec does not give any notation for (or example of) specifying the values of an item property participating in an item flow. For example, if water flows in multiple places in the distiller, each should be able to have a specified temperature and dissolved matter % (perhaps as distributions).

    Perhaps a variant of a property specific type would work, perhaps a callout approach would work.

    It possible, it would be desirable to allow for multiple item properties:item flows to have the same name within an ibd, as this would be a natural modeling approach (e.g., all the pipes covey the same thing, but with different values).

  • Reported: SysML 1.4 — Tue, 9 Jul 2013 04:00 GMT
  • Updated: Thu, 30 Mar 2017 16:16 GMT

No support for dot notation in activity and sequence diagrams

  • Status: open  
  • Source: NASA ( Robert Karban)
  • Summary:

    The SysML notation does not provide a way to display nested properties as life lines on sequence diagrams or swimlanes/partitions on activity diagrams.

    Supporting dot notation would enable the user of sequence diagrams to reference nested properties and facilitate the construction of swimlanes on activity diagrams where the user now has to construct nested swimlanes.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 20:42 GMT
  • Updated: Mon, 20 Mar 2017 18:07 GMT

layout error for compartment name

  • Legacy Issue Number: 19858
  • Status: open  
  • Source: Anonymous
  • Summary:

    The "part" (name of the third compartment of the block Block1 in Table 8.1) exceeds its scope/space. Name: Jingang Zhou
    Employer: Neusoft
    mailFrom: zjg_robin@hotmail.com

  • Reported: SysML 1.4 — Wed, 25 Nov 2015 05:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

SysML Provides Inadequate Support for Reuse of Requirements

  • Status: open  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    SysML provides inadequate support for reuse of requirements. The «copy» relationship does not provide the flexibility necessary to support concepts like requirement archetypes and reusable requirement hierarchies.

    SysML supports reuse in other modeling areas by distinguishing the classier (definition of the concept) from the property (use of that concept in a composition context).

    • In structural modeling this is done with blocks that type part properties.
    • In parametric modeling this is done with constraint blocks that type constraint properties.
      This concept has already been extended in SysML to include activity modeling: activities (classifiers) called by call behavior actions, and depicting these called behavior actions as adjunct properties on a block definition diagram.

    In all three cases, the vehicle for reuse is a classifier that types or is called by a property of another classifier. It is appropriate to extend this approach to requirements, thus supporting requirement archetypes as classifiers, and requirements as properties of classifiers.

    • Requirement hierarchy can then follow the standard composition relationship, rather than the current containment relationship.
    • Requirements as properties are contextualized by the classifier owning them, yet inherit characteristics of the requirement archetype classifier typing them.
  • Reported: SysML 1.4 — Thu, 28 May 2015 04:04 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

BNF definitions have literals/terminals in italics, which seems to imply that the occurrences of these strings should be in italics, but they are not.

  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is probably occurs in many cases, but as an example, see page 40 section 8.3.

    <param -prop> ::= ‘ordered’ | ‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’

    This statement states the the literal "ordered" (and the rest of the list) should be in italics when used on diagrams throughout the spec It is not

  • Reported: SysML 1.4 — Mon, 23 Mar 2015 18:38 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

Constraint clarification

  • Status: open  
  • Source: Thematix Partners LLC ( Richard Welling)
  • Summary:

    SysML deviates significantly from the latest UML specification in its concept of constraint, and not in a bad way. But the resulting differences are not well defined in the SysML specification. The UML spec is quite explicit in restricting constraints only to ValueExpressions which not only evaluate to Boolean but, when evaluated, have no side effects on the model. From the UML 2.5 specification:

    7.6.3 Semantics. The specification of a Constraint is given by a ValueSpecification (see Clause 8) of type Boolean…A Constraint is evaluated by evaluating its specification. If the specification evaluates to true, then the Constraint is satisfied at that time. If the specification evaluates to false, then the Constraint is not satisfied, and the realization of the model in which the evaluation occurs is not valid.
    7.6.4 Notation. The Constraint may then be notated textually within braces ({}) according to the following BNF:
    <constraint> ::= ‘{‘ [ <name> ‘:’ ] <boolean-expression> ‘ }’
    7.8.3.6 Constraints (of Constraint Classifier).

    • boolean_value - The ValueSpecification for a Constraint must evaluate to a Boolean value.
    • no_side_effects - Evaluating the ValueSpecification for a Constraint must not have side effects.

    8.3.1 Expressions-Summary. Expressions are ValueSpecifications that specify values resulting from a computation.

    Moreover, the UML spec makes no qualification for the evaluation of OpaqueExpressions, i.e., they must evaluate to Boolean. This is clearly not the case for SysML-style constraints, which include mathematical expressions (i.e., ValueSpecification<OpaqueExpression) that can be evaluated to type real and can cause state transitions and other changes to a model. It is difficult to understand how one could execute a model without this capability. Perhaps the Boolean constraint on constraints is a holdover from the earliest days of UML. It is one thing to constrain the mere logic of code and quite another to constrain the reality of real world objects. Essentially, all constraints in SysML are expressed as OpaqueExpressions, with special cases (i.e., a<b) evaluating as Boolean. Since most tools make this SysML assumption, this difference needs to be formalized, or at least reconciled, in SysML Clause 10.

  • Reported: SysML 1.4 — Wed, 2 Dec 2015 04:09 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT
  • Attachments:

Missing one right parenthesis in the constraint equation

  • Legacy Issue Number: 19862
  • Status: open  
  • Source: Anonymous
  • Summary:

    The constraint "

    {v(n+1 = v(n)+a*32*3600/5280*dt}

    " for the containt block VelocityEquation in Figure D.34 lacks a right parenthesis, which results in error of the contraint.

  • Reported: SysML 1.4 — Thu, 26 Nov 2015 05:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

ISO DIS 19514 (JTC1 Comments against SysML 1.4)

  • Status: open  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    (cross posted email from Andrew Watson)
    Yves, Rick, SysML 1.5 RTF members,

    As I'm sure you remember, OMG used its PAS status to submit SysML 1.4 to ISO/IEC JTC1 for consideration as an International Standard. The ISO
    identifier is DIS 19514, and the specification was accompanied by this
    explanatory report:

    http://doc.omg.org/pas/15-04-01

    JTC1 Members have now finished voting on the proposal, and the results are available as ptc/16-06-01:

    http://doc.omg.org/ptc/16-06-01

    As you can see, the vote passed, but because there was one "No" vote, OMG is being asked to respond with a revision of the SysML specification that addresses some or all of the reviewers' comments, also contained in the above archive.

    Because the SysML 1.5 RTF is working on revising this specification,
    creating this revision falls to you.

    The JTC1 comments will need to be filed as OMG issues, and then addressed in a SysML revision. If you only address the JTC1 comments, then I suggest we make this the SysML 1.4.1 revision, and publish it within a couple of months via the Urgent Issue process. Alternatively, you may want to roll this into the SysML 1.5 revision, along with resolutions to other SysML
    issues.

    Once you've decided which approach you want to use, please let me know so that I can tell JTC1 within what time-frame they can expect the response to its members' comments.

    One other, related issue; the SysML 1.5 RTF expires just after the Orlando
    meeting, and we still need to decide how long an extension to put on the
    Orlando agenda. 3 months? Six? Please let me know.

    Thanks,

    Andrew

  • Reported: SysML 1.4 — Wed, 15 Jun 2016 12:45 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

ParticipantProperty stereotype is redundant

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    ParticipantProperty is a property which duplicates and references an AssociationEnd. Reasoning of this duplication is not explained in the spec and creates issues for implementation and model users.

    Association ends can be represented in IBD diagram of AssociationBlock directly.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 18:30 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

Problems with 1.3 Enumeration Literals

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

    In section 6.3 ,the convention is given that indicates that enumeration literals within SysML are named with the suffix of Kind.

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”).

    Several of the SysML enumeration literals are correctly named, but the following do not follow the convention:

    Section 9.3.2 Figure 9.1 FlowDirection --> FlowDirectionKind

    Section 9.3.2 Figure 9.4 FeatureDirection --> FeatureDirectionKind

    Section 11.3.3 Figure 11.9 ControlValue --> ControlValueKind

  • Reported: SysML 1.4 — Tue, 12 Jun 2012 04:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are

  • Legacy Issue Number: 18705
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    SysML 1.3 section 9.1.3 Proxy Ports and Full Ports states:

    Full ports cannot be behavioral in the UML sense of standing in for the owning object, because they handle features themselves, rather than exposing features of their owners, or internal parts of their owners.

    This is incorrect; see UML 2.5, section 11.3.3 Structured Classifier Semantics:

    A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. If there is no Behavior defined for this EncapsulatedClassifier, any communication arriving at a behavior Port is lost.

    Based on the UML 2.5 semantics of behavioral ports, there is no legitimate reason to exclude a SysML 1.3 FullPort to be behavioral in the UML sense.

    This is inconsistent with SysML 1.3, section 9.3.2.7 FlowProperty:

    Items going to or from behavioral ports (UML isBehavior = true) are actually going to or from the owning block. (See “Block” on page 66 for definition of owning block of proxy ports in this case.)

    The above is consistent with the UML 2.5 semantics but it is inconsistent with the SysML 1.3 semantics of FullPort above.

    Finally, SysML 1.3 section 9.3.2.8 FullPort states:

    They cannot be behavioral ports, or linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts.

    The notion that a behavioral port implies identity with the owning block or internal parts is incorrect and does not make sense.

    It would require that a behavioral port to be typed by its owning block or internal part.

    It would be impossible for a block A to have a behavioral port typed by B for example.

  • Reported: SysML 1.4 — Thu, 9 May 2013 04:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

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

  • Legacy Issue Number: 18783
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

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

  • Reported: SysML 1.4 — Thu, 20 Jun 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 08:29 GMT

ProxyPort with FlowProperties

  • Legacy Issue Number: 18676
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I struggle to use proxy port with flow properties. One idea is to use a behavioral port and to bind the flow properties with the behavior parameters. In chapter 9.3.2.7 about FlowProperties the spec states:

    The binding of flow properties on ports to behavior parameters can be achieved in ways not dictated by SysML. One approach is to perform name and type matching. Another approach is to explicitly use binding relationships between the ports properties and behavior parameters or block properties.

    What are port properties? A port has no properties, but the type of the port, e.g. a InterfaceBlock. And these properties are the same for any usage of the InterfaceBlock and I can’t use context-specific binding relationships.

  • Reported: SysML 1.4 — Thu, 18 Apr 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 08:28 GMT

Interface blocks and protocols

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

    The practical usage of port implies the ability to specify a protocol, especially when operations or receptions are provided but not only (this can be true with flow properties too).

    The UML::Interface metaclass (at L3) has a specific property to define a protocol. Note that this protocol is not an owned behavior but only a specification of conformance characteristics.

    I believe we should add something similar to our InterfaceBlock stereotype, even if we do not include UML protocol state machines.

  • Reported: SysML 1.4 — Fri, 27 Jun 2014 11:16 GMT
  • Updated: Thu, 16 Mar 2017 07:53 GMT

Another issue with allocate

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

    The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that’s ok according to the current SysML specification.

    However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context

    and not be valid in another context.

    I’ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn’t work. MagicDraw doesn’t allow blocks to be owner of a allocate.

    I’m not sure whether it is a tool issue or if I’ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I’m not sure if that’ll solve

    my problem.

    Any ideas?

  • Reported: SysML 1.4 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Thu, 16 Mar 2017 07:50 GMT

AllocateActivityPartition should be more formaly related to allocation Relationship

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

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

  • Reported: SysML 1.4 — Thu, 11 Feb 2016 15:33 GMT
  • Updated: Thu, 16 Mar 2017 07:33 GMT

9.3.2.9 What is InterfaceBlock?

  • Key: SYSML16-88
  • Legacy Issue Number: 17255
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now.
    InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort.

    Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties?
    Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only"
    constraint [4] - it must be constraint[4] for FullPort???

  • Reported: SysML 1.4 — Tue, 20 Mar 2012 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:31 GMT

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Status: open  
  • Source: NASA ( Robert Karban)
  • Summary:

    Issue:
    When ItemFlow connects (deeply) nested or inherited properties (e.g. ports or parts) we cannot uniquely identify the sources and targets in its context.

    Description:
    This is similar to other relationships which specialize DirectedRelationshipPropertyPath, e.g. "The Allocate stereotype
    specializes DirectedRelationshipPropertyPath to enable allocations to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets."

    The DirectedRelationshipPropertyPath stereotype based on UML DirectedRelationship.
    Stereotype <<ItemFlow>> extends UML metaclass UML4SysML::InformationFlow which specializes DirectedRelationship.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 18:48 GMT
  • Updated: Thu, 16 Mar 2017 07:31 GMT

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Status: open  
  • Source: NASA ( Robert Karban)
  • Summary:

    Issue:
    The descriptions in the specification are inconsistent regarding the constraints of what can actually flow over a connector.
    The ItemFlow is used to constrain what actually flows w/r/t the flow properties which specify what can flow.
    In other sections the specifications suggest that the ItemFlow actually loosening the constraint by allowing more general types to be flowing.

    Description:
    These are the inconsistent parts in the specification:

    9.3.2.11 ItemFlow, p86 states:
    An ItemFlow describes the flow of items across a connector or an association. It may constrain the item exchange between blocks, block usages, or ports as specified by their flow properties.

    9.3.2.11 ItemFlow, p87 states:
    Each classifier of conveyed items on an item flow must be the same as, a specialization of, or a generalization of at least one flow property type on each end of the connected block usages.

    9.4.6 Item Flow Decomposition, p95
    Item flows can also be more general than the actual flow, as shown by the connector on the right. The water distiller produces distilled water, but the item flow is for any kind of fluid. The connection to the water heater is
    compatible because it accepts any kind of water, including distilled. The item flow does not require the heater to accept any kind of fluid, because the source of flow is still producing water, regardless of the generality of the item flow.

    Figure 9.15, p95 - Usage example of item flows in internal block diagrams
    Item Flow is Fluid.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 19:14 GMT
  • Updated: Thu, 16 Mar 2017 07:31 GMT

proxy and full port notation change request

  • Legacy Issue Number: 18993
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    After ˜1 year of using new proxy and full ports, our customers are not happy with using <<proxy>> and <<full>> keywords/labels for port kind identification.

    In real life, multiple labels on ports makes modeling a nightmare (see image below).

    In MagicDraw, we use different colors - full port has the same color as part, when proxy port is different, but it is not enough. Diagram may be printed in B&W too.
    What do you think about the idea to change proxy port graphical notation, by adding some special icons or using a dashed line for example?

  • Reported: SysML 1.4 — Wed, 9 Oct 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:29 GMT

Semantics clarification for removing a value from an out Flow Property

  • Legacy Issue Number: 18953
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The specification should clarify the semantics from removing a value from an “out” Flow Property. Since “removing” something is considered to be a “write”, can we assume that it is propagated to a connected and matching “in” Flow Property, if any?

  • Reported: SysML 1.4 — Mon, 30 Sep 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:25 GMT

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Legacy Issue Number: 18877
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    For “regular” properties, UML semantics in UML is “non-depletive”: the ability to read their value does not depend on the number of time they have been read previously. A “depletive” semantics would implies that a value is no more available once it has been read

    SysML does not say anything about this for flow properties.

  • Reported: SysML 1.4 — Mon, 19 Aug 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:24 GMT

Pull semantics for flow properties

  • Legacy Issue Number: 18876
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Currently in SysML, flow properties have “Push” semantics (cf. sub-clause 9.3.2.7): writing to a flow property with direction out, propagates value to matching flow property at opposite end of the connector. This implies that there is a behavior running on the part from the “out” side.

    “Pull” semantics could be useful as well: the value propagation is the result of a read made on the flow property with direction in to the matching property at the opposite end of the connector.
    This implies that there is a behavior running on the part from the “in” side.

    SysML should introduce a semantic variation point on this topic, and/or some specific notations/abstract syntax

  • Reported: SysML 1.4 — Mon, 19 Aug 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:24 GMT

The SysML classification of properties is incomplete

  • Legacy Issue Number: 18709
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    SysML 1.3 section 8.3.2.2 Block says:

    SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType.
    …
    A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.

    In SysML, we also have Signals.
    In UML, Signals can have properties.

    How does SysML then classify properties defined in a Signal?

    A very strict reading of the SysML spec would suggest that a Signal cannot have any kind of SysML property because a Signal is neither a SysML Block nor a SysML ValueType.
    However, this is clearly too restrictive in practice.

    I propose expanding SysML's classification of properties to include SysML Blocks, ValueTypes and Signals.
    This leads to another question:

    What are the legal types of a property belonging to a Signal?

    I propose restricting such properties to be typed by SysML ValueTypes only. This corresponds to the practical situation where a Signal carries a data payload – I.e., it is a message with some data content.
    Allowing a property belonging to a Signal to be typed by a SysML Block or Signal leads to semantic problems — what would it mean to send / receive such signals?

  • Reported: SysML 1.4 — Mon, 13 May 2013 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:23 GMT

Requirement constants should be integrated into Model-centric vision of SysmL

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

    SysML requirements are now pure text and not completely integrated in to
    the model-centric approach

    Currenltly requirements are written as

    The top speed of this car shall be greater than 100 mph.

    Instead, it should be written as

    The top speed of this car shall be greater than <x>.

    And there be a compartment of the requirement where the current value of
    <x> is given

    <x> = 200mph.

    This <x> should be integrated as a design value throughout SysmL and
    should be connectable to parmetrics. It should also support dependencies
    so that other requirements value's (and block's features) can be
    dependent on the value of <x>. Then I can determine all the places in my
    system where there is a dependency on <x> and my equations and
    constraints are automatically updated. Which in many cases would allow
    me to automatically rerun my simulations.

    This is an improvement in integrating the model. Currently, with pure
    text requirements constants in the requirements are often repeated in
    equations, parametrics, constraints, algorithms. This repeating defeats
    some of the advantages of model-approach, as they are identical or
    related elements that need to be synchronized by hand.

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Updated: Thu, 16 Mar 2017 06:28 GMT

Dubious UUIDs

  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    http://www.omg.org/spec/SysML/20150709/SysML.xmi, unlike its predecessors and UML 2.5, defines both xmi:uuid and xmi:id.

    This is a monumental bloat.

    The UUIDs are of dubious utility since the constructive algorithm does not incorporate anything specific to SysML 1.4. Therefore all future SysML serializations must use a different constructive algorithm that guarantees never to repeat the 1.4 UUIDs. (Simplest, never to bloat with UUIDs ever again.)

  • Reported: SysML 1.4 — Sat, 4 Jun 2016 08:12 GMT
  • Updated: Tue, 14 Mar 2017 15:11 GMT

Missing comment for some attributes

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

    There are some elements that don't have any comment in the SysML.xmi file.
    (The list can be found at the end of the description)

    Our tooling is using these comments to automatically generate documentation

    Small question: Is the xmi file available for contribution? Maybe on a GitHub repository?

    Here is the list
    SysML.package_packagedElement_Activities.stereotype_packagedElement_Probability_ownedAttribute.probability
    SysML.package_packagedElement_Activities.stereotype_packagedElement_Rate_ownedAttribute.rate
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.sourceContext
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.sourcePropertyPath
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.targetContext
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.targetPropertyPath
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.definitionURI
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.description
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.symbol
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.definitionURI
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.description
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.quantityKind
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.symbol
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.criterion
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.member
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.name
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.size
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concern
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concernList
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_View_ownedAttribute.stakeholder
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Viewpoint_ownedAttribute.concern
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Viewpoint_ownedAttribute.presentation
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_ChangeStructuralFeatureEvent_ownedAttribute.structuralFeature
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_DirectedFeature_ownedAttribute.featureDirection
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_InvocationOnNestedPortAction_ownedAttribute.onNestedPort
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_TriggerOnNestedPort_ownedAttribute.onNestedPort

  • Reported: SysML 1.4 — Mon, 9 May 2016 15:51 GMT
  • Updated: Tue, 14 Mar 2017 14:40 GMT


Figure B.35 object nodes


Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors

  • Legacy Issue Number: 18758
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Table 8.4 in SysML 1.3 defines the notation for a SysML BindingConnector in terms of an "<<equal>>" keyword. This notation is very expensive in terms of diagram footprint.
    Without displaying the "<<equal>>" keyword, SysML BindingConnectors become visually indistinguishable from bidirectional SysML assembly connectors.

    Suggest providing an alternate notation for SysML BindingConnectors in Table 8.4 based on an elegant solution that some SysML tools and SysML RTF members already use, that is, a single "=" symbol without the keyword guillemets, that is, "=", not "<<=>>".

  • Reported: SysML 1.4 — Wed, 5 Jun 2013 04:00 GMT
  • Updated: Mon, 6 Mar 2017 14:02 GMT

ElementGroup cannot be source or target of a dependency

  • Legacy Issue Number: 19595
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The stereotype ElementGroup extends the base class comment which is not a NamedElement. Therefore a ElementGroup can't be source or target of a dependency and it is not possible to use an ElementGroup for instance with a trace or satisfy relationship.

  • Reported: SysML 1.4 — Sun, 7 Sep 2014 04:00 GMT
  • Updated: Sun, 5 Mar 2017 05:00 GMT

About Rate, Continuous and Discrete

  • Legacy Issue Number: 18735
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    In the figure shown below, Continous and Discrete stereotypes seems to be applied an ActivityParameterNode of an Activity. However, those aforementioned stereotype do not extend ActivityParameterNode but only Parameter and ActivityEdge. Is it an error?

    In the same order, <<continuous>>, <<discrete>> and <<rate>> are also applied on something called “Object Node”? However, <<Rate>> seems not to extend any node.

  • Reported: SysML 1.4 — Thu, 23 May 2013 04:00 GMT
  • Updated: Sun, 5 Mar 2017 03:19 GMT

primitive types in SysML Activities

  • Legacy Issue Number: 18659
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    In SysML, value property types are restricted to be a ValueType.
    I see the problem with incompatible and inconsistent types in customer models, as Activities have no restrictions and still use UML primitive types as pin and parameter types.

    Did I miss something in the spec, or types used in Activity are not restricted to be ValueTypes?

    Also, did we fix VerdictKind to be a ValueType? I don't remember.

  • Reported: SysML 1.4 — Fri, 12 Apr 2013 04:00 GMT
  • Updated: Sun, 5 Mar 2017 02:57 GMT

SysML: References to CreateEvent incorrect

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

    In UML 2.4.1, the equivalent to createEvent and desturctionEvent are now called messages. This should be followed in SysML. This changes the text in the 1st row of Table 12.1 on page 116, but it may impact other places also.

  • Reported: SysML 1.4 — Sat, 7 Jul 2012 04:00 GMT
  • Updated: Sat, 4 Mar 2017 04:43 GMT

clarification, what "part property" is

  • Key: SYSML16-89
  • Legacy Issue Number: 17307
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    The NEW issue - clarification, what "part property" is, as new port types typed by Blocks changed everything, they fit into "part properties" definition.
    SysML 1.3, Page 43 : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. "

  • Reported: SysML 1.4 — Fri, 13 Apr 2012 04:00 GMT
  • Updated: Sat, 4 Mar 2017 04:23 GMT

Error in pending 1.3 diagram 15.6 and elsewhere

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

    In Figure 15.6 in pending SysML 1.3, on the left side of the diagram, the object-flow, labeled objectflow3 is a dashed line. From table 11.2, object flows always use solid lines (though control flow can use either solid or dashed).

    This was also wrong in SysML 1.2, though the diagram number was then 15.5.

    Thanks to Geoffrey Shuebrook who pointed this out to me,.

  • Reported: SysML 1.4 — Mon, 9 Jan 2012 05:00 GMT
  • Updated: Sat, 4 Mar 2017 04:01 GMT

Question about the Activity decomposition in Block Definition Diagrams

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

    I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.).

    For example I use that extensively in the FAS methodology (Functional Architectures for Systems).

    I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that.

    When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the

    activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior.

  • Reported: SysML 1.4 — Sun, 8 Jan 2012 05:00 GMT
  • Updated: Sat, 4 Mar 2017 03:59 GMT

Derived attribute should also be read only

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

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

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

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

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

  • Reported: SysML 1.4 — Thu, 28 Apr 2016 10:42 GMT
  • Updated: Thu, 2 Mar 2017 00:37 GMT

Expand use of rake symbol for all decompositions

  • Legacy Issue Number: 19783
  • Status: open  
  • Source: University of Detroit Mercy ( Michael Vinarcik)
  • Summary:

    I’d like to advocate for rakes on Call Operation nodes (that have associated methods) in the next SysML rev. We’re using operations extensively because they inherit nicely and have inputs/output parameters. By moving to Call Operations from Call Behaviors, we lose the rake that’s a visible sign you can drill deeper…so by using Call Operations with methods instead of Call Behaviors, we lose that visual cue.
    I put a stereotype with icons on the nodes as a fix, but I’d love to see it as a native function.

    I suggest that rake symbols should be expanded to include call operations on activity diagrams with methods attached (or any other situation in which drill-down is available).

  • Reported: SysML 1.4 — Tue, 9 Jun 2015 04:00 GMT
  • Updated: Wed, 1 Mar 2017 23:34 GMT

ConnectorProperty notation in wrong section.

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:47 GMT
  • Updated: Thu, 23 Feb 2017 13:21 GMT

Parts, references, values compartments in wrong section

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:52 GMT
  • Updated: Thu, 23 Feb 2017 13:20 GMT

Description of model elements in generated document not consistent with specification

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The document that is generated from the model file defining the SysML profile contains descriptions of the model elements that are not consistent with the specification.

    Some description texts are completely missing, some are incomplete, and some have a different text than in the specification document.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:10 GMT
  • Updated: Thu, 23 Feb 2017 13:20 GMT

Definition of SysML stereotypes: association ends versus attributes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

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

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:19 GMT
  • Updated: Thu, 23 Feb 2017 13:19 GMT

Cannot navigate and represent deep nested defining feature in a slot

  • Status: open  
  • Source: NASA ( Robert Karban)
  • Summary:

    As discussed in the RTF plenary on Sep 12 2016 the ability to
    navigate and represent deep nested defining feature not directly owned in the classifier of that instance would largely simplify the construction of instances specification trees.

    Consensus was reached in the plenary.

    There is a potential problem with UML which says that slot defining feature is a feature of that classifier.
    Michael Chonoles volunteered to work on this on the UML RTF side.

  • Reported: SysML 1.4 — Thu, 15 Sep 2016 14:44 GMT
  • Updated: Thu, 23 Feb 2017 13:19 GMT

specializations of requirement should specialize AbstractRequirement

  • Status: open  
  • Source: NASA ( Robert Karban)
  • Summary:

    They specialize requirement and therefore do not allow to have properties.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 19:51 GMT
  • Updated: Thu, 23 Feb 2017 13:17 GMT

A discarded resolution still appears in the ballot

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

    Resolution SYSML-331 was discarded from ballot#8, replaced by SYSMLR-359 then added to ballot#9.

    However in ballot#9, SYSMLR-331 still appears beside SYSMLR-359 with all the votes casted in the ballot#8!

    It's rather confusing because, in addition, JIRA said that we already voted for this ballot, which is not true!

    Can we fix this?

    Thanks

  • Reported: SysML 1.4 — Fri, 21 Oct 2016 05:56 GMT
  • Updated: Thu, 23 Feb 2017 13:17 GMT

Property path notation

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:

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

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

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

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:14 GMT
  • Updated: Thu, 23 Feb 2017 13:15 GMT

More than one View() operation allowed

  • Legacy Issue Number: 19623
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The viewpoint constraint about the View() operation allows more than one View() operation:

    [2] The property ownedOperation must include at least one operation named “View” with the UML Create stereotype
    applied.

    It is not specified what happens if there is more than one View() operation. For example:

    • In which order are they performed? If only one View() operation is performed it is not defined which one.
    • The wording of the derived property method is only about one operation ("of the operation").

    As long no one has a good use case to have more than View() operation I propose to change constraint [2] to:

    [2] The property ownedOperation must include exactly one operation named “View” with the UML Create stereotype
    applied.

  • Reported: SysML 1.4 — Sat, 27 Sep 2014 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:14 GMT

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

  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    1) SysML convention is to use Capitalized types. These use lower case

    2) There is no "int" within SysML. The correct type is "Integer". While it is possible that an "Int" was defined in a model, in this case it is misleading readers to think that SysML uses Int as opposed to Integer.

  • Reported: SysML 1.4 — Thu, 11 Sep 2014 04:46 GMT
  • Updated: Thu, 23 Feb 2017 13:13 GMT

[SysML] Semantic variation points

  • Legacy Issue Number: 19489
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Kind: Clarification

    Description:

    The current specification of SysML allows, in some places, variations on the semantics. For a part of them it is intentional because the standard does not want to enforce a specific one among others possible, for another part it is not and may result from ambiguities in the text which will have to be fixed.

    It would be useful to explicitly and exhaustively identify the list of intentional semantic variation points so that users can easily see the choices they have to make and state them clearly.

  • Reported: SysML 1.4 — Thu, 26 Jun 2014 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:13 GMT

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

  • Legacy Issue Number: 19328
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Background:

    SysML 1.3 introduced significant changes to SysML ports
    MBSE methodologies based on SysML 1.2 need to be updated for SysML 1.3 and
    later

    A summary of syntactic and semantic variations for SysML 1.4 ports is an
    important component for tailoring an MBSE methodology as an extension of
    SysML 1.4
    Independent of a particular MBSE methodology, such a summary is an
    important guide for users and tool implementors.
    For users, such a summary would help understand the capabilities and
    limitations of a particular SysML tool implementation
    For tool implementers, such a summary would help understand what
    capabilities need to be implemented to support SysML

    Issue:

    The SysML 1.4 specification lacks a compact summary of the range of
    syntactic variations allowed for SysML 1.4 ports
    and the corresponding semantics for these syntactic variations

    The SysML RTF should provide a catalogue of the syntactic factors that
    induce the syntactic and semantic diversity of SysML ports

    As of SysML 1.4, known factors include, but are not necessarily limited to:

    1) SysML Port Kind

    ­

    {proxy, full, uncommitted}

    2) SysML Port Type

    ­

    {InterfaceBlock, Block, ConstraintBlock}

    3) UML Interaction modality

    ­(UML::Port::isService, UML::Port::isBehavior)

    4) SysML Port Features & nesting

    ­Behavioral features:

    {operation, reception}

    ­Structural features:

    {value, flow, reference, part, constraint, binding, participant, connector, distributed, endPathMultiplicity, boundReference, adjunct, classifierBehavior} {property, port}

    5) Nested SysML Ports (kind, type, modality, features)

    6) Optional feature direction

    {provided, required, provided+required}

    7) SysML Port Connectivity

    ­Internal vs. external connectors
    ­UML Connector kind (assembly, delegation)
    ­SysML Connector kind (binding, non-binding)
    ­SysML Connector type

    {none, UML::Association, SysML::Block + UML::AssociationClass}

    ­SysML Association Block-typed Connector features & nesting
    (same as SysML Port Features & nesting)

    8) SysML ItemFlow

    ­Distinguishing what may flow in general vs. what actually flows in a
    context

  • Reported: SysML 1.4 — Thu, 3 Apr 2014 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:12 GMT

classifierBehaviorProperty and adjunctProperty notation

  • Legacy Issue Number: 19326
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    I cannot find new SysML 1.4 ClassifierBehaviorProperty and AdjunctProperty notation details, such as :

    1. what keyword should be used? <<classifierBehaviorProperty>> which is very long, or maybe shorter version <<classifierBehavior>> ? <<adjunctProperty>> ?

    2. In what block compartments should it appear? Under generic “properties” or maybe should have their own new compartments?

    3. Should we show “principal” value on adjunctProperty box? If so, showing only the name is not so useful as showing an element kind too, like <<callBehaviorAction>> or <<parameter>>, so user can understand what it represents.

  • Reported: SysML 1.4 — Wed, 2 Apr 2014 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:12 GMT

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

  • Legacy Issue Number: 19321
  • Status: open  
  • Source: PTC ( Simon Moore)
  • Summary:

    At the end of section E.4 on page 245:
    "The namespace for the standard profile is: http://schema.omg.org/spec/SysML/20090817/SysML-profile.xmi."

    Should this be referred to as a URI, not the namespace? Perhaps should simply reference the cover page of the spec since the one given here is out of date.

  • Reported: SysML 1.4 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:12 GMT

Update to Trace Relationship’

  • Legacy Issue Number: 19284
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I potentially found a mistake in the latest SysML specification. It can be found on page 144. The “Trace Dependency” and the “TraceCallout” are introduced on this page. Usually these two visualizations should show the same aspect of a SysML model. Unfortunately the “Trace Dependency” is only introduced between two requirements whilst the “TraceCallout” is shown between a requirement and a more general NamedElement. I think the named element should be allowed in both cases in the client role of the trace dependency. ADDITIONAL TEXT

    The trace stereotype as defined in 16.3.2.7 does not constrain either end of the trace relationship than the having one client and one supplier.

    16.3.2.7 Trace
    Description
    The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
    Constraints
    [1] The Trace stereotype may only be applied to dependencies.
    [2] Dependencies with a Trace stereotype or one of its specializations applied must have exactly one client and one supplier.

    From the UML 2.5 Standard Profile, the UML4SysML::Trace extends Abstraction, which subclasses Dependency. Dependencys are directed relationships between Named Elements. Therefore, the SysML::Trace can have any Named Element as its ends.

    The diagram elements Table 16.2 on pg 144 should be clarified.

    Also, in section 16.3.2.7, the trace relationship has specific definitions for Requirements:

    Operations
    [1] The query getTracedFrom() gives all the requirements that are clients (from end of the concrete syntax) of a Trace
    relationship whose supplier is the element in parameter. This is a static query.
    Trace::getTracedFrom(ref : NamedElement) : Set(Requirement )

    {query, static}

    getTracedFrom=Requirement.AllInstances()>select(traceTo>includes(ref))

    The query getTracedFrom() could be more general and query all NamedElements and not only Requirements.

  • Reported: SysML 1.4 — Fri, 14 Mar 2014 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:11 GMT

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Legacy Issue Number: 19062
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Instead of deleting the Unit and QuantityKind stereotypes according to the 18269 resolution in SysML 1.4 ballot 4, I suggest moving these stereotypes to the SysML::DeprecatedElements package.

    Without doing this, a SysML 1.4 tool that opens a SysML 1.3 model will have to convert InstanceSpecifications stereotyped by SysML 1.3 Unit or QuantityKind into InstanceSpecifications classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind respectively.

    Even if a SysML 1.4 tool alerts the user that this migration has happened, it will not be possible to discern InstanceSpecifications classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind due migration from SysML 1.3 vs. deliberate choice.

    A better migration strategy would be to convert SysML 1.3 Unit/QuantityKind-stereotyped InstanceSpecifications into SysML 1.4 InstanceSpecifications that are both:
    stereotyped by SysML::DeprecatedElements::Unit/QuantityKind
    Classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind
    The former leaves a persistent indication that the InstanceSpecifications have been partially migrated.
    The latter represents a partial migration to SysML 1.4 Units/QuantityKinds; that is, the user can complete the migration by classifying these InstanceSpecifications with concrete SysML Blocks that specialize SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind respectively.

  • Reported: SysML 1.4 — Fri, 1 Nov 2013 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:10 GMT

Semantics of multiple Dependencies

  • Legacy Issue Number: 18623
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    SysML defines or uses some relationship based on the UML Dependency metaclass. It is possible to specify multiple dependencies having with the same client or supplier. The user can rely on this capability for various purposes. The point is that there is no standard semantics for such constructs. This must be clarified.

  • Reported: SysML 1.4 — Mon, 8 Apr 2013 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:05 GMT

VerdictKind

  • Legacy Issue Number: 18312
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    I just realized that Requirements::VerdictKind enumeration in SysML profile is NOT a ValueType, so I can't use it in SysML model to type my values.

    Does everyone agree that it shall have ValueType stereotype applied?

    We should make sure all datatypes we provide are ValueTypes.

  • Reported: SysML 1.4 — Wed, 12 Dec 2012 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:01 GMT

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

  • Legacy Issue Number: 18268
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The SysML notation allows a stereotype <<S>> applied to an element E1 to be shown as the notation for a different element E2 related to E1 in some way.

    Example: 11.3.1.2 CallBehaviorAction and Figure 11.2:

    Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as

    shown in Figure 11.2.

    What this means is that if a CallBehaviorAction shows a stereotype <<S>>, then it is unclear whether <<S>> is applied to the CallBehaviorAction itself or to the behavior that the CallBehaviorAction calls.

    This ambiguity is problematic for users reading SysML diagrams as indicated by SysML issue 17549:

    Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied

    to a call behavior action (when that call behavior action calls an activity that also

    has the «controlOperator» stereotype applied).

    More generally, the SysML spec needs to be reviewed where this stereotype notation can result in this kind of ambiguity.

  • Reported: SysML 1.4 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:00 GMT

Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Legacy Issue Number: 18193
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Reported: SysML 1.4 — Mon, 22 Oct 2012 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:00 GMT

How to refer to properties of an extension?

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

    For a practical usage it is required to be able to refer to a property of a stereotype application, for instance as target or source of an allocation relationship. This need is somewhat similar to that of referencing a nested property but we shall make sure the solution selected for the Common Reference Path will be able to address this case too.

  • Reported: SysML 1.4 — Mon, 2 Apr 2012 04:00 GMT
  • Updated: Thu, 23 Feb 2017 12:58 GMT

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

  • Key: SYSML16-85
  • Legacy Issue Number: 17210
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML. Furthermore they are not even defined as instances of PrimitiveType despite their XMI id.

    For example we have:

    <packagedElement xmi:type="uml:DataType"
    xmi:id="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-String"
    name="String"/>

  • Reported: SysML 1.4 — Sat, 3 Mar 2012 05:00 GMT
  • Updated: Thu, 23 Feb 2017 12:55 GMT

SysML's PrimitiveValueTypes library is missing "value" properties everywhere

  • Key: SYSML16-81
  • Legacy Issue Number: 16876
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    For SysML 1.3, has anyone tried to specify the value of a SysML::ValueType ?

    If you haven't done so, please try to do this carefully – i.e., don't just assume that Real x = "42.0" is enough!

    You'll realize then that the SysML 1.3 spec doesn't provide the capability to specify the actual value for any of the SysML::Libraries::PrimitiveValueTypes

    SysML::Libraries::PrimitiveValueTypes::Boolean
    SysML::Libraries::PrimitiveValueTypes::Integer
    SysML::Libraries::PrimitiveValueTypes::Real
    SysML::Libraries::PrimitiveValueTypes::String

    Since we can't specify the actual real value of a SysML Real, we can't specify the realPart or the imaginaryPart of a SysML Complex number either!

    SysML::Libraries::PrimitiveValueTypes::Complex::realPart :
    SysML::Libraries::PrimitiveValueTypes::Complex::imaginaryPart

    What is missing is an actual "value" attribute whose type then must be from the UML PrimitiveTypes library since it's the only capability in UML/SysML we have to specify an actual "value" via the Literal[X] metaclasses in UML.

    SysML::Libraries::PrimitiveValueTypes::Boolean::value : PrimitiveTypes::Boolean – an actual value can be specified as a UML::LiteralBoolean
    SysML::Libraries::PrimitiveValueTypes::Integer::value : PrimitiveTypes::Integer – an actual value can be specified as a UML::LiteralInteger
    SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real – an actual value can be specified as a UML::LiteralReal
    SysML::Libraries::PrimitiveValueTypes::String::value : PrimitiveTypes::String – an actual value can be specified as a UML::LiteralString

    SysML::Libraries::PrimitiveValueTypes::Complex can remain as-is since it inherits the capability
    to specify an actual value for its realPart & imaginaryPart attributes thanks to SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real

    I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

    I believe that this is a new issue for SysML 1.3.

  • Reported: SysML 1.4 — Mon, 5 Dec 2011 05:00 GMT
  • Updated: Thu, 23 Feb 2017 12:53 GMT

Issue on Block constraint#4

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

    In SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states:

    [4]In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)”

    No such constraint exists in the UML specification which conversely says the following (UML v2.4, §7.3.45):

    “A property related to a classifier by ownedAttribute represents an attribute, and it may also represent an association end. It relates an instance of the class to a value or collection of values of the type of the attribute”

    The SysML Block constraint #4 has no clear justification and should be removed.

  • Reported: SysML 1.4 — Mon, 28 Nov 2011 05:00 GMT
  • Updated: Thu, 23 Feb 2017 12:53 GMT

Content of Requirement::/tracedTo

  • Key: SYSML16-75
  • Legacy Issue Number: 16373
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Yann Tanguy)
  • Summary:

    In the specification the content of the derived property “Requirement::tracedTo” is defined as follows:

    • /tracedTo: NamedElement [*]

    Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

    As «copy» «deriveReqt» «verify» and «satisfy» inherit from “Trace”, does this means that /tracedTo also list all elements that are the supplier of a «copy» «verify» «satisfy» «deriveReqt» relationship for which this requirement is a client ?

  • Reported: SysML 1.4 — Mon, 18 Jul 2011 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:19 GMT

Can Enumerations be used on parametric diagrams for typing constraint parameters

  • Key: SYSML16-74
  • Legacy Issue Number: 16304
  • Status: open  
  • Source: PTC ( Andreas Korff)
  • Summary:

    when participating in the discussions on the draft ballot 3 on the SysML 1.3 spec, we observed that there is a need for clarification. The question was about whether Enumerations can be used on parametric diagrams for typing constraint parameters. The spec defines:

    From 8.3.2.10

    SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. … A SysML ValueType may define its own properties and/or operations, just as for a UML DataType. See Section 8.3.2.2, “Block” for property classifications that SysML defines for either a Block or ValueType.

    ValueTypes can be used to type constraint parameters. Since ValueTypes extend UML DataTypes, and Enumerations are a subtype of DataType, Enumerations might be used. Since Blocks could be used as types of constraint parameters as well, the implication that any subtype of a UML datatype might lead to the implication that any subtype of UML classifier could be used here as well (e.g. activity or StateMachine), which is of course not meant.

    We need to constrain this definition better

  • Reported: SysML 1.4 — Wed, 1 Jun 2011 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:18 GMT

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

  • Key: SYSML16-71
  • Legacy Issue Number: 16113
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    the parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete w.r.t. to figure B.30. Is it ok?

  • Reported: SysML 1.4 — Mon, 28 Mar 2011 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:17 GMT

Where have stereotypes been defined?

  • Key: SYSML16-70
  • Legacy Issue Number: 16112
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    in some figures of the examples provided in Annex, some stereotypes are displayed: <<domain>>, <<external>>, <<diagramDescription>>, … and so on. Can someone tell me where these stereotypes have been defined?

  • Reported: SysML 1.4 — Mon, 28 Mar 2011 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:17 GMT

SysML Issue on Refine limitations

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

    The text description of how the refine relationship can be used disagrees with formal restrictions.

    On page 126, 2nd paragraph, the text says.

    “The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.”

    This allows a refine relationship to be

    [Requirement] ß1..*[Model element]

    Or

    [Requirement] à [Model element]

    However, Figure 16.1 only has

    /refinedBy:Named Element[*] as property for a Requirement

    Thus it is not possible to have a requirement refine a model element.

    This is confirmed by Figure 16.2, which in showing the tags for a NamedElement

    Has /refines Requirement [*]

    This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around).

    So problem 1.

    The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence:

    The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.

    Problem 2

    The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word “diagram” from the text

    Final wording

    The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement.

    Additional comment.

    It’s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement.

  • Reported: SysML 1.4 — Wed, 9 Feb 2011 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:15 GMT

SysML Issue representation of properties as associations

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

    In UML, there appears to be consistent representing of attributes as regular associations from the owning class. SysML, in similar circumstances, represents value properties as composite associations. We should try to understand what UML is saying (and perhaps push back on them) and consider the value of consistency.

  • Reported: SysML 1.4 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:14 GMT

SysML Issue based on UML 15369

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

    A new keyword was added for attributes in UML,

    {id}

    . This concatenation of all such attributes within a class (block) for an instance must be unique.

    While this will mostly be used by database developers, it’s also a domain model analysis property, e.g, Social Security Number for a US citizen, Mac Address, etc. As such, it may be useful to some SysML modelers.

  • Reported: SysML 1.4 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:14 GMT

SysML 1.2 Issues: Optional with streaming

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

    Sysm 1.2 Optional with «streaming»

    Page 92

    11.3.2.6 Optional

    Does optional on an input mean optional to start the activity or optional for the activity to finish? Consider an «optional» streaming input.

    Does optional on an output mean optional to appear at the end of the activity or optional for it ever to appear? Consider an «optional» streaming output..

    We need to have all the possibilities for streaming; it probably should have two multiplicities for each streaming parameter

    Starting Multiplicity: number of tokens that must appear for the activity to start

    Total Multiplicity: number of tokens that must appear over the lifetime of the activity

    Ending Multiplicity: number of tokens that must appear at the end of the activity

    Total Multiplicity: number of tokens that must appear over the lifetime of the activity

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:13 GMT

Continuous flows in non-streaming situations with >1 multiplicities

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

    SysML 1.2 Issues: Continuous flows in non-streaming situations with >1 multiplicities

    11.3.2.1 Continuous

    It’s a bit unclear how continuous flows work in non streaming situation, especially with high multiplicities.

    If a continuous flow arrives at a pin with a multiplicity of 2, it would appear that the 1st and 2nd value arriving at the pin would be captured. If the flow is also continuously valued, the two values would be same. The difference between two adjacent samples goes to zero if the delta time between samples goes to zero (assuming differentiability).

    Type: Fix

    To make this capability useful, we’ll need to add a sampling rate to be able to use continuous with >1 multiplicity. If we don’t the specification should have a caveat for >1 multiplicity and differentiable input values.

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:13 GMT

SysML 1.2 Issues: DistributedProperties on Activates

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

    Page 45 Distributed Properties on Activities

    Original Text

    8.3.2.4 DistributedProperty

    Constraints

    [1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.

    Comment

    As I read this, on a BDD, if we have activities, the properties of the activities cannot be distributed properties, because activities are not stereotyped as block

    Type: Fix

    Rewrite this constraint,

    [1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block, Activity, or ValueType.

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:13 GMT

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

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

    Page 36, 8.3.1.1 Default «block» stereotype on unlabeled box is not always optimal

    Original Text

    Default «block» stereotype on unlabeled box
    If no stereotype keyword appears within a definition box on a block definition diagram (including any stereotype property compartments), then the definition is assumed to be a SysML block, exactly as if the «block» keyword had appeared before the name in the top compartment of the definition.

    Comment

    I question whether this is always desirable, e.g.,

    1) if the diagram had the «functional hierarchy» diagram usage stereotype applied, wouldn’t the default be «activity»,

    2) if the containing block is an activity block, wouldn’t «activity» be the right default

    Type: Clarification/Fix

    Add sentences that say: If the bdd diagram has a «diagram usage» specified (such as «functional hierarchy»), a different default (such as «activity») can be used.

    If the bdd diagram is for an activity block, the default stereotype elements is «activity»

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:12 GMT

SysML 1.2 Issue Viewpoint referencing other viewpoints properties

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

    Page 26

    Original Text

    7.3.2.5 Viewpoint

    Description

    A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases

    Comment

    How is the highlighted sentence done? There are no examples. I see examples of Viewpoint with a dependency on another Viewpoint, but no references for the individual fields (e.g., language and methods). Are the fields populated in an inheritance manner. Can they be overridden? Does it only work if the fields are blank on the dependant Viewpoint?

    Type: Clarification

    Add example and clarify rules

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:12 GMT

Inheriting Allocations

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

    The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties

  • Reported: SysML 1.4 — Tue, 22 Dec 2009 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:09 GMT

SysML Issue on Multiplicity of Use Case Communication Associations

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

    SysMl does not give any example of using multiplicity on the relationships between actors and use cases. This is part of UML as shown in Figure 16.11.

    Apparently, the "official" interpretation of SysML is that if there is no example, it is not part of SysML. This incompatibility means that standardize training, books, etc, on Use Cases can not be applied to SysML. And the notation is of value.

  • Reported: SysML 1.4 — Mon, 6 Dec 2010 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:07 GMT

SysML primitive value types

  • Key: SYSML16-60
  • Legacy Issue Number: 15882
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    We have issues with SysML primitive value types - Real, Integer, Boolean, String etc.

    The problem is that these types are not inherited from corresponding UML primitive types - Real, Integer, Boolean, String.
    That means, UML tool can't understand, what kind of ValueSpecification should be created for values of properties typed by these value types.
    Should it be LiteralString or LiteralInteger or OpaqueExpression?
    Constraints can't check if slot values are compatible with property types, as it is not clear what kind of value specification it should be also.
    There are issues in parametrics solving also, as values must be compatible with property types.

    I think, SysML primitives must be directly inherited from UML primitives - Real subtype of UML Real, String subtype of UML String etc.

  • Reported: SysML 1.4 — Wed, 8 Dec 2010 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:05 GMT

Do parametric bindings observe derived and read-only properties

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

    Do parametric bindings observe derived and read-only constraints on properties?

    .

    In SysML if I bind a read-only property value to a parameter, I would expect that any evaluation of the parametric model would not be able to update the property value. If I wanted to have such a value calculated, I would expect to take off the read-only constraint

    Similarly, if I bind a derived property value to a parameter, I would expect that any evaluation of the parametric model would not use that value as an input, but only as an output.

    However, this is answered (and I hope it is answered positively), the SysML specification should clarify this behavior

  • Reported: SysML 1.4 — Fri, 22 Jan 2010 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:01 GMT

callout notation issues

  • Key: SYSML16-45
  • Legacy Issue Number: 14575
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    I'm trying to prepare requirements for "callout" notation changes in MagicDraw SysML diagrams and trying to remove tool-specific notation.

    The SysML spec says that each allocatedTo or allocatedFrom property will be expressed as «elementType» ElementName.
    It looks simple at a first glance, but later SysML spec is a total mess:

    "For uniformity, the «elementType» displayed for the /allocatedTo or /allocatedFrom properties should be from the following list, as applicable. Other «elementType» designations may be used, if none of the below apply.

    «activity», «objectFlow», «controlFlow», «objectNode» «block», «itemFlow», «connector», «port», «flowPort», «atomicFlowPort», «interface», «value»

    Note that the supplier or client may be an Element (e.g., Activity, Block), Property (e.g., Action, Part), Connector, or BehavioralFeature (e.g., Operation). For this reason, it is important to use fully qualified names when displaying / allocatedFrom and /allocatedTo properties. An example of a fully qualified name is the form (PackageName::ElementName.PropertyName). "

    So, looking at the predefined list it is clear that:
    For the Activity or other "clean" UML element it is an metaclass name in lowercase.
    for let's say ItemFlow or FlowPort is is an stereotype name in lowercase.
    That's ok.

    But what is <<atomicFlowPort>> ? Port with <<flowPort>> stereotype applied which has isAtomic=true.
    What is <<value>> ? Property which has Type with <<ValueType>> stereotype applied.

    In the example below (Figure 15.4) it has allocation of actions to parts and it uses another one <<elementType>> which is not described - <<part>>.
    What is <<part>> ? The Property with AggregationKind = composite?

    Also, full qualified names and <<elementTypes>> are used incorrectly in this Figure or I don't understand how it should be used.
    For example:
    <<block>> Block4.Part5 - why it is <<block>>, but not <<part>> ???
    <<part>> Part2:Block1 - why part name is before block name? It should be displayed as (PackageName::ElementName.PropertyName) as described above.

    I believe, all these rules and exceptions should be described somewhere

  • Reported: SysML 1.4 — Thu, 22 Oct 2009 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:00 GMT

Support BDD's for State Machines

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

    One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams

    BDD (for Blocks) IBDs

    BDD (for Activities) ACTs

    BDD (for Constraint Blocks) PARs

    The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form.

    It would be convenient and symmetric to support a similar diagram for for State Machines

    BDD(for States) STMs

    In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion.

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:58 GMT

Binding Relationships require unit conversions

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

    Binding relationships are used between model element properties and parameter in the constraint blocks, similarly they are used between constraint blocks.

    These constraint blocks are intended to be reusable.

    However connecting constraint blocks from different sources does not usually work unless the units are the same. Model element values may also not be using tehehe same units.

    A reasonable solution is to indicate the scaling factor on the binding relationship. This could be done in several ways. One way would be to indicate a simple assignment equations between the two parameter names.

    Currently

    x----------------------------------Y

    Proposed

    Y=100*x

    x-----------------------------------------Y

    Instead of using a constant 100, we could used a named constant such as cmPm

    If both ends of the binding relationship were identically named, we need to add an arrow to indicate the souce and target sidel

    à

    X=cmPM*X

    X-----------------------------------------X

    This would indicate that the left side X must be multipled by the cmPm to give the left side x

    This approach allows us to handle more complex conversions by including the ability to add/sub constants

    C=5/9*(F-32)

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:57 GMT

Requirements interchange issue

  • Key: SYSML16-31
  • Legacy Issue Number: 13177
  • Status: open  
  • Source: ProSTEP iViP Association ( Steven Vettermann)
  • Summary:

    Information for facilitating the partner integration within the specification and requirements definition process (requirements interchange) are missing (e.g. meta information like version, access rights).

    Remark: There is a specification already addressing this topic, the Requirements Interchange Format (RIF). It is available for download as ProSTEP iViP Recommendation PSI 6 at www.prostep.org. This specification was introduced to the SE DSIG by Rupert Wiebel from HOOD (a paper is available) and presented by Dr. Steven Vettermann from ProSTEP iViP and discussed at the ManTIS meeting on December 11th.

  • Reported: SysML 1.4 — Fri, 19 Dec 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:56 GMT

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

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

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

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:56 GMT

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

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

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

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:56 GMT

SysML: Align SysML Activities with Foundational UML

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

    SysML: Align SysML Activities with Foundational UML

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Updated: Tue, 21 Feb 2017 15:55 GMT

SysML: Interaction diagram and Data-based comm of SysML

  • Key: SYSML16-14
  • Legacy Issue Number: 11627
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via flow ports.

    Within UML, Message is associated with signature of either a Signal or an Operation (see constraint 2 on Message meta class, p. 492 of the UML2 superstructure spec.).

    In SysML, blocks introduce an alternative for communication between blocks w.r.t. to usual UML2 composite structures: flow ports are basically dedicated to support data-based communication between blocks in contrast of UML2 that does not support such kind of communication between composite structures.

    In this case, a Message within an interaction should be able to refer either a DataType, a Block, a ValueType if the communication happen between two atomic flow ports, or to a FlowSpecification if the communication happen between two non-atomic port.

    I did not see anything related this issue within the SysML spec. Do I miss something or is it something missing in the SysML doc?

  • Reported: SysML 1.4 — Mon, 22 Oct 2007 04:00 GMT
  • Updated: Tue, 21 Feb 2017 15:52 GMT

Lack of notation for units and dimensions on values.

  • Key: SYSML16-11
  • Legacy Issue Number: 11493
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Lack of notation for units and dimensions on values. There are no samples at all

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Updated: Tue, 21 Feb 2017 15:52 GMT

BindingConnector end s multiplicity

  • Key: SYSML16-10
  • Legacy Issue Number: 11333
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    The semantics of the Binding Connector is described as follow :

    “8.3.2.10 Binding Connector

    Description

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.”

    So, I understand that definition if the multiplicity of the properties linked by the binding connector is 0..1 or 1. But what happen is the upper bound of the multiplicity is greater than 1? If for example, it is 0..* ? And moreover, what happen when the multiplicity of both property is different, as for example on one end 0..1 and on the other end 1 ? In this case, as according to the previous definition, the value of both properties has to be equal, what happen to the value of the proiperty which multiplicity is 1 when the other property is not yet defined?

  • Reported: SysML 1.4 — Tue, 28 Aug 2007 04:00 GMT
  • Updated: Tue, 21 Feb 2017 15:51 GMT

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

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

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

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

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

    Example

    <SysML.Blocks:ValueType xmi:id="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029.stereotypeApplication_SysML.package_packagedElement_Blocks.stereotype_packagedElement_ValueType">
        <base_DataType xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <quantityKind xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <unit xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/></SysML.Blocks:ValueType>
    
  • Reported: SysML 1.4 — Tue, 9 Aug 2016 13:05 GMT
  • Updated: Thu, 9 Feb 2017 15:52 GMT

Provide support to capture engineering quantities and support intricate calculations

  • Status: open  
  • Source: NASA ( Robert Karban)
  • Summary:

    There is no SysML 1.6 RTF jira project yet, so I submit here.
    There is the need to capture engineering quantities and support intricate calculations than the base SysML semantics do.
    it might be worth formulating to SysML 1.6 to get initial capability while refining the approach for SysML 2.
    The attached proposal has been worked out with Bjorn Cole during OMG meetings.

  • Reported: SysML 1.4 — Fri, 30 Dec 2016 19:07 GMT
  • Updated: Thu, 9 Feb 2017 15:47 GMT
  • Attachments:

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

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

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

    Please clarify the definition of the objectiveFunction stereotype.

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

  • Reported: SysML 1.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Thu, 9 Feb 2017 15:47 GMT

2016-03-31 Online meeting minutes

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

    Attendance: Dick, Rick, Roger, Julio, Yves

    1. ISSUES
    1.1 NEW OPEN ISSUES
    (none)

    1.2 CHAPTER’S REPORTS
    1.2.1 Chap.16: Requirements (Rick)
    We reviewed the resolution proposal for SYSMLR-155. Comments made:

    • The issue identified in the OCL code of the Operations defined in section 16.3.2.4 cannot be fixed in this resolution. We need distinct issue and resolution for this.

    (Note: this was note discussed during this meeting but it might be possible to that we only need an issue that we could merge with SYSMLR-155 in order to provide only one global resolution. @Yves: check whether this is allowed)

    • It is preferable that the new figures provided by the resolution use the same font than the other figures in the document. @Rick: try to fix this directly on the SVG otherwise ask Yves to provide a new version with the right fonts.

    2. PBR WORKGROUP
    No meeting today.

    3. NEXT MEETINGS

    • Online April 7th - 10am ET
  • Reported: SysML 1.4 — Thu, 31 Mar 2016 14:46 GMT
  • Updated: Thu, 9 Feb 2017 15:46 GMT

2015-10-15 Online meeting minutes

  • Status: open  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Rick hosted using freeconferencecall.
    Rick, Tim, John, Dick in attendance

    Rick reviewed the status of issues in JIRA, and asked for help performing initial 'triage' on issues... identifying (via label) which are 'Easily_Disposable', which are 'Discussion_Required', and which are 'Controversial'. This has not been done for those sections (components) that have no lead person assigned.
    Rick also made a plea to encourage more people to help. It was suggested that Rick contact Roger and Conrad, to discuss their availability.
    (Roger subsequently mentioned on another call that Deere budget issues have forced his withdrawal from the RTF/OMG, but that the RTF chair can request a complimentary trial membership for a key contributor. Roger will send Rick some reference info about this)

    Tim agreed to be listed as lead for the Blocks chapter, and to start triage on these issues.

    Dick agreed to be listed as lead for the Constraint Blocks chapter, and start triage on these issues.

  • Reported: SysML 1.4 — Thu, 15 Oct 2015 16:47 GMT
  • Updated: Thu, 9 Feb 2017 15:46 GMT

"Allocated From" should be "Allocated"

  • Status: open  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

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

  • Reported: SysML 1.4 — Thu, 19 Nov 2015 15:49 GMT
  • Updated: Thu, 9 Feb 2017 15:41 GMT
  • Attachments:

Missing property descriptions for Probability and Rate

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The stereotypes Probability and Rate in the Activities chapter have no description of their properties.

  • Reported: SysML 1.4 — Mon, 2 Jan 2017 13:01 GMT
  • Updated: Thu, 9 Feb 2017 15:40 GMT

Causality of constraints in parametric diagrams

  • Status: open  
  • Source: Thematix Partners LLC ( Richard Welling)
  • Summary:

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

    SysML identifies and names constraint blocks, but does not specify a computer interpretable language for them. The interpretation of a given constraint block (e.g., a mathematical relation between its parameter values) must be provided. An expression may rely on other mathematical description languages both to capture the detailed specification of mathematical or logical relations, and to provide a computational engine for these relations. In addition, the block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine.

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

    Replace the above paragraph with the following:

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

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

  • Reported: SysML 1.4 — Sun, 22 Nov 2015 00:40 GMT
  • Updated: Thu, 9 Feb 2017 15:40 GMT

Item Flows on Activity Diagrams

  • Key: SYSML16-17
  • Legacy Issue Number: 12125
  • Status: open  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    Since ItemFlow is a stereotype of InformationFlow, it can be related to an ActivityEdge and depicted on an Activity Diagram. At least one tool has provided this capability. Clarify the use of ItemFlows on Activity Diagrams in the specification: If this is not desirable, then an additional constraint must be added to ItemFlows to prevent it. Personally, I like the idea of representing ItemFlows on ObjectFlows, but the semantic meaning of this representation is unclear. If this is retained, then it should be discussed in both chapter 9 and chapter 11.

  • Reported: SysML 1.4 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Thu, 2 Feb 2017 13:55 GMT

Inferred Allocation on Allocate Activity Partitions

  • Key: SYSML16-16
  • Legacy Issue Number: 12123
  • Status: open  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    When an allocation relationship is depicted on an activity diagram using Allocate Activity Partitions, it is unclear if the allocation relationship is from the Action Node to the Part represented by the partition (direct allocation), or from the Activity typing the Action Node to the Block typing the Part (Inferred allocation). Since in practice it has become necessary to represent both conditions, this portion of the SysML specification should be modified to incorporate some graphical indication to distinguish them.

  • Reported: SysML 1.4 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Thu, 2 Feb 2017 13:54 GMT

Sample problem: Parts are added directly into package

  • Key: SYSML16-13
  • Legacy Issue Number: 11499
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Parts are added directly into package. B27 - <<moe>> element that is a part is displayed inside of a package <<view>>

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:53 GMT

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

  • Key: SYSML16-12
  • Legacy Issue Number: 11496
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references):
    a) Stereotypes
    i. Block stereotypes are displayed on parts
    ii. Block stereotypes are displayed on object nodes
    iii. Parameter stereotypes are displayed on ActivityParameterNode
    iv. Behavior or operation stereotypes are displayed on CallActions
    b) Tags
    i. Block allocations are displayed on parts
    ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype
    c) Constraints
    i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30)

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:52 GMT

Issue: Nested connector ends

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

    Nested connector ends:

    "Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them."

    That's an important feature of SysML.

    "The ability to connect to nested properties within a containing block requires that multiple levels of decomposition be
    shown on the same diagram."

    I think that's a problem in practice. Often I don't want to see the nested properties in the diagram.
    I propose to add a notational feature to show that a connector end is connected with a nested property without
    showing that property.

    For example we could draw the connector to the border of the surrounding property and attach the stereotype <<nested>>
    as a short form of <<nestedConnectorEnd>> and optionally the propertyPath.

    What do you think?

  • Reported: SysML 1.4 — Fri, 10 Aug 2007 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:48 GMT

Block namespace compartment: Are external relationships allowed

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

    The block namespace compartment shows a bdd of the elements that are part
    of the namespace of the block.

    Is it allowed to show relationships from a block inside that compartment to
    a external block? The relationship could be in the model, but can I show it
    in the diagram?

    I think it should be allowed. I don't see any problems.

  • Reported: SysML 1.4 — Wed, 16 May 2007 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:45 GMT

SysML: Generalizing Activites

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

    Section 11 should show an example of generalization/specialization of Activiites when then are being shown in a bdd.

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:43 GMT

SysML: UML Qualified Associations

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

    SysML currently discards UML 2.1 qualified associations (see 8.3.1.4) as not being of interest to the SE community.

    I contest this on two grounds –

    1) a. Qualifiers are used expressively and meaningfully to explain domain situations that have nothing to do with data modeling. For example, when I say a baseball roster had 9 members and that there are 9 positions to fill, I am not explicitly saying that there is one person per position. Qualifiers allow me to clarify this piece of the real world and would be very useful on a BDD.

    b. Qualifiers are also used idiomatically with generalization discriminators to tie parallel generalization structures together. They are capable of modeling situations, such as when there are many types of missiles, each with their own launcher type.

    c. Qualifiers are also used to indicate addressing schemes and mechanisms. For example, by placing an operation/activity etc that returns a type in a qualifier, one can specify the mapping or prioritization /ordering algorithm. Specifying such algorithms may be the SE’s job, when it part of an equation report, algorithm development. This could fit into SysML and support allocation to functional (target prioritization scheme, best antenna-signal function) and structural components (packet routers). This is fully in the spirit of what practicing SEs do and would round out the capability of SysML.[Note that this capability could be delayed for a later SysML, the other parts should be addressed sooner]

    2) Qualifiers appear to be part of small part of UML that is incompatible with use with a SysML strict profile mechanism. Imagine a model done in strict SysML, then brought into UML, where a qualifier is added to the relationship, changing the multiplicity at one end. If the model is then brought back into (strict) SysML and the qualifier is then dropped, the multiplicity cannot be automatically restored (or determined from the model). Because of this, qualifiers must be forbidden in UML in such contexts

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:43 GMT

SysML: Protocol State Machines needed

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

    The current document eliminates Protocol State Machines on the grounds of simplification. See Section 13

    However, this leaves a hole in the capabilities of SysML. Currently, SysML supports UML interfaces (provided and required), which can’t have state machines to define them.

    It is an important part of designing systems interfaces (SE terminology) to define the details of the (UML/SysML) Interfaces. These details include the allowed ordering of messages. As we are not allowed to use behavior state machines and the standard solution, that of, protocol state machines are not included, we can’t properly do interface engineering within SysML

    If some other solution/work-around is proposed (which I don’t recommend) the explanation of how to accomplish this should be in the spec.

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Updated: Thu, 2 Feb 2017 13:42 GMT