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

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

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

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

Add a section in 8.3.1.1 to describe receptions compartment

Description of receptions compartment is missing.
Insert one similar to the other descriptions of compartments

Mr. 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!

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

Might be addressed by API in SysML20.

Might be addressed by API in SysML20.
Needs to be traced to SysML20 and addressed there.

Out of scope of RTF.

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

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

Conjugation dependency proposal

The conjugation mechanism can be implemented at type level by defining a new stereotype, specialized from InterfaceBock in order to specify a conjugated type.
This conjugated InterfaceBlock definition shall have the same feature defined as the original type but – where applicable – with the inverted directions. Note that the corresponding features could be automatically computed or checked by the tool.
In the conjugated InterfaceBlock, direction of any FlowProperty or DirectedFeature is inverted (i.e. as specified for a conjugated port today)

To avoid any ambiguity or conflict the UML mechanism for port conjugation must be disabled this is achieved by adding a constraint to the SysML::Block stereotype so that all owned ports shall have their "isConjugated" property set to "false". In addition, and for consistency, the UML mechanism will be deprecated.

In order to keep an equivalent notation one can give the conjugated interface block the same name than the original type with the tilde symbol "~" prepended but it is not required by this resolution.

A migration procedure is provided for legacy models: for any port with isConjugated=true, get its type and look in the scope for an existing conjugated type. If none is found create it. Replace the port's type by that conjugated type and set its isConjugated property to false.

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"

Constraint [2] specifies that "Interface blocks cannot have composite properties that are not ports". However, in order to show FlowProperties, typed by ValueTypes and owned by InterfaceBlocks, you need to be able to have composite properties.

The constraint at the moment is too strict and needs to be changed to allow certain composite properties.

Reword constraint#2

Modify constrain#2 as suggested and in order to merge with issue SYSML16-455 as well, as part of SYSML16-274:
Revised text:
Interface blocks' composite properties are either ports, value properties or flow properties_

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

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

Proposal : remove both redundant constraints from the text.

Instance For Initial Values

Remove the following sentence in section 8.3.2.1 paragraph 11:

" The instance Specification shall be unnamed and owned by the same package that own the outermost containing block for which the initial values are being specified."

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

Clarification

§9.3.2.12 “ProxyPort”, states the following:
1. “Completely specified proxy ports must be connected to internal parts or be behavioral ”
2. “Internal connectors to ports are the ones inside the port’s owner (specifically, they are the ones that do not have a UML partwithPort on the connector end linked to the port, assuming NestedConnectorEnd is not applied to that end, or if NestedConnectorEnd is applied to that end, they are the connectors that have only ports in the property path of that end) ”
3. “When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate as if they were to those parts, and flows and invocations it receives from those parts as if they were to the outside ”
4. “This aggregate is not a separate element of the system, and only groups the internal parts for purposes of binding to the proxy port ”
YBE: according to the above, we can infer that a proxy port which is no more than an aggregate of its nested ports is “completely specified” if all its nested ports are either connected to internal part or behavioral

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

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

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

as part of the automatic generation of the document the headers will be consistent.

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.

Constraint [4] of a Block says:

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

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

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

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

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

Remove constraint [4] from the Block stereotype: Block-typed properties must be defined by an association

There is no justification for the constraint [4]. Without the constraint is still allowed to define those properties by an association, but it is not mandatory.

[4] 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.)

Removing Block constraint [4] enables more efficient implementation of applications that don't depend much on graphics, but have very large numbers of associated blocks, possibly importing from other systems.

However, in order to avoid any ambiguity, the association-like notation which was not used so far in SysML because of this constraint#4 (see SYSML16-314) need to be explicitly excluded from SysML.

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.

The UML model library "StandardProfileL2" is called "StandardProfile" since UML 2.5. The new library also include the StandardProfileL3 library.

Update the references in the SysML specification (chapter 4.2, 5.1.1, 17) and check whether SysML should also include the StandardProfileL3 stereotypes that are now part of the StandardProfile library.

SysML references to UML StandardProfile

The references to the UML StandardProfile were already fixed with SysML 1.4.

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 SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states:

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

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

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

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

Same as SYSML16-154

Duplicate SYSML16-154

Definition of a property-specific type cannot be shown on a bdd. This would require, at least, a defined name for the block or value type that types the property, such as one based on the property name.

No runtime semantics is given. Presumably all instances of a property-specific type are values of the property it types, but this isn't said anywhere. It the property it types is an end of an association, this could be expressed by a lower multiplicity greater than zero on opposite end.

No examples of property specific types are given.

CB, 2018-05-03: Address interaction with property subsetting/redefinition. For example redefinition that doesn't change the PST will cause it to be owned twice, because is repeated in the redefining property.

The requirements for property-specific types to be anonymous, singly generalized, and owned by the owner of the property they type don't appear to be necessary. Naming is useful for managing PSTs, multiple generalization is useful for reusing property defaults and other characteristics on multiple PSTs, and package ownership enables the same PST to be used on multiple properties that have the same type.

The description of the property-specific types refers to:

"local specializations of referenced typed" (Section 8.3.1.1 Block Definition Diagram) and

"starting classifier of the property-specific type." (Section 8.3.2.7 PropertySpecificType)

The terms "local", "referenced type", "starting classifier nof the property specific type" are undefined and not deducible from other text.

The following sentence is a tautology (ie, adds nothing to the spec):

"The PropertySpecificType stereotype is automatically applied to the "classifier that types a property with a propertyspecific type. (Section "8.3.2.7 PropertySpecificType)"

because a property with a property specific type is one where the property type has the PropertySpecificType applied.

Section 8.3.1.1 (Block Definition Diagram) at the end says the name of the property specific type can be included in brackets, but constraint [2] of PropertySpecificType says they are anonymous.

The discussion of compartments on internal properties in Section 8.3.1.2 (Internal Block Diagram) can be simplified by removing the discussion of property-specific types.

PST clarifications, minor corrections

The purpose of this resolution is to clarify the semantics of the PropertySpecificType stereotype and to fix minor issues with its current description

Constraint [5] states:

"A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement»."

This would seem to stop Requirements from owning Classes stereotyped by specializations of Requirements (for example, ExtendedRequirement from D.2.2 Stereotypes), which seems too limiting. I'd suggest this is reworded to:

"A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement» or one of its specializations"

Fix constraint#5

Fix constraint#5 as suggested, as part of SYSML16-274
revised text:
A nested classifier of a class stereotyped by Requirement or one of its specializations shall also be stereotyped by Requirement or one of its specializations

Remove figure numbers where they still exist within the SysML diagram frame tab. As content is reshuffled in the document, figure numbers inside the diagrams can become out-of-sync with the figure numbers in the document, as is currently the case for figures C.35 and C.37. Maintain the figure number only in the figure caption, not redundantly within the diagram itself.

Diagrams that include figure numbers in the diagram frame tab include 4.2, 4.3, 17.5, C.35, C.36, and C.37.

Remove figure numbers from diagram names

Some figure numbers in diagram names are still there in SysML 1.5, and they are out-of-sync with the numbering in the document.

To decouple them we remove all numberings from the diagrams as proposed.

The following mentioned figures are already fixed in SysML 1.5:
Figure 4.2., Figure 4.3

Figure C.35 is D.38, and C.36 is D.39 in SysML 1.5

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

Out of scope for SysML RTF

This is partially already addressed by MARTE.
Decide how to address it in MARTE2 and SysML20 and find agreement among them how to handle this features in uipcoming meetings. Also relevant for Precise Semantics of Time WG,
Trace it to those three.

Out of scope for SysML RTF.

In our discussion about SYSML16-308, Mr. 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.

In figure 9.9, the <<participant>> ends are in solid boxes. This appears to be incorrect. Please check the surrounding association class ibd's for similar problems

ParticipantProperty boxes have dashed lines

Constraint [3] of ParticipantProperty says:

[3]The aggregation of a property stereotyped by ParticipantProperty shall be none.

Table 8.2 clearly depicts that ParticipantProperty boxes have dashed lines.

There are more examples for this wrong notation in the specification:
table 9.1, table 9.2, figure 9.9, figure 9.14, figure 9.16

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

Consensus was reached in the plenary.

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

Transfer to UML: Slot defining feature

The core of the problem has its origin in the UML specification.

Parsing Text in Requirements: There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements or perhaps to a URI. This will enable one to associated additional meaning to selected portions of the text string, such as a particular value, property name, function, or some other feature. A parsed text string which can refer to other elements could be generalized to support other uses within SysML where text is used. In this sense, the proposal could treat this in another chapter such as model elements to make it more generally applicable. One possible approach is to consider a net type called "ParsedText" that has some structure to it, so that the text can be parsed and a reference can be made from the parsed text. The Requirements text property would then be typed by ParsedText instead of String as it currently is.

Duplicate of SYSML16-34

Duplicate of SYSML16-34, out of scope

Parametrics provide a powerful capability for representing constraints on properties. However, they currently do not allow a modeler to specify or notate dependent and independent parameters on a usage of a constraint property. This will enable the modeler to better express the nature of the constraint in many usage situations. The recommendation is to stereotype constraint parameters so that they can be designated as in, out, or in-out if desired. They can also be left unspecified as they are in the current parametric diagram. Proposed Solution. Add a stereotype called constraint parameter that extends property, with a stereotype property that can be in, out, in-out, or unspecified. Consider including the desctiption in the diagram extension for the parametric diagram in 10.3.1.2, adding the stereotype in 10.3.2, the diagram elements in Table 10.2, and updating the usage example in Fig 10.3.

To be traced to SysML20

More a natural evolution of the language, adding new features. Therefore out of scope for RTF.
Needs to be traced to SysML20 and addressed there.

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

Currenltly requirements are written as

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

Instead, it should be written as

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

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

<x> = 200mph.

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

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

Needs to be traced to SysML20.

MARTE currently allows to define variables in text using $ sign.

Needs to be traced to SysML20.
Out of scope for RTF

There is currently limited ability to capture datasets for selected property values. A simple example is the difficulty in capturing the time histories for the position, velocity, and acceleration properties for two different instances of a vehicle, where the vehicle is a block, and the position, velocity, and acceleration are value properties of vehicle. Another example is the need to capture data such as environmental loads data (e.g. temperature, vibration as a function of freq) which is referenced as part of a requirement.

*new feature *

to be transferred to SysML v2

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

There is a typo in the xmi file for ElementGroup orderedMember

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

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

Fix the typo in the source model

Fix the typo in the source model so that the SysML::ElementGroup::orderedMember feature is correctly spelled.

Note that, as a consequence, its xmi:id will change as well.

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.

There is a critical need to model off nominal conditions and behavior associated with faults, failures, and hazards. However, there currently is no standard way to represent this in the SysML model. This issue is intended to provide some lightweight and standardized and light-weight capability for this type of modeling, such as a trigger on a state machine with the stereotype failure or a fault stereotype to represent a fault condition. There is a separate profile (not standardized) that was developed by Bruce Powell Douglass that provides a broader more comprehensive capability that could be leveraged as source material.

Out of scope

Architecture of SysML20 will address if libraries will be a concept supported by it.
Such a library/profile is a perfect candidate for SysML20.
Although closer to Systems Engineering, it might also be a candidate for UML.

Trace it to SysML20.

The Specification says

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

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

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

Clarification of binding connector

see SYSML16-319

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

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

Constant Block value properties

A constant block value property is modeled by defining a default value and setting isReadOnly to true.

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

Clarify the description of FlowProperty direction

The current description use the term of "block" incorrectly which lead in sentences which do not make sense when attempting to deal with nested port and multiple-level structures.

We need to make a clear distinction between a block, which defines characteristics of a type, and an instance which may hold and exchanges values, as specified by a type that classify it.

The generalization of model elements, e.g. blocks, does only affect the instances (from Generalization definition: Each instance of the specific classifier is also an indirect instance of the general classifier.). Doesn't that mean that stereotypes of a block and it's properties are not inherited by sub-blocks? If yes all informations about flow ports, units and so on get lost. They are not inherited by the sub-blocks.

Generalization of stereotyped elements

Comment from Conrad Bock:

Inheritance doesn't mean features appear on specializations, it just means instances of those specialization support those features. This means stereotyped features are still stereotyped after "inheritance", because nothing actually happens in the model due to inheritance. Tools show inherited features for convenience. Redefinition does change the model in specializations, and as I understand it, redefining features (in specializations) need to have stereotype reapplied unfortunately. Same for subsetting features.

Discussed during RTF meeting and decided to closed; no change.

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

An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
Some of the limitations that have been identified include the following:
a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)
The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint.
b) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
c) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
d) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is described below.
In a simple example, different subviews may correspond to different sections of a document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata ).
In this example, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
e) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.
f) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.
g) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

View and Viewpoint for auto-view generation

The View and Viewpoint elements were changed with SysML 1.4 to address the points mentioned in the issue.

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

Merge with: "Change keyword of binding connector from "equal" to "=""

see discussion in comment section

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

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

Duplicate of SYSML16-389

The issue is a duplicate of SYSML16-389

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

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

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

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

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

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

Contraint relaxed concerning nestedConnectorEnds

This is described in SysML 1.5 so no change is required:
8.3.2.4 Block
[9]The following constraint under 9.3.7, “ConnectorEnd” in the UML 2 standard is removed by SysML: “[3] The property held in self.partWithPort must [sic] not be a Port.”

Numbers of cleanups were identified in the SysML 1.4 specification document but we were unable to make them on time.

Same as SYSML16-344

To be merged with SYSML16-344

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

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

ParticipantProperty keyword

Considering the pattern has been broken upstream, defer to UML.

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

Need to have an explicit way to bind flow properties or atomic flow ports to block properties. Currently section 9.3.2.3 lacks such rules. Such rules would allow a consistent way to relay data via flow ports to the properties of blocks and also would allow a convenient way to transmit values via flow port by changing a value of a property owned by the block.

Merged with SYSML16-50

Can be merged with SYSML16-50

Section 8.3.1.3 (UML Diagram Elements
not Included in SysML Block Definition
Diagrams) says "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." An intermediate
block cannot capture multiplicities that
would be on an the ends of an n-ary
association. These multiplicities are
for the links from end to end, rather
than from intermediate object to end, as
they would be with an intermediate
object. However, intermediate blocks
can specify the number of links each end
might participate in for any of the
other n-1 ends, which is not possible
with n-ary associations. The
expressiveness of n-aries and
intermediate blocks is overlapping,
rather than equivalent.