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

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

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

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

SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML. Furthermore they are not even defined as instances of PrimitiveType despite their XMI id.

For example we have:

<packagedElement xmi:type="uml:DataType"
xmi:id="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-String"
name="String"/>

Defer

Issue deferred

In the specification the content of the derived property “Requirement::tracedTo” is defined as follows:

• /tracedTo: NamedElement [*]

Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

As «copy» «deriveReqt» «verify» and «satisfy» inherit from “Trace”, does this means that /tracedTo also list all elements that are the supplier of a «copy» «verify» «satisfy» «deriveReqt» relationship for which this requirement is a client ?

Defer

Issue deferred

The SysML notation allows a stereotype <<S>> applied to an element E1 to be shown as the notation for a different element E2 related to E1 in some way.

Example: 11.3.1.2 CallBehaviorAction and Figure 11.2:

Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as

shown in Figure 11.2.

What this means is that if a CallBehaviorAction shows a stereotype <<S>>, then it is unclear whether <<S>> is applied to the CallBehaviorAction itself or to the behavior that the CallBehaviorAction calls.

This ambiguity is problematic for users reading SysML diagrams as indicated by SysML issue 17549:

Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied

to a call behavior action (when that call behavior action calls an activity that also

has the «controlOperator» stereotype applied).

More generally, the SysML spec needs to be reviewed where this stereotype notation can result in this kind of ambiguity.

Defer

Issue deferred

Constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???

More specifically – can port be stereotyped as directed feature/flow property, what types of properties can be stereotypes with these stereotypes?

This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

Defer

Issue deferred

SysML defines or uses some relationship based on the UML Dependency metaclass. It is possible to specify multiple dependencies having with the same client or supplier. The user can rely on this capability for various purposes. The point is that there is no standard semantics for such constructs. This must be clarified.

Defer

Issue deferred

9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port?
This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

Defer

Issue deferred

I just realized that Requirements::VerdictKind enumeration in SysML profile is NOT a ValueType, so I can't use it in SysML model to type my values.

Does everyone agree that it shall have ValueType stereotype applied?

We should make sure all datatypes we provide are ValueTypes.

Defer

Issue deferred

I potentially found a mistake in the latest SysML specification. It can be found on page 144. The “Trace Dependency” and the “TraceCallout” are introduced on this page. Usually these two visualizations should show the same aspect of a SysML model. Unfortunately the “Trace Dependency” is only introduced between two requirements whilst the “TraceCallout” is shown between a requirement and a more general NamedElement. I think the named element should be allowed in both cases in the client role of the trace dependency. ADDITIONAL TEXT

The trace stereotype as defined in 16.3.2.7 does not constrain either end of the trace relationship than the having one client and one supplier.

16.3.2.7 Trace
Description
The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
Constraints
[1] The Trace stereotype may only be applied to dependencies.
[2] Dependencies with a Trace stereotype or one of its specializations applied must have exactly one client and one supplier.

From the UML 2.5 Standard Profile, the UML4SysML::Trace extends Abstraction, which subclasses Dependency. Dependencys are directed relationships between Named Elements. Therefore, the SysML::Trace can have any Named Element as its ends.

The diagram elements Table 16.2 on pg 144 should be clarified.

Also, in section 16.3.2.7, the trace relationship has specific definitions for Requirements:

Operations
[1] The query getTracedFrom() gives all the requirements that are clients (from end of the concrete syntax) of a Trace
relationship whose supplier is the element in parameter. This is a static query.
Trace::getTracedFrom(ref : NamedElement) : Set(Requirement )

getTracedFrom=Requirement.AllInstances()>select(traceTo>includes(ref))

The query getTracedFrom() could be more general and query all NamedElements and not only Requirements.

Defer

Issue deferred

SysML 1.3 section 8.3.2.2 Block says:

SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType.
…
A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.

In SysML, we also have Signals.
In UML, Signals can have properties.

How does SysML then classify properties defined in a Signal?

A very strict reading of the SysML spec would suggest that a Signal cannot have any kind of SysML property because a Signal is neither a SysML Block nor a SysML ValueType.
However, this is clearly too restrictive in practice.

I propose expanding SysML's classification of properties to include SysML Blocks, ValueTypes and Signals.
This leads to another question:

What are the legal types of a property belonging to a Signal?

I propose restricting such properties to be typed by SysML ValueTypes only. This corresponds to the practical situation where a Signal carries a data payload – I.e., it is a message with some data content.
Allowing a property belonging to a Signal to be typed by a SysML Block or Signal leads to semantic problems — what would it mean to send / receive such signals?

Defer

Issue deferred

After ˜1 year of using new proxy and full ports, our customers are not happy with using <<proxy>> and <<full>> keywords/labels for port kind identification.

In real life, multiple labels on ports makes modeling a nightmare (see image below).

In MagicDraw, we use different colors - full port has the same color as part, when proxy port is different, but it is not enough. Diagram may be printed in B&W too.
What do you think about the idea to change proxy port graphical notation, by adding some special icons or using a dashed line for example?

Defer

Issue deferred

I'm trying to prepare requirements for "callout" notation changes in MagicDraw SysML diagrams and trying to remove tool-specific notation.

The SysML spec says that each allocatedTo or allocatedFrom property will be expressed as «elementType» ElementName.
It looks simple at a first glance, but later SysML spec is a total mess:

"For uniformity, the «elementType» displayed for the /allocatedTo or /allocatedFrom properties should be from the following list, as applicable. Other «elementType» designations may be used, if none of the below apply.

«activity», «objectFlow», «controlFlow», «objectNode» «block», «itemFlow», «connector», «port», «flowPort», «atomicFlowPort», «interface», «value»

Note that the supplier or client may be an Element (e.g., Activity, Block), Property (e.g., Action, Part), Connector, or BehavioralFeature (e.g., Operation). For this reason, it is important to use fully qualified names when displaying / allocatedFrom and /allocatedTo properties. An example of a fully qualified name is the form (PackageName::ElementName.PropertyName). "

So, looking at the predefined list it is clear that:
For the Activity or other "clean" UML element it is an metaclass name in lowercase.
for let's say ItemFlow or FlowPort is is an stereotype name in lowercase.
That's ok.

But what is <<atomicFlowPort>> ? Port with <<flowPort>> stereotype applied which has isAtomic=true.
What is <<value>> ? Property which has Type with <<ValueType>> stereotype applied.

In the example below (Figure 15.4) it has allocation of actions to parts and it uses another one <<elementType>> which is not described - <<part>>.
What is <<part>> ? The Property with AggregationKind = composite?

Also, full qualified names and <<elementTypes>> are used incorrectly in this Figure or I don't understand how it should be used.
For example:
<<block>> Block4.Part5 - why it is <<block>>, but not <<part>> ???
<<part>> Part2:Block1 - why part name is before block name? It should be displayed as (PackageName::ElementName.PropertyName) as described above.

I believe, all these rules and exceptions should be described somewhere

Defer

Issue deferred

The SysML flow properties specify elementary flows (nature and direction) that can cross the boundary of a block through a port.

According to the functional approaches of systems engineering, an entering flow when getting over the boundary of a block is handled as an input by at least one function of the block. An outgoing flow getting out the boundary of the same block is produced as an output by at least one function.

Activity diagrams are used for carrying out functional graphs with SysML. Inputs and outputs of SysML activities are specified by parameters. Nevertheless SysML does not seem to provide any mean to relate activity input / output parameters to the flow properties. This entails that the unfortunate SysML developers, after having made careful and strenuous efforts for specifying the block interfaces with flow properties and ports, have no other solution than to redo exactly the same work for specifying the inputs / outputs of the functional architecture as activity parameters (or vice-versa). Moreover, there is no mean to ensure consistency in the SysML model between the flow properties and the activity parameters and neither between the ports and the activity pins.

A solution would be to enable to use flow properties like parameters as activity inputs / outputs.

Defer

Issue deferred

Page 36, 8.3.1.1 Default «block» stereotype on unlabeled box is not always optimal

Original Text

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

Comment

I question whether this is always desirable, e.g.,

1) if the diagram had the «functional hierarchy» diagram usage stereotype applied, wouldn’t the default be «activity»,

2) if the containing block is an activity block, wouldn’t «activity» be the right default

Type: Clarification/Fix

Add sentences that say: If the bdd diagram has a «diagram usage» specified (such as «functional hierarchy»), a different default (such as «activity») can be used.

If the bdd diagram is for an activity block, the default stereotype elements is «activity»

Defer

Issue deferred

Page 26

Original Text

7.3.2.5 Viewpoint

Description

A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases

Comment

How is the highlighted sentence done? There are no examples. I see examples of Viewpoint with a dependency on another Viewpoint, but no references for the individual fields (e.g., language and methods). Are the fields populated in an inheritance manner. Can they be overridden? Does it only work if the fields are blank on the dependant Viewpoint?

Type: Clarification

Add example and clarify rules

Defer

Issue deferred

The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties

Defer

Issue deferred

when participating in the discussions on the draft ballot 3 on the SysML 1.3 spec, we observed that there is a need for clarification. The question was about whether Enumerations can be used on parametric diagrams for typing constraint parameters. The spec defines:

From 8.3.2.10

SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. … A SysML ValueType may define its own properties and/or operations, just as for a UML DataType. See Section 8.3.2.2, “Block” for property classifications that SysML defines for either a Block or ValueType.

ValueTypes can be used to type constraint parameters. Since ValueTypes extend UML DataTypes, and Enumerations are a subtype of DataType, Enumerations might be used. Since Blocks could be used as types of constraint parameters as well, the implication that any subtype of a UML datatype might lead to the implication that any subtype of UML classifier could be used here as well (e.g. activity or StateMachine), which is of course not meant.

We need to constrain this definition better

Defer

Issue deferred

SysML 1.2 Issues: Continuous flows in non-streaming situations with >1 multiplicities

11.3.2.1 Continuous

It’s a bit unclear how continuous flows work in non streaming situation, especially with high multiplicities.

If a continuous flow arrives at a pin with a multiplicity of 2, it would appear that the 1st and 2nd value arriving at the pin would be captured. If the flow is also continuously valued, the two values would be same. The difference between two adjacent samples goes to zero if the delta time between samples goes to zero (assuming differentiability).

Type: Fix

To make this capability useful, we’ll need to add a sampling rate to be able to use continuous with >1 multiplicity. If we don’t the specification should have a caveat for >1 multiplicity and differentiable input values.

Defer

Issue deferred

Sysm 1.2 Optional with «streaming»

Page 92

11.3.2.6 Optional

Does optional on an input mean optional to start the activity or optional for the activity to finish? Consider an «optional» streaming input.

Does optional on an output mean optional to appear at the end of the activity or optional for it ever to appear? Consider an «optional» streaming output..

We need to have all the possibilities for streaming; it probably should have two multiplicities for each streaming parameter

Starting Multiplicity: number of tokens that must appear for the activity to start

Total Multiplicity: number of tokens that must appear over the lifetime of the activity

Ending Multiplicity: number of tokens that must appear at the end of the activity

Total Multiplicity: number of tokens that must appear over the lifetime of the activity

Defer

Issue deferred

The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that’s ok according to the current SysML specification.

However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context

and not be valid in another context.

I’ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn’t work. MagicDraw doesn’t allow blocks to be owner of a allocate.

I’m not sure whether it is a tool issue or if I’ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I’m not sure if that’ll solve

my problem.

Any ideas?

Defer

Issue deferred

Page 45 Distributed Properties on Activities

Original Text

8.3.2.4 DistributedProperty

Constraints

[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.

Comment

As I read this, on a BDD, if we have activities, the properties of the activities cannot be distributed properties, because activities are not stereotyped as block

Type: Fix

Rewrite this constraint,

[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block, Activity, or ValueType.

Defer

Issue deferred

SysMl does not give any example of using multiplicity on the relationships between actors and use cases. This is part of UML as shown in Figure 16.11.

Apparently, the "official" interpretation of SysML is that if there is no example, it is not part of SysML. This incompatibility means that standardize training, books, etc, on Use Cases can not be applied to SysML. And the notation is of value.

Defer

Issue deferred

A new keyword was added for attributes in UML,

. This concatenation of all such attributes within a class (block) for an instance must be unique.

While this will mostly be used by database developers, it’s also a domain model analysis property, e.g, Social Security Number for a US citizen, Mac Address, etc. As such, it may be useful to some SysML modelers.

Defer

Issue deferred

In UML, there appears to be consistent representing of attributes as regular associations from the owning class. SysML, in similar circumstances, represents value properties as composite associations. We should try to understand what UML is saying (and perhaps push back on them) and consider the value of consistency.

Defer

Issue deferred

Annex B, Figure B.35, the object nodes after the decision and before the merge should be removed and the names/types moved to the ProportionPower pins / output parameter node.

Defer

Issue deferred