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

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) .

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.

No Data Available

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".

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

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

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

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

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

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).

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

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.

Add constraint that full ports cannot be conjugated

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).

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.

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.

Revised as suggested above

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

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

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.

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.

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

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.

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.

Add clarifications for the areas cited

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)).

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

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.

Clarify the cited case.

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

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

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

See issue 16255 for disposition

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.

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

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.

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

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

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.

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.

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

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.

Agreed, but the constraint can just be removed

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

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.

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

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

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

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.

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.

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

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.

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.

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.

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.

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

Show block as stereotype in Figure 9.1.

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

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.

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.

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.

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.)

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

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

Disposition: See issue 15294 for disposition

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

Correct notation

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

Disposition: See issue 16396 for disposition

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.

Specify the above semantics for required behavioral features.

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

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

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

Revised as suggested above

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.

Revise as suggested

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.

Revise as suggested above.

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

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.

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.

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

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.

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

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.

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.

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.

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

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.

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.

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

Remove the cited constraint

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.

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.

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

Update flow property compatibility rules to be independent of item flow

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

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

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

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.

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.

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

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

Revise as suggested, and clarify step cross references

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

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

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

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

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

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

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

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

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

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

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.

Insert the missing «normal» keyword into the diagram.

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".

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

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.

No Data Available