OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Closed Issues

  • Acronym: SysML
  • Issues Count: 61
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML13-12 Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints SysML 1.2 SysML 1.3 Resolved closed
SYSML13-61 Invocations of required behavior features without going through ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-59 Wrong multiplicity for Requirement in stereotype description SysML 1.2 SysML 1.3 Resolved closed
SYSML13-60 sentence introduced in §9.1 by the resolution to issue #16280 is confusing SysML 1.2 SysML 1.3 Resolved closed
SYSML13-56 InvocationOnNestedPortAction and TriggerOnNestedPort SysML 1.2 SysML 1.3 Resolved closed
SYSML13-57 Improvements to QUDV for SysML v1.3 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-58 Rate does not support the examples SysML 1.2 SysML 1.3 Resolved closed
SYSML13-53 Broadcasting along connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-55 Provided and required feature abbreviations SysML 1.2 SysML 1.3 Resolved closed
SYSML13-54 Owning block terminology SysML 1.2 SysML 1.3 Resolved closed
SYSML13-52 Events for property value changes SysML 1.2 SysML 1.3 Resolved closed
SYSML13-49 Association decomposition in diagram element tables SysML 1.2 SysML 1.3 Resolved closed
SYSML13-51 Contextualized item flows SysML 1.2 SysML 1.3 Resolved closed
SYSML13-41 Non-behavioral ports on behavioral ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-43 Proxy ports should not have connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-42 Flow properties on blocks typing internal parts SysML 1.2 SysML 1.3 Resolved closed
SYSML13-45 Full ports should not be conjugated SysML 1.2 SysML 1.3 Resolved closed
SYSML13-46 Binding connectors may not have constraint parameters on any end SysML 1.2 SysML 1.3 Resolved closed
SYSML13-50 Proxy port owning block definition should refer to internal structure SysML 1.2 SysML 1.3 Resolved closed
SYSML13-48 Item flow property values SysML 1.2 SysML 1.3 Resolved closed
SYSML13-47 Clarify open and closed meaning of port types vs other property types SysML 1.2 SysML 1.3 Resolved closed
SYSML13-44 Internal fanout from proxy ports should be clarified SysML 1.2 SysML 1.3 Resolved closed
SYSML13-40 TriggerOnNestedPort refers to onPort instead of port SysML 1.2 SysML 1.3 Resolved closed
SYSML13-36 Block shown as metaclass SysML 1.2 SysML 1.3 Resolved closed
SYSML13-35 Owning block undefined SysML 1.2 SysML 1.3 Resolved closed
SYSML13-39 InvocationOnNestedPortAction and TriggerOnNestedPort notation not extended SysML 1.2 SysML 1.3 Resolved closed
SYSML13-38 Ports that have behavior ports should be behavioral SysML 1.2 SysML 1.3 Resolved closed
SYSML13-31 Sample problem using deprecated conjugated port notation SysML 1.2 SysML 1.3 Resolved closed
SYSML13-34 Internal and external connectors undefined SysML 1.2 SysML 1.3 Resolved closed
SYSML13-37 Flow property semantics only defined for external connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-32 Provided / required operations & receptions SysML 1.2 SysML 1.3 Resolved closed
SYSML13-33 onNestedPort should enable sending directly to target SysML 1.2 SysML 1.3 Resolved closed
SYSML13-30 Ownership of item flow properties SysML 1.2 SysML 1.3 Resolved closed
SYSML13-29 Clarifications to flow port resolution SysML 1.2 SysML 1.3 Resolved closed
SYSML13-25 Clarify that item flow decomposition examples are not methodology SysML 1.2 SysML 1.3 Resolved closed
SYSML13-28 Connectors should not link ports in block definition diagram elements SysML 1.2 SysML 1.3 Resolved closed
SYSML13-26 Flow property compatibility rules should not be dependent on item flow SysML 1.2 SysML 1.3 Resolved closed
SYSML13-27 Remove colons from item flow classifiers in decomposition examples SysML 1.2 SysML 1.3 Resolved closed
SYSML13-23 Missing cross references in Deprecated Elements Annex SysML 1.2 SysML 1.3 Resolved closed
SYSML13-24 Water association decomposition example should be in ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-22 Deprecated elements package SysML 1.2 SysML 1.3 Resolved closed
SYSML13-21 typo in diagram C. 15 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-19 Clarification when Allocated Stereotype is applied SysML 1.2 SysML 1.3 Resolved closed
SYSML13-16 partWithPort change from UML needs to be clearly stated SysML 1.2 SysML 1.3 Resolved closed
SYSML13-17 NestedConnectorEnd propertyPath should be non-unique SysML 1.2 SysML 1.3 Resolved closed
SYSML13-15 NestedConnectorEnd constraints SysML 1.2 SysML 1.3 Resolved closed
SYSML13-20 Test Context appears in XMI but not in Profile Spec SysML 1.2 SysML 1.3 Resolved closed
SYSML13-18 Claify partWithPort vs. NestedConnectorEnd SysML 1.2 SysML 1.3 Resolved closed
SYSML13-14 NestedConnectorEnd constraints refer to metaclass SysML 1.2 SysML 1.3 Resolved closed
SYSML13-13 Appendix F out of date SysML 1.2 SysML 1.3 Resolved closed
SYSML13-11 SysML Issue based on UML 15370 -- Package has optional URI SysML 1.2 SysML 1.3 Resolved closed
SYSML13-8 Structure Compartment shows blocks instead of parts SysML 1.2 SysML 1.3 Resolved closed
SYSML13-9 SysML 1.2 - Blocks SysML 1.2 SysML 1.3 Resolved closed
SYSML13-10 SysML Issue based on UML 14062 -- Stereotypes/keywords and upper/lowercase SysML 1.2 SysML 1.3 Resolved closed
SYSML13-6 SysML 1.2 Issues: Missing constraint on Rationals SysML 1.2 SysML 1.3 Resolved closed
SYSML13-7 SysML 1.2, ch 12 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-4 SysML 1.2 Issues: Activity's sub-activities should be able to have mandatory multiplicity SysML 1.2 SysML 1.3 Resolved closed
SYSML13-2 SysML 1.2 Section 16.4.4 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-5 SysML 1.2 Issues: Definition of Overwrite SysML 1.2 SysML 1.3 Resolved closed
SYSML13-3 SysML 1.2 Issues: Structure compartment wrong in spec SysML 1.2 SysML 1.3 Resolved closed
SYSML13-1 properties allocatedFrom and allocatedTo should be capitalized SysML 1.2 SysML 1.3 Resolved closed

Issues Descriptions

Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints

  • Key: SYSML13-12
  • Legacy Issue Number: 15876
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Today, during the SysML1.3 RTF, we discussed simplifying the definition of the SysML profile by referencing the UML metamodel directly instead of the UML4SysML construction and replace the UML4SysML construction with OCL constraints about the scope of UML that defines strict conformance to SysML in the context of the UML4SysML subset. The practical advantages include:

    • any UML tool can be used as the basis for implementing the SysML profile
    • the SysML profile can be easily combined with other profiles that extend UML; e.g., SoaML, etc... (i.e., this could simplify the construction of UPDM)
    • if users need to use more than the UML4SysML subset, they could simply disable the OCL constraints for strict UML4SysML conformance
  • Reported: SysML 1.2 — Mon, 6 Dec 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Prior to UML2.4.1, the OMG never published the merged UML metamodel as a
    normative machine-readable artifact nor specified compliance to UML in terms of
    it. From an OMG Specification Management point of view (i.e., OMG’s SMSC
    policy), it makes sense to require that the only dependencies a published
    normative machine-readable artifact might have should be to other published
    normative machine-readable artifacts.
    For SysML1.2, the published normative machine-readable SysML1.2 profile
    depended only on the published normative machine-readable UML4SysML
    merged metamodel constructed from the published normative machine-readable
    artifacts for UML2.3’s Infrastructure & Superstructure. Because the UML2.3
    StandardProfileL2 was never published, this also meant that the SysML1.2
    profile had to duplicate the definition of UML2.3’s StandardProfileL2::Trace
    stereotype in the SysML profile, i.e., SysML::Trace.
    The 2.4.1 series of UML, MOF and XMI made significant changes to the OMG
    metamodel/profile architecture. In particular, the merged UML2.4.1 metamodel
    and the UML2.4.1 StandardProfileL2 are both published as normative machinereadable
    artifacts, which simplifies greatly problems of model interchange across UML 2.4.1 compliant tools. By aligning the SysML1.3 profile as a simpler
    extension of the published, normative UML 2.4.1 metamodel rather than a
    complicated extension of a partial merge of the UML Superstructure, SysML1.3
    can also benefit from improvements in model interchange for UML 2.4.1
    compliant modeling tools.
    In SysML1.2, the UML4SysML subset served two distinct purposes:
    1. Specifying which UML elements can be used in compliance with the
    limited scope of the SysML language.
    2. Constructing and publishing SysML in terms of a normative published
    machine-readable artifacts, i.e., the UML4SysML metamodel.
    The second purpose, constructing and publishing SysML, resulted in a significant
    implementation complexity and caused significant problems for model
    interchange testing. The UML4SysML metamodel represents a significant
    disincentive for UML tool vendors to build a lesser capability metamodel, i.e.,
    UML4SysML, just to provide support for the SysML profile. In fact, some UML
    tool vendors used UML instead of UML4SysML to implement support for the
    SysML profile. The publication of a normative merged metamodel in UML2.4.1
    and the multi-vendor efforts in the Model Interchange Working Group (MIWG)
    provide compelling reasons to do away with the special-purpose construction and
    publication of UML4SysML as a merged metamodel just for defining SysML
    properly.
    The first purpose, specifying the scope of the SysML language as an extension
    of a limited subset of UML, was perfectly within the spirit of the metamodel
    architecture from UML2.0 until UML2.3 where the UML 2 Infrastructure &
    Superstructure provided the basis for package-level reuse in the family of UML
    languages. Since there was no published, normative, merged metamodel for
    UML 2, it was perfectly legitimate and recommended to use package merge
    techniques to construct special-purpose languages like the UML4SysML subset
    for defining domain-specific extensions like SysML. With the publication of a
    normative, merged metamodel in UML2.4.1 and the change in metamodel
    architecture where UML2.4.1 is defined as an instance of itself, it makes sense to
    define the SysML 1.3 profile as an extension of the UML 2.4.1 merged
    metamodel. Unfortunately, this creates a complication for specifying the limited
    reuse of UML in SysML.
    According to UML, a Profile must reference the metamodel it extends via a
    PackageImport relationship whose target is the referenced metamodel (see
    section 18.3.7 in UML2.4.1 Superstructure). Consequently, any profile
    referencing the merged UML2.4.1 metamodel potentially extends every
    metaclass defined in UML2.4.1. SysML 1.3 effectively extends only a subset of
    UML2.4.1 metaclasses. Whereas this subset was defined via a package merge
    construction in SysML 1.2 for each SysML compliance level, each compliance
    level subset is defined in SysML 1.3 via constraints specifying that there should not be any instances of metaclasses outside the scope of that subset in a
    compliant model. For example, UML::Component is outside the UML4SysML
    subset.
    The corresponding compliance constraint in OCL for excluding the use of
    UML::Component in a compliant SysML 1.3 model is:
    Component.allInstances()->isEmpty()
    For SysML1.3, the UML4SysML subset includes 213 of the 242 metaclasses in
    UML2.4.1. The UML4SysML subset is further broken down into the 3 compliance
    levels defined for SysML1.2 adjusted to ensure that the required classifier
    dependencies for each classifier at a given level are also at that level or below.
    All general classifiers and all of the classifiers typing a property with required
    multiplicity are considered required classifier dependencies for a given classifier.
    Specifying SysML1.3 as a profile referencing the UML2.4.1 metamodel provides
    tangible practical benefits:
    ? Any UML2.4.1-compliant tool can be used as the basis for a compliant
    implementation of SysML1.3.
    ? Model interchange for SysML1.3 reduces to the interchange of UML2.4.1
    models with the application of one or more profiles extending UML2.4.1.
    ? Verifying a UML2.4.1 model with the SysML1.3 profiled applied for a given
    level of SysML 1.3 compliance amounts to verifying an OCL constraint or
    equivalently a QVT Operational query or QVT Relational pattern on that
    model.
    As of UML 2.4.1, the specification does not explicitly indicate if it is legal for a
    profile (e.g., SysML) to be applied to a package defined within that profile (e.g.,
    ModelLibrary in SysML 1.2). This resolution adopts a conservative, pessimistic
    interpretation of UML 2.4.1 where the only capabilities that SysML can
    normatively depend from UML are those that are explicitly called out in the
    specification document. In this particular case, it means that the library of
    predefined value types – see 8.3.3 in SysML 1.2 – cannot be nested within the
    SysML profile itself since the UML::DataTypes in that library must have the
    SysML::ValueType stereotype applied to them. In SysML 1.3, the predefined
    library of such ValueTypes is moved outside of the SysML profile precisely to
    avoid relying on undocumented profile semantics (see figures 4.3 and 8.7) .

  • Updated: Thu, 28 Feb 2019 14:39 GMT

Invocations of required behavior features without going through ports

  • Key: SYSML13-61
  • Legacy Issue Number: 16264
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Invocations of required behavioral features on self should be forwarded along links from the executing object to external objects that provide those features. Currently this can only be done through ports.

  • Reported: SysML 1.2 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 17:59 GMT

Wrong multiplicity for Requirement in stereotype description

  • Key: SYSML13-59
  • Legacy Issue Number: 16407
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Both Figure 16.1 and the SysML 1.2 profile http://www.omg.org/spec/SysML/20100301/SysML-profile.uml define Requirement::/derived : Requirement[*]
    but in 16.3.2.3, the attribute is described incorrectly as: /derived : Requirement[0..1]

    It's obvious that the specification in 16.3.2.3 is incorrect; the property description should be changed from:

    /derived : Requirement[0..1]

    to:

    /derived : Requirement[*]

    I propose to include this resolution in ballot 5 for sysml 1.3.

  • Reported: SysML 1.2 — Sat, 30 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sentence introduced in §9.1 by the resolution to issue #16280 is confusing

  • Key: SYSML13-60
  • Legacy Issue Number: 16608
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The following sentence introduced in §9.1 by the resolution to issue #16280 is confusing: "Default compatibility rules are defined for connecting blocks used in composite structure, including parts and ports [...]" since it is not "blocks" (SysML sense), which are not connectable elements, that are connected in composite structure but parts and ports. In addition the rules we are speaking about deal with "matching/mapping" (i.e. routing) rather than with "compatibility" since one can have several possible solutions (mapping) to connect two compatible ports.

    I suggest replacing this sentence by the following one: "Default matching rules are defined for connecting parts or ports in composite structure but specific mappings can be specified thanks to association blocks".

  • Reported: SysML 1.2 — Tue, 28 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change the wording to indicate that association blocks can override the default
    compatibility rules

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InvocationOnNestedPortAction and TriggerOnNestedPort

  • Key: SYSML13-56
  • Legacy Issue Number: 16391
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In InvocationOnNestedPortAction and TriggerOnNestedPort, in the path attribute description, replace "until a port is reached" with "ending in a port", to support nonuniqueness

  • Reported: SysML 1.2 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revised as suggested above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improvements to QUDV for SysML v1.3

  • Key: SYSML13-57
  • Legacy Issue Number: 16396
  • Status: closed  
  • Source: Thematix Partners LLC ( Roger Burkhart)
  • Summary:

    There are mistakes and inconveniences in the model and model library of quantities, units, dimensions and values (QUDV) in SysML v1.2 as defined in Annex C. Furthermore the ordering of the sections in Annex C can be made more logical to improve the readability.

  • Reported: SysML 1.2 — Mon, 25 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove Quantity from Annex C.5. The reason is that the concept of quantity is
    fully implemented by a value property typed by a ValueType. Therefore an
    additional class/block Quantity is superfluous and confusing.
    The QUDV model can be simplified by merging DimensionFactor and
    QuantityKindFactor into one concept QuantityKindFactor.
    Remove property definition for symbolicExpression, since this is only an
    informational (presentation) property that can be derived from the ordered set of
    factor : DimensionFactor.
    In SysML 1.2, Figure C.8, a SystemOfUnits had a many-to-many relationship
    with SystemOfQuantities. This precluded aligning SysML 1.2 QUDV tightly with
    ISO 80000-1:2009 where the notion of ‘system of units’ (ISO 80000-1:2009, 3.13)
    is defined for a single ‘system of quantities’ (ISO 80000-1:2009, 3.3).
    Furthermore, Section C.5.2.22 Unit did not define the property Unit::quantityKind
    : QuantityKind[0..1] shown in Figure C.8 even though this property is extensively
    used for the specification of coherence analysis in section C.5.2.21
    SystemOfUnits, Constraints [1,2].
    The meaning of the undocumented association between Unit and QuantityKind
    should be revised to support the capability specified in ISO/IEC Guide 99:2007
    about a coherent system of units (item 1.14), Note 1:
    A system of units can be coherent only with respect to a system of
    quantities and the adopted base units. The adoption of a Unit as the base measurement unit for a given QuantityKind is
    understood to be a distinguished subset among the set of all QuantityKinds that
    are the measurementUnits for a particular Unit. A Unit can be the measurement
    unit of many QuantityKinds and a given QuantityKind can have many
    measurement Units per Note 2 of ISO 80000-1:2009, 3.9:
    NOTE 2 Measurement units of quantities of the same quantity dimension
    may be designated by the same name and symbol even when the
    quantities are not of the same kind. For example, joule per kelvin and J/K
    are respectively the name and symbol of both a measurement unit of heat
    capacity and a measurement unit of entropy, which are generally not
    considered to be quantities of the same kind. However, in some cases
    special measurement unit names are restricted to be used with quantities
    of specific kind only. For example, the measurement unit ‘second to the
    power minus one’ (1/s) is called hertz (Hz) when used for frequencies and
    becquerel (Bq) when used for activities of radionuclides. As another
    example, the joule (J) is used as a unit of energy, but never as a unit of
    moment of force, i.e. the newton metre (N · m).
    The above makes sense in the context of a particular relationship between a
    SystemOfUnits and a SystemOfQuantities. It would be more difficult to express
    the above in a more generalized context like that of SysML1.2 with many-tomany
    possible relationships between SystemOfUnits and SystemOfQuantities.
    Consequently, the QUDV model is revised to focus on the most common case in
    practice where a SystemOfUnits is defined for up to a single SystemOfQuantities.
    The reduced generality of the QUDV model is intended to simplify the use of
    QUDV in practice and is explicitly conveyed via new invariants (see below for
    new constraints added for C.5.2.20 and C.5.2.21).
    In SysML 1.2, Figure C.10 is not consistent with the text which includes OCL for
    deriving the non-derived property SystemOfQuantities::dimension :
    Dimension[0..*] (see C.5.2.20 SystemOfQuantities, Constraint [1])
    Since SysML 1.2 was published, the major parts of ISO/IEC 80000 have been
    published with definitions for the International System of Quantities (ISQ) and the
    International System of Units (SI). Annex C.4 is revised to be based on this
    authoritative source rather than the NIST special publication it formerly
    referenced. The SysML QuantityKind and Unit definitions in Annex C.4 are
    revised to follow the naming and organization of the quantity and unit definitions
    from Part 1 of ISO 80000, which cover the same base and derived units as
    before. Unit symbols have also been added to the SysML Unit definitions.
    The text in Annex C.4 is revised to indicate how the definitionURI strings of its
    QuantityKind and Unit definitions could be used to refer to corresponding QUDV
    definitions in a separately published model library. Figures C.10 and C.11 in
    Section 5.4.1 continue to provide examples of such QUDV definitions that could
    be expanded to the full set of quantities and units from ISO 80000-1.
    Specific definitionURI string values for reference to QUDV definitions have not
    been included in Annex C.4, not only because they would clutter the diagrams,
    but because they could be automatically supplied as part of the publication of
    more complete, machine-readable versions of both model libraries.
    Because Annex C.4 continues to define a model library consisting only of SysML
    QuantityKind and Unit definitions, without any direct dependence on QUDV or
    other QUDV model libraries, there is no inherent problem with the ordering or
    logical dependence of the current Annexes. No change is made to the current
    Annex C sections other than a new name for the ISO 80000-1 model library in
    Section C.4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rate does not support the examples

  • Key: SYSML13-58
  • Legacy Issue Number: 16406
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    There is an inconsistency w.r.t. the definition of SysML Rate with the notation & examples.

    According to figure 11.8, SysML Rate extends only 2 metaclasses: Parameter and ActivityEdge.
    By generalization, SysML Continuous and Discrete also extend these two metaclasses.

    According to the notation in Table 11.1, <<rate>>, <<continuous>> and <<discrete>> also apply to ObjectNodes.
    The examples in figure B.33 and B.35 show applications of <<continuous>> to CentralBufferNodes and ActivityParameterNodes, both are direct specializations of ObjectNode.
    Some examples in the Practical Guide to SysML do the same – see figure 8.17 on p. 196; figure 15.14 on p. 373

    Both SysML 1.2 Figure 11.8 and the published profile http://www.omg.org/spec/SysML/20100301/SysML-profile.uml are incomplete.

    The resolution is fairly simple: Add an extension from Rate to ObjectNode in figure 11.8 and update the SysML profile accordingly.

    I propose to include this resolution in ballot 5 for sysml 1.3.

  • Reported: SysML 1.2 — Sat, 30 Jul 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This the same issue as 11498 (closed), but add clarification for Figure C.33 and C.35
    about the notation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Broadcasting along connectors

  • Key: SYSML13-53
  • Legacy Issue Number: 16345
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    It is not possible to send out invocations along untyped connectors to parts. Flow properties can be changed on self and broadcast along connectors to neighbors that support them, but invocations cannot. Extend invocation action semantics to send invocations out connectors to neighbors that support them.

  • Reported: SysML 1.2 — Wed, 22 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Specify the above semantics for required behavioral features.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provided and required feature abbreviations

  • Key: SYSML13-55
  • Legacy Issue Number: 16352
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The provreq abbrevation for providedrequired should be provreqd, to be consistent with the reqd abbrevation for required. The block diagram elements table in the ports and flows chapter should use the abbreviations.

  • Reported: SysML 1.2 — Wed, 29 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Owning block terminology

  • Key: SYSML13-54
  • Legacy Issue Number: 16351
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The resolutions of issues 16227 and 16221 sometimes use the term "owning block" for proxy ports differently than UML ownership. For flow direction it is the block items are flowing in or out of, and for behavioral ports and directed features, it is the block the proxy port is standing in for. These uses should have different terms than "owning block".

  • Reported: SysML 1.2 — Tue, 28 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    New terminology might be more confusing, but the text can be clearer when
    using “owning block”, see revisions below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Events for property value changes

  • Key: SYSML13-52
  • Legacy Issue Number: 16344
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    Extend ChangeEvent and AcceptEventAction to detect and changes in property values.

  • Reported: SysML 1.2 — Wed, 22 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Extend ChangeEvent for changes in values of structural features, and extend
    AcceptEventAction to handle these events.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association decomposition in diagram element tables

  • Key: SYSML13-49
  • Legacy Issue Number: 16335
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:


    In Section 9.2.1 (Extensions to Block Definition Diagram), as modified by Issue 16217, the row for item flows has an internal structure for the association class that does not match its end classes. Similar examples should also be in Section 9.2.1 (Extensions to Internal Block Diagram), and in Section 8.2.2 (Internal Block Diagram).

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change association classes in ports and flows diagram element tables to be
    consistent with the end classes of the association, and add examples of
    connector properties typed by association classes. Section 8.2.1 (Block
    Definition Diagram) and in the water delivery example already have examples of
    connector properties typed by an association class.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Contextualized item flows

  • Key: SYSML13-51
  • Legacy Issue Number: 16337
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Item flows are based on dependencies, which cannot be contextualized in an internal structure, but many of the use cases are for item flows realizing connectors.

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Item flows are contextualized by realizing connectors.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non-behavioral ports on behavioral ports

  • Key: SYSML13-41
  • Legacy Issue Number: 16265
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Issue 13178 added a constraint requiring ports of behavioral ports to be behavioral. This prevents nested proxy ports from being bound to internal parts.

  • Reported: SysML 1.2 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove the cited constraint

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Proxy ports should not have connectors

  • Key: SYSML13-43
  • Legacy Issue Number: 16284
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Proxy ports in the resolution of 13178 should have a constraint preventing them from owning connectors.

  • Reported: SysML 1.2 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Connectors on interface block typing proxy port might be useful for some
    applications, such as applying parametrics to interfaces.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Flow properties on blocks typing internal parts

  • Key: SYSML13-42
  • Legacy Issue Number: 16280
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Issue 13178 prevents flow properties from being defined on blocks that type internal parts. Flow properties specify the kind of things that flow into and out of a block, regardless of how the block is used. In v1.2 they are related to receptions, which also do not restrict how the block owning the flow property is used. The constraint also causes an unnecessary difference between full ports and internal parts.

  • Reported: SysML 1.2 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Loosen the restriction that block owning flow properties cannot type internal
    parts.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Full ports should not be conjugated

  • Key: SYSML13-45
  • Legacy Issue Number: 16293
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    he types of full ports have behaviors defined independently of the ports they type. They cannot switch the direction of flows and invocations based on the port they type.

  • Reported: SysML 1.2 — Mon, 30 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Add constraint that full ports cannot be conjugated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binding connectors may not have constraint parameters on any end

  • Key: SYSML13-46
  • Legacy Issue Number: 16332
  • Status: closed  
  • Source: InterCAX ( Manas Bajaj)
  • Summary:

    On pg 74 (section 10.4.2) of the SysML 1.2 spec, it is stated that:

    "A parametric diagram is similar to an internal block diagram with the exception that the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end."

    One may have binding connectors, whether or not they are shown in par diagrams, that have neither of their ends as constraint parameters. A binding connector may have both ends as value properties of the owning block or any of the nested part/ref/shared properties (at any depth).

  • Reported: SysML 1.2 — Mon, 13 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove the overly restrictive language in the referenced sentence. A binding
    connector directly between two properties can be considered as a simple form of
    parametric constraint specifying equality of the two properties

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Proxy port owning block definition should refer to internal structure

  • Key: SYSML13-50
  • Legacy Issue Number: 16336
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Section 9.3.2.8 (ProxyPort), first paragraph, as modified by Issue 16227, should refer to internal structure instead of diagrams, because multiple diagrams can describe the internal structure of the same class.

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Item flow property values

  • Key: SYSML13-48
  • Legacy Issue Number: 16334
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    In Section 9.3.2.7 (ItemFlow), Issue 13178 modified the last sentence of second paragraph ungrammatically. It should say the values of the item property are the flowing instances of water.

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revised as suggested above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify open and closed meaning of port types vs other property types

  • Key: SYSML13-47
  • Legacy Issue Number: 16333
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Clarify that connectors use port types in a closed way, rather than open, as described in Block, unless specialized

  • Reported: SysML 1.2 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Untyped properties should be described as not constraining their values. This
    will be clearly different from the additional functionality ports types have in
    restricting which features are available to external connectors of the port.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Internal fanout from proxy ports should be clarified

  • Key: SYSML13-44
  • Legacy Issue Number: 16285
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    he semantics of multiple internal connectors from proxy ports should be clarified. For example, what is the value of the port? Issue 13178 refers to a "virtual aggregate" that is not explained.

  • Reported: SysML 1.2 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Clarify the cited case.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TriggerOnNestedPort refers to onPort instead of port

  • Key: SYSML13-40
  • Legacy Issue Number: 16255
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    TriggerOnNestedPort introduced by issue 13178 refers to UML's onPort property, but it's actually called port. It should constrain that property to have exactly one value.

  • Reported: SysML 1.2 — Wed, 18 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change references to UML Trigger’s onPort property to port, and constrain it to
    have exactly one value. Also address 16254 by extending the UML textual
    notation for onPort/port on InvocationAction and Trigger for nested ports.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Block shown as metaclass

  • Key: SYSML13-36
  • Legacy Issue Number: 16230
  • Status: closed  
  • Source: PTC ( Andreas Korff)
  • Summary:

    Figure 9.1, as modified by issue 13178 shows block as a metaclass instead of a stereotype.

  • Reported: SysML 1.2 — Thu, 12 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Show block as stereotype in Figure 9.1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Owning block undefined

  • Key: SYSML13-35
  • Legacy Issue Number: 16227
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The term owning block is used in v1.2 and the resolution of 13178, but is not defined.

  • Reported: SysML 1.2 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Ownership is defined in UML, and blocks in SysML, so the term is not
    ambiguous, but it is sometimes used incorrectly, and it needs a special definition
    for proxy ports. The revised text corrects these cases, and adds the definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InvocationOnNestedPortAction and TriggerOnNestedPort notation not extended

  • Key: SYSML13-39
  • Legacy Issue Number: 16254
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Issue 13178 extends UML's onPort abstract syntax for InvocationAction and Trigger, but not the notation.

  • Reported: SysML 1.2 — Wed, 18 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    See issue 16255 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ports that have behavior ports should be behavioral

  • Key: SYSML13-38
  • Legacy Issue Number: 16234
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:


    The resolution of issue 13178 only requires ports of behavioral ports to be behavioral, but should also require ports owning behavioral ports to be behavioral.

  • Reported: SysML 1.2 — Fri, 13 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This would prevent proxy ports bound to internal parts from having nested
    behavior ports that direct flows and invocations to those internal parts. This is
    useful for grouping features of the internal part type in various ways on nested
    behavioral ports, without adding nested ports to the internal part type.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sample problem using deprecated conjugated port notation

  • Key: SYSML13-31
  • Legacy Issue Number: 16220
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    Figure B.36 (Flow Allocation to Power Subsystem (Internal Block Diagram)) uses black-filled rectangles for ports.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change black-filled port rectangles to white-filled in figure cited.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Internal and external connectors undefined

  • Key: SYSML13-34
  • Legacy Issue Number: 16226
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The terms internal and external connector are used in v1.2 and the resolution of 13178, but are not defined.

  • Reported: SysML 1.2 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Define the terms internal and external connector and use them to disambiguate
    “connector” where necessary

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Flow property semantics only defined for external connectors

  • Key: SYSML13-37
  • Legacy Issue Number: 16231
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The flow property semantics in the second paragraph of Section 9.3.2.3 (FlowProperty) only gives semantics for out to in flow properties, which does not work for internal connectors to proxy ports as introduced in issue 13178.

  • Reported: SysML 1.2 — Thu, 12 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    The current semantics of flow properties also works for internal connectors of full
    ports, but should not apply to internal connectors of proxy ports, as the filer says.
    The flow property semantics for internal connectors of proxy ports is implied by
    the semantics of proxy ports, but this should be clarified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provided / required operations & receptions

  • Key: SYSML13-32
  • Legacy Issue Number: 16221
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    It would simplify the use of required / provided interfaces if operations and receptions could be required and provided instead. It would enable provided and required ops/recs to be defined on the same block, including InterfaceBlock introduced by resolution of 13178.

  • Reported: SysML 1.2 — Mon, 9 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Extend Feature to indicate whether they are provided, required, or both (limited
    to behavioral features and non-flow properties).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

onNestedPort should enable sending directly to target

  • Key: SYSML13-33
  • Legacy Issue Number: 16225
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    UML's onPort property on invocation actions enables invocations to be sent to ports of the target objects directly. The nested port extension to onPort in 13178 does not have this capability, but it should, since it is meant as an extension of onPort

  • Reported: SysML 1.2 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove constraints against full ports for InvocationOnNestedPortAction, and
    explain the two invocation semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ownership of item flow properties

  • Key: SYSML13-30
  • Legacy Issue Number: 16219
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The description of item flow properties refers to owner of source and target, which might not be the same. Fourth constraint should refer to realization.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Modify the item property owner to be common (possibly indirect) owner of the
    source and target of the corresponding item flow. Clarify the fourth constraint by
    referring to realization.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarifications to flow port resolution

  • Key: SYSML13-29
  • Legacy Issue Number: 16218
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Chapter 9 (Flow Ports), as revised by issue 13178, should clarify what "expressively" means in the overview, how textual notation flow direction in compartments is determined, and what the term "behavioral port" means in UML.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Add clarifications for the areas cited

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify that item flow decomposition examples are not methodology

  • Key: SYSML13-25
  • Legacy Issue Number: 16214
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Clarify that item flow decompositions examples introduced by issue 13178 are not rules for item flow decomposition.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested and clarify in the title that the examples are about
    decomposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connectors should not link ports in block definition diagram elements

  • Key: SYSML13-28
  • Legacy Issue Number: 16217
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The subfigure added to the block definition diagram elements table by issue 13178 in the item flow row has a connector between ports. So does Figure B.23 (Elaborating Definition of Fuel Flow. (Block Definition Diagram)).

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Move the connectors in the cited figures to link blocks instead of ports

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Flow property compatibility rules should not be dependent on item flow

  • Key: SYSML13-26
  • Legacy Issue Number: 16215
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The flowFlow property compatibility rules introduced by issue 13178 assume item flow is present. They should be applicable when item flow is not present.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Update flow property compatibility rules to be independent of item flow

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove colons from item flow classifiers in decomposition examples

  • Key: SYSML13-27
  • Legacy Issue Number: 16216
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Remove colons from item flow classifiers in item flow decompositions examples introduced by issue 13178. Colons are for item properties, not item flow classifiers.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revised as suggested, and include all blocks in the block definition diagrams

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing cross references in Deprecated Elements Annex

  • Key: SYSML13-23
  • Legacy Issue Number: 16212
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The annex added for deprecated elements by issue 13178 has cross referencing errors. It should also be marked as informative.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Revise as suggested, and clarify step cross references

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Water association decomposition example should be in ports

  • Key: SYSML13-24
  • Legacy Issue Number: 16213
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue 13178 updated the Water association decomposition example in the blocks chapter to use ports. It should be in the ports chapter.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Move the water association decomposition to the ports chapter, with a forward
    reference from the blocks chapter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deprecated elements package

  • Key: SYSML13-22
  • Legacy Issue Number: 16211
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Elements deprecated in issue 13178 should have a package in the language architecture and be noted in the compliance chapter.

  • Reported: SysML 1.2 — Sun, 8 May 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Add deprecated elements package to SysML profile. Do not require it for
    compliance.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo in diagram C. 15

  • Key: SYSML13-21
  • Legacy Issue Number: 16114
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    I think there is a typo error in the diagram C.15. The stereotype <<normal>> should be shown on the property force of the class Canon.

  • Reported: SysML 1.2 — Thu, 31 Mar 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Insert the missing «normal» keyword into the diagram.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification when Allocated Stereotype is applied

  • Key: SYSML13-19
  • Legacy Issue Number: 16046
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocated stereotype is applied to an element at either end of an allocate relationship. This enables the use of the compartment and callout notations to identify what element is on the other end of the allocate relationship. The specification does not explictly state that the allocated stereotype is applied to the elements when the allocate relationship is established. This should be specified as a constraint for the allocated stereotype. This should not imply that the stereotype name must be displayed, but only that the stereotype is applied.

  • Reported: SysML 1.2 — Tue, 1 Mar 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    The intent of the derived properties provided by the Allocated stereotype is to enable
    the end of the allocation relationship to be identified by the other end, whatever it is.
    The approach is similar with derived properties like the “/satisfied” or the “/traceFrom”
    from the RequirementRelated stereotype.
    The drawback is that requiring these stereotypes to be applied when the
    corresponding relation is created implies modifying the elements at one (requirement
    related relations) or both (Allocation relation) of its ends. Modification of the elements
    involved in the relationship is not possible when one or both of those elements is
    read-only and this is likely during the modeling of allocation relationships or of
    requirements traceability.
    These stereotypes do not actually hold any information by themselves, they only
    provide a way to query information owned by directed relationships which may have
    been established between the elements they are applied to. The stereotypes
    specified that the corresponding derived properties (i.e. the corresponding queries)
    shall be available for any model element which is involved in one an allocation or in a
    requirement related relationship. The proposed solution consists in adding to the
    definition of each relationship the necessary queries in order to provide this facility.
    These queries are specified “static” so that they can be used independently of any
    relationship instance.
    Both the Allocated and RequirementRelated stereotypes can then be suppressed
    from the SysML specification. Example of usage with OCL:
    Assume “getAllocatedFrom(ref: NamedElement) : Set(NamedElement)” is the static
    query defined by the Allocate stereotype to retrieve any named element to which a
    given named element has been allocated.
    If “X” is a named element “X”, then:
    Allocate::getAllocatedFrom(X)
    Will give the set of any element to which X is allocated.
    Note that the call will not fail even if there is no allocate relationship at all. In this case
    or if X is not allocated it will simply return an empty set.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

partWithPort change from UML needs to be clearly stated

  • Key: SYSML13-16
  • Legacy Issue Number: 16008
  • Status: closed  
  • Source: PTC ( Simon Moore)
  • Summary:

    From discussion within the MIWG (raised at Sandy's request).

    In UML 2.3 partWithPort is clearly only valid for a connector connected to a Port. SysML appears to expect this to be used when a connector is connected to any nested Property. This breaks the UML constraint and needs to be stated clearly in the SysML specification.

  • Reported: SysML 1.2 — Fri, 4 Feb 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This issue overlaps with issue 16045, which was raised in response to the
    same MIWG discussions. SysML NestedConnectorEnd does apply to any nested
    property, but the resolution for 16045 removes the specific SysML constraint that
    conflicts with UML constraints for partWithPort. SysML nested connector ends
    and partWithPort, under all its UML constraints, can both be present and be
    given values for nested connector ends that satisfy both their conditions.
    Disposition: See issue 16045 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NestedConnectorEnd propertyPath should be non-unique

  • Key: SYSML13-17
  • Legacy Issue Number: 16041
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The same property might appear more than once
    in the path.

  • Reported: SysML 1.2 — Wed, 23 Feb 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Blocks can have properties that are typed by the same block that owns them, or
    a specialization, so property paths can contain the same property multiple times.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NestedConnectorEnd constraints

  • Key: SYSML13-15
  • Legacy Issue Number: 15984
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Blocks, NestedConnectorEnd, Constraints 3 and 4, replace all occurrences of "ConnectorEnd metaclass" with "connector end".

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This is an exact duplicate of issue 15918. The wording changes suggested by
    both 15918 and 15984 are included in the resolution for issue 16045, which also
    removes the existing Constraint 4.
    Disposition: See issue 16045 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Test Context appears in XMI but not in Profile Spec

  • Key: SYSML13-20
  • Legacy Issue Number: 16061
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The stereotype TestContext appears in the SysML profile XMI file http://www.omg.org/spec/SysML/20100301/SysML-profile.uml , but is not in the SysML v1.2 profile specification. It should be removed from the xmi file and anywhere else it may have inadvertently been introduced.

  • Reported: SysML 1.2 — Wed, 16 Mar 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Discussion:
    The stereotype TestContext no longer appears in the SysML profile XMI file
    generated by the SysML 1.3 RTF and published as OMG document ptc/2011-08-11
    and under the URL http://www.omg.org/spec/SysML/20110801/SysML.xmi. No
    change to the specification itself is required.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Claify partWithPort vs. NestedConnectorEnd

  • Key: SYSML13-18
  • Legacy Issue Number: 16045
  • Status: closed  
  • Source: Thematix Partners LLC ( Roger Burkhart)
  • Summary:

    Add a constraint to Section 8.3.2.5 NestedConnectorEnd that the stereotype is applied only to connector ends that violate Constraint [3] of Section 9.3.6 Connector in the UML Superstructure specification. Replace the existing Constraint [4] of 8.3.2.5 NestedConnectorEnd (that the partWithPort property must be must be equal to the property at the last position of the propertyPath list) with a constraint that partWithPort must be empty for any ConnectorEnd to which the stereotype is applied. Also, add clarifications to the SysML specification to make it explicit that SysML goes beyond extending UML entirely by UML stereotypes by also removing an existing constraint of the UML metamodel.

  • Reported: SysML 1.2 — Mon, 28 Feb 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove Constraint [4] of 8.3.2.5 NestedConnectorEnd so that partWithPort can
    continue to be set in accordance with constraints 1-4 of Section 9.3.7
    (ConnectorEnd) in the UML Superstructure specification.
    Also correct wording to refer to the connector end itself rather than the
    ConnectorEnd metaclass, as suggested by issues 15918 and 15984. Clarify the
    descriptive text under propertyPath stereotype property that contains a similar
    reference to the ConnectorEnd metaclass.
    A separate resolution for issue 12268, "not possible to take away constraints in a
    profile," removes text from Chapter 6 that incorrectly stated that SysML is
    specified entirely by UML 2 specification techniques. Constraint 5 under 8.3.2.2
    Block already makes clear that SysML removes an existing constraint of the UML
    metamodel.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NestedConnectorEnd constraints refer to metaclass

  • Key: SYSML13-14
  • Legacy Issue Number: 15918
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Blocks, NestedConnectorEnd, Constraints 3
    and 4, replace all occurrences of "ConnectorEnd
    metaclass" with "connector end".

  • Reported: SysML 1.2 — Fri, 7 Jan 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    This is an exact duplicate of issue 15984. The wording changes suggested by
    both 15918 and 15984 are included in the resolution for issue 16045, which also
    removes the existing Constraint 4.
    Disposition: See issue 16045 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix F out of date

  • Key: SYSML13-13
  • Legacy Issue Number: 15905
  • Status: closed  
  • Source: Thematix Partners LLC ( Roger Burkhart)
  • Summary:

    Appendix F refers to a glossary and other documents that are out of sync with the SysML spec. Suggest removing the appendix.

  • Reported: SysML 1.2 — Mon, 3 Jan 2011 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Remove Annex F from the specification. There are no references to this Annex
    from elsewhere in the specification. The glossary referenced is from 2006 and
    would still require considerable work to be complete and correct even for the
    original version of SysML.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML Issue based on UML 15370 -- Package has optional URI

  • Key: SYSML13-11
  • Legacy Issue Number: 15731
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    UML issue 15370 added an optional URI field to packages. This has several potential usages, including unique identification, federated models, etc. There appears to be no reason not to include this change into SysML

  • Reported: SysML 1.2 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    SysML is an extension of the UML Superstructure. Since SysML 1.3 extends UML
    2.4.1 the requested change by this issue is already incorporated in SysML in the
    UML4SysML package. The SysML specification defines the complete concrete
    syntax including the elements from UML.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Structure Compartment shows blocks instead of parts

  • Key: SYSML13-8
  • Legacy Issue Number: 15355
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The structure compartment shows two blocks connected with a connector. It should be two parts.

  • Reported: SysML 1.2 — Tue, 6 Jul 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Disposition: See issue 15294 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2 - Blocks

  • Key: SYSML13-9
  • Legacy Issue Number: 15600
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    It’s not clear whether the notation for static is part of SysML or not.

  • Reported: SysML 1.2 — Sun, 19 Sep 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Restore the version of the diagram in the "Block" row of Table 8.1, "Graphical nodes
    defined in Block Definition diagrams" which was adopted by a resolution of Issue
    10381 by the SysML 1.0 FTF.
    See the SysML 1.0 FTF Report, published as OMG document ptc/2007-03-19, for the
    original resolution of Issue 10381. This issue included an updated version of the
    diagram in the "Block" row of Table 8.1, specifically modified to include an example
    of a static feature.
    In the SysML 1.0 FTF convenience documents, OMG documents ptc/2007-02-03 and
    ptc/2007-02-04, this diagram appeared as adopted by Issue 10381, but in the final
    SysML 1.0 formal specification, published as OMG document formal/2007-09-01, and
    in all subsequent SysML revisions, the underline of the newly added "property5"
    property, which indicates a static feature, no longer appears.
    Restore the underline of "property5" in this diagram as originally adopted by the
    resolution of Issue 10381.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML Issue based on UML 14062 -- Stereotypes/keywords and upper/lowercase

  • Key: SYSML13-10
  • Legacy Issue Number: 15729
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    UML issue 14062 now attempts (though is not completely successful) in begin Stereotypes with uppercase and keywords with lowercase, though the old stuff will still work. Effectively, this is a style recommendation for the specification and for later methodologist.

    SysML should probably for sake of consistency adopt this as a guideline for our spec and developers

  • Reported: SysML 1.2 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Discussion:
    In the UML 2.4 Superstructure specification, under the subsection "Notation" in
    Section 18.3.9, Stereotype (from Profiles), the following statement appears:
    Normally a stereotype's name and the name of its applications start with
    upper-case letters, to follow the convention for naming classes. Domainspecific
    profiles may use different conventions. Matching between the names
    of stereotype definitions and applications is case-insensitive, so naming
    stereotype applications with lower-case letters where the stereotypes are
    defined using upper-case letters is valid, although stylistically obsolete.
    SysML consistently follows the lower-case keyword convention for stereotype
    applications, which the UML specifications now indicates is a valid convention for
    domain-specific profiles. The less-obtrusive lowercase keywords are valid according
    to the case-insenstive matching of stereotype names, and is preferred by many users
    based on long-standing practice in SysML and because the many uses of such
    keywords in SysML are less obtrusive than uppercase names would be.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2 Issues: Missing constraint on Rationals

  • Key: SYSML13-6
  • Legacy Issue Number: 15301
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 214, C.5.2.14 Rational

    Current description of the Rational value type is missing a constraint that prohibits the denominator from being 0.

    Type: Fix

    Add constraint [1]) The denominator must not be 0

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Disposition: See issue 16396 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2, ch 12

  • Key: SYSML13-7
  • Legacy Issue Number: 15302
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Table on page 110 – Creation Event should be shown as a dashed arrow to be consistent with UML.

  • Reported: SysML 1.2 — Tue, 22 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Correct notation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2 Issues: Activity's sub-activities should be able to have mandatory multiplicity

  • Key: SYSML13-4
  • Legacy Issue Number: 15297
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Activity's sub activities should be able to have mandatory multiplicity

    Page 86, 3rd paragraph and page 86 constraint 3

    Original Text

    Combining the two aspects above, when an activity invokes other activities, they can be associated by a composition association, with the invoking activity on the whole end, and the invoked activity on the part end. If an execution of an activity on the whole end is terminated, then the executions of the activities on the part end are also terminated. The upper multiplicity on the part end restricts the number of concurrent synchronous executions of the behavior that can be invoked by the containing activity. The lower multiplicity on the part end is always zero, because there will be some time during the execution of the containing activity that the lower level activity is not executing.

    p87 [3] The lower multiplicity at the part end must be zero.

    Comment

    While this is technically true, it is not in the spirit of UML. We can have classes/blocks with mandatory components, because the, even though there is always a delay between the creation of the owner and the part, because we assume the time is

    1) small, and

    2) the situation can be made undetectable by normal UML means.

    The same situation can occur here, that we should allow the lower multiplicity to exclude zero, if the component activity is the first sub behavior to run (or tied for first) and that it is the last sub-behavior to end (or tied for last)

    Type: Fix

    Rewrite constraint

    [3]) The lower multiplicity of the part end must be zero, if

    a) An instance of the part is not always the first thing started (or concurrently initialized with the first thing stared) or

    b) An instance of the part is not always the last thing terminated (or terminated concurrently terminated with the last thing terminated), or

    c) It is possible at some point, for no instances of the part to exist.

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Agreed, but the constraint can just be removed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2 Section 16.4.4

  • Key: SYSML13-2
  • Legacy Issue Number: 15131
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Several errors in this section that need to be fixed.

    1) Figure 16.8. Type of diagram should be "stm" not "sm"
    2) Figure 16.7 and Figure 16.8. The relation between the testCase and the Requirement should be «verify» not «refine»
    3) The paragraph mentions Figure 16.7, but actually describes Figure 16.8.
    4) No description of Figure 16.7 appears.

  • Reported: SysML 1.2 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Resolve as follows:
    1) Fig 16.8 diagram type was already fixed in SysML 1.2.
    2) The callouts in Fig. 16.7 and Fig. 16.7 were already changed to "VerifiedBy" and
    "Verifies" in SysML 1.2.
    3) & 4). Replace text for section 16.4.4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2 Issues: Definition of Overwrite

  • Key: SYSML13-5
  • Legacy Issue Number: 15300
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 92 Overwrite

    The description of how overwrite works is wrong. The rule given in the spec is to replace the token that would be last to be selected according to the node rules.

    For example, let us imagine a node with 1..3 FIFO tokens when overwrite is applied.

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B B A

    C C B A

    D D B A

    E E B A

    Probably desired behavior

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B B A

    C C B A

    D D C B

    E E D C

    The recommended behavior is the standard behavior for real-time systems (usually implemented as a circular buffer, with the most recently arrived element the oldest element

    For LIFO queues

    For example, let us imagine a node with 1..3 LIFO tokens when overwrite is applied.

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B A B

    C A B C

    D D B C

    E E B C

    Probably desired behavior

    New Token Position 3 Position 2 Head (1st to be taken off)

    A A

    B A B

    C A B C

    D B C D

    E C D E

    The recommended approach makes both LIFO/FIFO queues always having the freshest elements to work from.

    Recommended

    “For upper bounds greater than one, when the queue is full, an arriving token replaces the oldest token in the queue, leaving a FIFO queue with the remaining earliest arriving token at the head of the queue and leaving a LIFO queue with the latest arriving token at the head of the queue.

    Also, consider giving an example as above.

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Agreed, but use wording reflecting the examples, rather than the recommended
    wording

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML 1.2 Issues: Structure compartment wrong in spec

  • Key: SYSML13-3
  • Legacy Issue Number: 15294
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 31

    There is an example of the Structure Compartment.

    As this compartment follows the ibd format, it should contain parts not blocks

    Type: Formatting/Clarification

    Change Block2 and Block3 to :Block2 and :Block3

  • Reported: SysML 1.2 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    The original SysML submission document, published as OMG document ptc/2006-
    05-04 as the Final Adopted Specification, and the SysML 1.0 FTF convenience
    documents, all had the following version of the diagram in the Structure
    Compartment row of Table 8.1, "Graphical nodes defined in Block Definition
    diagrams":
    Block1
    structure
    p1: Type1 p2:
    Type2
    1
    e1
    c1:
    The current but incorrect version, of this diagram, however, appeared in the final
    SysML 1.0 formal specification, published as OMG document formal/2007-09-01,
    apparently as a result of reauthored graphics after Visio version incompatibilities.
    Replace the current, incorrect version of this diagram by its original version, with
    slight cleanup of its formatting.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

properties allocatedFrom and allocatedTo should be capitalized

  • Key: SYSML13-1
  • Legacy Issue Number: 15078
  • Status: closed  
  • Source: Object Management Group ( Jon Siegel)
  • Summary:

    The properties allocatedFrom and allocatedTo should be capitalized as shown here, and are so in SysML 1.1 pp 133 and following, but they are incorrect in the text on pp 131 and 132. (They are always capitalized correctly in figures; the errors occur in the text.)

  • Reported: SysML 1.2 — Sat, 20 Feb 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    Change capitalization on page 131 and 132 to be consistent with remaining
    document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT