Please clarify what is the significance of Directed on the composition line. In the section 8.4.5, the directed line is used, whereas in other sections the direction is not used e.g. in section 11.3.1.1.1.
Also I referenced in SysML 2.0 beta and I could see directed composition in one of the example. If there is no significance, will it be removed in SysML 2.0?

Metadata attributes

1) category. Refers to DCMI abstract which isn't a category
2) dublinCoreTag refers to 'A metadata category that is a DublinCore tag.' This doesn't define anything. Any DCMI tag? Not all CMI tags are categories. Why not simply list those DCMI tags that you think are essential / useful rather than what looks to be an arbitrary and inconsistent reference?
3) Metadata is defined as 'a conment that can be applied to any element in the architecture'. This is incorrect - it can be applied to any AD element. The DCMI tags only apply to artefacts - video, text, sound, document etc so they don't apply to every AD element as many/most of these do not represent artefacts. DCMI tags only apply to documents, standards etc.

This is a consequence of the lack of differentiation within the UAF (and donor AFs) between 'Architecture' and 'Architecture Description'

Fig 9:122 Metadata.
Definition: 'A comment that can be applied to any element in the architecture. The attributes associated with this element details the relationship between the element and its related dublinCoreElement, metaDataScheme, category and name. This allows the element to be referenced using the Semantic Web.'

it is clear that this refers to 'architecture description' not 'architecture' e.g. the application of DCMI elements

It should therefore be 'applied to any element in the architecture description'

If Metadata is already defined as applying to an architecture description, how can ArchitectureMetadata specialise this and also be applied to the architecture description description - this is what Metadata does and as part of an AD which describes an architecture there is no need for 'ArchitectureMetadata'?

8.1.2 View Specifications::Summary & Overview::Summary & Overview

General problem - there is no such thing as 'view specification' - it doesn't exist in the DMM itself (text should only include defined concepts), it seems to be being used as a synonym for ISO 42010::'architecture viewpoint' (if this is the case then 'architecture viewpoint' is the correct and consistent term to use.

Concerns: ''quick overview of an architecture description and summary of analysis. In the initial phases of architecture development, it serves as a planning guide. Upon completion of an architecture, it provides a summary of findings, and any conducted analysis.'

Problems -
1) this is an overview and its application not a list of concerns held be stakeholders
2) Given the common confusion in the UAF between 'architecture' and 'architecture description' - is this 'phases of architecture development' or 'phases of architecture description development'? Since an architecture description may be used to provide comment on architecture this is ambiguous in the UAF contetx where these terms aren't differentiated.
3) 'It isn't completion of architecture - it's not even completion pf 'architecture description' - what the author seems to be stating is completion of the 'architecture task' that produce the architecture description. The description os wrong and possibly more triples need to be defined in the DMM

Defintion
'provides executive-level summary information in a consistent form that allows quick reference and comparison among architectures. The Summary and Overview includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture.'

Problems;
4) This is a description not a definition

Figure 8:11 - Summary & Overview

The green elements are relationships - not tuples as defined in the legend. The expectation is that view content consists of triples (node-connector-node).
5) General problem - There is nothing that defines how these views are to be interpreted (ISO 42010 requires this and it would aid consistent development and provide rules for verification of each view).

Anything that doesn't form the basis for a triple shouldn't be in the viewpoint definition i.e.

6) ArchitecturalDescription, ArchitectureMetadata, Metadata as these don't appear to form any triple

7) View, Viewpoint. There are no relationship elements provided to form a triple with ArchitecturalDescription

8) Stakeholder, Concern, OrganizationalResource, ActualOrganizationalResource have no relationship with ArchitecturalDescription

9) There is no relationship element between ArchitecturalReference and Architecture so it is impossible to establish a link between the Architecture, its impacts etc and the ArchitecturalDescription so impossible to describe this.

Triples should be able to be read as sentences and have clear semantics:

'ArchitecturalDescription Architectural Reference Architectural Description'
10) What does this mean? Is this a trace between ArchitecturalDescriptions i.e. 'ArchitecturalDescription traces to / references / etc ArchitecturalDescription'. A currently defined this makes no sense. I suspect that the problem is that elements are added but the triples so-formed are not being read to make sure that they are intelligible i.e. object-focussed rather than relationship-focussed approach.

11) 'Opportunity Phases ActualStrategicPhase' - what does this mean? If the sentence is unclear it either won't be used or be used inconsistently as each individual attempts to try and understand it (not conducive to shared understanding)

Figure 9:134 – UAFElement shows a single attribute - URI

Don't UAFElements have a name, identifier (other than URI), description etc? According to this they don't.

URI is incorrectly defined - 'Captures Unique identifier for the element.'

assuming that URI = Unifiform Resource Identifier - which a url-form of identifier (W3C define this so the definition ought to be standards-based rather than local). It isn't just an identifier. 'captures' shouldn't be part of the definition - that's how the attribute is used.

Within the document there appears to be no usable link or definition of Satisy [another implementation artefact] and no definition of a Requirement element or other relationships linked to Requirement (Trace, Verify, Refine).

Figure 8:86 multiplicities don't look to be consistent - 0..1 on Trace but 1 on Satisfy. Trace looks to be wrong - think someone trying to describe Requirement traces to Requirement, UAFELement traces to UAFElement and UAFElement traces to Requirement but there is no identification of path and its ambigous or wrong.

Why is Requirement not a UAF Element? If it's not why is it even in this specification? Again I suspect this is an implementation artefact - someone thinking of a SysML::Requirement (which is an implementation of the DMM)

Inconsistent name wrt ISO 42010 and with its own definition - ArchitecturalDescription vs Architecture Description.

The multiplicities aren't correct. For example we have on Architecture to ArchitecturalDescription we have * on both ends which means that an Architecture has no existance independently of its ArchitectureDescriptions (plural as there have to be many of them). Should be 0..* on ArchitecturalDescription. Similarly with View it ought to be 1..* View and 0..* Viewpoint (otherwise an ArchitecturalDescription is required to include multiple Viewpoints which doesn't allow for a central set of 'library' viewpoints in ISO 42010 terminology).

The relationships with View, Viewpoint, Architecture need to be named.

'expresses' looks like a role but cannot be. If it is a role it needs to qualify the target element e.g. 'describedArchitecture' not the relationship.

Why does ArchitectureMetadata have a multiplicity of 1 on ArchitecturalDescription - is each piece of metadata unique to every ArchitecturalDescription?

What is an ArchitecturalReference? This looks like a relationship. What then is the point of adding a role name to a relationship? Isn't this just 'UAFElement traces to ArchitecturalDescription?

The use of a '*' multiplicity is incorrect - should be 1 or more Concerns. Similarly an ArchitecturalDescription (name error - should be ArchitectureDescription) should be composed of 1 or more Architecture Views (not *). A Viewpoint may frame only 1 Concern (not *)

The use of a direction indicator is undefined and looks to be incorrect. In the direction from View to Viewpoint what is the relationship? In ISO 42010 there is a 'governs' relationship.

The use solely of role names is incorrect - roles only label the target (source) node - they do not define a relationship. How is anyone supposed to implement a set or relationships where the relationships are not labelled? Figure 8:2 should use the relationship names defined in 42010 i.e. standardise.

Using a role name that simply repeats the name of the source / target element is pointless - it adds no information whatsoever. The other problem with solely using role names is that if the label is offset it isn't clear whether it is a role or a relationship name and therefore whether it applies to the node or relationship.

The use of a '*' multiplicity is incorrect - should be 1 or more Concerns. Similarly an ArchitecturalDescription (name error - should be ArchitectureDescription) should be composed of 1 or more Architecture Views (not *). A Viewpoint may frame only 1 Concern (not *)

The use of a direction indicator is undefined and looks to be incorrect. In the direction from View to Viewpoint what is the relationship? In ISO 42010 there is a 'governs' relationship.

The use solely of role names is incorrect - roles only label the target (source) node - they do not define a relationship. How is anyone supposed to implement a set or relationships where the relationships are not labelled? Figure 8:2 should use the relationship names defined in 42010 i.e. standardise.

Using a role name that simply repeats the name of the source / target element is pointless - it adds no information whatsoever. The other problem with solely using role names is that if the label is offset it isn't clear whether it is a role or a relationship name and therefore whether it applies to the node or relationship.

incorrect identifiers for OMG documents

1. 'The UAF Domain Metamodel (DMM) (this document dtc/21-12-06)' - incorrect - should be - formal/22-07-03
2. 'The UAF Modeling Language (UAFML) (document dtc/21-12-07)' - incorrect - should be - formal/22-07-05
3. 'The UAF Traceability, Appendix A (document dtc/21-12-10)' - incorrect - should be - formal/22-07-07

Errors also in Table 1-1 Table of Related Documents

In 3.2.1, the statement "11 Activities - Defines the extensions to UML 2 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams. The activity diagram is used to describe the slow of control and flow of inputs and outputs among actions." mentions "slow of control".
It should have been "flow of control".

After correction, it shall be,
"11 Activities - Defines the extensions to UML 2 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams. The activity diagram is used to describe the flow of control and flow of inputs and outputs among actions."

The first row of Table 8-4 shows element InternalBlockDiagram - for a connector whose Abstract Syntax ref is UML4SysML::Dependency.

This is incorrect - it should be a Dependency connector element - identical to first row in Table 8-2

A Conform relationship is a generalization between a view and a viewpoint.

This is semantically incorrect. Assuming that viewpoint is being used in ISO 42010 sense (no stated anywhere within the specification so this is an error if true as the common use of 'viewpoint' is not the same as that in the standard) - a viewpoint is a specification against which a view is prepared (and interpreted). A view is not a viewpoint. What's has effectively been said is that a design that conforms to a requirement document is a requirement document.

In the reverse sense if I want to define that an oak (tree) is an oak I wouldn't then state an Oak (tree) conforms to a Tree.

If you need to state the conformance relationship between view and viewpoint SysML provides somewhere a 'satisfy' stereotype.

The history of the OMG misrepresenting or misunderstanding what a 42010::viewpoint is in their documents over the years is woeful.

The View conform Viewpoint relationship is shown as a Generalization. This then states that a View is a Viewpoint which is incorrect. A Viewpoint in ISO/IEC/IEEE 42010 terms is a specification against which a View is prepared and interpreted.

I suspect that this is another example of a long held error where View was described as an instance of a Viewpoint. It isn’t. This has never been true in the international standard.

the statement from v. 1.5 (section A.2)

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.

was removed from 1.6... but 1.6 retained Artifact in its UML4SYSML set...

I think, either remove Artifact or put the statement back in

In Table 4.2 UML::Artifact is defined as excluded.

In previous versions there was a paragraph Figure A.4 - 'SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. '

This, whilst contradicting the exclusion of Artifact from SysML did at least define how artifacts/documents were to be represented. Now there is absolutely nothing other than we can't use Artifact.

How are we supposed to represent a document? As there are few to no specialisation hierarchies in the specification it's almost impossible to see the thinking and, say, where / how deployedDocument fits into a taxonomy.

I'm trying to create a SysML profile and I need to represent a Document, Standard, Contract etc - all artifacts in the UML sense but no idea what I should now be using in a SysML profile.

The verifyMethod, source and risk attributes are only available for extended requirements i.e. a straight vanilla Requirement has no associated verification method or risk. This doesn't reflect reality / the actual taxonomy and has nothing to do with the sub-classification of a requirement as physical, functional etc. i.e. these are attributes of the parent Requirement not the child extended requirement. It also then requires that a SE has to subclassify before they can ascribe a risk level or verification method.

Even looking at the definiton of extendedRequirements this definition has nothing to do differentiation in terms of an ontology - only the means to do things. 'A mix-in stereotype that contains generally useful attributes for requirements'

It also means that if the SE has a requirement that doesn't fit into the OMG classification schema i.e. none of the existing categories then they cannot easily assign these attributes (e.g. a requirement to conform to a standard isn't a design constraint, isn't functional etc). These common attributes should be present without forcing the SE to subclassify before they are available.

I found a bunch of issues, mostly unresolved references, in the SysML 1.7 XMI files.

1) In SysML.xmi:

• the reference "http://www.omg.org/spec/UML/20161101/UML.xmi#UML" should be "https://www.omg.org/spec/UML/20161101/UML.xmi#_0" (actually, the first metamodel reference is duplicated and can be removed)
• the reference "http://www.omg.org/spec/UML/20161101/StandardProfile.xmi#StandardProfile" should be "https://www.omg.org/spec/UML/20161101/StandardProfile.xmi#_0"
• many (if not all) references to UML elements can't be resolved, as the ID portions of the HREFs are improperly prefixed with "UML.". References starting with "http://www.omg.org/spec/UML/20161101/UML.xmi#UML." should instead start with "https://www.omg.org/spec/UML/20161101/UML.xmi#"
• similarly, references starting with "http://www.omg.org/spec/UML/20161101/StandardProfile.xmi#StandardProfile." should instead start with "https://www.omg.org/spec/UML/20161101/StandardProfile.xmi#"
• the reference "http://www.eclipse.org/uml2/4.2.0/JavaPrimitiveTypes#double" should be "https://www.omg.org/spec/UML/20161101/PrimitiveTypes.xmi#Real"
• the SysML profile URI (i.e. namespace) is "https://www.omg.org/spec/SysML/20220801/SysML.xmi", which is the profile URL. While this is legal, URIs and URLs are typically different for a given spec (see UML and previous SysML), so I'm not sure this change of practice was intended.

2) In QUDV.xmi:

• the import of http://www.eclipse.org/uml2/4.2.0/JavaPrimitiveTypes#_0 should be removed

3) In ISO8000.xmi (which should be ISO80000.xmi):

• the reference http://www.omg.org/spec/UML/20161101/StandardProfile.xmi#_19_0_126503b7_1551253025717_66684_4668 should be (I assume) https://www.omg.org/spec/UML/20161101/StandardProfile.xmi#_0
• the reference https://www.omg.org/spec/SysML/20220801/SysML.xmi#_19_0_4_3c00182_1656609128202_353595_374 should be (I assume) https://www.omg.org/spec/SysML/20220801/SysML.xmi#SysML_dataType.Integer
• the reference https://www.omg.org/spec/SysML/20220801/SysML.xmi#_19_0_4_3c00182_1656609128517_84542_524 should be (I assume) https://www.omg.org/spec/SysML/20220801/SysML.xmi#SysML_dataType.Real
• the reference https://www.omg.org/spec/SysML/20220801/SysML.xmi#_19_0_4_3c00182_1614268874904_58951_5 should be https://www.omg.org/spec/SysML/20220801/SysML.xmi#SysML
• all the idrefs starting with "ISO-80000" should instead start with "ISO80000"
• the idref "ISO80000.ISO80000-7Light.Quantities.refractiveindex.refractiveindex" can't be resolved. There should be (I assume) an instance spec typed by QuantityKind in the "ISO80000.ISO80000-7Light.Quantities.refractiveindex" package

Note: I've been using HTTPS links for URLs, since HTTP links are no longer accessible using the browser and are not the official URLs defined in the UML spec... although they are used in the UML and SysML 1.6 XMI.

Duplicate of SYSML17-222 for which the resolution does not resolve anything!

The specification says:

Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic.

However, the UML says in clause 15.6.3.1 (which is the current number of the referenced section):

Behaviors invoked within the partition are the responsibility of instances of the Classifier that the partition represents.

Let me paraphrase this:
SysML: "UML says Classifiers are responsible for invoking behaviors"
UML: "Classifiers are responsible for behaviors"

I guess invoking a behavior was confused with carrying out a behavior.

My suggestion: It is not necessary to restate UML semantics in SysML. Since it cannot be expressed in ocl anyway, the complete constraint can be removed.

The specification says:

Contraints 2_not_uml_semantics [...]. Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic.

This is not what UML specifies. Instead it says in "ActivityPartition", Semantics topic:

Behaviors invoked within the partition are the responsibility of instances of the Classifier that the partition represents.

That means, the instances of the represented element are responsible for carrying out the Behavior, not for invoking it. The context of the Activity owning the action is doing that - partitions have no effect on this.

The redefinition of Unit::quantityKind property by PrefixeUnit::noQuantityKind with multiplicity 0 is wrong.

The ConversionBasedUnit class should redefine quantityKind so that it is derived from the one defined by its referenceUnit.

Add UML::BehavioralFeature (UML::Operation or UML::SignalReception) to the allowed list of UML metaclasses of SysML::AdjunctProperty.principal, thus allowing a visual symbol (association) as well as fUML implementable way of accessing runtime instances of these behaviors through the structures that have them as their context. You could add them to the same constraint as CallAction, using the UML::BehavioralFeature.method as the constraining metaproperty . Also add an “or” to the constraint to allow SignalReception to get to it’s Signal metaproperty instead, or just create a new constraint separate for SignalReceptions.

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

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

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

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

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

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

The port on the ecu:PowerControlUnit of type ~ICE that links to the InternalCombustionEngine should be named "ice", not "ctrl", in order to match the text description of the figure.

Why can I not create something that requires a flow of
fuel to operate?... this would require me to do something
like

flow properties
reqd out gas:Gasoline

Why would we exclude this?

2_specializations_are_constraintblocks in FeatureDirectionKind should belong to 10.3.2.1 ConstraintBlock。

2_no_part Interface blocks composite properties are either ports, value properties or flow properties.
self.base_Class.ownedAttribute->select(a|a.isComposite)->forAll(a | a.oclIsKindOf(UML::Port) or a.oclIsKindOf(ValueType))

This OCL does not cover all of FlowProperties... FlowProperties can be typed by ValueTypes, Signals, or Blocks... so it does not cover Signals or Blocks (so presumably Signal and Block typed FlowProperties can only be aggregates, which I think is wrong)

Presumably, an AggregationKind=shared of FlowProperties means that the block does not own the Flow but has a reference to that flow... (this is not really specified well or talked about in the standard)...

But the issue is that if you want a FlowProperty that is typed by Block or Signal... you can not because of this OCL... it has to be a ValueType... I think this is wrong

The SysML specification says (section 11.3.2.4, description sub-clause):
"tokens arriving at the node are discarded if they are refused by outgoing edges"

But the condition fro considering that a token is "refused" is specified neither in that specification nor in the UML specification.

Proposal:
Assume that a token is refused when its availability has been checked by an action that has an edge incoming from the node where this token is stored but not accepted by this action, whatever the reason.

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

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

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

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

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

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

If it is correct, that Rate extends ObjectNode:

• Add extension in figure 11.8.
• Provide semantic

If it is not correct:

• Remove extension from XMI and association ends section
• Remove concrete syntax from diagram table

SYSML14-36 removed the attribute primaryQuantityKind. In Figures E.8 - E.10 it is still shown. Additionally there is a constraint that uses it: SystemofUnits constraint 1 on page 296.

Discussed by the RTF on Sep 9, 2021:

The notation showing UML4SYSML as the namespace of metaclasses imported from UML does not conform to the UML definition of a qualified name.

The simple name of the metaclasses shall be used instead

This has already been an issue of the first version and is marked as beeing resolved in SYSML-112. I checked all versions and found it everywhere. Obviously the change was forgotten.

It also affects table 11.1 on page 133 which shows "rate=constant, rate=distribution". While you can argue, that these are just names of InstanceSpecifications, the names suggest that they are meant to be values with this non existing stereotype. I think they should be changed to a rate value like "10/s". This table is also subject to changes in SYSML17-270. These changes should be coordinated.

The Statemachine ReadAmountSM is shown with an EndState on its border. This is not possible. The diagram is a partial copy of figure 14.13 in the UML-specification, where it is an exitPoint Pseudostate.

Connector properties must be composite (there is a constraint) and therefore are to be shown in the "parts" compartment. In table 8.2 they are shown in the "references" compartment.

If you have multiple nested ports and one is a behavioral port... does that mean that all the path of ports is behavioral?... the standard should have some statement concerning this

There are issues in the referenced sections

In table 7-2 the circle plus notation is noted as referencing the abstract syntax UML4SysML::Package::ownedElement. Actually, according to the UML specification, it refers to Package::member. Conformant tools can optionally limit it to packagedElements, which is a subset of ownedMember. This excludes comments,which could be ownedElements but not ownedMembers.

There is the fact that a Trigger can define a port (or nested ports in SysML)... Activities add the ability to do Call/Sends using "via <port>" (and SysML adds in how to do it with nested ports)... there is nothing in StateMachines that allow Effects to be sent through specific ports... this needs to be added in for consistency

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

and the fact that if you can navigate to something you also own it in SysML... then one can derive a rule...

"if it does not have a navigation on the end, it can not be named"

context: Association
inv: memberEnd→ forAll(m |  a.navigableOwnedEnd.excludes(m) implies m.name = null)

I think this needs to be in the Standard

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

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

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

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

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

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

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

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

see at https://material.elparazim.com/gap%20for%20Flows%20and%20Behavior.pdf

The two pins are not named... so there is no standard way of defining which is the before pin and which is the after.... would suggest you standardize the names "before" and "after"

The extensions for SysML are of value to the general community, however, because they are not delivered in a machine readable and refrencable way, they cannot be used as a basis either for making normative to another specification and/or extended by another specification. There are issues as well for model interchange because of the lack of a normative form.

It is suggested that SysML specification change the extensions to normative but optional profile and to further describe a compliance in which if the non-normative extensions are used, the whole profile shall be used and only changed by extension of that profile. There should also be recommendations for migrating from vendor implementation of extensions to the new normative version.

The reason for this request is that the CubeSat System Reference Mode Profile (CSRM Profile)l used the non-normative extensions as a basis to further extend into the CubeSat domain. Unfortunately the use of the vendor supplied extensions were not from a compliant profile. The CSRM Profile team was forced to copy the extensions into the CSRM Profile in order to extend and use the extensions. This creates the danger that the CSRM Profile adds copies of the extension into a vendor's SysML implementation implementation and can cause interoperability issues.

At this time, the CSRM Profile is pre-finalization and we could convert to a compliant version rather than the copy of the extensions we created. We would like this treated as a priority fix to allow for the creation of an XMI for refere3nce by our specification.

this
[1] The query accessibleQuantityKinds() gives all the QuantityKinds directly defined in the SystemOfQuantities or transitively in any included or used SystemOfQuantities.
allAccessibleQuantityKinds() : QuantityKind[0..*]

body: allAccessibleSystemOfQuantities()>collect(quantityKind)>flatten()->asSet() inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

should be under SystemOfQuanties

getKindOfQuantitiesForMeasurementUnit should be renamed getQuantityKindsForMeasurementUnit

inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

this statement

includedSystemOfUnits: SystemOfUnits[0..*] Including a SystemOfQuantities means including all of the QuantityKind it defines and includes from other SystemOfQuantities

should reflect Units rather than SystemOfQuantities

OCL with SpecializedQuantityKind needs to be changed

UML::Behavior.allInstances()>forAll(b | not (ControlOperator.allInstances().base_Behavior>includes(b) xor b.ownedParameter >exists(p | p.type=SysML::Libraries::ControlValues::ControlValue))) and UML::Operation.allInstances()>forAll(o | not (ControlOperator.allInstances().base_Operation->includes(o) xor o.ownedParameter ->exists(p | p.type=SysML::Libraries::ControlValues::ControlValue)))

TO

UML::Behavior.allInstances()>forAll(b | not (ControlOperator.allInstances().base_Behavior>includes(b) xor b.ownedParameter >exists(p | p.type=SysML::Libraries::ControlValues::ControlValueKind))) and UML::Operation.allInstances()>forAll(o | not (ControlOperator.allInstances().base_Operation->includes(o) xor o.ownedParameter ->exists(p | p.type=SysML::Libraries::ControlValues::ControlValueKind)))

Changes to Annex D sample problem model (since SysML1.6) may impact on some spec body figures. Possibly impacted diagrams include:

Figure 8-12 - Block diagram for the Wheel Package (WheelHubAssembly)

Figure 8-13: Internal Block Diagram for WheelHubAssembly

Figure 8-15: Vehicle decomposition

Figure 8-16: Vehicle internal structure (BoundReference example)

Figure 8-17: Vehicle specialization

Figure 9-6: Usage example of ports with provided and required features

Figure 11-11: Continuous system example

Figure 11-13: Example block definition diagram for activity decomposition

Figure 11-14: Example block definition diagram for object node types

Figure 15-9: Allocation Matrix showing Allocation for Hybrid SUV Accelerate Example

Figure 16-2: Requirements Derivation

Figure 16-3: Links between requirements and design

Figure 16.4: Requirement satisfaction in an internal block diagram

Figure 16-5: Use of the copy dependency to facilitate reuse

Figure 16-6: Linkage of a Test Case to a requirement (and Figure 16-7)

In some cases this may also impact text that refers to these examples.

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

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

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

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

allAccessibleQuantityKinds() : QuantityKind[0..*]

body: allAccessibleSystemOfQuantities()>collect(quantityKind)>flatten()->asSet() inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

notice the "in ->allUnits()" ... something wrong here

The operation SystemOfUnits::isCoherent() and the figure E.8 uses a property "primaryQuantityKind" which is not defined in E.5.

Section §2 of the SysML specification should mention the URI of all the models (normative and non-normative) that are produced as part of a SysML version (i.e. those for which the URL is given on the front page)

SysML already has the capability to list :features (such as :values, :operations etc.) in compartments on Property and Port symbols in IBDs.

The same capability could be introduced for Pin symbols in Activity Diagrams to reveal :features of the types of Pins.

UML2.5.1 describes also an elided Pin notation where a single rectangular "ObjectNode" symbol along with two arrows (not edges) represents two Pins of identical type and a single ObjectFlow edge (in the underlying model). This notation does not have good support in all tools. It could however also benefit from the ability to list :features on that "ObjectNode" symbol (where the type is the type of the 2 Pins it actually represents).

This ticket is a re-imagining of (partial resurrection of) a proposal from Michael Chonoles that I strongly supported:

https://issues.omg.org/browse/SYSML17-103

https://issues.omg.org/browse/SYSML17-208

If the RTF chairs truly consider any new features out-of-scope this can be bumped to SysMLv2, but as Conrad wrote under SYSML17-208:

I think SysML 1.x should address this. It will be a long time before SysML2 is a finalized OMG spec. We should be supporting modelers in the meantime with small upgrades like this.

SysML already has the capability to list :features (such as :values, :operations etc.) in compartments on Property and Port symbols in IBDs. Indeed, this notation has proved one of the most popular advantages of SysML over UML.

The same capability could be introduced for ItemFlows, which could be extended to optionally support representation as a rectangle symbol on Connectors lines and Associations lines (or wherever ItemFlows may be shown), with compartments for listing :features.

In the case where the ItemFlow does not have an itemProperty, the rectangle could appear much like a Block symbol (but over a relevant line).

In the case where the ItemFlow has an itemProperty, the rectangle could appear much like a Property symbol (but over a relevant line).

In both cases the header of the rectangle could show the direction arrow for the ItemFlow.

In both cases the ability to display defaults for value properties would be extremely useful.

(Variations on the notation would have to cope with situations where there is more than one applied ItemFlow.)

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

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

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

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

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

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

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

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

DK

The body conditions of the QUDV operations in section E.5.2 are not specified as Boolean expressions. They specify only the computation of the return value.

If the return parameter is named "result" they should be stated as

result = <computation of return value>

QUDV::PrefixedUnit redefines quantityKind to set the multiplicity to 0:

noQuantityKind : QuantityKind [0]

It would be better to define a constraint instead:
self.quantityKind = null

The property noQuantityKind is specified in the XMI, but not mentioned in the PDF.

Figure E-7: QUDV QuantityKinds has the following issues:

• Should be a bdd instead of pkg
• Remove diagram number and icon from header
• Remove owner from blocks
• Association between Dimension and SystemOfQuantities: Multiplicity end systemOfQuantities is 1..* in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
• Association between QuantityKind and QuantityKindFactor: Multiplicity end quantityKind is 1 in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
• Association between DerivedQuantityKind and QuantityKindFactor: Multiplicity end DerivedQuantityKind is 1 in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.

I agree with this that this should be the intent... "Within an instance of a SysML Block, the instances of properties with composite aggregation shall form an acyclic graph"... but I believe the OCL statement restricts the types and not the instances... I will give an example... it should restrict an instance from being a part of itself... but is should not restrict a Type having a part of the same type (which I believe this does)... take for example something that says System has a composition to itself whose navigation end is named "subSystem"... this says that a System can contain other Systems as a part "subsystem"... this should be legal... but a system1:System cannot contain itself as a subsystem of itself... that should be illegal... I believe that your constraint, constrains the Type (which it should not) and therefore the instance... but it should only constrain the instance and not the type...

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

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

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

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

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

orderedMember in ElementGroup should be

The pattern used through out the standard is with an Association End so Attribute base_NamedElement should be an association end and not an attribute

The Description for getSatisfies should be similar to that of getVerifies

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

The parameter names in the signature of that operation are "p1" and "p2" respectively while "a1" and "a2" are used in the statement of the body condition

Spawned from SYSML17-31 to help support comparisons for BindingConnector.

Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison)

A compatible Unit is any Unit that has the same fundamental Dimensions as the Unit of the value property for which the magnitude is to be obtained. It need not be (but typically would be) from the same Unit system.

[EDIT: See attached Wolfram Mathematica example with CompatibleUnitQ example]

Equality of values of value properties at the ends of a BindingConnector can be compared via the proposed operation:

• The case where the two value properties have the same Unit from the same system is trivial.

• In the case where the two value properties have compatible Units (same fundamental Dimensions) from the same system but different scaling factors (say g vs kg), a simple scaling must be performed.

• In the case where the two value properties have compatible Units (same fundamental Dimensions) from different systems (say ft vs km), a conversion and possibly also a scaling must be performed.

This proposal does not restrict tools to use any particular choice of Unit when performing equality comparisons.

This proposal specifically only supports comparison of values of value properties with compatible fundamental Dimensions, but does not involve quantity kind.

Although the name of the constraint 6_valueproperties_composite suggests it is only intended for value properties, the text and OCL of the constraint imply that a FlowProperty typed by a ValueType should also have AggregationKind composite:

‘If a property owned by a SysML Block or SysML ValueType is typed by a SysML ValueType, then the aggregation attribute of the property shall be "composite."’

self.base_Class.ownedAttribute->select(a| ValueType.allInstances().base_DataType ->includes(a.type))->forAll(a|a.isComposite())

Note also that the following specification text on p.53 under 8.3.2.4 Block if taken literally would mean that any FlowProperty typed by a ValueType is a value property:

'A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.'

From SysML-1.6 8.3.1.2.1 Property types p.43 :

'Four general categories of properties of blocks are recognized in SysML: parts, references, value properties, and constraint properties. (See 8.3.2.4 for definitions of these property types.)'

Elsewhere 'parts' and 'references' are described as being typed by Blocks, but a FlowProperty typed by a Block is not typically listed in the corresponding compartments.

A FlowProperty need not be typed by a ValueType, and is not typically understood to be a value property so is not covered by 'value properties' (see however SYSML17-399).

The same issue arises on p.53 under 8.3.2.4 Block:

SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType. A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. Constraint properties are further defined in Clause 10. A port is another category of property, as further defined in Section 9. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. Part, reference, value, and constraint properties may be shown in block definition compartments with the labels "parts," "references," "values," and "constraints" respectively. Properties of any type may be shown in a "properties" compartment or in additional compartments with user-defined labels.

Because FlowProperty can be typed by ValueType, Block or Signal it is not covered well by the above; every attempt to handle the cases applied to any of the above results in "definition whack-a-mole"

p.99

2_no_part

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

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

EDIT: Needs to also check whether is a FlowProperty of a valid type other than ValueType, noting from SysML-1.6 FlowProperty:

'1_restricted_types A FlowProperty shall be typed by a ValueType, Block, or Signal.'

The Standard is not clear about compartments for Connectors and Participants... it is presumed that since Connectors has a OwnedConnectors in the metamodel in UML... that a "connectors" compartment is implied (but the standard should probably state as much to make sure tools are consistent)... there could also be a <<connector>> compartment according to the standard... so this needs to be consistent... there is nothing about Participants... so presumably they go into "properties" compartment... or a <<participants>> compartment... they are could be references (because they are composite) but one may not want to mix them in with references (I would not want to, but the standard may want to grant a compartment called "participants" for the purpose)

This issue report illustrates two separate (but apparently related) issues:

DISCLAIMER: The example shown for modelling an electronics jack or socket in electronics is not an approach advocated by this reporter. It is however a frequently used or attempted approach.

Primary issue: When a BindingConnector used to indicate pure proxying is typed by an AssociationBlock, the AssociationBlock can be used to undermine the claimed equality of the proxy, at least when nested Ports are involved.

In the attached example, the L and R channels of a stereo system have been swapped by the AssociationBlock (which swapping is invisible at the level of the BindingConnector it types).

It is proposed that constraint(s) be introduced for BindingConnector and/or AssociationBlocks, along with improved explanations for ParticipantProperty, to prevent the typing of BindingConnectors by AssociationBlocks used for pure proxying.

(AssociationBlocks are otherwise very useful, it is not suggested here that their use should be otherwise prevented.)

A 2nd issue was identified by John Brush of 7Sigma. In the situation as modelled, tools report that the innermost BindingConnectors (owned by the AssociationBlock) between the nested Ports have invalid flow directions.

That issue can be avoided by instead using a non-behavioral Port or a FullPort with additional inner-facing nested Ports to model the jack/socket, however that 2nd issue may be a valid concern for some other modelling cases.

1. Vehicle should have a compartment labeled "bound references" rather than just "references"
2. According to constraint 7 in BoundReference
"BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"
so Vehicle Model 2 should not have <<boundReference>>, endPathMultiplicity is ok... but should have lower and upper defined for the example
3. This diagram should be an example of how multiplicity on the property and lower and upper can differ

From SysML-1.6:

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

In block Vehicle Model 1:

• The multiplicity of cylinderBR should be [4] not [*]

• Multiplicity of rollBarBR should be [1] not [*] and it has no redefined type for the 'light roll bar' (it would also help if the parent block Vehicle and the sub-blocks all showed the types on their properties).

• Multiplicity of lugBoltBR in the spec figure is [6..8], it should be [6]

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

In block Vehicle Model 1:

• Multiplicity of rollBarBR should be [0] not [*]

• EndPathMultiplicity is applied to rollBarBR instead of lugBoltBR

• It's also not entirely clear (to me) whether the multiplicity of lugBoltBR should be [*].

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

perhaps a specification is needed that says that lower and upper are the same as lower and upper of the multiplicity if they are not specified or not initialized... that way, if tools are asking what is lower and upper they will get something relevant

• How do you tie a view to a stakeholder, should specify a type of relationship

Currently with CallBehaviorActions there is no way to specify that there are only so many instance that can be executed if one has an instance of an Activity... if that action is marked as isReentrant=true.. but with adjuncts one can specify that an adjunct property has multiplicity (which restricts min/max number of instances)... it would be nice if that could also be shown on an Activity diagram by allowing multiplicities in the upper right corner of an appropriate Action that specifies these multiplicities

What compartment does a property go into that redefines a BoundReference... note that such a property can not be stereotyped as BoundReference so presumably, it can not go into that compartment... so is it a reference? (but it does not fit the definition because it is not the end of an association)... there is just the properties compartment...

BoundReference is ordered and nonunique... this is not the default and should be shown in the diagrams...
Since EndPathMultiplicity is a redefine of BoundReference if it is applied by itself... then each
EndPathMultiplicity has to also be ordered and nonunique... this should be explained... and should be a constraint in EndPathMultiplicity

I believe the reason Lower and Upper were added into the standard was to allow for multiplicities that did not follow the multiplicity rules of the standard... I have an example... and I think an example should be in the standard to clarify this mystifying need for lower and upper... because it is not clear really why they are needed...

suppose I have the following
part1[3..4]
part2[3..7]
part3[4..6]

and I want to bind a BoundReferece x to part1.part2.part3 in block y... now I can take several approaches...
1. <<boundReference>> x:Part3 [*[ - this removes the double maintenance problem when multiplicities of the paths change does not restrict anything
2. <<boundReference>> x:Part3 [36..168] - this mimics the multiplicities of the path, so really no restriction
3. <<boundReference>> x:Part3 [2..10] - this restricts the number of part3s that there can be at the end of that path

option 3 could have also been specified as
<<boundReference>> x:Part3 [*]

now block z specializes block x and I have another property a such that
<<endPathMultiplicity>> a:Part3[*[

but this only works if x has multiplicity * otherwise
<<endPathMultiplicity>> a:Part3 [5..20[

if x is <<boundReference>> x:Part3 [2..10] does not work
because 5..20 is not a restriction of 2..10

This is why lower and upper can be different (but constrained by) the multiplicity

There should be a constraint in EndPathMultiplicity which states that Lower is no less than the lower on the multiplicity and that upper is no greater than the upper on the multiplicity

constraint 1 in EndPathMultipliticity
"Properties to which EndPathMultiplicity is applied shall be related by redefinition to a property to which BoundReference is applied."
and constraint 7 in BoundReference says
"BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"

so if there is a endPathMultiplicity applied... it must be to a property, not a BoundReference, but to one redefining a boundReference
... this should be explicitly stated in the standard... otherwise it is not obvious

A BoundReferrence must be more general in multiplicity than the property it binds to... but there is nothing in the constraints that specify this... the lower and upper limit the number in that specific Type

Also, the best practice for BoundReference is to make its multiplicity * so there is not the double maintenance issue if any multiplicity changes along the path it is bound to... this should be specified

Also, specify that lower, upper of BoundReference restricts the multiplicity of the property it is bound to... and there should be example showing how the multiplicity of BoundReference can be different than the values of lower,upper and why

also, the statement "Properties to which BoundReference is applied shall be the role of a connector end of at least one binding connector, or generalized by such a property through redefinition" especially "or generalized by such a property through redefinition" is not clear as to what is being generalized

also, an example of when nonuniqueness would come into play would be good in the standard

Block1 should have two compartments one reference and one bound reference (for property11)... property11 in Block2 is not correct as a redefine because it widens rather than restricts the multiplicity of property11 in Block1...property11 in block1 would need to have a multiplicity of *

The OCL is probably clear but the English is not...

4_same_owner
Properties with AdjunctProperty applied shall be owned by an element that owns the principal, at least indirectly, or one of that elements specializations.

could be read as "Properties with AdjunctProperty applied shall be owned by a specialization of the element that owns the principal"

or "Properties with AdjunctProperty applied shall be owned by an element whose specialization owns the principal"

Currently Annex E of the SysML spec is called "Non-Normative Extensions" and marked "Informative". However, the content of Annex E is widely implemented and used, and recently also referred to by other submissions as normative reference. It would therefore make much sense to make the Annex E normative, but optional (via a Compliance clause). This would still leave implementers the freedom to implement Annex E, or to ignore it. However, if implemented, then it must precisely follow the specification. This would improve interoperability and exchangeability of the Annex E items, and would make the content of Annex E referable by other submission.

To achieve this change, the Annex E title and Overview sub-clause need to be changed, and an additional bullet point inserted into Clause 5.2:

"Optional extension conformance. A tool may implement the specifications of Annex E in its entirety, or implement selected specifications from Annex E at the discretion of the tool implementer. If so, then any implementation must follow the specifications provided by Annex E exactly."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The term 'slave' appears on p.181:

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

And p.188:

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

p.189

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

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

In 2014 Drupal CMS adopted the term primary/replica.

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

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

p.181

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

p.191

16.3.2.5 Requirement
...

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

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

EDIT: from SysML-1.6 p.52:

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

—

SysML-1.6 p.52 states:

1_compatible_types

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

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

OCL-1.4 states concerning conformsTo:

8.2.1 Type Conformance

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

...

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

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

This renders numerous desirable ProxyPort connection scenarios invalid.

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

From SysML-1.6 p.52:

9.3.2.13 ProxyPort

...

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

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

Consider now from p.103:

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

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

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

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

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

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

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

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

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

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

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

p.103

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

And:

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

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

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

Figure 16-2: Requirements Derivation

In SysML-1.5 Requirement text was:

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

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

Tested in Adobe Reader and Mac Preview on a Mac.

p.195

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

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

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

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

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

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

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

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

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

p.115:

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

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

p.115:

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

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

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

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

p.115 and p.116:

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

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

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

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

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

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

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

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

SysML-1.6 p.146 states:

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

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

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

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

Further: SysML-1.6 p.127 states:

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

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

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

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

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

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

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

From UML-2.5.1:

edges

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

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

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

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

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

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

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

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

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

But this means the reported figure immediately contradicts:

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

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

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

Some related UML-2.5.1 spec quotes and constraints:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The diagram does not show any allocation to a FlowProperty.

Also:

• It does not show the allocatedFrom for 'Action2' on Block7

• It does not make sense naming the BDD 'Block0' if that block is not shown in the diagram

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

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

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

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

p.190: please check OCL directions:

1_supplier_is_requirement

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

2_client_is_requirement

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

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

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

From p.174:

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

The 'not' should probably be 'nor'

p.254:

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

Figure D.25 has FuelTankAssembly.

Plural missing in:

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

Should be:

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

SysML-1.6 p.249:

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

There is a missing end ')'

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

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

Should be:

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

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

This is implied by p.254:

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

From SysML-1.6 p.254:

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

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

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

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

Known already to Marlin and Rick

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

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

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

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

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

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

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

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

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

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

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

7.3.2.3 Expose

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

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

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

Otherwise it reads like a View has a method.

p.123 Has:

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

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

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

This is the pattern used in UML-2.5.1.

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

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

Should probably be:

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

A flow propertys values

Should be:

A flow property's values

The SysML-1.6 spec states:

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

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

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

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

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

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

Otherwise, it should be drawn outside the ModelLibrary.

Lots of ControlValues that should be ControlValueKinds

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

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

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

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

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

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

Section number 17.2.1.1 is used whereas section 17.2.1 does not exist

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

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

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

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

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

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

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

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

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

The current standard says:

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

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

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

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

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

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

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

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

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

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

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

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

Or more verbosely, something like:

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

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

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

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

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

• 'Ports that are not specified as proxy or full are simply called "ports."'

• 'Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full.'

• 'Modelers can choose between proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology.'

• 'Modelers have the option of applying stereotypes for proxy and full ports to indicate whether ports are specifying features of their owners and internal parts (proxy), or for themselves separately (full).'

• 'Using existing blocks with ports only requires knowing the port types ...'

• 'Modelers can apply stereotypes for proxy and full ports at any stage of model development, or not all if the stereotype constraints are not needed.'

• 'Figure 9-7 happens to use unstereotyped ports on a general block distributed to users, and stereotyped ports on its specializations for implementation, but the modelers might have not used stereotypes at all ...'

• 'Unstereotyped ports do not commit to whether they are proxy or full, and do not prevent or dictate future application of the stereotypes'

etc.

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

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

UML4SysML::CreationEvent
UML4SysML::DestructionEvent

There is no Creation or Destruction Event in the current UML

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

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

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

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

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

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

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

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

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

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

in Block1 and Block2, compartments need to be Bound References

• diagram was lifted it looks like from UML... the header is UML not SysML needs to be fixed
• the semantics are unknown, what message can be sent between an in and an inout primitve... would suggest that these are standardized, like set,get messages
• this shows Parameters and Arguments, but does not show Variables which should be added

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

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

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

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

Discuss.

I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

I believe that this is a new issue for SysML 1.3.

This is the wrong way round:

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

However the operation statement is correct:

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

See also attached image in a tool.

—

Compare with consistent verifiedBy, satisfiedBy:

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

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

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

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

—

It seems it was correct in SysML1.4:

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

The error may have been introduced during other changes.