At the moment the stereotype distrubtedProperty is only allowed to be applied to properties of classifier stereotyped by Block or ValueType.
We would like to apply the distributedProperty stereotype also to properties of classifier stereotyped by Signal.
Reason: The properties of a block are transmitted by signal properties, the properties of the signal should also reflect the distribution.

Defer

Issue deferred

The specification states that a binding connector can be typed.
The semantics are not clear.
The purpose of this ticket is to provide clarification of typing a binding connector.

Defer

Issue deferred

Some DirectedRelationshipPropertyPath constraint definitions assume that the relationship on which this stereotype is applied is binary but there is no formal constraint enforcing it.

Defer

Issue deferred

In several places of the SysML specification document the term "has been" is used. It should be replaced by "is".

Defer

Issue deferred

The usage of Generalization in SysML is a key part of establishing Domain Specific Languages and contexts for models. In particular it has great ability to establish reusability within our models. However, the only mechanism via which we can visually denote the nature of an object is via non-normative extensions to M2 via stereotypes such as <<Car>> or other examples. This is undesirable, we should have the ability (on classes and parts typed by those classes) to optionally display the General (or any General class of a Block) classifier of a Block on BDD's, IBD's and Parametric diagrams. This will, greatly enhance the readability of our diagrams, remove the complexity of implementing M2 stereotypes simply designed for visualization, and expose via the diagram usage of reusable libraries to make the foundation of our models.

Example Format might be (in ASCII art):

------------
<<Block>>
[Car]
Porsche
--------------

Defer

Issue deferred

The SysML diagram header is not easily interpreted. Suggest a new format that provides the same information and content but following the typical naming convention used in SysML - i.e. name:Type

Suggestion/Example:

From:
req [Package] Auto_Specification [Automobile System Requirements]

To:
Automobile System Requirements:req | Auto_Specification:Package

Optional format adds "[req]" as an option to turn on to in bold or white text on a black background filling the header box around the diagram kind "req" in this case. Image examples provided to Rick Steiner and Sandy Friedenthal in separate communications.

[req] Automobile System Requirements:req | Auto_Specification:Package

Defer

Issue deferred

Between SysML 1.2 and SysML 1.3, some stereotypes were deprecated
This deprecation was done by moving Stereotypes from their original package to a new "DeprecatedElements" package.

Changing the qualified names of these stereotypes may break some code in tooling. Ideally the deprecation should be indicated without changing the element.

SysML 1.3 : http://www.omg.org/spec/SysML/20120401/SysML.xmi
SysML 1.2 :http://www.omg.org/spec/SysML/20100301/SysML-profile.uml

No change

That's not an issue about the specification but about the way of working. Request registred and agreed

Some of the combined units use a period character instead of a multiply symbol. An example is the unit ‹newton metre› where the symbol is ‹N.m›. In contrary, other units make use of the middle dot character, e.g., ‹kilogram metre squared per second›, using the symbol ‹kg · m 2/s›.

The SI Guide prescribes to use a middle dot or a thin space or if not ambiguous no character to combine different units that are multiplied.

Defer

Issue deferred

Table 4.1. excludes several UML metaclasses from SysML. However, figure 4.2 shows that the SysML profile imports the whole UML. Instead, the SysML profile should use the metamodelReference and metaclassReference properties to import only the included elements.

Defer

Issue deferred

While it is not possible to check if a value conforms to, for example, uniform or mean distribution, it is possible to check, if it conforms to constraints of the specified distribution. For example, the minimum and maximum values of a uniform distribution.

Defer

Issue deferred

SysML should be based on the newest available UML specification. Current UML specification is version 2.5.1. SysML 1.5. is still based on UML 2.5.

Fix it

Agreed, to take care about it for SysML 1.7

Split from SYSML16-86:

What is the type of FullPort? Spec says nothing

Defer

Issue deferred

The DistributedProperty itself does not make sense. As specified in the specification specific distributions should be defined as subclasses of the DistributedProperty stereotype. Therefore, the stereotype should be abstract.

Defer

Issue deferred

The DistributedProperty stereotype should be abstract since it needs to be specialized in order to be usable.

duplicate

Duplicate by SYSML17-170

The diagrams in Annex D are in many ways inconsistent with each other. Fixing existing issues with each individual diagram will tend to make this problem worse, instead of better. For consistency's sake, the set of diagrams in Annex D needs to be generated from an integrated model as existing issues are addressed.

Replace 1.6 Annex D with 1.7 Annex D generated from integrated model.

Two documents attached:
1. Annex D generated from the 1.7 integrated model in TWC (SysML 1.x Specification [trunk] #1206.
2. SYSML17-185 Resolution Document, generated from the same model (#1210) with tables showing each issue resolved & the effected diagram(s), then each of the 41 figures in both final form and annotated to show which changes have been made. Note that figures without annotated diagrams have not substantially changed from 1.6.

Figure D.25 depicts a allocate call-out notation that represents more than one call-out relationship. I don't think that it is allowed.

Merge with SYSML17-185

This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

I would question whether it was correct to change section 11.3.1.1 "Activity" by replacing the BDD representation of activity hierarchy (as per v1.3) with adjunct action properties (introduced in v1.4). Whilst the latter is possible with the AdjunctProperty facility, the prior method, inherited from UML, is still valid. That is, unless the UML activity hierarchy is expressly deprecated from SysML. Even then, it will leave end users with the question of what the additional benefit is of the adjunct property as applied to call behaviour actions.

Closed, no change: Restrict bdd presentation of activities

There is no need that SysML restricts the modeling of activities in block definition diagrams like it is allowed by UML rules. The paragraph above Figure 11-1 in 11.3.1.1.1 says "Properties with AdjunctProperty applied ... can be used", it doesn't say they must be used.

The ConnectorProperty is redundant. The same feature is provided by AdjunctProperty.

see slide 17: http://tinyurl.com/ybvdx6ew

Resolution: Deprecate ConnectorProperty

The AdjunctProperty with a connector as principal provides the same capability as the ConnectorProperty. To continue to be backward compatible, the stereotype ConnectorProperty will not be removed, but marked as deprecated in the specification.

The definition of owning block for proxy port given in the description sub-section of 9.3.2.7 FlowProperty is unclear and misleading. It should be reworded and moved to the ProxyPort description

Remove the sentence between parenthesis

The sentence will be removed

In http://www.omg.org/spec/SysML/20161101/SysML.xmi, some parameter directions are set to "_return" instead of "return".

Proposal: Parameter direction typo in XMI

To be fixed by updating the XMI generation algorithm.

Split from SYSML16-86:

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

Proposal: Owned properties of an InterfaceBlock

InterfaceBlock constraint 2_no_part defines the possible owned properties.

The intended use for the <<DirectedFeature>> stereotype is not at all clear from its specification in section 9.3.2.4 in SysML 1.5. To be clear, the current description describes what it is, but not why it is required, or how a modeller might use it. Moreover, it is not clear whether it specifically applies to ports (since its part of the section that specifies the language facilities for ports and flows (section 9), or whether it relates to features (properties?) of a block that are not ports.

The issue was discussed at the RTF meeting of 2017-10-12 as a result of discussing issue http://issues.omg.org/browse/SYSML16-108. There was little consensus on what DirectedFeature is, although Conrad suggested the following (being my interpretation of what was said):
A DirectedFeature of a block describes whether the block implements that feature (it's "provided") or that the feature is represents a conceptually virtualised feature as an "assumption" that something else in the model will provide it. The fulfilment of the required assumption with an actually provided realisation of that feature is by a connector between the required and the provided features.

The problem with this interpretation is that it seems to have nothing to do with ports! There is of course further scope for confusion with the UML notation of provided and required interfaces on UML ports.
At the very least, some examples that clearly illustrate what problem DirectedFeature solves and the types of model elements that it is to be applied to would help a lot.

Improved description of DirectedFeature

The description in SysML 1.6 has improved quite considerably. However it can be further improved by slightly modifying the way the corresponding text is structured and by clarifying that any feature are implicitly "provided" if no DirectedFeature stereotype is applied

A reference property of a Block may only be typed by (i.e. "reference") another Block. There is no current mechanism for a reference property to explicitly reference a part property of a different block. See Figure D.16 for example; the PowerSubsystem Block is assumed to be referencing the part property of the BrakeSubsystem typed by BrakePedal. This is a logical conclusion since there is only one part property typed by BrakePedal, but if there were multiple part properties typed by BrakePedal, the reference property of the PowerSubsystem Block would be ambiguous.

Practical use of reference properties has consistently implied that a particular part property CAN be referenced (i.e. "a part property owned by another block"), but no mechanism for this is explicitly provided in SysML. Also, there does not appear to be any constraint on instance semantics of reference properties that might clarify this ambiguity at the instance level.

See also SYSML16-42 and SYSML16-228.

Proposal: Reference properties do not reference properties

Discussed during May 16th, 2019, RTF meeting:

We believe that the requested capabilities are already provided by the current SysML version. There are multiple ways to represent such constructs:

1. A binding connector and optionally a BoundReference property can be used
2. Derived attribute and/or an operation
3. Specific properties that subset the collection (assuming the types of the properties owners conform to one another)
4. Using proxy ports with appropriate connectors

In SysML 1.5 pdf document ( p 147 Table 14.2- Graphical paths included in Use Case diagrams)

Latest element in the table :

• Path name: Generalization
• Concrete Syntax : ->
• Abstract Syntax Reference : UML4SysML::Kernel
  => it should be UML4SysML::Generalization

Also present in SysML 1.4 pdf version

Proposal: Replace UML4SysML::Kernel with UML4SysML::Generalization

The abstract syntax reference is not correct as pointed out by the reporter of the issue and must be resolved as proposed.

The SysML::Trace stereotype is a specialization of the UML::Trace stereotype defined in the StandardProfile.

In the SysML XMI the SysML::Trace stereotype has no generalization relationship to the UML::Trace stereotype. It is just a stereotype extending UML::Abstraction.

Resolution: Model generalization from stereotype SysML::Trace to UML::Trace

The XMI is not conform to the written specification. The generalization relationship between the SysML::Refine and the UML::Refine stereotypes as specified in figure 16.1 is not defined in the XMI.

The SysML::Refine stereotype is a specialization of the UML::Refine stereotype defined in the StandardProfile.

In the SysML XMI the SysML::Refine stereotype has no generalization relationship to the UML::Refine stereotype. It is just a stereotype extending UML::Abstraction.

Resolution: Model generalization from stereotype SysML::Refine to UML::Refine

The XMI is not conform to the written specification. The generalization relationship between the SysML::Refine and the UML::Refine stereotypes as specified in figure 16.1 is not defined in the XMI.

This issue is dedicated to typos and editorials we find in the SysML1.5 specification document.

Any finding has to be recorded as an annotation added to a shared PDF document available on the OMG SVN server at: http://www.omgwiki.org/repos/SysML/trunk/Documents/formal-17-05-01(annotated).pdf

>>> Note to RTF Chairs: do not schedule this issue for vote before the last ballot of the RTF <<<

1.6 is done

to be replace by a new issue similar to this one but about 1.6 rather than 1.7

The first sentence of the description of the Adjunct property stereotype does not make sense:
"The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states"

Merged with SYSML17-248

Discussed during RTF meeting, Sep. 19th:
SYSML17-248 is also about clarifying the definition of an AdjunctProperty.

Figure D.23 depicts two blocks with ports that are connected by a connector.

Remove illegal connector/association

Figure D.23 had, up through SysML 1.6, a bdd with a connector between the ports of two blocks. SysML 1.6 diagram was a slight modification of this, with an association between the blocks that was rendered through the ports. This is more legal, but ambiguous and doesn't meet the original intent. This proposal includes a replacement diagram without the offending connector. The diagram was generated out of the same model that generated the SysML 1.6 diagram, but with the association removed.

The description of stereotypes in the abstract syntax is missing all the "base_xxx" attributes that refer to the instances of extended elements. However this is required in order to specify the corresponding multiplicity and redefinition, if any.

In addition, it should also be specified whether the corresponding stereotype is "required" or not. At that time, the only way to know it is to parse the normative XMI file.

Proposal: Statements missing in the abstract syntax description

The issue was already fixed in SysML 1.6.

Typos in revised text for Annex C

• Change "C.1.1 and C.1.2" to "C.1.2 and C.1.3".

• Change "C.5 through C.7" to "C.4 through C.7".

Proposal: Typo in revised text of issue SYSML16-289

The typo refers to a typo in a revised text of a SysML 1.6 issue and is not in SysML 1.6 specification.

The constraint#3 of NestedConnectorEnd could be advantageously replaced by making base_ConnectorEnd a redefinition of the base_Element property

Merged with SYSML16-274

To be fixed as part of SYSML16-311:

• Make base_ConnectorEnd a redefinition of base_Element property
• Delete constraint#3

Conrad Bock points out that the OCL for the InterfaceBlock::getConjugated() operation in the revised text approved in the corresponding resolution (i.e. SYSML16-289) that was included in Ballot#8 was wrong. Indeed, this OCL correspond to a obsolete version of the resolution that was based on Dependency.

The right OCL for the body condition of that getConjugated() operation is:

~InterfaceBlock.allInstances()->any(ib | ib.original = self)

Fix the OCL code

Fix the OCL code as suggested.

As discussed at Reston , issue SYSML16-100 shall be extended to include all kind of composite properties allowed on InterfaceBlocks

Merged with SYSML16-100 (and SYSML16-274)

Constraint to be modified to cover all kind of composite properties allowed.
Revised text:
Interface blocks' composite properties are either ports, value properties or flow properties

Only few constraints specified in SysML v1.5 have a corresponding formal OCL statement. Even if not all of them can be expressed using SysML, most of them could. This would help clarifying then and will remove ambiguity that shall remain in their English description.

Provide OCL statements for SysML stereotype constraints everywhere possible

The resolution will result in a version of the SysML profile models that will include OCL statements for constraints everywhere we will be able to write one or the sentence: "Cannot be expressed in OCL" otherwise

Here is the URL to models in the SVN branch for this issue resolution: http://www.omgwiki.org/repos/SysML/branches/SYSML16-311

Note: If you want to contribute leave a comment below, and don't forget to "lock" (SVN) but avoid keeping the version locked too long and commit your work in order to not block other contributions. Thanks!

Setting a flow property on blocks with multiple behavioral ports that also have that property causes the new value to propagate out through all the ports (see test case in B.3.2.3, Block with Multiple Behavior ProxyPorts in https://www.omg.org/spec/PSCS/1.1). Modelers should be able to specify which behavior port the value flows through.

Add flow property value action, onport

Provide the requested capability

Constraints owned by either Satisfy or Verify stereotype still refer to the SysML::Requirement stereotype while they should have been modified so that they refer to the AbstractRequirement stereotype added in 1.5

Merged with SYSML16-274

To be fixed as suggested by SYSML16-311
Constraints owned by either Satisfy or Verify stereotype shall refer to SysML::AbstractRequirement instead of the SysML::Requirement stereotype.

Revised Text:
SysML::Satisfy::Constraint#1 shall be replaced by:
The supplier shall be an element stereotyped by any subtype of «AbstractRequirement»

AbstractRequirement.allInstances().base_NamedElement->includes(self.base_Abstraction.supplier)

SysML::Verify::Constraint#1 shall be replaced by:
The supplier shall be an element stereotyped by any subtype of «AbstractRequirement»

AbstractRequirement.allInstances().base_NamedElement->includes(self.base_Abstraction.supplier)

ItemFlow constraint#3 makes the implicit assumption that both source and target of an ItemFlow are properties:

itemProperty shall be a property of the common (possibly indirect) owner of the source and the target.

However they can be Classifiers as well.

Merged with SYSML16-274

To be fixed as suggested by SYSML16-311.
Revised text:
If itemProperty has a value it shall be a property of the common (possibly indirect) owner of the source and the target.

Allocate constraint#3 states:

If subtypes of the «allocate» dependency are introduced to represent more specialized forms of allocation, then they shall have constraints applied to supplier and client as appropriate.

This is neither clear nor verifiable. It should be removed

Merged with SYSML16-274

Remove the constraint #3 as suggested

The following sentence is misleading:

9.1.3 Proxy Ports and Full Ports

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

There are in fact at least three usage patterns: normal (UML) ports, full, and proxy.

There is a prevailing misunderstanding that normal ports should not be used at all in SysML.
(There are dozens of places in the spec stating that normal ports still can be used.)

This has lead to recent tool vendor errors not offering
a basic ports compartment, although it is clearly specified and even shown in some figures.

A single word might improve things:

'SysML identifies two additional usage patterns for ports …’

Or more verbosely:

'SysML identifies two more specific usage patterns for ports in addition to standard ports …

All usage kinds are defined

The two "usage patterns" specified by the referenced text actually described two mutually exclusive options. A "third" option, if any will be not to choose between this two alternatives. This is specified by applying none of those SysML stereotype or, in other words, to use the UML concept of port natively.

So, I would not be correct to tell about "additional usage patterns".

In addition there is this sentence at the end of the first paragraph of section 9.1.3: "Ports that are not specified as proxy or full are simply called “ports.", then in the next paragraph : "Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full. Modelers can choose between
proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology"

Appendix A.2 Guidelines (for Diagrams) says:

"SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to
the artifact model element. Properties of the artifact can capture information about the document. Use a «trace»
abstraction to relate the document to model elements. The document can represent text that is contained in the related
model elements."

However, the artifact model element is excluded from SysML and cannot be used (see table 4.1).

Remove diagram guideline about representing documents

The diagram guideline in section A.2 refers to the excluded UML model element Artifact.

"SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to
the artifact model element. Properties of the artifact can capture information about the document. Use a «trace»
abstraction to relate the document to model elements. The document can represent text that is contained in the related
model elements."

The guideline should be removed. How to represent documents in SysML models must be answered by methodologies.

The keyword "equal" needs a lot of space in a diagram. It would be better to have shorter notation for binding connectors.

The proposal is to use the equal sign = instead of the keyword with guillements <<equal>>.

Proposal: Change keyword of binding connector from "equal" to "="

Add the equal sign = instead of the keyword <<equal>> as an additional alternate notation for binding connectors. Binding connectors are often used in internal block diagrams and the keyword <<equal>> clutters the diagram. The equal sign is much shorter and the meaning is commonly known.

Refine constraint#1 states:

The Refine stereotype shall only be applied to dependencies

and Refine constraint#2 states:

Dependencies with a Refine stereotype or one of its specializations applied shall have exactly one client and one supplier.

• SysML::Refine specializes StandardProfile::Refine that extends UML::Abstraction. So the constraints should refer to UML::Abstraction rather than to UML::Dependency

• constraint#1 could be replaced by a redefinition

The same with the SysML::Trace stererotype

Merged with SYSML16-274

To be fixed as suggested by SYSML16-311:
1/ Refine stereotype:

• Add a base_Abstraction property to the SysML::Requirements::Refine stereotype with the type UML::Abstraction and a multiplicity of [1] and make it a redefinition of both UML::StandardProfile::Refine::base_Abstraction and SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship

• Delete Constraint#1 from SysML::Requirements::Refine

• Constraint# 2 textual statement shall be replaced by:
  Abstractions with a Refine stereotype or one of its specializations applied shall have exactly one client and one supplier

• Constraint# 2 OCL statement shall be:

  self.base_Abstraction.client->size()=1 and self.base_Abstraction.supplier->size()=1

2/ Trace stereotype:

• Add a base_Abstraction property to the SysML::Requirements::Trace stereotype with the type UML::Abstraction and a multiplicity of [1] and make it a redefinition of both UML::StandardProfile::Trace::base_Abstraction and SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship

• Delete Constraint#1 from SysML::Requirements::Trace

• Constraint# 2 textual statement shall be replaced by:
  Abstractions with a Trace stereotype or one of its specializations applied shall have exactly one client and one supplier

• Constraint# 2 OCL statement shall be:

  self.base_Abstraction.client->size()=1 and self.base_Abstraction.supplier->size()=1

Copy constraint#2 states:

The text property of the client requirement is constrained to be a read-only copy of the text property of the supplier requirement.

While Copy constraint#3 states:

Constraint [2] is applied recursively to all subrequirements.

They should be merged in one unique constraint so that the requested recursivity could be formally stated in OCL using an helper operation

Merged with SysML16-274

To be fixed as part of SYSML16-311

• Add an "Operations" sub clause with the following operation definition:
  isCopy (in req1 : AbstractRequirement, in req2 : AbstractRequirement) : Boolean [1]

bodyCondition:
let subReq1: Set(AbstractRequirement) = AbstractRequirement.allInstances()->select(r | req1.base_NamedElement.ownedElement->includes(r.base_NamedElement)) in
let subReq2: Set(AbstractRequirement) = AbstractRequirement.allInstances()->select(r | req2.base_NamedElement.ownedElement->includes(r.base_NamedElement)) in
req1.text = req2.text and
subReq1->size() = subReq2->size() and
subReq1->forAll(r1 | subReq2->exists(r2 | self.isCopy(r1, r2) ))

• Constraint#2's textual statement shall be replaced by:
  The text property of the client requirement is constrained to be a read-only copy of the text property of the supplier requirement and this applies recursively to all subrequirements (i.e. requirements related by a containement relationship)

• Constraint#2's OCL statement shall be:

  let cltReq: AbstractRequirement = AbstractRequirement.allInstances()->any(r | self.base_Abstraction.client->includes(r.base_NamedElement)) in
  let supReq: AbstractRequirement = AbstractRequirement.allInstances()->any(r | self.base_Abstraction.supplier->includes(r.base_NamedElement)) in
  self.isCopy(cltReq, supReq)
  

• Constrain#3 shall be deleted

The constraint#6 of TriggerOnNestedPort could be advantageously replaced by making base_Trigger a redefinition of base_Element property

Merged with SYSML16-274

To be fixed as part of SYSML16-311:

• Make base_Trigger a redefinition of base_Element property
• Delete constraint#6

The constraint#5 of TriggerOnNestedPort states:

The type of the port at the last position of the onNestedPort list must own or inherit the port of the stereotyped invocation action.

This constraint should refer to the stereotyped trigger.

Merged with SYSML16-274

Fix as part of SYSML16-311 as suggested.

Constraint #5 textual statement shall be replaced by:
The type of the port at the last position of the onNestedPort list must own or inherit the port of the stereotyped trigger

The TriggerOnNestedPort constraint#4 is stated:

The first constraint of ElementPropertyPath shall apply to onNestedPort

Such a reference to another constraint that, in addition, requires substituting words in order to be contextualized is not appropriate. It shall be properly stated in a straightforward way.

Merged with SysML16-274

To be fixed as part of SYSML16-311:

• The textual statement shall be replaced by:
  The port at each successive position of the onNestedPort attribute, following the first position, shall be owned by the Block that types the port at the immediately preceding position, or a generalization of the Block.

• The corresponding OCL statement shall be:

  self.onNestedPort->size() >1 implies self.onNestedPort->subSequence(2, self.onNestedPort->size())->forAll(p |
  let np: UML::Port = self.onNestedPort->at(self.onNestedPort->indexOf(p)-1) in
  let owners: Set(UML::Classifier) = np.type.oclAsType(UML::Classifier)->including(np.type.oclAsType(UML::Classifier)) in
  owners->includes(p.owner))

ItemFlows constraint#1 implicitly implies that the corresponding InformationFlow has no more than one target and one source:

A Connector or an Association, or an inherited Association shall exist between the source and the target of the
InformationFlow.

However this is not explicitly stated. Constraint#1 should be improved or a specific constraint shall be added.

The constraint does not assume that

It should be a way for the flow to occur between every source and every target ("star connection pattern").

Rate constraint#2 states:

The rate of a parameter shall be less than or equal to rates on edges that come into or go out from pins and parameters nodes corresponding to the parameter

This is ambiguous since SysML::Rate::rate is typed by UML::InstanceSpecification for which "less than or equal to" is not defined

Merged with SYSML16-274

To be fixed as part of SYSML16-311 by assuming than the specification of Rate can be given a OCL::Real value:

The complete OCL statement for this constraint shall be:

self.base_Parameter->notEmpty() implies (
	let nodes: Set(UML::ObjectNode) =
	if self.base_Parameter.owner.oclIsKindOf(UML::Behavior) then
		let pOwner: UML::Behavior = self.base_Parameter.owner.oclAsType(UML::Behavior) in
		UML::CallBehaviorAction.allInstances()->select(a | a.behavior = pOwner)->collect(a | a.argument->at(pOwner.ownedParameter->indexOf(self.base_Parameter)))
		->union(UML::StartObjectBehaviorAction.allInstances()->select(a | a.behavior() = pOwner)->collect(a | a.argument->at(pOwner.ownedParameter->indexOf(self.base_Parameter))))
		->union(UML::ActivityParameterNode.allInstances()->select(n | n.parameter = self.base_Parameter))
		->asSet()		
	else if self.base_Parameter.owner.oclIsKindOf(UML::Operation) then
		let pOwner: UML::Operation = self.base_Parameter.owner.oclAsType(UML::Operation) in
		UML::CallOperationAction.allInstances()->select(a | a.operation = pOwner)->collect(a | a.argument->at(pOwner.ownedParameter->indexOf(self.base_Parameter)))->asSet()
	else
		Set(UML::ObjectNode){}
	endif endif in
	nodes.incoming->flatten()->union(nodes.outgoing->flatten())
	->forAll(e | let eRate: Rate = Rate.allInstances()->any(r |  r.base_ActivityEdge=e) in
		(not eRate.oclIsUndefined() and self.rate. specification.realValue() <= eRate.rate. specification.realValue()))
)

Probability constraint#1 states:

The «probability» stereotype shall only be applied to activity edges that have decision nodes or object nodes as sources, or to output parameter sets.

This is ambiguous since ParameterSets have no direction, only their parameters have.

A constraint defined by UML on parameter sets clarify it

See UML::ParameterSet constraint named "same_parameterized_entity": its implies that all parameters of a set have the same direction

ConstraintBlock constraint#3 states:

Any property of a block that is typed by a ConstraintBlock shall have composite aggregation.

And the following OCL statement is provided

self.ownedAttribute->forAll(p | p.type.oclIsKindOf(ConstraintBlock) implies p.aggregation = #composite)

The OCL is invalid and wrong since "self" refers to the stereotype instance while this is the property typed by the ConstraintBlock which is constrained

Merged with SYSML16-274

Fix the OCL statement as proposed in the comment as part of SYSML16-311:

self.base_Class.ownedAttribute->forAll(p| p.isComposite)

the constraint#5 of InvocationOnNestedPortAction stereotype states:

InvocationOnNestedPortAction shall only be applied to invocation actions

This is because it inherits from ElementPropertyPath the ability to be potentially applied to any UML::Element.

However we could easily restrict this by making its base_InvocationAction property a redefinition of the base_Element property of its parent.

Merged with SYSML16-274

To be fixed as suggested by SYSML16-311:

• Make the base_InvocationAction property a redefinition of the base_Element property of its parent stereotype.
• Delete constraint #5

The 4 first constraints of DirectedRelationshipPropertyPath are defined as follows:

[1]sourceContext shall have a value when source is a property, otherwise it shall not have a value.
[2]targetContext shall have a value when target is a property, otherwise it shall not have a value.
[3]source shall be a property when sourcePropertyPath has a value.
[4]target shall be a property when targetPropertyPath has a value.

#1 implies #3 and #2 implies #4, so #3 and #4 are redundant and should be deleted.

Reporter is wrong

Reporter was confused, nothing wrong here.

BoundReference constraint#3 states the following:

The role of boundEnd shall be a property accessible by navigation from instances of the block owning the property to which BoundReference is applied, but shall not be the property to which BoundReference is applied, or one that it is related to by redefinition.

It's not clear what "navigable" means here. Please clarify.

Merged with SYSML16-274

Clarify as suggested as part of SYSML16-311.
Revised text:

self.base_Property.association->notEmpty() and 
self.boundEnd.definingEnd->notEmpty() and
self.base_Property.association.navigableOwnedEnd->includes(self.boundEnd.definingEnd)

The constraint#10 of AdjunctProperty is specified by the following sentence, which does not make sense:

Properties with AdjunctProperty applied that have a Variable or Parameter applied shall have a lower multiplicity the same as or lower than the lower multiplicity of the Variable or Parameter, and an upper multiplicity the same as or higher than the upper multiplicity of the Variable or Parameter.

In addition the statement could be simplified since this should be extended to any AdjunctProperty for which the principal is a kind of MultiplicityElement

Fix constraint#10

Reword as proposed, as part of SYSML16-274:
Properties with AdjunctProperty applied that have a Variable or Parameter as principal shall have a lower multiplicity the same as or lower than the lower multiplicity of their principal, and an upper multiplicity the same as or higher than the upper multiplicity of their principal.

Allocate constraint#1 states:

The Allocate stereotype shall only be applied to abstractions

Could be removed if its base_Abstraction property redefines the base_DirectedRelationship property it inherits from DirectedRelationship
PropertyPath

Merged with SYSML16-274

To be fixed as part of SYSML16-311 by making base_Abstraction a redefinition of base_DirectedRelationship.

Constraint#1 can then be removed

The InvocationOnNestedPortAction constraint#3 is stated:

The first constraint of ElementPropertyPath shall apply to onNestedPort

Such a reference to another constraint that, in addition, requires substituting words in order to be contextualized is not appropriate. It shall be properly stated in a straightforward way.

Merged with SYSML16-274

To be fixed as part of SYSML16-311 directly in the OCL statement:

The SysML::ElementPropertyPath::Constraint#1 states:
The property at each successive position of the propertyPath attribute, following the first position, shall be owned by the Block or ValueType that types the property at the immediately preceding position, or a generalization of the Block or ValueType.

So the OCL code for SysML::InvocationOnNestedPortAction::Constraint#3 shall be:
The port at each successive position of the onNestedPort attribute, following the first position, shall be owned by the Block that types the port at the immediately preceding position, or a generalization of that Block .

self.onNestedPort->size() > 1 implies self.propertyPath->subSequence(2, self.onNestedPort->size())->forAll(p |
let pp: UML::Property = self.onNestedPort->at(self.onNestedPort->indexOf(p)-1) in
let owners: Set(UML::Classifier) = pp.type.oclAsType(UML::Classifier)->including(pp.type.oclAsType(UML::Classifier)) in
owners->includes(p.owner))

InvocationOnNestedPortAction constraint #2 states:

The port at the first position in the onNestedPort list shall be owned (directly or via inheritance) by a block that types the target pin of the invocation action, or one of the block’s generalizations

However the InvocationAction metaclass has no "target" pin, only some of its subclasses have.

Merged with SYSML16-274

To be fixed as suggested by SYSML16-311.
The principle of the resolution will be to write the OCL code so that each possible case is considered:

let target: UML::InputPin = if self.base_InvocationAction.oclIsKindOf(UML::CallOperationAction) then 
	self.base_InvocationAction.oclAsType(UML::CallOperationAction).target
else if self.base_InvocationAction.oclIsKindOf(UML::SendSignalAction) then 
	self.base_InvocationAction.oclAsType(UML::SendSignalAction).target
else if self.base_InvocationAction.oclIsKindOf(UML::SendObjectAction) then 
	self.base_InvocationAction.oclAsType(UML::SendObjectAction).target
else
	invalid
endif endif endif in
not target.oclIsUndefined() and (
let target_type: UML::Class = Block.allInstances()->any(b | b.base_Class = target.type).base_Class in
not target_type.oclIsUndefined() and target_type.allFeatures()->includes(self.onNestedPort->first()))

In our discussion about SYSML16-308, Conrad Bock pointed out that the association-like notation provided by UML is ambiguous.

See below:

In the figure below the "size" attribute is not part of an association this is only an "association-like" notation that UML allows. The point is that there in no multiplicity and the opposite side because there is no corresponding role. By the way, multiplicity on this opposite side is not constrained (i.e. it is "0..*") while with a "true" association, multiplicities that are not shown are often interpreted by some reader to be "1..1" (even if the UML specification explicitly say that: "If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model")

In order to fix this we can either:

• propose a better notation
• deprecate this notation

Merge with SYSML16-154

It makes sense to merge this issue with SYSML16-154 (about Block constraint#4) in order to provide a consistent resolution.

Are nested diagrams allowed in SysML?

I could not find any description that it is allowed. However, figure E.31 shows an example of nested diagrams: a parametric diagram is shown in a block definition diagram.

Nested diagrams are not allowed

Either the UML specification nor the SysML specification says something about nested diagrams. Although it could be a useful feature, it is currently not allowed.

Figure E.31 has two nested diagrams. The diagram in the upper right corner shows a subset of the other nested diagram and could be removed.

According to table 10.2. a binding connector in a parametric diagram is depicted as a solid line without a keyword.

Figure E.31 shows a binding connector in a parametric diagram with keyword <<equal>>.

I propose to remove the keyword in figure E.31 and to add a section below 10.3.1.2 Parametric Diagram to say that the binding connector keyword is not shown in parametric diagrams.

Clarify that binding connectors are depicted without keyword in parametric diagrams

The diagram elements table for internal block diagrams defines a keyword <<equal>> for binding connectors. The diagram elements table for parametric diagrams defines the notation without a keyword. However, the appendix shows an example of a parametric diagram with a binding connector and keyword <<equal>>.

Although it is unusual, it is allowed to have both - normal and binding connectors - in a parametric diagram. The binding connector keyword is important to distinguish the connector kinds.

The diagram elements table 10.2 should depict the binding connector keyword. There is no need to update parametric diagram examples in the specification document, because it is still allowed to discard the keyword (see diagram table of binding connector).

Strict implementation of a Requirement, which is based on a Class, restricts the expected usage of a requirement on diagrams that do not allow the visualization of a class. Not all tools enforce this, but those that do (MD), restrict the desired approaches to addressing requirements traceability and communication.

SysML has no strict constraints about diagram content

Section "16.3.1.4 Requirements on Other Diagrams" says "Requirements can also be represented on other diagrams to show their relationship to other model elements." If a tool enforces the usage of requirements on a diagram, it is a tool issue.

Would be useful to siupport an equal sign (=) for binding connectors. The current keyword is fine, but not very compact.

Duplicate of SYSML16-389

SYSML16-389 also asks for the equal sign and has a proposal.

The Block constraint [5] quotes the UML specification. The reference to UML specification section 9.3.6 is not correct. The correct chapter number is 11.8.

The block constraint [9] quotes the UML specification. The reference to UML specification section 9.3.7 is not correct. The correct chapter number is 11.8.

Correct the references to the UML specification in block constraints [5] and [9]

see issue description SYSML16-303

Remove the sentences

"Qualified associations, shown in SysML by an open box at the end of an association path with a property name inside, are
a specialized feature of UML that specifies how a property value can represent an identifier of an associated target. This
capability, while useful for data modeling, does not seem essential to accomplish any of the SysML requirements for
support of systems engineering."

These sentences are partly incorrect (qualified associations are not shown in SysML), cover only an opinion, and could easily lead to misunderstandings. On the other side it only adds a minimal value.

Remove sentences about qualified associations from 8.3.1.3

see issue description SYSML16-300

Remove the sentence "N-ary associations, shown in UML by a
large open diamond with multiple branches, can be modeled by an intermediate block with no loss in expressive power." from the specification.

N-ary associations are still excluded by the second sentence in the clause. The sentence to be removed added a motivation for the exclusion, but the statement "with no loss in expressive power" is not correct.

Remove the statement about N-ary associations

see issue description SYSML16-299

According to table 8.4 it is allowed to show a binding connector without keyword <<equal>>. In that case it is identical with the normal Connector and makes the diagram ambiguous. The keyword should be mandatory.

Make keyword notation for binding connectors in internal block diagrams mandatory

Binding connectors without a keyword in internal block diagrams could not be distinguished from normal Connectors. The keyword must be mandatory to avoid ambiguity.

the constraint#3 of the SysML::View stereotype states the following:

The derived values of the stakeholder attribute shall be the names of the classifiers stereotyped by Stakeholder that are [...]

However the View::stakeholder attribute is typed by SysML::Stakeolder[*] and not by String, as in SysML versions before 1.4. We probably missed it in 1.4.

Fix the text of the constraint

Modify the constraint statement so that it refers to element of the right type

In Figure 8.11 (Model library for Unit and QuantityKind), Unit and QuantityKind are blocks (at least according to the XMI), but they don't
have the block keyword showing.

*Add the block keyword to Unit and QuantityKind *

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

However, it is a good style to be very clear in a specification and the figure will be updated anyway (see SYSML16-334).

SysML::Block constraint#3 states the following

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

However there is no constraint in UML requiring that ends owned by the association have empty names. SysML can possibly require it but the added value is not obvious. I suggest focusing this constraint on the link between navigability and end ownership:

Any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association may not be defined as a navigable owned end of the association.

To be merged with the formalization of SysML constraints (SYSML16-274)

To be merged with the formalization of SysML constraint which includes adding them explicitly in the model of the SysML profile

Remove the string "[sic] " in the constraints on Block.

Remove [sic] statements in block constraints

see issue SYSML16-295

AdjunctProperty constraint#8 is partly redundant with constraint#3 since both require that the Property on which this stereotype is applied has a composite aggregation when the principal is typed by a CallAction.

Constraint#8 could be simplified by not requiring it again and by focusing on the type of AdjunctProperties that have CallActions as principals. Also, it should be reworded to avoid using parenthesis.

Merged with SYSML16-274

Merged with SYSML16-311 in order to provide one unique, global and consistent resolution for all the issues about constraints defined for SysML stereotypes, as far as possible.

In the current SysML specification, every constraint defined as part of a stereotype is identified by a number.

However the ownedRule property is not ordered. So this numbering does not make sense. Using meaningful names for all those constraints - just like UML does - would be more appropriate.

To be merged with the formalization of SysML constraints (SYSML16-274)

To be merged with the formalization of SysML constraint which includes adding them explicitly in the model of the SysML profile: a meaningful name will be proposed for each of those constraints.

EndPathMultiplicity constraint#2 states:

However, there is no such property defined for the EndPathMultiplicity stereotype. Obviously, the intent is to constrain EndPathMultiplicity::lower

To be merged with the formalization of SysML constraints (SYSML16-274)

To be merged with the formalization of SysML constraint which includes adding them explicitly in the model of the SysML profile

The figure 8.10 shows a compartment of the value type Complex without a compartment header. According to table 8.1, it should be labelled with "properties".

Figure 8.11 shows two blocks with a unlabelled compartment. Add the compartment header "values".

Add compartment header

Compartment should have a header like defined in table 8.1.

The diagram header should show the model element type and name.

bdd [modelLibrary] UnitAndQuantityKind [Unit and QuantityKind library]

Update diagram header of figure 8.11

The diagram header should show the model element type and name.

It seems that the SysML specification wants to exclude the usage of qualified associations. However, it only says that it does not seem to be essential to use them:

"Qualified associations, shown in SysML by an open box at the end of an association path with a property name inside, are a specialized feature of UML that specifies how a property value can represent an identifier of an associated target. This capability, while useful for data modeling, does not seem essential to accomplish any of the SysML requirements for
support of systems engineering." (8.3.1.3, SysML 1.5)

It is still unclear if qualified associations are allowed or not.

Explicitly exclude the usage of qualified associations

Qualified associations are explicitly excluded by the second sentence in clause 8.3.1.3: "Notational and metamodel support for n-ary associations and qualified associations has been excluded from SysML.".

The SysML specification excludes the usage of association arrowheads:

"The use of navigation arrowheads on an association has been simplified by excluding the case of arrowheads on both ends, and requiring that such an association always be shown without arrowheads on either end." (8.3.1.3, SysML 1.5).

However, arrowheads are commonly used in SysML modeling. There are also examples of usages in the SysML specification itself, for example, figure D.15.

Association arrowheads at both ends at the same time are forbidden

The specification only excludes the case of arrowheads at both ends of an association at the same time. The modeling scenarios mentioned by the reporter are still possible in SysML.

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

However there is no such a constraint in UML metamodel. Firstly, the concept of "block" is not part of UML, and secondly there is not even an equivalent constraint for UML::Properties typed by a UML::Class. Typing a UML::StructuredClassifier::ownedAttribute with a Class is legal

Duplicated by SYSML16-154

http://issues.omg.org/browse/SYSML16-154

Some DirectedRelationshipPropertyPath constraint definitions assume that the relationship on which this stereotype is applied is binary but there is no formal constraint enforcing it.

Defer

Postponed to the next RTF

The specification states that a binding connector can be typed.
The semantics are not clear.
The purpose of this ticket is to provide clarification of typing a binding connector.

Defer

Postponed to the next RTF

In several places of the SysML specification document the term "has been" is used. It should be replaced by "is".

Defer

Postponed to the next RTF

In http://www.omg.org/spec/SysML/20161101/SysML.xmi, some parameter directions are set to "_return" instead of "return".

Defer

Postponed to the next RTF

SysML should be based on the newest available UML specification. Current UML specification is version 2.5.1. SysML 1.5. is still based on UML 2.5.

Defer

Postponed to the next RTF

The description of stereotypes in the abstract syntax is missing all the "base_xxx" attributes that refer to the instances of extended elements. However this is required in order to specify the corresponding multiplicity and redefinition, if any.

In addition, it should also be specified whether the corresponding stereotype is "required" or not. At that time, the only way to know it is to parse the normative XMI file.

Defer

Postponed to the next RTF

Split from SYSML16-86:

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

Defer

Postponed to the next RTF

Split from SYSML16-86:

What is the type of FullPort? Spec says nothing

Defer

Postponed to the next RTF

The definition of owning block for proxy port given in the description sub-section of 9.3.2.7 FlowProperty is unclear and misleading. It should be reworded and moved to the ProxyPort description

Defer

Postponed to the next RTF

The intended use for the <<DirectedFeature>> stereotype is not at all clear from its specification in section 9.3.2.4 in SysML 1.5. To be clear, the current description describes what it is, but not why it is required, or how a modeller might use it. Moreover, it is not clear whether it specifically applies to ports (since its part of the section that specifies the language facilities for ports and flows (section 9), or whether it relates to features (properties?) of a block that are not ports.

The issue was discussed at the RTF meeting of 2017-10-12 as a result of discussing issue http://issues.omg.org/browse/SYSML16-108. There was little consensus on what DirectedFeature is, although Conrad suggested the following (being my interpretation of what was said):
A DirectedFeature of a block describes whether the block implements that feature (it's "provided") or that the feature is represents a conceptually virtualised feature as an "assumption" that something else in the model will provide it. The fulfilment of the required assumption with an actually provided realisation of that feature is by a connector between the required and the provided features.

The problem with this interpretation is that it seems to have nothing to do with ports! There is of course further scope for confusion with the UML notation of provided and required interfaces on UML ports.
At the very least, some examples that clearly illustrate what problem DirectedFeature solves and the types of model elements that it is to be applied to would help a lot.

Defer

Postponed to the next RTF

A reference property of a Block may only be typed by (i.e. "reference") another Block. There is no current mechanism for a reference property to explicitly reference a part property of a different block. See Figure D.16 for example; the PowerSubsystem Block is assumed to be referencing the part property of the BrakeSubsystem typed by BrakePedal. This is a logical conclusion since there is only one part property typed by BrakePedal, but if there were multiple part properties typed by BrakePedal, the reference property of the PowerSubsystem Block would be ambiguous.

Practical use of reference properties has consistently implied that a particular part property CAN be referenced (i.e. "a part property owned by another block"), but no mechanism for this is explicitly provided in SysML. Also, there does not appear to be any constraint on instance semantics of reference properties that might clarify this ambiguity at the instance level.

See also SYSML16-42 and SYSML16-228.

Defer

Postponed to the next RTF

Table 4.1. excludes several UML metaclasses from SysML. However, figure 4.2 shows that the SysML profile imports the whole UML. Instead, the SysML profile should use the metamodelReference and metaclassReference properties to import only the included elements.

Defer

Postponed to the next RTF

This issue is dedicated to typos and editorials we find in the SysML1.5 specification document.

Any finding has to be recorded as an annotation added to a shared PDF document available on the OMG SVN server at: http://www.omgwiki.org/repos/SysML/trunk/Documents/formal-17-05-01(annotated).pdf

>>> Note to RTF Chairs: do not schedule this issue for vote before the last ballot of the RTF <<<

Defer

Postponed to the next RTF

In SysML 1.5 pdf document ( p 147 Table 14.2- Graphical paths included in Use Case diagrams)

Latest element in the table :

• Path name: Generalization
• Concrete Syntax : ->
• Abstract Syntax Reference : UML4SysML::Kernel
  => it should be UML4SysML::Generalization

Also present in SysML 1.4 pdf version

Defer

Postponed to the next RTF

The ConnectorProperty is redundant. The same feature is provided by AdjunctProperty.

see slide 17: http://tinyurl.com/ybvdx6ew

Defer

Postponed to the next RTF

While it is not possible to check if a value conforms to, for example, uniform or mean distribution, it is possible to check, if it conforms to constraints of the specified distribution. For example, the minimum and maximum values of a uniform distribution.

Defer

Postponed to the next RTF

The DistributedProperty itself does not make sense. As specified in the specification specific distributions should be defined as subclasses of the DistributedProperty stereotype. Therefore, the stereotype should be abstract.

Defer

Postponed to the next RTF

The DistributedProperty stereotype should be abstract since it needs to be specialized in order to be usable.

Defer

Postponed to the next RTF

The first sentence of the description of the Adjunct property stereotype does not make sense:
"The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states"

Defer

Postponed to the next RTF

Typos in revised text for Annex C

• Change "C.1.1 and C.1.2" to "C.1.2 and C.1.3".

• Change "C.5 through C.7" to "C.4 through C.7".

Defer

Postponed to the next RTF

At the moment the stereotype distrubtedProperty is only allowed to be applied to properties of classifier stereotyped by Block or ValueType.
We would like to apply the distributedProperty stereotype also to properties of classifier stereotyped by Signal.
Reason: The properties of a block are transmitted by signal properties, the properties of the signal should also reflect the distribution.

Defer

Postponed to the next RTF

The usage of Generalization in SysML is a key part of establishing Domain Specific Languages and contexts for models. In particular it has great ability to establish reusability within our models. However, the only mechanism via which we can visually denote the nature of an object is via non-normative extensions to M2 via stereotypes such as <<Car>> or other examples. This is undesirable, we should have the ability (on classes and parts typed by those classes) to optionally display the General (or any General class of a Block) classifier of a Block on BDD's, IBD's and Parametric diagrams. This will, greatly enhance the readability of our diagrams, remove the complexity of implementing M2 stereotypes simply designed for visualization, and expose via the diagram usage of reusable libraries to make the foundation of our models.

Example Format might be (in ASCII art):

------------
<<Block>>
[Car]
Porsche
--------------

Defer

Postponed to the next RTF

The SysML diagram header is not easily interpreted. Suggest a new format that provides the same information and content but following the typical naming convention used in SysML - i.e. name:Type

Suggestion/Example:

From:
req [Package] Auto_Specification [Automobile System Requirements]

To:
Automobile System Requirements:req | Auto_Specification:Package

Optional format adds "[req]" as an option to turn on to in bold or white text on a black background filling the header box around the diagram kind "req" in this case. Image examples provided to Rick Steiner and Sandy Friedenthal in separate communications.

[req] Automobile System Requirements:req | Auto_Specification:Package

Defer

Postponed to the next RTF

Between SysML 1.2 and SysML 1.3, some stereotypes were deprecated
This deprecation was done by moving Stereotypes from their original package to a new "DeprecatedElements" package.

Changing the qualified names of these stereotypes may break some code in tooling. Ideally the deprecation should be indicated without changing the element.

SysML 1.3 : http://www.omg.org/spec/SysML/20120401/SysML.xmi
SysML 1.2 :http://www.omg.org/spec/SysML/20100301/SysML-profile.uml

Defer

Postponed to the next RTF