OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML17-372 Figure E.6 QUDV Units Diagram display exactly the same content as Figure E.5 QUDV Concepts Diagram SysML 1.6 open
SYSML17-271 Typos/editorials found in the SysML 1.6 specification document SysML 1.6 open
SYSML17-347 The 'initialValues' compartment needs to be renamed 'contextValues' and they need to be referred to as 'context-specific values' SysML 1.6 open
SYSML17-371 Suggest primary/replica as alternative to master/slave terminology for Copy relationship SysML 1.6 open
SYSML17-370 SysML-1.6: Refers to both 'composite requirement' and 'compound requirement' SysML 1.6 open
SYSML17-369 BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features SysML 1.6 open
SYSML17-368 9.3.2.13 ProxyPort 'When a proxy port is connected to a single internal part ...' extend to include ' or port on an internal part' SysML 1.6 open
SYSML17-365 Meta-ticket: SysML-1.6: Specification body (only) figure inconsistencies and errors and related text inconsistencies SysML 1.6 open
SYSML17-367 InterfaceBlock: constraint 2_no_part is missing FlowProperty check SysML 1.6 open
SYSML17-366 Need constraint for inverted provided/required Interfaces (InterfaceRealization and Usage) on ~InterfaceBlock SysML 1.6 open
SYSML17-361 SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [also affects Figure 16-6] SysML 1.6 open
SYSML17-362 'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it as 'an example of a compound requirement' SysML 1.6 open
SYSML17-348 Figure 8-17: Vehicle specialization: multiple inconsistencies SysML 1.6 open
SYSML17-349 'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features SysML 1.6 open
SYSML17-350 SysML-1.6 does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports'. And does not show direction of flows on Ports symbols SysML 1.6 open
SYSML17-352 Figure 9-16 and Figure 9-17 'Usage example of item flow decomposition': multiple inconsistencies SysML 1.6 open
SYSML17-351 If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8 SysML 1.6 open
SYSML17-353 The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator SysML 1.6 open
SYSML17-354 Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow SysML 1.6 open
SYSML17-357 Suggest introduce strict diagram policy: avoid "elided Pin" ObjectNode notation in Activity Diagrams in all revised and future specification figures SysML 1.6 open
SYSML17-364 Suggest additional main body figure illustrating context-specific values (initialValues) compartment used for deep system configuration SysML 1.6 open
SYSML17-310 Figure 9-5 and 9-4 are the same SysML 1.6 open
SYSML17-329 Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0' SysML 1.6 open
SYSML17-355 'Figure 15-4: Behavior Allocation' multiple issues in the diagram and the supporting text SysML 1.6 open
SYSML17-356 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to a FlowProperty and multiple other minor issues SysML 1.6 open
SYSML17-360 Fig D.41 should be bdd with instance specs & slot values, not ibd with default values SysML 1.6 open
SYSML17-363 SysML-1.6: DeriveReqt: OCL constraint directions client vs supplier SysML 1.6 open
SYSML17-358 Trivial: consistency: Either show the [metaclass] on all Stereotype symbols or none in 'Figure 16-1: Abstract Syntax for Requirements Stereotypes' SysML 1.6 open
SYSML17-339 Figure D.24 Parametric Diagram does not explicitly show «equal» keyword or '=' on BindingConnectors SysML 1.6 open
SYSML17-344 Typo: 'not' should be 'nor' in '... not is this always even desirable' SysML 1.6 open
SYSML17-343 Typo: references to FuelTankAssy should be FuelTankAssembly for consistency with Figure D.25 SysML 1.6 open
SYSML17-334 Typo: 'Various other model elements may be necessary to help develop a derived requirement, and these model element' plural missing SysML 1.6 open
SYSML17-336 Typo: Missing end parentheses bracket: '(described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams)' SysML 1.6 open
SYSML17-330 Typo: 'with is owned by the AutomotiveDomain block.' SysML 1.6 open
SYSML17-342 Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)' SysML 1.6 open
SYSML17-341 Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.' SysML 1.6 open
SYSML17-338 Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification» SysML 1.6 open
SYSML17-332 'Figure D.7 - Elaborating Black Box Behavior' some OCL missing, State names in oclInState() should be capital first letter, and display of name of alt fragment SysML 1.6 open
SYSML17-345 SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows) SysML 1.6 open
SYSML17-346 7.3.2.3 Expose refers to 'The method' without referencing Viewpoint SysML 1.6 open
SYSML17-340 Typo: 'Binding connectors, as defined in Clause 8 are used ...' missing comma SysML 1.6 open
SYSML17-333 Typo: 'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.' should be 'deletes' SysML 1.6 open
SYSML17-337 Typo: 9.3.2.8 FlowProperty 'A flow propertys values' SysML 1.6 open
SYSML17-335 For Connectors in IBD Figure D.4 to be typed by implied anonymous Associations need define them in BDD Figure D.15 between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment' SysML 1.6 open
SYSML17-331 In Figure D.2 Real appears to be owned by the Automotive Value Types ModelLibrary (with no explicit ElementImport) SysML 1.6 open
SYSML17-307 Lots of ControlValues that should be ControlValueKinds SysML 1.6 open
SYSML17-317 Incorrect description of SysMLBlockDefinitionDiagram SysML 1.6 open
SYSML17-319 It should not be allowed to modify an AdjunctProperty SysML 1.6 open
SYSML17-232 Table 8.3: Row ActorPart shows Actor SysML 1.6b1 open
SYSML17-289 Allocate: Error in operation bodies SysML 1.6 open
SYSML17-266 UML::ExceptionHandler should be part of SysML SysML 1.6 open
SYSML17-265 Stereotype Rate extends ObjectNode in the XMI, but not in the abstract syntax in the specification SysML 1.6 open
SYSML17-316 Duplicated sentence SysML 1.6 open
SYSML17-315 Unexpected word 'Figure' in Figure 4-2 name SysML 1.6 open
SYSML17-314 Unexpected section number SysML 1.6 open
SYSML17-313 Clarify that contraint parameters are value properties SysML 1.6 open
SYSML17-308 7_cannot_redefine_boundreference is too constrained SysML 1.6 open
SYSML17-306 Aggregation multiplicities not correct SysML 1.6 open
SYSML17-300 SysML 1.6 statement is too strong SysML 1.6 open
SYSML17-299 Caveat is not specific for UseCases SysML 1.6 open
SYSML17-293 Introduction to 9.1.3 Proxy Ports and Full Ports might be interpreted as SysML only permitting Full and Proxy Ports (not standard ports) SysML 1.6 open
SYSML17-298 Continuous and Discrete need to be on FlowProperties as well SysML 1.6 open
SYSML17-296 No Creation and Destruction Event in Current UML SysML 1.6 open
SYSML17-297 Figure 11-14 is identical with figure 11-13 SysML 1.6 open
SYSML17-295 Figure 9.5 missing, duplicates 9.4 SysML 1.6 open
SYSML17-290 Remove reference to non-existing properties allocatedFrom and allocatedTo SysML 1.6 open
SYSML17-286 Remove notation form ActorPart SysML 1.6 open
SYSML17-284 Conjugation Stereotype SysML 1.6 open
SYSML17-285 is the stereotype <<~InterfaceBlock>> SysML 1.6 open
SYSML17-283 Need Bound References Compartment SysML 1.6 open
SYSML17-274 Parameters and Variables don't make sense SysML 1.6 open
SYSML17-181 VerdictKind enumeration missing SysML 1.6 open
SYSML17-182 Verdict described incorrecty SysML 1.6 open
SYSML17-239 AllocateActivityPartition: Reference to UML specification is wrong SysML 1.6b1 open
SYSML17-248 The definition of AdjunctProperty SysML 1.6 open
SYSML17-234 QUDV library inconsistently uses SysML::Libraries::PrimitiveValueTypes SysML 1.6b1 open
SYSML17-278 AbstractRequirement: direction of /tracedTo wrong in Attributes description SysML 1.6 open
SYSML17-276 Description of getRefines() restricts returned elements to AbstractRequirement [0..*] but the OCL static query does not (effectively NamedElement [0..*]) SysML 1.6 open
SYSML17-277 Description of getRefines() has typo and inconsistent singular vs plural SysML 1.6 open
SYSML17-275 Parts is too restrictive SysML 1.6 open
SYSML17-273 Missing guard brackets in example activity diagram 11-12 SysML 1.6 open
SYSML17-261 How to interpret non-Navigation SysML 1.6b1 open
SYSML17-252 ConstraintBlock: abstract syntax consistency SysML 1.6 open
SYSML17-251 Syntactical clarification for ConstraintBlock SysML 1.6 open
SYSML17-258 No changebars in SysML 1.6b1 open
SYSML17-257 Proposal: patent-friendly part/element numbering system with compliant solid line SysML 1.6b1 open
SYSML17-250 Should <> have a capital V? SysML 1.6b1 open
SYSML17-249 Duplicate Elements in Table SysML 1.6b1 open
SYSML17-243 Refine / Trace relationship operations are too restrictive SysML 1.6b1 open
SYSML17-242 VerdictKind should also have the literal none SysML 1.6b1 open
SYSML17-237 Precise Semantics for SysML SysML 1.6 open
SYSML17-233 Comments in the XMI have no annotated elements SysML 1.6b1 open
SYSML17-231 ProxyPort property "matching" SysML 1.6 open
SYSML17-220 Bad reference in section 4.2 SysML 1.6 open
SYSML17-222 Typo: Constraint name 8 of Adjunct Property SysML 1.6 open
SYSML17-218 Stakeholder constraint is listed twice SysML 1.6 open
SYSML17-178 Virtual member representing the whole RTF SysML 1.6 open
SYSML17-227 About Block constraint "3" removed by SysML v1.6 SysML 1.6 open
SYSML17-214 Hidden constraints in description of PropertySpecificType SysML 1.6 open

Issues Descriptions

Figure E.6 QUDV Units Diagram display exactly the same content as Figure E.5 QUDV Concepts Diagram

  • Status: open  
  • Source: KARL STORZ SE & Co. KG ( Marting Bohring)
  • Summary:

    In Version SysML 1.5 the QUDV Units diagram presented the other Unit Types. In Version SysML 1.6 the Units Diagram displays the same content as the Concepts Diagram.
    AS a result the Units Diagram of SysML Version 1.5 has disappeared

  • Reported: SysML 1.6 — Wed, 15 Jul 2020 11:50 GMT
  • Updated: Tue, 21 Jul 2020 20:50 GMT

Typos/editorials found in the SysML 1.6 specification document

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

    This issue is dedicated to collect all typos and editorials we find in the SysML1.6 specification document. See linked annotated PDF for the list.

    -------------------------------------------------------------------------------------------------------
    >>> Note to RTF Chairs: do not schedule this issue for voting before the last ballot of the RTF; until then we update the list in the issue description if we find new typos <<<
    -------------------------------------------------------------------------------------------------------

  • Reported: SysML 1.6 — Tue, 10 Dec 2019 17:40 GMT
  • Updated: Sun, 19 Jul 2020 12:45 GMT

The 'initialValues' compartment needs to be renamed 'contextValues' and they need to be referred to as 'context-specific values'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    I have never liked the term 'initial values' or the compartment name 'initialValues' for what were originally called 'context-specific values'.

    I propose instead they be called 'context-specific values' because that is what they in fact are (values within the context of a top-level configuration block), and a compartment 'contextValues'.

    In most cases the values as used have nothing to do with "initial". Even the spec example Figure D.41 has nothing to do with initial, it is about a test configuration.

    I helped supervise development and testing of this feature many years ago in the MagicDraw tool (along with Nerijus at No Magic). It was the first tool to implement the feature. Back then we referred to the feature as context-specific values (and it used to be called that in the tool menu).

    I have been using this feature a lot for some years with real world clients. Nearly all of them find the term 'initialValues' completely confusing, especially after just having been introduced to the 'defaultValue' concept.

    Case: Am using SysML for a construction group. They use initialValues to describe multiple "deep" configurations of buildings in different modes and customer configurations. They find the term initialValues completely confusing.

    Case: The mobile phone initialValues sample available for MagicDraw/Cameo is in fact a "deep" configuration example (and an excellent one) and has nothing to do with "initial values".

    I also have a course session dedicated to how to use this feature for "deep" configuration of systems. Attendees find the term 'initialValues' completely confusing, I tell them to call it 'contextValues' instead.

    And as for time? If you want to use the feature to show the value state of a system at different times: t0, t1, t2, t3 in different block contexts you can't; because the compartment name 'initialValues' makes it sound like every time slice is the initial time t0.

    It truly has to go. It does not work. The compartment name 'contextValues' works for all cases.

    I have even taken to "painting over" the term 'initialValues' in some diagrams.

    This SysML feature/capability itself is extremely important and useful; it's an absolutely critical extension over UML.

  • Reported: SysML 1.6 — Sun, 28 Jun 2020 00:41 GMT
  • Updated: Mon, 6 Jul 2020 17:11 GMT

Suggest primary/replica as alternative to master/slave terminology for Copy relationship

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Suggest primary/replica as alternative to master/slave terminology for Copy relationship.

    The term 'slave' appears on p.181:

    The use of namespace containment to specify requirements hierarchies precludes reusing requirements in different contexts since a given model element can only exist in one namespace. Since the concept of requirements reuse is very important in many applications, SysML introduces the concept of a slave requirement. A slave requirement is a requirement whose text property is a read-only copy of the text property of a master requirement. The text property of the slave requirement is constrained to be the same as the text property of the related master requirement. The master/slave relationship is indicated by the use of the copy relationship.

    And p.188:

    getMaster () : AbstractRequirement [0..*]
    bodyCondition: Copy.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier

    p.189

    A Copy dependency created between two requirements maintains a master/slave relationship between the two elements for the purpose of requirements re-use in different contexts.

    The change would also require changing all references to '/master' to '/primary'.

    In 2014 Drupal CMS adopted the term primary/replica.

    The terminology master/slave has recently been removed from the Python language.

    There are some other options recently adopted by technology companies, but they do not play as nicely with the Copy relationship as 'primary/replica'.

  • Reported: SysML 1.6 — Mon, 6 Jul 2020 09:24 GMT
  • Updated: Mon, 6 Jul 2020 09:24 GMT

SysML-1.6: Refers to both 'composite requirement' and 'compound requirement'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.181

    16.1 Overview
    ...
    A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its containing child requirements. A composite requirement ..

    p.191

    16.3.2.5 Requirement
    ...

    Compound requirements can be created by using the nesting capability of the class definition mechanism. The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied.
    ...

    Might be best to choose just one term 'compound requirement' or 'composite requirement

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 14:00 GMT
  • Updated: Sun, 5 Jul 2020 14:01 GMT

BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    EDIT: from SysML-1.6 p.52:

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

    SysML-1.6 p.52 states:

    1_compatible_types

    The two ends of a binding connector shall have either the same type or types that are compatible so that equality of their values can be defined.

    self.base_Connector.end->at(1).role.type.conformsTo(self.base_Connector.end
     ->at(2).role.type) or self.base_Connector.end
     ->at(2).role.type.conformsTo(self.base_Connector.end->at(1).role.type)
    

    OCL-1.4 states concerning conformsTo:

    8.2.1 Type Conformance

    The type conformance rules are formally underpinned in the Semantics sub clause of the specification. To ensure that the rules are accessible to UML modelers they are specified in this sub clause using OCL. For this, the additional operation conformsTo(c : Classifier) : Boolean is defined on Classifier. It evaluates to true, if the self Classifier conforms to the
    argument c.

    ...

    [2] Classes conform to superclasses and interfaces that they realize.
    context Class
    inv : self.generalization.general->forAll (p |
    (p.oclIsKindOf(Class) or p.oclIsKindOf(Interface)) implies
    self.conformsTo(p.oclAsType(Classifier)))
    

    As far as this submitter can tell, there is no sense in which OCL conformsTo is not Type-based at the level of a Classifier.

    This renders numerous desirable ProxyPort connection scenarios invalid.

    Case: A ProxyPort of InterfaceBlock type PP1 and an internal part property of block type Standalone, where PP1 and StandalonePart have identical Feature signatures, but do not share a Type relationship.

    From SysML-1.6 p.52:

    9.3.2.13 ProxyPort

    ...

    When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector (the value of the proxy port and the connected internal part are the same; links of associations typing the connector are between all objects and themselves, and no others).

    Whether one uses a BindingConnector or a Connector with the same semantics, the reported constraint renders the Connection from proxy port :PP1 to internal part :Standalone invalid, even though all Features match, because there is no type "value" equivalence.

    Consider now from p.103:

    When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate as if they were to those parts, and flows and invocations it receives from those parts as if they were to the outside.

    ASIDE: The spec could make clearer in the above whether the Connectors that are used for such multiple connections are NOT BindingConnectors

    An attempt to work around it using multiple Connectors from the proxy port :PP1 to at least all of the Property features of internal part :Standalone - which are themselves 'parts' in the UML sense - also leads to a contradiction w.r.t:

    the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features ..

    The attempt was to aggregate the Property features themselves, not their features.

    And even if the above were to work, it does not address the compatibility with Operations, and is also highly impractical in tools when there are many Properties to bind (collect).

    The complexity and number of possible contradictions explodes when indeed connections are made to multiple parts.

    What is needed is a completely different definition of compatibility that is not bound in any way to types, but primarily to matching Features (including Operations, Receptions and Properties) by "collecting" the Features via Connectors to their owners.

    This would then support common engineering scenarios where subsets of Features of internal parts are aggregated and then "exported" via a single exposed Port.

    This would greatly reduce the number of Connectors needed, and would make validation in tools much easier. Type-based compatibility can still be kept, but it is just a special case of Feature-wise compatibility.

    The Property features of internal part :Standalone clearly count as 'multiple internal parts'. Assuming regular Connectors are used (but not BindingConnectors) from proxy port :PP1 to every Property of internal part :Standalone

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 09:28 GMT
  • Updated: Sun, 5 Jul 2020 11:34 GMT

9.3.2.13 ProxyPort 'When a proxy port is connected to a single internal part ...' extend to include ' or port on an internal part'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.103

    Proxy ports can be connected to internal parts or ports on internal parts, identifying features on those parts or ports that are available to external blocks.

    And:

    When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector ...

    The 2nd sentence would more consistent if it included ' or port on an internal part' thus:

    When a proxy port is connected to a single internal part or port on an internal part, the connector shall be a binding connector, or have the same semantics as a binding connector ...

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 08:45 GMT
  • Updated: Sun, 5 Jul 2020 08:45 GMT

Meta-ticket: SysML-1.6: Specification body (only) figure inconsistencies and errors and related text inconsistencies

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    For issues with figures and diagrams and directly related text in the main specification body (only).

    Excludes diagrams from Annex D (but includes those diagrams in the text body that should be consistent with the Hybrid SUV sample problem).

    Includes diagrams that are not related to the Hybrid SUV sample problem.

    To prevent issue explosion, please report minor issues as single comments here.

    Please link more substantial issues related to main spec body figures and related text to this meta-ticket.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 12:54 GMT
  • Updated: Sun, 5 Jul 2020 08:28 GMT

InterfaceBlock: constraint 2_no_part is missing FlowProperty check

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.99

    2_no_part

    Interface blocks composite properties are either ports, value properties or flow properties.

    self.base_Class.ownedAttribute->select(a|a.isComposite)->forAll(a |
    a.oclIsKindOf(UML::Port) or a.oclIsKindOf(ValueType))

    Needs to also check a.oclIsKindOf(FlowProperty))

  • Reported: SysML 1.6 — Sat, 4 Jul 2020 14:50 GMT
  • Updated: Sat, 4 Jul 2020 14:51 GMT

Need constraint for inverted provided/required Interfaces (InterfaceRealization and Usage) on ~InterfaceBlock

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    SysML-1.6 supports Interfaces provided/required (InterfaceRealization and Usage) by a Block, including an InterfaceBlock.

    Given that UML-style Port conjugation is not supported in SysML-1.6, a mechanism for inversion of provided/required Interfaces is needed.

    While Figure D.19 does not show the Port types, it does show provided/required Interfaces on Ports, and it is implied by other diagrams in the sample problem that those Ports that have inverted provided/required Interfaces are typed by ~InterfaceBlocks.

    A constraint should be added to 9.3.2.15 ~InterfaceBlock corresponding to the inversion of any required/provided Interfaces on the original InterfaceBlock.

  • Reported: SysML 1.6 — Fri, 3 Jul 2020 09:25 GMT
  • Updated: Fri, 3 Jul 2020 09:26 GMT

SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [also affects Figure 16-6]

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Figure 16-2: Requirements Derivation

    In SysML-1.5 Requirement text was:

    (a) IBT: <= 65 °C (149 °F), <= 100 °C (212 °F). (b) Test surface: PFC of at least 0.9.

    In SysML-1.6 p.195 Requirement text does not have comparison operators.

    Tested in Adobe Reader and Mac Preview on a Mac.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 08:54 GMT
  • Updated: Thu, 2 Jul 2020 13:16 GMT
  • Attachments:

'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it as 'an example of a compound requirement'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.195

    SysML-1.6: Figure 16-2: Requirements Derivation indeed shows DeriveReqt examples, but the spec text refers to it as 'an example of a compound requirement'.

    Either: The spec text needs to say is also an example of DeriveReqt

    Or: The figure needs to be renamed to something like: Figure 16-2: Requirements Derivation and compound requirements

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 09:05 GMT
  • Updated: Thu, 2 Jul 2020 13:15 GMT

Figure 8-17: Vehicle specialization: multiple inconsistencies

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    From SysML-1.6:

    'The specialization on the lower left restricts the number of cylinders to four, requires a light roll bar, and a total of 24 lug bolts over all the wheels. '

    In block Vehicle Model 1:

    • The multiplicity of cylinderBR should be [4] not [*]
    • Multiplicity of rollBarBR should be [1] not [*] and it has no redefined type for the 'light roll bar' (it would also help if the parent block Vehicle and the sub-blocks all showed the types on their properties).
    • Multiplicity of lugBoltBR in the spec figure is [6..8], it should be [6]

    'The specialization on the lower right restricts the number of cylinders to between six and eight, rules out any roll bar, and limits lug bolts per wheel to between 6 and 7, by giving the end path upper and lower values.'

    In block Vehicle Model 1:

    • Multiplicity of rollBarBR should be [0] not [*]
    • EndPathMultiplicity is applied to rollBarBR instead of lugBoltBR
    • It's also not entirely clear (to me) whether the multiplicity of lugBoltBR should be [*].

    The annotated attachment shows an attempt at improving it (but is not offered as a resolution figure).

  • Reported: SysML 1.6 — Sun, 28 Jun 2020 13:55 GMT
  • Updated: Thu, 2 Jul 2020 13:05 GMT
  • Attachments:

'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    All the diagram shows is some port types and their conjugated types.

    It would be more instructive if the ports on the diagram used the capability to show the underlying directed features of the blocks that type the ports.

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 05:54 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

SysML-1.6 does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports'. And does not show direction of flows on Ports symbols

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    SysML-1.6 spec figure 'Figure 9.7 - Usage example of proxy and full ports'.

    Does not leverage redefinition of sp:Surface, which is shown as redefined in many blocks but nothing is actually redefined.

    Some earlier spec versions did leverage the redefinition, see also the attachment for similar done in a tool.

    Also, it does not show direction of flows on the ports (but this notation is optional).

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 06:36 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

Figure 9-16 and Figure 9-17 'Usage example of item flow decomposition': multiple inconsistencies

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.115:

    Figures 9.16 and 9.17 are examples of item flow decomposition that modelers might choose...

    Should be 'Figures 9-16 and 9-17'

    p.115:

    In Figure 9-16, the item flow classifier (EnginePart) is a supertype of the classifiers of the item flows in the decomposition. The flow properties are all in the types of the nested ports ...

    But it does not show those flow properties in the lower BDD (compare with attachment 1).

    It would make sense to show the flow property direction indicators in the structure compartment of A1 in the lower BDD.

    Minor/optional: If the parent ports do not have any flow properties in this example, it might be better to not show the flow direction indicator in the parent port in Figure 9-16, even though the flow direction for each nested port within each parent port is in the same direction. Then, for contrast, the flow direction indicators can be shown on the parent ports of Figure 9-17, noting they have explicit flow properties.

    p.115 and p.116:

    In Figure 9-17, the item flow classifier (Engine) composes the classifiers of the items flows in the decomposition from Figure 9-17.

    This should probably be 'from Figure 9-16'.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 00:29 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8: Water Delivery association block

    Although it is explained in the text, I have had many clients and training customer unnecessarily imitate it.

    It [EDIT: the «port» keyword] is introduced in Figure 9-8, and then never used in any of diagrams that follow.

    If it must stay, it should be made clear that it is a user-defined stereotype keyword.

    BTW: I address this in my own models by using conventions for Port type naming: I_Contract, F_FlowStuff etc.

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 07:45 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.147 Figure 11-10: Continuous system example 1 shows an object flow with an object token of type ControlValue (should probably be ControlValueKind) from a ControlOperator Enable on Brake Pressure > 0 to Monitor Traction.

    The notation shown is consistent with UML-2.5.1 "elided Pin" notation:

    'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

    The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

    Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

    At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type

    SysML-1.6 p.146 states:

    Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior. No pins are used on Monitor Traction, so once it is enabled, the continuously arriving enable control values from the control operator have no effect, per UML semantics.

    It is not permissible in UML-2.5.1 to have 'No pins used on Monitor Traction'. And if there were no Pins, it is not clear how {contro\l} is indicated in Figure 11-10, because, from UML-2.5.1:

    Control Pins are shown with the textual annotation {control} placed near the Pin symbol.

    If there are 'No pins used on Monitor Traction' the {control} notation can't be supported.

    Further: SysML-1.6 p.127 states:

    A control value is an input or output of a control operator ..

    If there is any sense in which it can be "input" to another type of Action (the controlled one), this should also be stated.

    On SysML-1.6 p.140 it is not made clear what 'control parameters' are:

    Pins for control parameters are regular pins, not UML control pins.

    If they are parameters of a Behavior with the ControlOperator stereotype applied this should be clearly stated. Otherwise, the (necesssary) {control} input Pin required on Monitor Traction in Figure 11-10 could be considered to have an underlying "control parameter" that contradicts the above rule.

    A partial solution (apart from suggested expansions of the explanatory text) would be to at least use an explicit {control} Pin on Monitor Traction and remove the claim that it has no Pins.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 10:09 GMT
  • Updated: Thu, 2 Jul 2020 13:03 GMT
  • Attachments:

Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The edge for the [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow (it is currently dashed):

    From UML-2.5.1:

    edges

    The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 11:49 GMT
  • Updated: Thu, 2 Jul 2020 13:03 GMT

Suggest introduce strict diagram policy: avoid "elided Pin" ObjectNode notation in Activity Diagrams in all revised and future specification figures

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    I suggest that diagram submitters never ever again use the infamous "elided Pin notation" for ObjectNode anywhere in the spec, as it is widely misunderstood and the tool support for it is poor (broken).

    This concerns not only the Annex D sample problem, but all other Activity Diagrams in all figures in the spec.

    The problematic "elided Pin" notation as described in UML-2.5.1 :

    'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

    The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

    Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

    At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type.

    I appreciate the OMG JIRA is not intended for personal remarks, but I can't begin to explain how much time wrangling with broken "elided Pin" ObjectNode notation in one tool has cost me, time which could be better used contributing to the specification. I ask you all to please vote yes for this in a ballot soon so that I can contribute more.

    DK

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 11:31 GMT
  • Updated: Thu, 2 Jul 2020 13:01 GMT
  • Attachments:

Suggest additional main body figure illustrating context-specific values (initialValues) compartment used for deep system configuration

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    It has been suggested that sample Figure D.41 should not be an IBD but a BDD with objects (instances).

    A new spec example (not related to Annex D Hybrid SUV problem) is then required.

    Suggest use mobile phone camera configuration example (known to me and a tool vendor).

    Submitter willing to provide spec-friendly diagram(s) and supporting spec text.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 11:18 GMT
  • Updated: Thu, 2 Jul 2020 13:01 GMT

Figure 9-5 and 9-4 are the same

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

    Figure 9-5 (Item Flow Stereotype) is the same as Figure 9-4 (Provided and Required Features).

  • Reported: SysML 1.6 — Thu, 5 Mar 2020 15:39 GMT
  • Updated: Thu, 2 Jul 2020 12:59 GMT

Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The 'Figure 11.12 - Continuous system example 3' for the Activity 'Enable on Brake Pressure > 0' shows a single incoming ObjectFlow from the ActivityParameterNode pressure : Brake Pressure to a DecisionNode with two outgoing ControlFlows (shown dashed) with guards vs Brake Pressure.

    It is not indicated whether the incoming ObjectFlow is a DecisionNode::decisionInputFlow. Assuming it is or is not both lead to contradictions vs the UML-2.5.1 spec.

    First, assume that is it not a decisionInputFlow. Then according to UML-2.5.1 it is then the primary incoming edge:

    A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge.

    But this means the reported figure immediately contradicts:

    If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

    Because in the reported figure clearly there is a mix of a single incoming ObjectFlow and 2 outgoing ControlFlows.

    Let us then instead assume that the incoming ObjectFlow is a decisionInputFlow. The UML spec then seems to require that there be an additional ControlFlow (that is not present in the reported figure).

    Some related UML-2.5.1 spec quotes and constraints:

    edges
    The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

    incoming_outgoing_edges
    A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge.

    decisionInputFlow : ObjectFlow [0..1] (opposite A_decisionInputFlow_decisionNode::decisionNode)
    An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode.

    If the primary incoming edge of a DecisionNode is an ObjectFlow, and the DecisionNode does not have a decisionInput or decisionInputFlow, then the value contained in an incoming object token may be used in the evaluation of the guards on outgoing ObjectFlows.

    This is clearly not consistent with the reported figure, which has outgoing ControlFlows.

    The following seems to imply that decisionInputFlow is always accompanied by another incoming edge, but this is not (as far as I can tell) made explicit elsewhere as a constraint:

    If a DecisionNode has a decisionInputFlow, then a token must be offered on both the primary incoming edge and the decisionInputFlow before the token from the primary incoming edge is offered to the outgoing edges.

    [ASIDE: The UML-2.5.1 might be inconsistent when referring to 'incoming' w.r.t. decisionInputFlow (but this does not explain away the inconsistency in the reported SysML spec figure). The DecisionNode::decisionInputFlow does not subset ActivityNode::incoming:ActivityEdge[0..*], but it is sometimes referred to as an incoming edge.]

    An additional consideration is why outgoing ControlFlows are being used in the first place. The UML-2.5.1 does not seem to explicitly reject the use of incoming ObjectFlows on a ValueSpecification (although at least one tools declares InputPins on them to be invalid). It is not clear to this reporter that ObjectFlows with Probability could not be used to activate the ValueSpecifications for enable/disable (even though the reported spec figure for this version seems to have been changed to used dashed-line ControlFlows, compared with previous SysML spec versions).

    [EDIT:DK: Axel explained: 'ValueSpecificationActions can in fact have no InputPins (the attribute input is a derived union and ValueSpecificationActions don't define a subset of it).']

    It seems to this reporter that there are 2 solutions to the reported inconsistency:

    1. Somehow use an additional ControlFlow to the DecisionNode, and declare the existing Brake Pressure incoming ObjectFlow to be a decisionInputFlow.

    2. "Revert" the outgoing edges to be ObjectFlows [NOT permitted]

  • Reported: SysML 1.6 — Mon, 15 Jun 2020 04:47 GMT
  • Updated: Thu, 2 Jul 2020 12:58 GMT

'Figure 15-4: Behavior Allocation' multiple issues in the diagram and the supporting text

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The title of the section is:

    15.4.1 Behavior Allocation of Actions to Parts and Activities to Blocks

    There is in fact no allocation of an Activity to a Block, there is an allocation of an Activity6 to a Part7.

    From p. 177:

    Specific behavior allocation of Actions to Parts are depicted in Figure 15-4.

    But the diagram includes an allocation from an Activity6 to a Part7 (that it is a part is confirmed by the «part» keyword in the allocatedTo callout).

    The allocation to Activity6 comes from a nested part ..

    The allocation is from the Activity6 to a part ...

    The use of part names 'Part5', 'Part7' with Capitals is confusing. It is much clearer to have property names that are lowerCase. If they must have names with Capitals then the Blocks that type them should be shown (see attached image).

    The use of the part name 'Block1' as the allocation target for Action1 is beyond confusing when there is a block Block1 in the same diagram.

    ASIDE: I wish the RTF diagram contributors would adopt a policy across the entire specfication of using lowerCamelCase (no spaces) for all block properties and UpperPascalCase (no spaces) for all Blocks

    The diagram figure is low resolution and needs to be replaced.

    The following may be in part MagicDraw/Cameo 19SP3 tool issues:

    • The path callout in the Note for the allocatedTo on Activity6 in the tool is '«part» Block4::Block7::part7'; the spec has '«part» Block4.Part5.Part7'
    • The tool could not (as far as I can tell) display the qualified name corresponding to Part:Block1 for the header in a swimlane
  • Reported: SysML 1.6 — Wed, 1 Jul 2020 03:34 GMT
  • Updated: Thu, 2 Jul 2020 12:58 GMT
  • Attachments:

'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to a FlowProperty and multiple other minor issues

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    In SysML-1.6 p.179: Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty

    The diagram does not show any allocation to a FlowProperty.

    Also:

    • It does not show the allocatedFrom for 'Action2' on Block7
    • It does not make sense naming the BDD 'Block0' if that block is not shown in the diagram

    There are allocations from Actions (usage level) to Blocks (definition level); whether that is an error is a matter of opinion, as it would seem SysML permits it. I suggest, however, that the spec figures completely avoid such "cross-level" allocations in the spec figures.

    May I once again suggest (plead, beg) diagram submitters to not (never ever again) use the infamous "elided Pin notation" for ObjectNode anywhere in the spec, as it is widely misunderstood and the tool support for it is poor (broken).

    An example diagram in the MagicDraw tool including explicit Pins is included. The naming conventions is different from the spec figures.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 11:20 GMT
  • Updated: Thu, 2 Jul 2020 12:57 GMT

Fig D.41 should be bdd with instance specs & slot values, not ibd with default values

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

    Figure D.41 is unchanged from SysML 1.0. The purpose of the figure was to illustrate how part serial numbers can be handled in SysML, but it was created without any practical experience in instance specification slot values. Instance slot values provide a more concrete representation of instance-level values such as serial numbers. A serial number should never be treated as a default value, because each serial number needs to be unique.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 17:13 GMT
  • Updated: Thu, 2 Jul 2020 11:19 GMT

SysML-1.6: DeriveReqt: OCL constraint directions client vs supplier

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.190: please check OCL directions:

    1_supplier_is_requirement

    The supplier shall be an element stereotyped by a subtype of
    AbstractRequirement.AbstractRequirement.allInstances().base_NamedElement->includesAll(self.base_Abstraction.client)

    2_client_is_requirement

    The client shall be an element stereotyped by a subtype of
    AbstractRequirement.AbstractRequirement.allInstances().base_NamedElement->includesAll(self.base_Abstraction.supplier)

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 09:45 GMT
  • Updated: Thu, 2 Jul 2020 09:45 GMT

Trivial: consistency: Either show the [metaclass] on all Stereotype symbols or none in 'Figure 16-1: Abstract Syntax for Requirements Stereotypes'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The Stereotype symbols for AbstractRequirement and Requirement show their [metaclass], the others do not.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 13:39 GMT
  • Updated: Wed, 1 Jul 2020 13:39 GMT

Figure D.24 Parametric Diagram does not explicitly show «equal» keyword or '=' on BindingConnectors

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    If the Connectors in the Figure D.24 'Defining Fuel Flow Constraints (Parametric Diagram)' are BindingConnectors suggest explicitly show «equal» keyword or '='.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 00:13 GMT
  • Updated: Wed, 24 Jun 2020 07:04 GMT

Typo: 'not' should be 'nor' in '... not is this always even desirable'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    From p.174:

    It is acknowledged that this concept does not support a standard object-oriented paradigm, not is this always even desirable.

    The 'not' should probably be 'nor'

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 04:24 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: references to FuelTankAssy should be FuelTankAssembly for consistency with Figure D.25

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.254:

    The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine.

    Figure D.25 has FuelTankAssembly.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 04:03 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: 'Various other model elements may be necessary to help develop a derived requirement, and these model element' plural missing

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Plural missing in:

    'Various other model elements may be necessary to help develop a derived requirement, and these model element may be related by a «refinedBy» relationship.'

    Should be:

    'Various other model elements may be necessary to help develop a derived requirement, and these model element*s* may be related by a «refinedBy» relationship.'

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 22:22 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: Missing end parentheses bracket: '(described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams)'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    SysML-1.6 p.249:

    Note that the interactions DriveBlackBox and Stac4rtVehicleBlackBox (described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams), are depicted as owned by the AutomotiveDomain block.

    There is a missing end ')'

    (The issue with 'Stac4rtVehicleBlackBox' already caught under SYSML17-271)

  • Reported: SysML 1.6 — Sun, 21 Jun 2020 02:57 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: 'with is owned by the AutomotiveDomain block.'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    This diagram represents the “DriveBlackBox” interaction, with is owned by the AutomotiveDomain block.

    Should be:

    This diagram represents the “DriveBlackBox” interaction, which is owned by the AutomotiveDomain block.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 00:11 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'

    This is implied by p.254:

    The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine ...

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 03:41 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    From SysML-1.6 p.254:

    Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.

    The Figure D.24 shows these value properties: 'fuelFlowRate', 'fuelDemand' and 'fuelPressure' (all lowerCamelCase). The text does not match those value property names.

    The Figure D.24 shows these bound constraint parameters: 'flow rate' (with a space), 'injectorDemand' and 'press'. Suggest also constraint parameter 'flow rate' should be consistently named in the diagram 'flowRate' (no space and lowerCamelCase).

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 02:10 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»

    Known already to Marlin and Rick

  • Reported: SysML 1.6 — Mon, 22 Jun 2020 07:40 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

'Figure D.7 - Elaborating Black Box Behavior' some OCL missing, State names in oclInState() should be capital first letter, and display of name of alt fragment

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Figure D.7 Elaborating Black Box Behavior for the “Drive the Vehicle” Use Case (Sequence Diagram)

    The OCL for the ref fragment for Idle appears to be missing in the SysML 1.6 figure version (was present in the SysML 1.5 version).

    The referenced State name should have capital first letters to match the States in Figure D.1. From OCL-1.4:

    The operation oclIsInState(s) results in true if the object is in the state s. Possible states for the operation oclIsInState(s) are all states of the statemachine that defines the classifier's behavior. ...

    [EDIT: Actually, SysML-1.6 makes explicit that the Interaction DriveBlackBox is owned by the AutomotiveDomain block,
    so the ‘self’ won’t be the same context as for the StateMachine (so it might not be able to reference those States directly).]

    The name of the alt fragment 'controlSpeed' does not appear in the SysML-1.6 figure (it did in SysML-1.5 ). This may be deliberate. And it can't (as far as I can tell) be shown in MagicDraw/Cameo anyway. But it's a bit confusing when referenced here:

    The conditions for each alternative in the alt controlSpeed sub clause are expressed in OCL, and relate to the states of the HybridSUV block, as shown in Figure D.8.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 01:25 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows)

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)

    Has the type Fuel for both an in Port and an out Port on FuelTankAssembly

    And it is not ideal to have same name Fuel as the Classifier Fuel that flows.

    I happen to use the prefix convention F_ for Ports that have flows (only) of one Classifier, so in this case F_Fuel and ~F_Fuel

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 06:36 GMT
  • Updated: Wed, 24 Jun 2020 06:44 GMT

7.3.2.3 Expose refers to 'The method' without referencing Viewpoint

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    7.3.2.3 Expose

    ...
    The view and the model elements related to the view are passed to the constructor when it is invoked. The method describes how the exposed elements are navigated to extract the desired information.

    Although it is explained (somewhat) under 7.1.1. View and Viewpoint, it would be clearer if it said something like:

    The method of the Viewpoint the View conforms to describes how the exposed ...

    Otherwise it reads like a View has a method.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 12:20 GMT
  • Updated: Tue, 23 Jun 2020 12:20 GMT

Typo: 'Binding connectors, as defined in Clause 8 are used ...' missing comma

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    p.123 Has:

    Binding connectors, as defined in Clause 8 are used ...

    Should probably be (note comma after 'Clause 8,'):

    Binding connectors, as defined in Clause 8, are used ...

    This is the pattern used in UML-2.5.1.

    Hope this one is not too trivial to raise as a ticket. Worth establishing a convention/policy

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 00:54 GMT
  • Updated: Tue, 23 Jun 2020 01:02 GMT

Typo: 'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.' should be 'deletes'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.'

    Should probably be:

    'Deleting the container requirement deletes the nested requirements, a functionality inherited from UML.'

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 21:58 GMT
  • Updated: Tue, 23 Jun 2020 01:02 GMT

Typo: 9.3.2.8 FlowProperty 'A flow propertys values'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    A flow propertys values

    Should be:

    A flow property's values

  • Reported: SysML 1.6 — Mon, 22 Jun 2020 07:07 GMT
  • Updated: Mon, 22 Jun 2020 07:07 GMT

For Connectors in IBD Figure D.4 to be typed by implied anonymous Associations need define them in BDD Figure D.15 between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The SysML-1.6 spec states:

    'The associations among the classes may represent abstract conceptual relationships among the entities, which would be refined in subsequent diagrams.'

    'Note how the relationships in this diagram are also reflected in the Automotive Domain Model Block Definition Diagram, Figure D.15.'

    Actually, they aren't, the BDD Figure D.15 only shows non-navigable composition Associations between the Automotive Domain block and the owned Properties, which appear in the IBD Figure D.4 as Property symbols.

    The Connectors in the spec figure have labels like 'x1:', 'x2:', etc. This seems to imply the existence of anonymous Assocations (between 'HybridSUV' and 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'), but they are not defined in Figure D.15.

  • Reported: SysML 1.6 — Sun, 21 Jun 2020 01:41 GMT
  • Updated: Sun, 21 Jun 2020 03:26 GMT
  • Attachments:

In Figure D.2 Real appears to be owned by the Automotive Value Types ModelLibrary (with no explicit ElementImport)

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    In 'Figure D.2: Defining value Types and units to be used in the Sample Problem' the Real appears to be owned by the Automotive Value Types ModelLibrary.

    This might be intended (it might intend to imply there is an ElementImport); if this is the case maybe it should be made explicit somewhere (in a diagram or in text).

    Otherwise, it should be drawn outside the ModelLibrary.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 00:17 GMT
  • Updated: Wed, 17 Jun 2020 00:17 GMT

Lots of ControlValues that should be ControlValueKinds

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Lots of ControlValues that should be ControlValueKinds

  • Reported: SysML 1.6 — Fri, 28 Feb 2020 05:06 GMT
  • Updated: Mon, 15 Jun 2020 05:11 GMT

Incorrect description of SysMLBlockDefinitionDiagram

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Description mentions SysMLBlockDefinitionDiagram stereotype extends UMLPackageDiagram whereas it extends UMLClassDiagram according to Figure B.3 page 219.

  • Reported: SysML 1.6 — Fri, 27 Mar 2020 06:00 GMT
  • Updated: Thu, 14 May 2020 14:44 GMT

It should not be allowed to modify an AdjunctProperty

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

    As described in the specification, AdjunctProperties are clearly intended for representing as properties things that should have been defined as such but that are not for historical reasons.

    However, even if it can actually be convenient to use read actions adjunct properties, it is not clear what is the semantics of using write actions on them. In addition, per its description, it is clear that and an adjunct property is derived from its principal.

    Base on the above, constraints shall be added in order to: (1) require an adjunct property to be derived, and (2) prevent using a adjunct property as the target of write action

  • Reported: SysML 1.6 — Thu, 30 Apr 2020 12:42 GMT
  • Updated: Thu, 30 Apr 2020 15:32 GMT

Table 8.3: Row ActorPart shows Actor

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

    The row ActorPart in table 8.3 should depict SysML::Blocks::PartProperty typed by UML4SysML::Actor, but it shows an Actor.

  • Reported: SysML 1.6b1 — Sat, 18 May 2019 17:37 GMT
  • Updated: Sat, 25 Apr 2020 00:08 GMT

Allocate: Error in operation bodies

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

    The body condition of the Allocate::getAllocatedFrom()
    getAllocatedFrom = Allocate.allInstances()->select(to = ref).from
    should be
    getAllocatedFrom = Allocate.allInstances()->select(supplier = ref).client

    to and from are no stereotype or metaclass properties. The appropriate properties are client and supplier defined in the metaclass "Dependency".

    Accordingly change the Allocate::getAllocatedTo() body condition as well as the name "getAllocatedFrom" to "getAllocatedTo":

    getAllocatedTo = Allocate.allInstances()->select(supplier = ref).client.

  • Reported: SysML 1.6 — Thu, 13 Feb 2020 16:19 GMT
  • Updated: Sat, 25 Apr 2020 00:08 GMT

UML::ExceptionHandler should be part of SysML

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

    According to chapter 4.1 of the SysML 1.6 specification document, RaiseExceptionAction is part of SysML, but the ExceptionHandler is not part of UML4SysML.

    It makes sense to have a complete exception mechanism in SysML, for example, to model exceptional conditions like the violation of a constraint.

    Throwing an exception is not restricted to software, but a useful logical concept of modeling flow behaviors. For instance, it is also included in BPMN.

  • Reported: SysML 1.6 — Thu, 21 Nov 2019 11:30 GMT
  • Updated: Sat, 25 Apr 2020 00:08 GMT

Stereotype Rate extends ObjectNode in the XMI, but not in the abstract syntax in the specification

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

    According to figure 11.8, the stereotype Rate extends UML4SysML::Parameter and UML4SysML::ActivityEdge.

    In SysML.xmi, you can find a third extension of UML4SysML::ObjectNode. The Association Ends section in the specification also lists the ObjectNode extension:

    Association Ends
    • base_ActivityEdge : ActivityEdge [0..1]
    • base_ObjectNode : ObjectNode [0..1]
    • base_Parameter : Parameter [0..1]

    The diagram table in the activity chapter provides a concrete syntax for object nodes with stereotype Rate applied.

    Besides that, the extension of ObjectNode is not mentioned in the specification.

    If it is correct, that Rate extends ObjectNode:

    • Add extension in figure 11.8.
    • Provide semantic

    If it is not correct:

    • Remove extension from XMI and association ends section
    • Remove concrete syntax from diagram table
  • Reported: SysML 1.6 — Thu, 14 Nov 2019 16:26 GMT
  • Updated: Sat, 25 Apr 2020 00:08 GMT

Duplicated sentence

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    The following sentence appears both before the bullet items list and as the first item in the bullet items list.

    "In the context of the definition of a SysML Stereotype, the name refers to the definition of a UML::PrimitiveType in the UML 2 PrimitiveTypes library"

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 04:51 GMT
  • Updated: Fri, 3 Apr 2020 18:51 GMT

Unexpected word 'Figure' in Figure 4-2 name

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Figure 4-2 name is "SysML Extension of UMLFigure".
    The word "Figure" at the end of the legend is not expected.

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 04:47 GMT
  • Updated: Fri, 3 Apr 2020 18:51 GMT

Unexpected section number

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Section number 17.2.1.1 is used whereas section 17.2.1 does not exist

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 02:36 GMT
  • Updated: Fri, 3 Apr 2020 18:50 GMT

Clarify that contraint parameters are value properties

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

    The description given for ConstraintBlock makes it implicit that constraint parameter are value properties but there is no formal constraint about it.

  • Reported: SysML 1.6 — Thu, 12 Mar 2020 14:38 GMT
  • Updated: Thu, 12 Mar 2020 14:38 GMT

7_cannot_redefine_boundreference is too constrained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Standard says.... "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"

    This constraint seems very arbitrary... BoundReference could be used akin to an alias... which allows one to use it as another layer of indirection... BoundReferences should be allowed to refer to other BoundReferences so if the "other BoundReference" changes one does not have to change the first one which refers to it

  • Reported: SysML 1.6 — Sun, 1 Mar 2020 16:36 GMT
  • Updated: Mon, 2 Mar 2020 15:58 GMT

Aggregation multiplicities not correct

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Statement... "That is: "0..1" if the attribute has a composite aggregation and "0..*" otherwise"

    The standard specifies that...
    "8.3.1.1.10 Default multiplicities
    SysML defines defaults for multiplicities on the ends of specific types of associations. A part or shared association has a default multiplicity of [0..1] on the black or white diamond end. A unidirectional association has a default multiplicity of 1 on its target end. These multiplicities may be assumed if not shown on a diagram. To avoid confusion, any multiplicity other than the default should always be shown on a diagram."

    so the assumption would be 0..1 not 0..* on the otherwise part... UML has the same thing

  • Reported: SysML 1.6 — Thu, 27 Feb 2020 18:21 GMT
  • Updated: Mon, 2 Mar 2020 15:57 GMT

SysML 1.6 statement is too strong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    SysML says...
    “Unless a type of diagram element is shown in some form in one of the SysML diagram elements tables, or in a usage example in one of the normative SysML clauses, it is not considered to be part of the subset of UML included within SysML, even if the UML metamodel packages support additional constructs. For example, SysML imports the entire Dependencies package from UML, but it includes diagram elements for only a subset of the dependency types defined in this package.”

    so does that mean all of the actions in common behavior are not there (even though they are explicit included in the tables in the first chapter?)

    I think the statement above in SysML does not include everything... if this is what is wanted then UML4SysML needs to be changed to be only the things in the diagrams in the standard...

  • Reported: SysML 1.6 — Tue, 25 Feb 2020 03:18 GMT
  • Updated: Tue, 25 Feb 2020 14:52 GMT

Caveat is not specific for UseCases

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The current standard says:

    "The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property."

    But this is not totally true... the Communication Path in Use Cases is modeled as an Association and it has no navigability shown, which means it is navigable on both ends, which means ownership on both ends, but the ends are UseCases and Actors which are BehavioredClassifiers which do not have attributes, so this statement in the standard must be added to, to

    (this should go in a sentence in the standard after the sentence cited)
    allow Association to own both end of the association ends if one end is either an Actor or a UseCase.

    I state either because SysML deriving most of its UseCase semantics from UML... an Actor can be associated to a Classifier in a UseCase per UML... and a UseCase can be associated to another UseCase in UML provided that UseCase is not specifying the same Subject... this is specified in UML 2.5.1 in section 18.1.4

    "UseCases may have other Associations and Dependencies to other Classifiers"

    also 18.2.1.4 says "An Actor can only have Associations to UseCases, Components, and Classes. Furthermore these Associations
    must be binary."

    and 18.2.5.6 "UseCases cannot have Associations to UseCases specifying the same subject"

  • Reported: SysML 1.6 — Fri, 21 Feb 2020 14:40 GMT
  • Updated: Tue, 25 Feb 2020 14:51 GMT

Introduction to 9.1.3 Proxy Ports and Full Ports might be interpreted as SysML only permitting Full and Proxy Ports (not standard ports)

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The following sentence under 9.1.3 Proxy Ports and Full Ports can cause confusion:

    SysML identifies two usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    It may be read as SysML only permitting Proxy Port and Full Port.

    I suggest it could be improved by adding the one word 'additional':

    SysML identifies two additional usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    Or more verbosely, something like:

    Apart from standard UML port usage, SysML identifies two additional usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    My experience is that some new SysML users (in part because of the way some tool menus work) get the impression that one somehow should not being standard ports at all in SysML, which is completely wrong.

    Some tools seem to assume (incorrectly) that just because SysML introduces Proxy and Full Port that one is always supposed to use one of them instead of a standard port, and they hide standard ports from some menus.

    I absolutely advocate the use (where appropriate) of standard ports still, especially early on during modelling. External clients of a port are not supposed to care ("know") anyway, it's ultimately an implementation detail.

    The SysML spec itself (as of SysML 1.6) is currently very clear on this:

    • 'Ports that are not specified as proxy or full are simply called "ports."'
    • 'Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full.'
    • 'Modelers can choose between proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology.'
    • 'Modelers have the option of applying stereotypes for proxy and full ports to indicate whether ports are specifying features of their owners and internal parts (proxy), or for themselves separately (full).'
    • 'Using existing blocks with ports only requires knowing the port types ...'
    • 'Modelers can apply stereotypes for proxy and full ports at any stage of model development, or not all if the stereotype constraints are not needed.'
    • 'Figure 9-7 happens to use unstereotyped ports on a general block distributed to users, and stereotyped ports on its specializations for implementation, but the modelers might have not used stereotypes at all ...'
    • 'Unstereotyped ports do not commit to whether they are proxy or full, and do not prevent or dictate future application of the stereotypes'

    etc.

    (There are also considerations when using Ports from readonly libraries.)

  • Reported: SysML 1.6 — Sat, 15 Feb 2020 01:10 GMT
  • Updated: Mon, 24 Feb 2020 03:17 GMT

Continuous and Discrete need to be on FlowProperties as well

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Continuous and Discrete need to be on FlowProperties as well as Parameters and ActivityEdge

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 20:03 GMT
  • Updated: Thu, 20 Feb 2020 20:08 GMT

No Creation and Destruction Event in Current UML

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    UML4SysML::CreationEvent
    UML4SysML::DestructionEvent

    There is no Creation or Destruction Event in the current UML

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 15:10 GMT
  • Updated: Thu, 20 Feb 2020 17:26 GMT

Figure 11-14 is identical with figure 11-13

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

    Figures 11-13 and 11-14 are identical. According to the text figure 11-4 should show an example block definition diagram for object node types, but not object node types are in the diagram.

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 17:08 GMT
  • Updated: Thu, 20 Feb 2020 17:08 GMT

Figure 9.5 missing, duplicates 9.4

  • Status: open  
  • Source: Georgia Institute of Technology ( Marlin Ballard)
  • Summary:

    In this version of the spec, "Figure 9-5: Item Flow Stereotype" is a duplicate of "Figure 9-4: Provided and Required Features" and does not show the ItemFlow stereotype. The correct figure is present in 1.5 (pp85) and the 1.6beta (pp92) versions of the spec.

  • Reported: SysML 1.6 — Mon, 17 Feb 2020 21:34 GMT
  • Updated: Tue, 18 Feb 2020 15:55 GMT

Remove reference to non-existing properties allocatedFrom and allocatedTo

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

    Section 15.3.1.5 states:
    "For brevity, the «elementType» portion of the allocatedFrom or allocatedTo property may be elided from the diagram."

    The properties "allocatedFrom" and "allocatedTo" do not exist. Change the sentence to:

    "For brevity, the «elementType» portion of the allocatedFrom or allocatedTo section may be elided from the diagram."

  • Reported: SysML 1.6 — Thu, 13 Feb 2020 16:21 GMT
  • Updated: Thu, 13 Feb 2020 16:21 GMT

Remove notation form ActorPart

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

    Table 8.3 has a row giving notation for an "Part Property typed by an actor". However since actors cannot have the Block stereotype applied, properties they type cannot be part properties as defined in the SysML specification Clause 8.3.2.4 Block, (p53)). So, this row shall be removed

  • Reported: SysML 1.6 — Thu, 6 Feb 2020 16:59 GMT
  • Updated: Thu, 6 Feb 2020 16:59 GMT

Conjugation Stereotype

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in the Algorithm given in section C.7, they refer to a stereotype named Conjugation (<<conjugates>>) which is also referred to in the resolution information... but that Stereotype does not appear in the standard

  • Reported: SysML 1.6 — Tue, 4 Feb 2020 13:25 GMT
  • Updated: Wed, 5 Feb 2020 20:03 GMT

is the stereotype <<~InterfaceBlock>>

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    is the stereotype on a conjugate block <<~InterfaceBlock>> or <<InterfaceBlock>> not specified in the Standard and very confusing from what information is given in the standard

    I find the whole thing wrong... one should have a stereotype <<InterfaceBlock>> that has the attribute original in it... and remove <<~InterfaceBlock>> ... it works just the same without the confusion... one would need to make original [0..1]... or better yet, one could say that every InterfaceBlock must have an implicitly (possibly created by tool) or explicitly created by the modeler conjugate InterfaceBlock which is in the Model

    one could instead add in the stereotype <<conjugates>> which keeps that information as well... but then there needs to be a constraint in the standard that keeps conjugates and original in sync.. but this would be acceptable to be able to show this in a model

    by the way, there are places in the standard (examples) where it is not original as the attribute

  • Reported: SysML 1.6 — Tue, 4 Feb 2020 13:39 GMT
  • Updated: Wed, 5 Feb 2020 19:51 GMT

Need Bound References Compartment

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in Block1 and Block2, compartments need to be Bound References

  • Reported: SysML 1.6 — Wed, 29 Jan 2020 20:37 GMT
  • Updated: Mon, 3 Feb 2020 16:45 GMT

Parameters and Variables don't make sense

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:
    • diagram was lifted it looks like from UML... the header is UML not SysML needs to be fixed
    • the semantics are unknown, what message can be sent between an in and an inout primitve... would suggest that these are standardized, like set,get messages
    • this shows Parameters and Arguments, but does not show Variables which should be added
  • Reported: SysML 1.6 — Wed, 22 Jan 2020 13:17 GMT
  • Updated: Mon, 27 Jan 2020 10:51 GMT

VerdictKind enumeration missing

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

    VerdictKind appears in a constraint on TestCase and in Table 4.3 (SysML stereotypes, blocks, valuetypes, and datatypes), but isn't defined in the spec. I should be in a model library, like ControlValueKind (see 11.3.3.1 Package ControlValues).

  • Reported: SysML 1.6 — Mon, 21 Jan 2019 15:20 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT
  • Attachments:

Verdict described incorrecty

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

    Clause 16.1 (Requirements, Overview, search on "verdict") refers to "A verdict property of a test case", but verdicts are return parameters, which aren't properties (unless this means an adjunct).

  • Reported: SysML 1.6 — Mon, 21 Jan 2019 15:24 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

AllocateActivityPartition: Reference to UML specification is wrong

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

    The second constraint of the stereotype AllocateActivityPartition references a section in the UML specification:

    "To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic."

    Subclause 12.3.10 does not exist. It is probably 15.6.3.1 in UML 2.5.1.

    I propose to remove the subclause reference number.

  • Reported: SysML 1.6b1 — Wed, 26 Jun 2019 12:50 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

The definition of AdjunctProperty

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

    The definition of AdjunctProperty states that "The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states." However, the practical application to a modeler of these different types of adjunct properties is not made explicit in the text.

    For example, adjuncts of behavior parameters allows a block's behavior to be bound to its value properties, or those in its ports, and thus solves a long standing problem in the language prior to SysML 1.4.

    But when it comes to adjunct properties of activity object nodes the practical application is hard to determine and at the same time it breaks encapsulation by making the behavior's internal state visible and may have a significant impact on the efficiency of model simulation and generated code. The same concerns apply to activity variables.

    I am also mystified about the practical application for adjunct properties of interaction uses and sub-machine states (but not a state machine's states). It would be very useful to have a block property that enumerates the current state of an associated state-machine, but as it stands this is not possible by any means that I am aware of (other then by doing it explicitly inside the state-machine's model).

    Discuss.

  • Reported: SysML 1.6 — Wed, 21 Aug 2019 16:30 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

QUDV library inconsistently uses SysML::Libraries::PrimitiveValueTypes

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

    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.6b1 — Thu, 13 Jun 2019 14:34 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

AbstractRequirement: direction of /tracedTo wrong in Attributes description

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    This is the wrong way round:

    /tracedTo : NamedElement [0..*]
    Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.(derived)

    However the operation statement is correct:

    getTracedTo () : NamedElement [0..*]
    bodyCondition:Trace.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier
    

    See also attached image in a tool.

    Compare with consistent verifiedBy, satisfiedBy:

    /satisfiedBy : NamedElement [0..*]
    Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier.(derived)

    getSatisfiedBy () : NamedElement [0..*]
    bodyCondition:Satisfy.allInstances()->select(base_Abstraction.supplier=self).base_Abstraction.client
    

    /verifiedBy : NamedElement [0..*]
    Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier.(derived)

    getVerifiedBy () : NamedElement [0..*]
    bodyCondition:Verify.allInstances()->select(base_Abstraction.supplier=self).base_Abstraction.client
    

    It seems it was correct in SysML1.4:

    /tracedTo: NamedElement [*]
    Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

    The error may have been introduced during other changes.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 02:37 GMT
  • Updated: Thu, 23 Jan 2020 02:41 GMT
  • Attachments:

Description of getRefines() restricts returned elements to AbstractRequirement [0..*] but the OCL static query does not (effectively NamedElement [0..*])

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    The attached image was initially for analysis of SYSML17-57

    In UML2.5.1 the client(s) and supplier(s) of an Abstraction (including Trace stereotype) are always NamedElements.

    There are no additional constraints placed on the type of the client or supplier of the SysML Refines.

    The description of the operation getRefines() restricts the return elements to AbstractRequirement[0..*]

    getRefines (in ref : NamedElement) : AbstractRequirement [0..*]

    The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter. This is a static query.

    (Typos in the above are addressed in a separate issue report.)

    But the OCL static query does not, and effectively returns NamedElement [0..*]

    bodyCondition:
         Refine.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    

    As examined under SYSML17-15, all of the following are currently valid (see also attached image):

    • Any NamedElement refines a Requirement.
    • A Requirement refines another Requirement.
    • A Requirement refines any NamedElement.
    • Any NamedElement refines another NamedElement.

    Tools correctly implementing the static OCL query permit display (or callout) of getRefined() on any NamedElement.

    It has to be decided whether:

    Option1: The static OCL query should have the return type filtered to only AbstractRequirement (not preferred by this submitter)

    Option2: Loosen the restriction on the description of the return type of getRefined() to the NamedElement[0..*] (preferred by this submitter)

    While Option2 may seem to depart from the initial spirit of the SysML Refines extension within the context of Requirements, it is more consistent with the general UML use of Refines between any (in SysML a pair only) of NamedElements. If this is done, the description also need to be rewritten thus (including typo fixes and fix of plural vs singular):

    The query getRefines() gives all the named elements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the named element in parameter.

    This submitter see no reason why the use of NamedElement[0..*] throughout can't be adopted. Modellers using SysML Refines for Requirement are not impacted, and modellers using Refines for more general purposes would still have access to the useful getRefines().

    The above also implies moving Refines out of the Requirements chapter entirely (into, for example, Model Elements), with a description of the more general use of Refines, but also then describing the typical usage of it for Requirements refinement in the Requirements chapter.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 01:47 GMT
  • Updated: Thu, 23 Jan 2020 02:05 GMT
  • Attachments:

Description of getRefines() has typo and inconsistent singular vs plural

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    In the statement of getRefines():

    getRefines (in ref : NamedElement) : AbstractRequirement [0..*]

    The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter. This is a static query.

    There should be a space in:

    "to"end

    So:

    "to" end

    There are mistakes in the use of singular vs plural, the operation description should read:

    The query getRefines() gives all the requirements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the element in parameter. This is a static query.

    If the suggestion SYSML17-276 is adopted the above could be rewritten to state:

    The query getRefines() gives all the named elements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the named element in parameter.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 02:03 GMT
  • Updated: Thu, 23 Jan 2020 02:05 GMT

Parts is too restrictive

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the standard says
    ""The Sequence diagram describes the flow of control between actors and systems (blocks) or between parts of a system... lifelines into their constituent parts."

    But lifelines can be parts, references, parameters, arguments, variables

    also think one needs to make the distinction between Actors that are parts of the block and Actors that are external to the block because they can be represented as lifelines as well

    also should specify that because an interaction in definition is not tied to a particular block (but the context is derived when executed by a block)... there is no way of telling whether something is a part or a reference at definition time... therefore every head of a lifeline is should as solid and no distinction (like a dotted line for a head) is made in interaction diagrams

  • Reported: SysML 1.6 — Wed, 22 Jan 2020 13:28 GMT
  • Updated: Wed, 22 Jan 2020 13:49 GMT

Missing guard brackets in example activity diagram 11-12

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

    The guard Brake Pressure > 0 in figure 11-12 on page 148 has no enclosing square brackets.

  • Reported: SysML 1.6 — Tue, 21 Jan 2020 16:44 GMT
  • Updated: Tue, 21 Jan 2020 16:44 GMT

How to interpret non-Navigation

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    An “X” on a single end of an association to indicate that an end is not navigable has similarly been dropped

    Does this statement mean that SysML has no concept of non-Navigation (only unspecified)... or does it mean that if you
    have an association end A has no Navigation shown, end B has Navigation shown... then End A should be interpreted as
    being non-Navigatable...

    The standard would indicate this as it says "has been similarly dropped" which means it is not shown but it is there all the same...

  • Reported: SysML 1.6b1 — Sat, 9 Nov 2019 15:53 GMT
  • Updated: Mon, 11 Nov 2019 19:57 GMT

ConstraintBlock: abstract syntax consistency

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

    Even if their respective specified semantics indicate that UML::Constraint::constrainedElement and the constraint parameters of a ConstraintBlock are similar, there is currently no constraint enforcing their consistency

  • Reported: SysML 1.6 — Thu, 5 Sep 2019 14:37 GMT
  • Updated: Thu, 17 Oct 2019 15:39 GMT
  • Attachments:

Syntactical clarification for ConstraintBlock

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

    There is no clear statement saying how the expression that specifies the constraint is managed, even if we can imagine that the intent was to use the ownedRule for that purpose it's not formally stated.

    Assuming ownedRule is used, it's not specified either how to deal with ConstraintBlocks that would have more than one ownedRule (since the current specification only consider "one" constraint only)

  • Reported: SysML 1.6 — Thu, 5 Sep 2019 14:35 GMT
  • Updated: Thu, 17 Oct 2019 15:07 GMT

No changebars in

  • Status: open  
  • Source: The Aerospace Corporation ( Ryan Noguchi)
  • Summary:

    The version of the specification document that is supposed to have changebars does not appear to have any changebars or redlines. This makes it unnecessarily difficult to find out what has changed since the released 1.5 spec.

  • Reported: SysML 1.6b1 — Tue, 8 Oct 2019 18:16 GMT
  • Updated: Thu, 10 Oct 2019 19:18 GMT

Proposal: patent-friendly part/element numbering system with compliant solid line

  • Status: open  
  • Source: Webel ( Darren Kelly)
  • Summary:

    National patent offices require patent drawings in a very specific format. The “parts” of an invention must typically be numbered consistently, and always indicated with a solid line from each part number to the part.

    I have found many applications can be represented well as SysML Parts Property symbols, and with convenient correct propagation of part numbers across diagrams (Single Source of Truth).

    I have been re-appropriating Comment for this using the following diagramming “hack" in the MagicDraw/Cameo tool:

    • Use the Documentation field of a Part Property to hold each unique part number.
    • Use the Retrieve Documentation feature to display that part number in a Comment symbol (which is stereotyped «Documentation»).
    • The HACK: hide the border of the Comment by making it white against white background, and also hide the stereotype.

    But then you have to use an external image editing tool to tediously make the dashed lines all solid to meet the patent office's requirements.

    Note that UML2.5.1 states:

    'The connection to each annotatedElement is shown by a separate dashed line.’

    A refinement of this proposal might involve creating a special new dedicated SysML element to achieve this, with a dedicated attribute for carrying the numbering.

    It is beyond the scope of this initial proposal to specify how the capability might be achieved.

    The proposal is not limited to numbering and indicating SysML Part Properties typed by Blocks, it could be applied to other Element kinds, but Part Properties lend themselves immediately to the purpose.

    This proposal does not yet elaborate on how the numbering sequence might be handled (largely a tool feature matter).

    The section '7 Model Elements' is a candidate for specification of the new proposed element.

    [Diagrams illustrating the required result will be provided via JIRA once the proposal issue ticket is raised]

    Reference: IP Australia: Best Practice Guide: Appendix: Examples of Drawings: https://www.ipaustralia.gov.au/sites/g/files/net856/f/best_practice_guide_appendix_iv.pdf

  • Reported: SysML 1.6b1 — Mon, 23 Sep 2019 17:35 GMT
  • Updated: Tue, 24 Sep 2019 15:56 GMT

Should <> have a capital V?

  • Status: open  
  • Source: Boeing ( Alan Lee)
  • Summary:

    I'm not sure if this is actually an issue (I think it is). There are 2 keywords in Figure E.10: Spring Length Example; <<valueType>> and <<ValueType>>. Wondering if it is the same keyword and the latter should be lowercase v.

  • Reported: SysML 1.6b1 — Wed, 21 Aug 2019 16:29 GMT
  • Updated: Tue, 3 Sep 2019 18:47 GMT

Duplicate Elements in Table

  • Status: open  
  • Source: Boeing ( Alan Lee)
  • Summary:

    Elements starting from Namespace Compartment to InstanceSpecification (9 items Elements total) is listed twice in the 8.2.1 Block Definition Diagram: Table 8.1.

  • Reported: SysML 1.6b1 — Wed, 21 Aug 2019 16:03 GMT
  • Updated: Tue, 3 Sep 2019 18:46 GMT

Refine / Trace relationship operations are too restrictive

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

    Refine::getRefines(in ref : NamedElement) : AbstractRequirement should return NamedElement according to the definition of the refine stereotype in section 16.1. The body condition of the operation is not consistent with the return type AbstractRequirement.

    There is no constraint that restricts that one end of the refine relationship must be an element of type AbstractRequirement.

    Trace::getTracedFrom(in ref: NamedElement) : AbstractRequirement should return NamedElement according to the definition of the trace stereotype. The body condition should be updated as well from AbstractRequirement to NamedElement.

    The sentence in section 16.1 "A generic trace requirement relationship provides a general-purpose relationship between a requirement and any
    other model element." is too restrictive with regard to the definition of the trace stereotype.

  • Reported: SysML 1.6b1 — Thu, 8 Aug 2019 16:04 GMT
  • Updated: Thu, 8 Aug 2019 16:04 GMT

VerdictKind should also have the literal none

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

    As defined in the UTP element Verdict, the SysML VerdictKind should also define an enumeration literal none:

    none The test case has not been executed yet.

    When a test case is not executed yet or just invoked, its verdict is none. None indicates that no communication between
    test components and the SUT has been carried out yet. None is the weakest verdict. It is never set by the tester directly.

  • Reported: SysML 1.6b1 — Thu, 8 Aug 2019 07:58 GMT
  • Updated: Thu, 8 Aug 2019 07:59 GMT

Precise Semantics for SysML

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

    Clarify the executable semantics of SysML Stereotypes

  • Reported: SysML 1.6 — Thu, 13 Jun 2019 16:01 GMT
  • Updated: Thu, 13 Jun 2019 16:01 GMT

Comments in the XMI have no annotated elements

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

    The comments in the XMI that specify the documentation of the stereotypes and stereotype attributes do not annotate the elements they document.

  • Reported: SysML 1.6b1 — Fri, 7 Jun 2019 06:50 GMT
  • Updated: Fri, 7 Jun 2019 15:01 GMT

ProxyPort property "matching"

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

    [From email to sysml-rtf@omg.org 7-May-2019, and discussed at the SysML RTF meeting 9-May-2019.]

    The situation of a proxy port's InterfaceBlock having multiple flow properties, and may be also multiple value properties, leads to the vexing question of how they all get paired up with [the] port's owning blocks' features. Putting aside behaviour ports (isBehavior=true), the most straightforward solution would be to use a binding connector between each feature in the proxy port and the actual features in the owning block. However, I find the public draft of SysML 1.6 to still not be completely clear on this matter, despite its improvements to the chapter on ports and flows.

    The section on FlowPorperty (9.3.2.8) refers to property matching (2nd paragraph), but does not contextualise when property matching might occur. Most of what it states makes perfect sense in the context of connected proxy ports, especially when the ports have the same type (i.e. an InterfaceBlock) and one port is conjugated. However, it becomes remarkably unclear what it means when matching is applied to the proxy port and its owning block's flow properties.

    The section on Proxy Ports (9.3.2.13), replaces the later part of the first paragraph with a subsequent paragraph to spell out how a proxy port relates to its owning block, but seems to do this in a weak way by stating "This can be achieved in several ways. For instance by...", which sounds informative, rather than normative. Nevertheless it does state "by binding it to a fully specified internal part or by having all its properties individually bound to internal parts."

    If a proxy port is bound to an internal part, is there a need for the port's type to match that of the bound part? If not, what are the rules for feature matching?

    If a proxy port's "properties [are] individually bound to internal parts", then dose the meaning of "part" extend to the block's value properties and flow properties? (I wouldn't ordinarily consider them to be parts.) If not then where does it state that these properties can be bound?

  • Reported: SysML 1.6 — Thu, 9 May 2019 14:13 GMT
  • Updated: Thu, 9 May 2019 14:13 GMT

Bad reference in section 4.2

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

    At the end of section 4.2 is an unresolved reference:

    "UnitAndQuantityKind, see Erreur : source de la référence non trouvée"

    Replace it with

    UnitAndQuantityKind, see 8.3.3.2

  • Reported: SysML 1.6 — Tue, 19 Mar 2019 21:39 GMT
  • Updated: Tue, 23 Apr 2019 00:20 GMT

Typo: Constraint name 8 of Adjunct Property

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

    Name of constraint 8 is "8_callAction_composite_and_consitent_type",
    but should be "8_callAction_composite_and_consistent_type".

  • Reported: SysML 1.6 — Thu, 21 Mar 2019 17:35 GMT
  • Updated: Tue, 23 Apr 2019 00:20 GMT

Stakeholder constraint is listed twice

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

    The Stakeholder constraint 1_not_association is listed twice in the specification document and the XMI.

    One constraint is named "1_not_association" the other one "not_association".

    Remove the "not_association" constraint.

  • Reported: SysML 1.6 — Tue, 19 Mar 2019 21:34 GMT
  • Updated: Tue, 23 Apr 2019 00:20 GMT

Virtual member representing the whole RTF

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

    Would it be possible to create a special member in the RTF with no voting right (i.e. "assistant") , whose has the sysml-rtf@omg.org for email address?

    By adding it to the "watch this issue" list it would then become possible to notify the whole RTF automatically.

  • Reported: SysML 1.6 — Thu, 17 Jan 2019 13:48 GMT
  • Updated: Tue, 23 Apr 2019 00:20 GMT

About Block constraint "3" removed by SysML v1.6

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

    Ed Seidewitz caught this:
    While researching a question forwarded to me by Sandy, I noticed what seems to be an inconsistency in the SysML 1.6 specification. SysML 1.5 included the following constraint under the Block stereotype:

    [3] In the UML metamodel on which SysML is built, any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association must [sic] not have a name and may not be defined as a navigable owned end of the association. (While the Property has a “name” property as defined by its NamedElement superclass, the value of the “name” property, which is optional, must be missing.)

    However, this constraint has been removed from the SysML 1.6 spec (and it is not included in the XMI).

    Issue SYSML16-310, which was merged into the resolution of SYSML16-274, addresses this constraint. In the comments on 310, Yves made a suggestion to remove the constraint, but then added a subsequent comment that reads: “Discussed during RTF weekly meeting on Sep 21: Ok for deleting the fits part of the sentence: "In the UML metamodel on which SysML is built" but any other change requires a separate issue” (SYSM16-310 - comment-17892, 21/Sep/17). There is also an earlier comment on the resolution to SYSML16-295 that notes “We had a discussion about constraint[3]. It seems the be not correct. Yves or Conrad will file an issue about that.” (SYSML16-295/SYSML16-297 - comment-17815, 31/Aug/17])

    But I cannot find any separate issue that was actually filed to remove constraint 3. The constraint was simply not included in the revised text in the resolution of SYSML16-274, and hence ended up being left out of the SysML 1.7 beta spec.

    So, there does not seem to be an apparent intent of the RTF to remove this constraint in SysML 1.6. Indeed, the following paragraph remains in the description section of subclause 8.3.2.3 Block in the 1.6 spec:

    “SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel.”

    This is text certainly no longer true without constraint 3, and I would have expected it to have been removed or updated if there had actually been an affirmative resolution to remove the constraint.

  • Reported: SysML 1.6 — Thu, 11 Apr 2019 13:24 GMT
  • Updated: Thu, 11 Apr 2019 13:35 GMT

Hidden constraints in description of PropertySpecificType

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

    The description of the PropertySpecificType states:

    The PropertySpecificType stereotype can be applied to classifiers that type exactly one property and that are owned by the owner of that property. Classifiers with this stereotype applied shall be generalized by at most one
    other classifier.

    The constraint section covers only "can be applied to classifiers that type exactly one property". The other constraints

    "that are owned by the owner of that property."
    and
    "Classifiers with this stereotype applied shall be generalized by at most one
    other classifier."

    are missing.

  • Reported: SysML 1.6 — Sun, 17 Mar 2019 10:25 GMT
  • Updated: Sun, 17 Mar 2019 10:25 GMT