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.

The diagram extension in the second paragraph of 8.3.2.6 (ConnectorProperty), should be in 8.3.1.2 (Internal Block Diagram).

Defer

Issue deferred

Annex A "Diagrams", whilst /informative/, sets out a confusing definition of the diagram types.

On the one hand, there are nine SysML diagram types that have "model elements and corresponding concrete syntax", with each diagram kind cross referenced to the specific clause defining a specific part of the SysML modelling language. So for example an activity diagram "represents" (by virtue of the appropriate nodes and paths) the model elements and connectors described in the Activities clause (clause 11).

On the other hand, there is the weaselly statement "Although the [diagram]taxonomy provides a logical organization for the various major kinds of diagrams, it does not preclude the careful mixing of different kinds of diagram types". A similar remark can be found in UML 2.5 in the form of a note in it's Annex A "Diagrams" section:
"NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioural elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced."

So, despite Annex A being informative, it creates at least two possible interpretations for tools to implement:
1. A diagram can present representations of any model element and connector, or
2. Only the specific model elements associated directly with a diagram kind (according to Annex A) can be represented on a diagram with a specific kind.

Case 1 would allow all manner of diagrammatic mixing of model elements from the different semantic clauses, even when these clauses do not allow for any logical connection. However, it might allow an activity diagram to show a «Block» with an owned activity model. It would also allow a use case diagram to include a «Block» connected with a communications path to a use case node (since neither the use case or block clauses seem to set out a constraint to prevent this in the model).

Case 2 would only allow the model elements from the directly associated clause along with the model elements that are common to all diagrams. This is a strict implementation, but may have consequences where more flexibility would have been desired. For example a modeller using Blocks, or user stereotyped classes, for stakeholder modelling would find that they cannot use these model elements directly on a use case diagram where only use case and actor model element types can be represented.

The standard should also consider the practicalities of modelling tool design and usability considerations. Case 1 would imply just one diagram implementation and a large model element library (or tool bar) for the user to work with (in a model creation through the diagram paradigm). Whereas, case 2 requires distinct implementation of the diagram kinds along with their implied constraints of which model elements can be added to them, although it does mean that the model element library (or tool bar) is quite specific to each diagram kind.

Without standardising what each diagram kind can contain, there will be no possibility of model interchange that includes the diagrams.

On a final note, the explicit exclusion of the Profile diagram from UML seems strange because defining and working with Stereotypes is a common (albeit advanced) modelling concept in MBSE, but to do it requires specific modelling concepts (and their associated nodes and paths). Hence, the current suggestion that this is done with package diagram would seem to suggest that the aforementioned diagram case 1 was being implied.

Suggested change (with a strict diagram syntax leaning):
1. Make Annex A normative and remove the diagram mixing statement: "it does not preclude mixing different kinds of diagram types"
2. Review each of the modelling clauses 8 through to 16 to check that they completely define the set of model elements and connectors that are useful to make available to modellers on the associated diagram kind. That is make explicit what is otherwise inferred by the lack of a constraint. E.g. that use case model elements can (or cannot) be connected to Blocks (or other forms of stereotyped classes) with a communication path connector.
3. Add the UML Profile diagram to the list of SysML diagrams.

Defer

Issue deferred

Having occasion to review all outstanding constraint block issues, I have read more closely the overview and find that the last paragraph on page 97 of the SysML 1.4 specification has significant problems. It also is the only mention in the SysML spec of constraint causality. This proposal is an attempt to clarify that paragraph while addressing concerns about constraint causality, affecting SYSMLR-99, SYSMLR-47, and SYSMLR-38. This is the paragraph as written:

SysML identifies and names constraint blocks, but does not specify a computer interpretable language for them. The interpretation of a given constraint block (e.g., a mathematical relation between its parameter values) must be provided. An expression may rely on other mathematical description languages both to capture the detailed specification of mathematical or logical relations, and to provide a computational engine for these relations. In addition, the block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine.

• The first sentence is not describing constraint blocks but rather a language for constraint expressions.
• The second sentence again says, “block” when it is clearly referring to expressions, but then, says an “interpretation…must be provided.” By whom? Presumably by the tool provider but that's not clear.
• The third sentence seems to say “An expression may rely on other mathematical description languages…to provide a computational engine for these relations.” It is clearly not the language that provides the computational engine but the tool implementing the language.
• The treatment of causality is puzzling. Why was non-causality specified when causality is always at least implicit? In the F = m*a example, F is implicitly the dependent variable while a = F/m would indicate a as dependent. If the intent was to make causality non-mandatory to simplify the modeler’s task, then one could say parameters are assumed to be non-causal unless specified explicitly as such.
• Michael Chonoles proposal (SYSMLR-47) to interpret parameters bound to derived values as dependent (output) and those bound to read-only values as independent (input) is not only useful but it should be noted that MagicDraw notates derived properties in recursive parametric diagram patterns and these clearly represent dependent variables. This is standard UML notation.

Replace the above paragraph with the following:

Constraint expressions may rely on any suitable mathematical description language to capture the detailed specification of mathematical or logical relations between parameters. The syntax and interpretation of the language and its associated computational engine are a tool responsibility. By default, constraints are assumed to be non-causal and do not necessarily specify dependent or independent variables, in which case specific dependent and independent variables may be defined by initial conditions and determined by the computational engine. Alternatively, dependent and independent variables (constraint parameters) may be expressed by designating their bound values as, respectively, derived ("/" prefix) or {read-only}.

Move this paragraph to be the fourth paragraph on page 97, after paragraph starting with "Parametric diagrams include..." and before the paragraph starting with "Time can be modeled..." This places it in a logical flow that follows discussions of constraint blocks, constraints, and bindings.

Defer

Issue deferred

http://www.omg.org/spec/SysML/20150709/SysML.xmi, I think when SysML specializes UML's standard profile, uses "_base" instead of "-base" in the reference. Here are a couple examples, might be more:

1) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine_base_Abstraction"/>
should be :
<redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine-base_Abstraction"/>

2) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace_base_Abstraction"/>
should be:
<redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace-base_Abstraction"/>

To be fixed

To fix the XMI as requested

The SysML notation does not provide a way to display nested properties as life lines on sequence diagrams or swimlanes/partitions on activity diagrams.

Supporting dot notation would enable the user of sequence diagrams to reference nested properties and facilitate the construction of swimlanes on activity diagrams where the user now has to construct nested swimlanes.

Defer

Issue deferred

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

Defer

Issue deferred

An inconsistency has been noted among requirement dependencies. «copy» and «deriveReqt» are the only requirement dependencies that do NOT have an operation to 'get' the supplier end («refine», «satisfy», «verify») or the client end («trace») of the dependency. The reason for this inconsistency is not clear.

Defer

Issue deferred

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

Defer

Issue deferred

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

Defer

Issue deferred

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

Defer

Issue deferred

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

Example Format might be (in ASCII art):

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

Defer

Issue deferred

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

Suggestion/Example:

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

To:
Automobile System Requirements:req | Auto_Specification:Package

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

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

Defer

Issue deferred

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

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

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

No change

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

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

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

Defer

Issue deferred

The description of the PropertySpecificType states:

The PropertySpecificType stereotype can be applied to classifiers that type exactly one property and that are owned by the owner of that property. Classifiers with this stereotype applied shall be generalized by at most one
other classifier.

The constraint section covers only "can be applied to classifiers that type exactly one property". The other constraints

"that are owned by the owner of that property."
and
"Classifiers with this stereotype applied shall be generalized by at most one
other classifier."

are missing.

Defer

Issue deferred

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

Defer

Issue deferred

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

Defer

Issue deferred

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

Fix it

Agreed, to take care about it for SysML 1.7

Split from SYSML16-86:

What is the type of FullPort? Spec says nothing

Defer

Issue deferred

This issue is dedicated to collect all typos and editorials we find in the SysML1.6 specification document. See linked annotated PDF for the list.

-------------------------------------------------------------------------------------------------------
>>> Note to RTF Chairs: do not schedule this issue for voting before the last ballot of the RTF; until then we update the list in the issue description if we find new typos <<<
-------------------------------------------------------------------------------------------------------

Proposal: Fixed typos/editorials in SysML 1.6

This resolution fixes all typos summarized in the issue.

Clarify the executable semantics of SysML Stereotypes

Add an Annex to the SysML specification

The ViewEditor present an informative annex (Annex H) that we propose as a resolution to this issue.

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

Defer

Issue deferred

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

duplicate

Duplicate by SYSML17-170

In the Constraints section the specification states the following:

'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.'

For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be:

a) One allocate from the StructuredActivityNode only?
b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode?

To make things clearer, instead of the constraints section saying:

'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”'

It should say something along the lines of:

'An Action referenced in the "node" role of an “AllocateActivityPartition”'

This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.

Defer

Issue deferred

Currently in SysML, flow properties have “Push” semantics (cf. sub-clause 9.3.2.7): writing to a flow property with direction out, propagates value to matching flow property at opposite end of the connector. This implies that there is a behavior running on the part from the “out” side.

“Pull” semantics could be useful as well: the value propagation is the result of a read made on the flow property with direction in to the matching property at the opposite end of the connector.
This implies that there is a behavior running on the part from the “in” side.

SysML should introduce a semantic variation point on this topic, and/or some specific notations/abstract syntax

To be addressed by SysML v2

This kind of topic shall now be deferred to SysMLv2

There's a few issues with the Copy relationship as described in the specification.

1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)?

2. How do you match subrequirements in the slave to subrequirements in the master?

3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters?

4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?

Defer

Issue deferred

In SysML, value property types are restricted to be a ValueType.
I see the problem with incompatible and inconsistent types in customer models, as Activities have no restrictions and still use UML primitive types as pin and parameter types.

Did I miss something in the spec, or types used in Activity are not restricted to be ValueTypes?

Also, did we fix VerdictKind to be a ValueType? I don't remember.

Defer

Issue deferred

Background:

SysML 1.3 introduced significant changes to SysML ports
MBSE methodologies based on SysML 1.2 need to be updated for SysML 1.3 and
later

A summary of syntactic and semantic variations for SysML 1.4 ports is an
important component for tailoring an MBSE methodology as an extension of
SysML 1.4
Independent of a particular MBSE methodology, such a summary is an
important guide for users and tool implementors.
For users, such a summary would help understand the capabilities and
limitations of a particular SysML tool implementation
For tool implementers, such a summary would help understand what
capabilities need to be implemented to support SysML

Issue:

The SysML 1.4 specification lacks a compact summary of the range of
syntactic variations allowed for SysML 1.4 ports
and the corresponding semantics for these syntactic variations

The SysML RTF should provide a catalogue of the syntactic factors that
induce the syntactic and semantic diversity of SysML ports

As of SysML 1.4, known factors include, but are not necessarily limited to:

1) SysML Port Kind

­

2) SysML Port Type

­

3) UML Interaction modality

­(UML::Port::isService, UML::Port::isBehavior)

4) SysML Port Features & nesting

­Behavioral features:

­Structural features:

5) Nested SysML Ports (kind, type, modality, features)

6) Optional feature direction

7) SysML Port Connectivity

­Internal vs. external connectors
­UML Connector kind (assembly, delegation)
­SysML Connector kind (binding, non-binding)
­SysML Connector type

­SysML Association Block-typed Connector features & nesting
(same as SysML Port Features & nesting)

8) SysML ItemFlow

­Distinguishing what may flow in general vs. what actually flows in a
context

Defer

Issue deferred

The abstract syntax supporting the specification of initial values for properties of SysML block has to be clarified and aligned with the intended semantics.

In SysML 1.4, §8.3.1.2.8 says: “A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block.

These values override any default values that may have been previously specified on these properties on their originally

defining block”

While §8.3.2.3 says: “An entire tree of context-specific values can be specified on a containing block to carry values of nested

properties as shown on an internal block diagram”, then: “If a property belonging to a block has a specification of initial values for any of the properties belonging to its type, then

the default value of that property must be a UML InstanceValue element. This element must reference a UML

InstanceSpecification element created to hold the initial values of the individual properties within its usage context. The

instance specification must be unnamed and owned by the same package that owns the outermost containing block for

which the initial values are being specified”

If the specification of an initial value is “context specific”:

· It cannot be specified using the default value of a property

· It should be possible to distinct initial value depending on the context, i.e. we need a resolution mechanism to know which initial value has to be used

Defer

Issue deferred

Section E.4 (non-normative) defines the objectiveFunction stereotype to describe objective functions for use in trade studies. However, whereas Table E.5 defines the objectiveFunction stereotype to extend (or rather generalize) ConstraintBlock, this seems to be inconsistent with the parametric diagram on the same page where the objectiveFunction stereotype is (seems to be [*]) applied to the a constraintProperty instead.
Given the fact that constraintProperty is only 'loosely' defined in the spec (i.e. it is not part of the xmi file), the only viable alternative seems to be that objectivefunction extends uml::Property and adds the necessary constraints in order to warrant the fact that the type of the uml::Property is (stereotyped by) a ConstraintBlock...

Please clarify the definition of the objectiveFunction stereotype.

[*] Since there is no formal notation defined for objectiveFunction, one can of course merely guess...

Defer

To fix the XMI generator, as appropriate

I cannot find new SysML 1.4 ClassifierBehaviorProperty and AdjunctProperty notation details, such as :

1. what keyword should be used? <<classifierBehaviorProperty>> which is very long, or maybe shorter version <<classifierBehavior>> ? <<adjunctProperty>> ?

2. In what block compartments should it appear? Under generic “properties” or maybe should have their own new compartments?

3. Should we show “principal” value on adjunctProperty box? If so, showing only the name is not so useful as showing an element kind too, like <<callBehaviorAction>> or <<parameter>>, so user can understand what it represents.

Defer

Issue deferred

Kind: Clarification

Description:

The current specification of SysML allows, in some places, variations on the semantics. For a part of them it is intentional because the standard does not want to enforce a specific one among others possible, for another part it is not and may result from ambiguities in the text which will have to be fixed.

It would be useful to explicitly and exhaustively identify the list of intentional semantic variation points so that users can easily see the choices they have to make and state them clearly.

Defer

Issue deferred

For “regular” properties, UML semantics in UML is “non-depletive”: the ability to read their value does not depend on the number of time they have been read previously. A “depletive” semantics would implies that a value is no more available once it has been read

SysML does not say anything about this for flow properties.

Defer

Issue deferred

At the end of section E.4 on page 245:
"The namespace for the standard profile is: http://schema.omg.org/spec/SysML/20090817/SysML-profile.xmi."

Should this be referred to as a URI, not the namespace? Perhaps should simply reference the cover page of the spec since the one given here is out of date.

Defer

Issue deferred

The specification should clarify the semantics for removing a value from an “out” Flow Property. Since “removing” something is considered to be a “write”, can we assume that it is propagated to a connected and matching “in” Flow Property, if any?

Defer

Issue deferred

SysML says nothing about how to deal with multiplicity for flow properties matching

Defer

Issue deferred

The ISO-80000 library has numerous instances of the SysML::ValueType stereotype applied on data types. They are intended to specify the corresponding units and quantity kinds.

According to SysML, both unit and quantityKind properties of the ValueType stereotype shall be InstanceSpecifications.

However in http://www.omg.org/spec/SysML/20150709/ISO-80000 all of them refer to the data type the stereotype is applied to rather than to the expected instance specifications. This could result from a bug in the ID generation algorithm used for SysML 1.4

Example

<SysML.Blocks:ValueType xmi:id="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029.stereotypeApplication_SysML.package_packagedElement_Blocks.stereotype_packagedElement_ValueType">
    <base_DataType xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
    <quantityKind xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
    <unit xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/></SysML.Blocks:ValueType>

To fix the xmi generator

To fix the XMI generator, as appropriate

Issue:
The descriptions in the specification are inconsistent regarding the constraints of what can actually flow over a connector.
The ItemFlow is used to constrain what actually flows w/r/t the flow properties which specify what can flow.
In other sections the specifications suggest that the ItemFlow actually loosening the constraint by allowing more general types to be flowing.

Description:
These are the inconsistent parts in the specification:

9.3.2.11 ItemFlow, p86 states:
An ItemFlow describes the flow of items across a connector or an association. It may constrain the item exchange between blocks, block usages, or ports as specified by their flow properties.

9.3.2.11 ItemFlow, p87 states:
Each classifier of conveyed items on an item flow must be the same as, a specialization of, or a generalization of at least one flow property type on each end of the connected block usages.

9.4.6 Item Flow Decomposition, p95
Item flows can also be more general than the actual flow, as shown by the connector on the right. The water distiller produces distilled water, but the item flow is for any kind of fluid. The connection to the water heater is
compatible because it accepts any kind of water, including distilled. The item flow does not require the heater to accept any kind of fluid, because the source of flow is still producing water, regardless of the generality of the item flow.

Figure 9.15, p95 - Usage example of item flows in internal block diagrams
Item Flow is Fluid.

Defer

Issue deferred

Issue:
When ItemFlow connects (deeply) nested or inherited properties (e.g. ports or parts) we cannot uniquely identify the sources and targets in its context.

Description:
This is similar to other relationships which specialize DirectedRelationshipPropertyPath, e.g. "The Allocate stereotype
specializes DirectedRelationshipPropertyPath to enable allocations to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets."

The DirectedRelationshipPropertyPath stereotype based on UML DirectedRelationship.
Stereotype <<ItemFlow>> extends UML metaclass UML4SysML::InformationFlow which specializes DirectedRelationship.

Defer

Issue deferred

1) SysML convention is to use Capitalized types. These use lower case

2) There is no "int" within SysML. The correct type is "Integer". While it is possible that an "Int" was defined in a model, in this case it is misleading readers to think that SysML uses Int as opposed to Integer.

Defer

Issue deferred

Several users at JPL have been asking me about this particular combination.
I can't find anything in the 1.4 spec precluding typing a full port by a value type.

Have I missed anything?

Defer

Issue deferred

Some properties of the SysML stereotypes are defined by associations and others by simple properties. It should be consistent and clearly defined how to define the stereotype properties.

For example, propertyPath of ElementPropertyPath is defined by an association. boundEnd of BoundReference is defined by a simple property.

Defer

Issue deferred

Parts, references, and values compartments are described in Subclause 8.3.2.3 (Block), but should with the diagram extensions for BDDs (Subclause 8.3.1.1) with the others.

Defer

Issue deferred

They specialize requirement and therefore do not allow to have properties.

Defer

Issue deferred