The term “system” is very ambiguous.

Proposed Change: Define or clarify the term “system” in “1 Scope”.

Refer to ISO 15288 for definition of System and Systems Engineering

Add simple note in Clause 1.1 that refers to ISO 15288 for definition of 'system" and 'system engineering'. Added text is shown in red.

See also SYSMLR-296 for adding ISO 15288 to the normative references.

SysML specification constraints the usage of Satisfy, Verify and DeriveReqt relationships to requirement model elements.
When in MBSE approach, textual requirements are most likely to be left aside and non-textual requirements start commonly being used. For example, an Activity can represent a functional requirement, as it has inputs, outputs and a processing that shows how inputs are transformed into outputs.
When using non-textual requirements, other model elements will start representing requirements. Therefore, those relationships should accept elements that are not SysML::Requirement model elements.

Requirement Relationship Constraints are Appropriate

Requirement relationships need to be contained to have at least one end be identified as a "requirement" in the model. The resolution to SYSMLR-155 has clarified the scope of requirement properties, which may help address the originator's concern.

Property Based Requirements Background Information

1. Challenge / Needs
Action: provide a clear statement of the modeling capabilities and end user wants from SysML requirements modeling

1.1 BASIC NEED as stated in 'criteria for an enhanced text based requirement' document (below): CURRENT USERS OF TEXT BASED REQUIREMENTS NEED AN ENHANCED CAPABILITY TO EXPRESS TEXT BASED REQUIREMENTS MORE PRECISELY, TO REDUCE AMBIGUITY AND FACILITATE VERIFICATION BY ANALYSIS AND OTHER METHODS.

Amplification: The enhanced text requirement is used in conjunction with the overall system model to assist in specifying and architecting systems. Sometimes, the system model is used as a model-based specification, such as when block instances with specific property values represent the requirement. In this case, the model-based specification further refines the enhanced text based requirements.

1.2 Primary needs derived from the basic need:
1.2.1 PROPERTIES OF REQUIREMENTS (see also issue SYSMLR-34): Requirements in SysML need to specify properties with quantitative values. These properties and their values must be relatable to other model elements or properties for the purpose of design refinement, analysis, and verification.
RATIONALE: The most fundamental way to add precision to requirements is the addition of properties and values.

1.2.2 MINIMIZING REDUNDANCY and AMBIGUITY: A requirement in SysML should be expressed with the minimum number of model elements and relationships.
RATIONALE: Refinement of textual requirements into other model elements has the potential to add redundancy and ambiguity. For example, the maximum acceptable weight for a system should appear as a single number within a requirement, and that number should be linked directly to both design values and verification methods. Redundant textual and numerical versions of the weight requirement add redundancy, and requirement relationships at a parent level instead of a value level add ambiguity.

1.3 Other needs derived from basic and primary need:
1.3.1 MIXED EXPRESSIONS (see also issue SYSMLR-34): Requirements in SysML should be able to be written as "The top speed of this car shall be greater than <x>. And there be a compartment of the requirement where the current value of <x> is given, such as <x> = 200mph." <x> in this case is a property of a requirement, mentioned in 1.2.1 above.
RATIONALE: This explicitly and unambiguously ties the numerical/variable property of the requirement (1.2.1) to the textual expression of the requirement. Also, by using this mixed expression as a transformation or replacement for the plain text expression, redundancy and ambiguity are reduced (1.2.2).

1.3.2 VALUE TYPES: Numerical value/variable properties of requirements in SysML need to have quantity kind and units applied to them. (The implementation of this need leads to Value Properties of requirements)
RATIONALE: This is consistent with the quantity kind/units need that led to Value Properties of blocks and parts.

1.3.3 VALUE DISTRIBUTIONS: Numerical value properties of requirements in SysML need to be able to be expressed as distributions, meaning an acceptable distribution of values.
RATIONALE: Requirements are often expressed as having an acceptable range of values

1.3.4 DIRECTION/CAUSALITY OF REQUIREMENT PROPERTIES: (this need is controversial) Numerical value/variable properties of requirements in SysML need to be able to have direction associated with them.
RATIONALE: In order for requirements to specify input/output relationships, direction must be able to be applied to various values or variables in order to indicate if they are inputs or outputs.

1.3.5 REQUIREMENT RELATIONSHIPS TO PROPERTIES OF REQUIREMENTS: Properties of requirements in SysML need to be able to participate in requirement relationships (satisfy, verify, etc) directly, and not solely through the requirement that types it.
RATIONALE: This capability removes potential ambiguity (1.2.2) and enables one to reuse requirements in different contexts.

1.4 Other derived needs from the above needs:
1.4.1 TEXT PARSING (see also issue SYSMLR-40): There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements.
RATIONALE: This capability is a mechanism for transforming pure-text statements into mixed expression statements.

1.4.2 MATHEMATICAL EXPRESSIONS: There is a need for requirements to own or contain mathematical expressions that elaborate and clarify textual or mixed expressions so they can be evaluated as being satisfied and verified.
RATIONALE: Mixed and textual expressions can't be evaluated. A slightly more rigorous formalism, such as -

, provides a potentially evaluatable format for expressions.

1.5 Needs that have been discussed but are not directly related to the basic need in issue 19591:
1.5.1 REQUIREMENT REUSE: A requirement needs to be able to be reused in different contexts. This implies a property can be typed by a requirement so that it can give the requirement context. It also supports the intent of specializing requirements.
RATIONALE: Treating requirement like other classifiers in SysML adds symmetry to the language and adds modeling efficiencies through reuse.

1.5.2 RULES FOR HIERARCHICAL REQUIREMENT RELATIONSHIPS: Consider adding precision to the current text based requirement relationships as follows: a) One or more properties are asserted to satisfy a requirement when the input/output parametric relationships and/or constraints are satisfied, b) A test case that verifies a requirement proves the parametric relationship and/or constraint is satisfied through a verification method (e.g., inspection, analysis, test), c) A requirement is derived from another requirement when the parameters of one requirement are derived from the parameters of another requirement typically through some form of analysis, d) A requirement refines one or more other requirements when it expresses the requirement more precisely, e) The requirement can contain other requirements, which reflects the logical AND of those requirements unless stated otherwise
RATIONALE: When requirement relationships are provided at both the requirement level, and the requirement property level (1.3.5), the relationship between the parent relationship and the property relationships need to be semantically understood.

2. Current Solution / Workaround
Action: how are users currently addressing this today and what are the issues with the workarounds?

This has been demonstrated in various presentations at the PBRWG

3. Proposed Solution for SysML 1.5
Action: How are we proposing to do this in SysML 1.5?

1. Enable the following
a. include properties in requirements
b. include expressions in requirements (e.g., derived, constraint, opaque)
c. enable text to refer to other model elements
d. enable a property to be typed by a Requirement so that it can be used in context
e. enable a requirement to be specialized

2. Ensure users can continue to model requirements as they have in SysML v1.4

Note 1: For specification consistency, refer to how the constraint block stereotype is specified in the specification, which may have similar characteristics to the requirement stereotype proposal. In particular, the specification of the constraint block stereotype includes the constraint property that is typed by a constraint block. Also, ensure consistency with the diagram extensions for constraint block and constraint property.

See 'Relaxing Constraints Rationale' document, and most recent

4. References:
4.1. Source Document (issue filed by Sandy): http://solitaire.omg.org/secure/attachment/10829/sysml%20issue-precise%20expression%20of%20requirements-sf-c.doc
4.2. PBRWG meeting minutes (PBRWG wiki): http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf5:groups:require:requirements

Updated Proposal for PBR

Rationale for making a change to SysML:
The current SysML specification inadvertently inhibits the creation of user profiles to extend «requirement». This kind of user profile was envisioned from the inception of SysML to not only be allowed, but encouraged… see the final paragraph in section 16.1 of the SysML 1.0 specification. Annex C.2 in the SysML 1.0 specification provides an example of a non-normative extension to «requirement», the initial intention to be able to add useful properties to requirements (e.g. source, risk, verifyMethod, verifyMethodKind), and add constraints on specific requirement relationships based on the indicated subtype of requirement. See original issue for a more detailed problem statement: http://issues.omg.org/browse/SYSMLR-155

Priorities in developing the resolution to SYSMLR-155:
▪ Retain the current constraints on «requirement» and meaning, and require no change or transformation of existing user models.
▪ Provide a capability for user profile development of requirement-related capabilities. This was an oversight in the original specification, and was always an expected capability. Note that extension of requirement capabilities is completely consistent with non-normative Annex E.3, which has extended «requirement» from SysML 1.0 onwards.
▪ Make all existing requirement relationships available for any new «requirement» user profile, since it would be confusing to add new relationships with different names to express essentially the same meaning.

This proposal refactors the «requirement» model element such that it retains all the previous constraints, but creates a new abstract stereotype «abstractRequirement» that retains ID, Text, and the requirement relationships. This new abstract stereotype may be used as a mix-in on new user-defined, non-normative profiles to meet the agreed initial scope of PBR as discussed above. Note that the new «abstractRequirement» model element, being abstract, can only be used in a user profile and NOT directly in a user model.

Refactoring of this kind is a well-established and accepted method of maintaining software and databases, and the normative change required is well within the authority of the SysML Revision Task Force.

The proposal consists of two distinct parts:
1. The normative change to the specification (restricted to Chapter 16) including refactoring of «requirement» into «abstractRequirement», and associated changes to references and paragraph numbers.
2. A non-normative appendix (Annex E.8) that describes
a. the purpose and basic guidance for use of «abstractRequirement» in custom user profiles, and
b. an example of a user profile based on «abstractRequirement» & «constraintBlock», as well as a user model example employing the profile, and
c. an example of a user profile based on «abstractRequirement» & «constraint», as well as a user model example employing the profile.

Requirement relationships were originally intended to be optionally depicted in a compartment notation, in a manner similar to allocation relationships (see Table 15.1 on page 130). Table 16.1 does not depict requirement compartment notation, but it is referenced in section 16.3.1.2 and 16.3.1.4.

Requirement relationship compartment notation needs to be fully elaborated in the spec, including additional elements in Table 16.1 and section 16.3.1, in a manner consistent with allocation compartment format in Chapter 15.

Add Requirement Compartments to Table 16.1

The requirements relationships compartment was mistakenly omitted from Table 16.1. This compartment notation should be added to the Requirement element, consistent both with the callout notations in Table 16.2 and the allocation compartment shown in Table 15,1 (derived, derivedFrom, satisfiedBy, verifiedBy, refinedBy, tracedTo, master, slave; all in italics).

Additionally, NamedElement should be added to the end of Table 16.1 showing compartment notation for requirement relationships consistent with callout notations in Table 16.2 (satisfies, verifies, refines, tracedFrom; all in italics)

The property path becomes unreadable when properties are unnamed.
e.g. car.....length

when named, the property path looks like this:
car.e.c.p.length

Use type names if property names are not set

Use the property types to construct the property path when property names are not set.

Assuming that:
car:Car.
e:Engine
c:Cylinder
p:Piston

The property path should look like this:
car.:Engine.:Cylinder.:Piston.length

Optionally the property name can be displayed:
car:Car.e:Engine.c:Cylinder.p:Piston.length

Issue:
The specification provides no notation for units on properties and values.
There is no notation provided to show units on value properties in block definition.
There is no notation provided to show units on values of slots or default values of value properties.

Create notation to show units on properties and values.

1) Add optional unit name or symbol for value properties.
<vpname>:<valueTypename> <unitSymbol | unitName>

e.g. distance:Length (m)

2) Add optional unit name or symbol for values:
<value> <unitSymbol | unitName>
e.g. 10 m

9.3.2.13 constraint [5] states "The type of the port at the last position of the onNestedPort list must own or inherit the port port of must own or inherit the port port of". This makes no sense

Apply revision from previously adopted resolution

Apply revision from Issue 18407 in http://doc.omg.org/ptc/2013-12-08, page 129, at the bottom, the two edits for constraint [5] of TriggerOnNestedPort, which updates SysML 1.3. This will replace the unapproved constraint in the SysML 1.4 spec.

9.3.2.13 Constraint [6] states "the stereotyped invocation actionthe stereotyped invocation action." This makes no sense.

Apply revision from previously adopted resolution

Apply revision from Issue 18407 in http://doc.omg.org/ptc/2013-12-08, page 130, which updates SysML 1.3 by adding a constraint to TriggerOnNestedPort. This will replace the unapproved constraint added in the SysML 1.4 spec.

There are “QUDV” and “ISO-80000” package. However, these material isn’t listed as Normative Reference.

Proposed Change: Add “QUDV” and “ISO-80000” as Normative Reference.

Reference Annexes

Make reference to the annexes of this specification that include QUDV and ISO-80000 profiles. Add text to the final sentence in clause 4.3 as shown in red.

The only “PrimitiveTypes” package is extracted on this figure although there are a lot of UML2 packages. Besides, the package “UML” is ambiguous and inaccurate. In case of UML2, it is divided into small packages.

Recommended Change: Clarify the figure.

Clarify text

Add clarifying text to Clause 4.3. Added text in in red.

This sentence refers to the RFP. Previously mentioned, this clause is informative. (If it is necessary to describes the requirements, it should list the concrete requirements.)

Recommended Change: Remove the description which include “RFP”.

Dupe of SYSMLR-265

duplicate issue.

What is “UML 2’s StandardProfile”? Is it Profile package? I couldn’t find such materials.

Proposed Change: Clarify the description.

Revise text in Clause 4.3

Insert text into Clause 4.3 per directions below. Inserted text is in red.

This sentences use the “Part II”, “Part III”, etc. However, these “Part”s cannot be found on this document.

Proposed Change: Get rid of “Part” and change to the Subpart.

Remove "Part" and "Subpart"

Remove all reference to "Part" and/or "Subpart" from the table of contents and text, but retain the divider headings (Introduction, Structural Concepts, Behavioral Concepts, Crosscutting Concepts, and Annexes), un-numbered, in both the table of context and as divider pages in the text.

This clause refers to the RFP. Previously mentioned, this clause is informative.

Recommended Change: Remove the descriptions which include “RFP”.

Dupe of SYSMLR-265

duplicate issue

This sentence refer to SysML RFP. However, this RFP is not a prescription, besides, this sentence is informative. It is obvious matter to follow the RFP.

Proposed Change: Remove this sentence which includes such description of RFP. If it is necessary to refer to the RFP, list such materials as the “Normative Reference”.

Update Normative References per SYSMLR-296

see SYSMLR-296

There is a constraint in 8.3.2.12 ParticipantProperty

[6] The property referred to by end must have a multiplicity of 1.

What is "property referred to by end??? And why it's multiplicity must be [1]?
Why it is not set in a profile or metamodel? Why constraint is needed?

Also, in model example in Figure 8.13 - Internal Block Diagram for WheelHubAssembly

There is connector typed by AssociationBlock and both ends have multiplicities more than 1.

Apply revision from previously adopted resolution

Apply revision from http://issues.omg.org/browse/SYSML12-19, as reported in http://doc.omg.org/ptc/09-08-13.pdf (PDF page 75, or search on 13666).

Concerning: http://issues.omg.org/browse/SYSMLR-155
example attached

Add example of PBR using Block

Add example of PBR using Block

Constraint [2] in 8.3.2.7 DirectedRelationshipPropertyPath, p 55 says that targetContext must be specified when targetPropertyPath has a value.
There are cases where targetPropertyPath does not have a value but still should be set.

See attached example and cases P, R, T.

Case R must have targetContext set to «block»D, and Case P must have targetContext set to «block»A, instead of being empty. For completeness, in Case T, targetContext must be set to «block»D. We believe that this would be technically consistent with the current SysML 1.4 specification.
Constraint [2] says that targetContext must be specified when targetPropertyPath has a value. In Case R, targetPropertyPath does not have a value.
But, it would be consistent with Section 8.3.2.7, including Constraint [2], to assign a value even if targetPropertyPath has no value. Constraint [2] uses the term ‘when’ rather than ‘when and only when’.

Recommendation:
Update constraints [1] and [2] to say that sourceContext and targetContext must be set when source or target is a property.

Update constraints [1] and [2]

in 8.3.2.7 DirectedRelationshipPropertyPath, p55

replace:
[6]The type of the property at the last position of the sourcePropertyPath list must own or inherit the source of the stereotyped directed relationship.
[7]The type of the property at the last position of the targetPropertyPath list must own or inherit the target of the stereotyped directed relationship.

with:
[6]The type of the property at the last position of the sourcePropertyPath list must own or inherit the source of the stereotyped directed relationship. The sourceContext must be set when source is a property.
[7]The type of the property at the last position of the targetPropertyPath list must own or inherit the target of the stereotyped directed relationship. The targetContext must be set when target is a property.

There is no clause number & heading on the first paragraph right after “Subpart”. It is a hanging paragraph.

Proposed Change: Add the clause number & heading.

Remove text from Part/Subpart

See SYSMLR-293, resolution to SYSMLR-263 and associated duplicate issues.

The term “UML 2” suddenly appears without definition. Just “UML2“ is ambiguous, because OMG has some UML 2 versions. (OMG’s UML 2.4.1 is same as ISO/IEC 19505-1,2.)

Proposed Change: “UML 2” should be defined as ISO/IEC 19505-1,2 or OMG’s specific UML 2 version in “2 Normative References”.
Also “UML 2” shall be defined as abbreviation.

Change incorporated in SYSMLR-309

see SYSMLR-309. Note that this specification has no list of abbreviations.

In the ISO standard, "must" is disabled.

Proposed Change: Use “shall” or “should” adequately instead of “must” based on the intention of “must”.

Change modal verbs throughout specification as indicated in the attached file

All modal verbs used in constraints and requirements in the pas/2015-08-01 (ISO/DIS 19514) document have been evaluated, and markups made to the pdf version with recommended changes in accordance with ISO/IEC Directives, Part 2, 2016

Terms shall be unity.

Proposed Change: Change “UML2” to “UML 2”

Change "UML2::ActivityPartition" to "UML::ActivityPartition"

The term “UML2::ActivityPartition” refers to a unique model element in the UML metamodel. Other places in this specification make similar references as “UML::xx”, so the clause in question should be updated for consistency. Modified text is noted in red.

This sentence designates “ sub clause”

Proposed Change: This sentence designates “ subclause”

Dupe of SYSMLR-263

Close as duplicate of SYSMLR-263

This sentence designates “Parts II-IV”.

Proposed Change: Change “PartsII-IV” to “Subparts II - IV”.

Dupe of SYSMLR-263

Close as duplicate of SYSMLR-263

Don’t separate the “Normative Reference” clause.

Proposed Change: Remove the heading “2.3 Other Documents”.

Revise Normative References per SYSMLR-296

See SYSMLR-296

The format of normative references doesn't meet ISO format.

Proposed Change: Designate reference like as other OMG PAS documents.

Revise Normative References per SYSMLR-296

See SYSMLR-296

UML2.0 should be refers to UML 2.4.1 unless there is inevitable reason, since UML2.4.1 has been standardized as IS.

Proposed Change: Change the UML2.5 to UML2.4.1 on the Normative Reference list. Or if UML 2.5 is referenced, it is necessary to clarify specific reasons

*Provide rationale for use of UML 2.5 *

Since UML 2.5 is not the ISO approved version, the reason for it's use as the basis for SysML 1.4 needs to be justified.

This justification and appropriate reference should be added to the third and fourth paragraph of the introduction. The added/modified text appears in red.

This sentence designates “Parts II – IV”.

Proposed Change: Change “PartsII-IV” to “Subparts II - IV”.

Dupe of SYSMLR-263

Close as duplicate of SYSMLR-263

This sentence refers to the “OMG’s Model Driven Architecture (MDA)”. However, there is no prescription for the MDA. The MDA is just informative.

Proposed Change: This sentence is informative. Therefore, this sentence should be removed.

Add reference to MDA Guide 2.0

The entirety of Clause 3.1 is informative. MDA is a key driver of the language architecture of SysML. This statement about MDA is both informative and necessary. Add reference to MDA Guide 2.0, and add guide to normative references section. Added text indicated in red.

This sentence refers to the “ISO 10303 STEP AP233”. However, there is no description of this reference on the “Normative References”.

Proposed Change: Add “ISO 10303 STEP AP233” to the normative references list.

Update Normative References per SYSMLR-296

see SYSMLR-296

According to the first line of the 3rd paragraph, “Table4.1 lists the metaclasses excluded from the UML4SysML subset”. However, only “metaclass” is ambiguous, since it is not sure which metaclass is intended. It is necessary to clarify which metaclass is intended.

Proposed Change: Add “UML2” prior to “metaclasses”.

Context of metaclasses is clear in context.

Context of the metaclasses as UML 2 is clear from 1) previous paragraphs, 2) reference to the UML4SysML metacalss subset, and 3) UML 2 appearing in title of referred tables.

The term only “UML” is ambiguous. In the previous text, it is designated as “UML 2”.

Proposed Change: Replace “UML” with “UML2”.

Use of "UML" is clear in context.

The text clearly refers to UML as a language in general. UML 2 is specifically mentioned in the previous paragraph. See also SYSMLR-309, "UML" in this spec refers to UML 2.5.

SysML 2.2 B

7.3.2.5 Viewpoint

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

How is this done? There are no examples. I see examples of a Viewpoint with a dependency on another Viewpoint, but no languages referencing languages in another viewpoint.

Suggest either developing an example or deleting the sentence and adding another one after the next sentence, so it reads.

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. 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. A viewpoint may reference another viewpoint to help in the specification.
SysML 2.2 B

7.3.2.5 Viewpoint

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

How is this done? There are no examples. I see examples of a Viewpoint with a dependency on another Viewpoint, but no languages referencing languages in another viewpoint.

Suggest either developing an example or deleting the sentence and adding another one after the next sentence, so it reads.

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. 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. A viewpoint may reference another viewpoint to help in the specification.

Removed criticized sentence - it refers to an older SysML version

Proposal:
Remove the sentence as suggested

„The languages and methods for specifying a view may reference languages and methods in another viewpoint.” from the specification. It is a relic from the view/viewpoint concept in SysML 1.3 and prior versions.

Viewpoints cannot reuse other viewpoints. Therefore the second suggestion should not be added to the viewpoint description.

Rationale:

Now the SysML 1.4 specification clearly states that languages is a URI to a meta-model, profile or other language specifications. The URI could not be a reference to a languages property in another viewpoint.

Methods is a derived property of type Behavior. The sentence that the methods could reference methods in another viewpoint was valid in pre-1.4 SysML where methods was a property of type String.

ISO/IEC standards use specific format as a document reference.

Proposed Change: Use directive defined reference format as a document refer. (ISO/IEC Directive part2)

Changes to Normative References (JTC1 02, 04, 05, 06, 10, 12, 14, 23)

Remove all subclauses from Clause 2, reformat all references to the approved ISO format, and add references as noted.

Operations paragraph under Requirement are inconsistent in calling base_class vs. base_abstraction. Also, type face is inconsistent.

Update Requirement Operation [1]

Change requirement operation [1] in section 16.3.2.4 to be consistent with other operations.

Japan will approve this DIS if the all TE comments are accepted.

No action required.

Comment is not actionable by OMG. No change to spec.

In Table 8.1 2nd row, Block, the compartment header, "parts" is misplaced. It is above the compartment separator but belongs below it.

In the constraints compartment, there is an extraneous space after the { (left brace). The remainder of the diagram uses no space inside the braces.

In the operations compartment, operation2 has a parameter q1 of Type 1 (with an embedded space). It is also used with a space in op3. However, Type1 without a space is used in operation1. Generally, no space should appear in a type name. These problems with Type 1 also appear in row 4 showing an example of a valueType. Also in row 4 (showing the valuetype) prop6 and prop7 have extraneous spaces in their types.

Also, in Row 4 an extraneous space appears in the subsets clause of property2. It says {subsets property 0). It should say

.

In both Row 2 and Row 4, operation2 has a return type of Types. Either this is some sort of category operation (which doesn't generally seem possible in UML) or one of the worst possible names for a Type

Proposal: Table 8.1 Block compartment header misplaced and other formatting problems and inconsistencies

Changed as proposed by the submitter and changed Block0 to ValueType0 in the redefinition clause for the ValueType since a ValueType can not inherit from a Block.

The current document eliminates Protocol State Machines on the grounds of simplification. See Section 13

However, this leaves a hole in the capabilities of SysML. Currently, SysML supports UML interfaces (provided and required), which can’t have state machines to define them.

It is an important part of designing systems interfaces (SE terminology) to define the details of the (UML/SysML) Interfaces. These details include the allowed ordering of messages. As we are not allowed to use behavior state machines and the standard solution, that of, protocol state machines are not included, we can’t properly do interface engineering within SysML

If some other solution/work-around is proposed (which I don’t recommend) the explanation of how to accomplish this should be in the spec.

Defer

Postponed to the next RTF

In Appendix A there is a list that says:
The following are some of the designated model elements associated with the different diagram kinds.
? activity diagram - activity
? block definition diagram - block, package, or constraint block
? internal block diagram - block or constraint block
? package diagram - package or model
? parametric diagram - block or constraint block
? requirement diagram - package or requirement
? sequence diagram - interaction
? state machine diagram - state machine
? use case diagram - package

Based on my readings, which seems to indicate that the type of element whose namespace contains the elements in the diagram, I would say it should be
? activity diagram - activity
? block definition diagram - block, package, or constraint block, activity, profile
? internal block diagram - block or constraint block
? package diagram - package or model, view, modelLibrary, profile
? parametric diagram - block or constraint block
? requirement diagram - package or requirement, model, view, modelLibrary,
? sequence diagram - interaction
? state machine diagram - state machine, block, operation, use case
? use case diagram ? package, block, view, model, modelLibrary

( I left out some cases of profile, when I couldn?t think of what it would show, but profile could be added to any list that covers package)

List of "some of the designated model elements" that can represent a diagram frame has been clarified.

The text reads 'some of the designated model elements' and not 'all of the designated model elements' in the following introductory sentence. The list does not show all possible elements that can designate a frame in the same way that the diagram elements tables do not identify all possible elements that can be shown in a SysML diagram. In general, this is a broader issue with SysML that we have not rigorously mapped the concrete syntax to the abstract syntax. However, this may be done in the future, at which time we can include the complete list of elements that can designate each frame. In the interim, including or excluding the element in this list does not imply any change to the underlying abstract syntax and semantics, but merely impacts the ability to present this model element as a diagram frame.

The resolution incorporates some of the proposed changes but not all. A compelling use case should be provided to designate other diagram elements as frames.

The following should be noted in response to the proposed changes:
• As of SysML v1.4, view extends class and not package
• A state machine diagram always designates a state machine

In Table 8.2 (Graphical paths defined by in Block Definition diagrams), rows MultibranchPart Association and MultibranchShared Association shows two association lines sharing one end (property3), implying the end is owned by two blocks (assuming the other ends are different), which isn't possible. Even if the two blocks on the opposite ends redefine property3 using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of property3 should be added to the figure, and some diagram extension text should explain that the "shared" graphical elements refer to three underlying model elements. The notation isn't in 2.4.1 that I can find.

Resolution: Forked association notation ill-formed

The semantics of multibranch associations are clarified in UML 2.5:

If there are two or more aggregations to the same aggregate, a conforming tool may as a purely presentational option show them as a tree by merging the aggregation ends into a single segment adorned by the solid or hollow aggregation diamond symbol. Any adornments on that single segment apply to all of the aggregation ends. The absence of an adornment on a merged segment does not imply that the properties corresponding to the suppressed adornment have equal values for all of the aggregation ends.

The notation depicted in table 8.2 in the SysML specification is misleading.

The UML 2.5 specification, section 9.2.4, states in part,
“The compartment named “receptions” contains notation for Receptions. The receptions compartment is mandatory and always appears below the operations compartment, if it is not suppressed. The receptions compartment is used for Classifiers that own Receptions, including Class (see 11.4).”

The SysML specification is silent regarding this compartment in blocks. I suggest that the compartment be added to the list of compartments and if the label is going to be optional like the other block compartments, then this be explicitly stated in section 8.3 as something that is not included as part of UML4SYSL.

Proposal: Reception compartment not addressed

The SysML specification does not mention a notation for receptions. The metaclass Reception is part of UML4SysML (see table 4.2) and in the context of ports receptions are mentioned.

The notation for receptions like it is defined in the UML 2.5 specification should be added to the SysML specification.

As discussed in the SysML 1.4 RTF meeting today, it is currently unclear whether all of the elements shown in SysML diagrams have a SysML stereotype applied or not.

In some cases, there is an explicit mention about the meaning of SysML diagrams, e.g., 11.3.1.1 Activity:

Activities in block definition diagrams appear as regular blocks, except the «activity» keyword may be used to indicate the Block stereotype is applied to an activity, as shown in Figure 11.1.

We need a clarification whether the meaning of SysML diagrams is that they show only SysML-stereotyped elements or not and if not which UML elements can be shown on a SysML diagram without any SysML stereotype applied.

No Change Required.

There are many UML elements that are reused in SysML that do not have a SysML stereotype applied. The elements that can appear on SysML diagrams are identified in the diagram element tables and the diagram extensions sections of each specification chapter. Any additional general clarification required should be added to Section 6.3 Conventions and Typography. However, no additional clarification is required at this time.

In the spec, it is said that : « Notational and metamodel support for n-ary associations and qualified associations has been excluded from SysML.”.

However, as shownin the extract of the table of the SyML symbol, multibranch association are possible:

Resolution: Multiassociation

The reporter confounds n-ary associations with multibranch associations. SysML only support binary associations, i.e. associations with exactly two association ends. The metamodel support for n-ary associations has been excluded from SysML.

Multibranch associations are a notational variant of two or more binary associations that have each an association end with the same property specification.

When a swimlane in an activity diagram has the «allocate» stereotype, it means that the actions within the swimlane are allocated to the structural element in question. How come the examples seem to have the structural compartment of allocate from — «activity» xxx intead of «action» xxx

Same as SYSMLR-16

What Michael describes in SYSMLR-51 is a subset of what was described in SYSMLR-16.

SysML currently discards UML 2.1 qualified associations (see 8.3.1.4) as not being of interest to the SE community.

I contest this on two grounds –

1) a. Qualifiers are used expressively and meaningfully to explain domain situations that have nothing to do with data modeling. For example, when I say a baseball roster had 9 members and that there are 9 positions to fill, I am not explicitly saying that there is one person per position. Qualifiers allow me to clarify this piece of the real world and would be very useful on a BDD.

b. Qualifiers are also used idiomatically with generalization discriminators to tie parallel generalization structures together. They are capable of modeling situations, such as when there are many types of missiles, each with their own launcher type.

c. Qualifiers are also used to indicate addressing schemes and mechanisms. For example, by placing an operation/activity etc that returns a type in a qualifier, one can specify the mapping or prioritization /ordering algorithm. Specifying such algorithms may be the SE’s job, when it part of an equation report, algorithm development. This could fit into SysML and support allocation to functional (target prioritization scheme, best antenna-signal function) and structural components (packet routers). This is fully in the spirit of what practicing SEs do and would round out the capability of SysML.[Note that this capability could be delayed for a later SysML, the other parts should be addressed sooner]

2) Qualifiers appear to be part of small part of UML that is incompatible with use with a SysML strict profile mechanism. Imagine a model done in strict SysML, then brought into UML, where a qualifier is added to the relationship, changing the multiplicity at one end. If the model is then brought back into (strict) SysML and the qualifier is then dropped, the multiplicity cannot be automatically restored (or determined from the model). Because of this, qualifiers must be forbidden in UML in such contexts

Defer

Postponed to the next RTF

Parts are added directly into package. B27 - <<moe>> element that is a part is displayed inside of a package <<view>>

Defer

Postponed to the next RTF

Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references):
a) Stereotypes
i. Block stereotypes are displayed on parts
ii. Block stereotypes are displayed on object nodes
iii. Parameter stereotypes are displayed on ActivityParameterNode
iv. Behavior or operation stereotypes are displayed on CallActions
b) Tags
i. Block allocations are displayed on parts
ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype
c) Constraints
i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30)

Defer

Postponed to the next RTF

Lack of notation for units and dimensions on values. There are no samples at all

Defer

Postponed to the next RTF

The semantics of the Binding Connector is described as follow :

“8.3.2.10 Binding Connector

Description

A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.”

So, I understand that definition if the multiplicity of the properties linked by the binding connector is 0..1 or 1. But what happen is the upper bound of the multiplicity is greater than 1? If for example, it is 0..* ? And moreover, what happen when the multiplicity of both property is different, as for example on one end 0..1 and on the other end 1 ? In this case, as according to the previous definition, the value of both properties has to be equal, what happen to the value of the proiperty which multiplicity is 1 when the other property is not yet defined?

Defer

Postponed to the next RTF

Nested connector ends:

"Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them."

That's an important feature of SysML.

"The ability to connect to nested properties within a containing block requires that multiple levels of decomposition be
shown on the same diagram."

I think that's a problem in practice. Often I don't want to see the nested properties in the diagram.
I propose to add a notational feature to show that a connector end is connected with a nested property without
showing that property.

For example we could draw the connector to the border of the surrounding property and attach the stereotype <<nested>>
as a short form of <<nestedConnectorEnd>> and optionally the propertyPath.

What do you think?

Defer

Postponed to the next RTF

Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via flow ports.

Within UML, Message is associated with signature of either a Signal or an Operation (see constraint 2 on Message meta class, p. 492 of the UML2 superstructure spec.).

In SysML, blocks introduce an alternative for communication between blocks w.r.t. to usual UML2 composite structures: flow ports are basically dedicated to support data-based communication between blocks in contrast of UML2 that does not support such kind of communication between composite structures.

In this case, a Message within an interaction should be able to refer either a DataType, a Block, a ValueType if the communication happen between two atomic flow ports, or to a FlowSpecification if the communication happen between two non-atomic port.

I did not see anything related this issue within the SysML spec. Do I miss something or is it something missing in the SysML doc?

Defer

Postponed to the next RTF

I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario

Defer

Postponed to the next RTF

The block namespace compartment shows a bdd of the elements that are part
of the namespace of the block.

Is it allowed to show relationships from a block inside that compartment to
a external block? The relationship could be in the model, but can I show it
in the diagram?

I think it should be allowed. I don't see any problems.

Defer

Postponed to the next RTF

Timing diagrams are missing in SysML. They are an important diagram for several engineering disciplines. For example I know a project from the automotive/robotic domain that won't use SysML, because of the missing timing diagrams. Timing diagrams will improve the acceptance of SysML in engineering disciplines.

Defer

Postponed to the next RTF

The figure and added text describing the use of <<extend>> is still unclear and inconsistent. As agreed, converting Start the vehicle to an <<include>> and Park to <<extend>> will correct the confusion and make the added text unnecessary.

Defer

Postponed to the next RTF

The relationship between a behavioral flow port and parameters is marked as a semantic variation point. Isn't it possible to specify a concrete relationship here? The specification proposes a binding relationship. What is a binding relationship? It is not known in SysML or UML.

Defer

Postponed to the next RTF

Section 11 should show an example of generalization/specialization of Activiites when then are being shown in a bdd.

Defer

Postponed to the next RTF

Since ItemFlow is a stereotype of InformationFlow, it can be related to an ActivityEdge and depicted on an Activity Diagram. At least one tool has provided this capability. Clarify the use of ItemFlows on Activity Diagrams in the specification: If this is not desirable, then an additional constraint must be added to ItemFlows to prevent it. Personally, I like the idea of representing ItemFlows on ObjectFlows, but the semantic meaning of this representation is unclear. If this is retained, then it should be discussed in both chapter 9 and chapter 11.

Defer

Postponed to the next RTF

When an allocation relationship is depicted on an activity diagram using Allocate Activity Partitions, it is unclear if the allocation relationship is from the Action Node to the Part represented by the partition (direct allocation), or from the Activity typing the Action Node to the Block typing the Part (Inferred allocation). Since in practice it has become necessary to represent both conditions, this portion of the SysML specification should be modified to incorporate some graphical indication to distinguish them.

Defer

Postponed to the next RTF

SysML needs the capability to interchange diagrams in addition to model data. The concrete syntax complliance should include a requirement to comply with diagram interchange in a similar way that the infrastructure specifciation does. The following is included in section 2.3 of the Infrastructure Spec under Concrete Syntax Compliance: - the ability to output diagrams and to read in diagrams based on the XMI schema defined by the Diagram Interchange specification for notation at that level. This option requires abstract syntax and concrete syntax compliance. The proposal is to add the same requirement as above to section 5.3 as a second bullet under the concrete syntax compliance.

Defer

Postponed to the next RTF

Figure B.27: <<view>> Package "steals ownership" of MOEs, Actor, UseCase and Requirement Severity Critical since there is currently no sensible way to implement <<view>> in tools ! In Figure B.27 - Establishing a Performance View of the User Model It is not at all clear how the MOEs, Actor, UseCase and requirement should be shown as directly within the view without the view package "stealing ownership". Appears to break constraint: '7.3.2.4 View [1] A view can only own element import, package import, comment, and constraint elements.' See also example images in Magicdraw UML SysML Plugin at: http://school.nomagicasia.com/node/127 http://school.nomagicasia.com/files/images/Figure%20B.27%20-%20Establishing%20a%20Performance%20View%20of%20the%20User%20Model.png Note that this relates to:: Issue 11500: <<view>> as Package extension is very bad idea (sysml-rtf), No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com) '<<view>> as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view)'

Defer

Postponed to the next RTF

Figure B.9: clarify turnIgnitionToStart message on driver:Driver Is it supposed to be a message to self ? If so please include message to self path, otherwise explain,

Defer

Postponed to the next RTF

Figure B.10: justify/clarify 'StartVehicle' from outside in terms of UML Please clarify how UML4SysML supports the drawing of a 'StartVehicle' message from the boundary of a ref Interaction.

Defer

Postponed to the next RTF

B.4.8.3 Activity Diagram (EFFBD): refers to allocations to parts instead of blocks SysML1.0: 'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail) Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34. It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.' In fact the AllocateActivityPartitions in Figure B.35 represent blocks, not part Properties typed by blocks.

Defer

Postponed to the next RTF

10.3.1.2 Parametric Diagram: clarify applicability of square box notation to constraint parameters (or otherwise) SysML1.0, 10.3.1.2 Parametric Diagram: 'Small square box notation for an internal property A value property may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a value property may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of property boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where an internal property box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the innermost property.' It is not clear whether 'value property' here is meant to refer to a constraint parameter. Also, the term 'internal property' does not exclude, for example, nested constraints, leaving open the possibility of drawing nested constraint properties using square box notation, which is surely not intended. The following suggests that only constraint parameters - not value properties - are intended: SysML1.0, , 10.3.2.1 ConstraintBlock: '[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, binding connectors between its internally nested constraint parameters, constraint expressions that define an interpretation for the constraint block, and general-purpose model management and crosscutting elements.' Rewrite SysML1.0, 10.3.1.2 Parametric Diagram, replacing all references to 'value property' and 'internal property' with 'constraint parameter': 'Small square box notation for a constraint parameter A constraint parameter may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a constraint parameter may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of constraint parameter boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where a constraint parameter box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the constraint parameter.'

Defer

Postponed to the next RTF

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

Defer

Postponed to the next RTF

In Figure B.29 'delta-t' is shown with solid-line (AggregationKind 'composite'), it should be shown with a dashed line (AggregationKind 'none') to be consistent with Figure B.26 BDD for EconomyContext.

Defer

Postponed to the next RTF

Figure B.38: property names of p:[PowerSubsystem] inconsistent w.r.t. other figures Figure B.38 gives p:[PowerSubsystem] with parts: em: [ElectricMotor] t: [Transmission] ice: [InternalCombustionEngine] Figure 9.3 shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController) Figure 9.6 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController) Figure 15.10 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine emg:ElectricalMotorGenerator (ecu:PowerControlUnit) (epc: ElectricalPowerController) (can:CAN_Bus) Figure B.18 BDD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine em: ElectricalMotorGenerator pcu:PowerControlUnit (epc: ElectricalPowerController) .. For consistency Figure B.38 should show p:[PowerSubsystem] with parts: emg: [ElectricMotor] (not 'em') trsm: [Transmission] (not 't') ice: [InternalCombustionEngine] Also, Figure B.18 should show PowerSubsystem with part: ecu:PowerControlUnit Visit also analysis at: http://school.nomagicasia.com/node/149

Defer

Postponed to the next RTF

Figure B.35: prefer <<continuous>> pins over contrived placement of ObjectNodes on border of swimlanes Placement of ObjectNodes on boundaries of swimlanes is contrived and graphically unstable. Prefer typed output/input Pin pairs on CallBehaviorActions corresponding to Parameters. TODO: alternative diagram with pins for resolution. See also: http://school.nomagicasia.com/node/138 http://school.nomagicasia.com/files/images/Figure%20B.35%20-%20Detailed%20Behavior%20Model%20for%20Provide%20Power%20(with%20Swimlane%20Allocation).png

Defer

Postponed to the next RTF

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

Defer

Postponed to the next RTF

In Allocations, AllocateActivityPartition, Constraints, the second paragraph says the AllocateActivityPartition stereotype does nopt preserve the semantics of of UML 2 ActivityPartition, and that partitions with AllocateActivityPartition do not have responsibility for invoking the actions in them. I think there is no conflict with UML 2 semantics, because UML 2 ActivityPartition only requires performing the actions to be the responsibility of the element represented by the partiion, not the invoking of the action. This seems compatible with allocation.

Defer

Postponed to the next RTF

One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams

BDD (for Blocks) IBDs

BDD (for Activities) ACTs

BDD (for Constraint Blocks) PARs

The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form.

It would be convenient and symmetric to support a similar diagram for for State Machines

BDD(for States) STMs

In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion.

Defer

Postponed to the next RTF

Binding relationships are used between model element properties and parameter in the constraint blocks, similarly they are used between constraint blocks.

These constraint blocks are intended to be reusable.

However connecting constraint blocks from different sources does not usually work unless the units are the same. Model element values may also not be using tehehe same units.

A reasonable solution is to indicate the scaling factor on the binding relationship. This could be done in several ways. One way would be to indicate a simple assignment equations between the two parameter names.

Currently

x----------------------------------Y

Proposed

Y=100*x

x-----------------------------------------Y

Instead of using a constant 100, we could used a named constant such as cmPm

If both ends of the binding relationship were identically named, we need to add an arrow to indicate the souce and target sidel

à

X=cmPM*X

X-----------------------------------------X

This would indicate that the left side X must be multipled by the cmPm to give the left side x

This approach allows us to handle more complex conversions by including the ability to add/sub constants

C=5/9*(F-32)

Defer

Postponed to the next RTF

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

Currenltly requirements are written as

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

Instead, it should be written as

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

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

<x> = 200mph.

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

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

Defer

Postponed to the next RTF

FigureB34 shows an Activity decomposition with: * an <<activity>> ControlElectricPower owning part Property 'elecDrivePower:ElecPower'. * an <<activity>> ProvideElectricPower without any owned part Properties. FigureB35 shows: * an Action 'a3:ControlElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> driveCurrent' * an Action 'a4:ProvideElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> elecDrivPower' The translation of ObjectFlows in FigureB35 to part Properties in the Activity decomposition FigureB34 is thus inconsistent.

Defer

Postponed to the next RTF

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

Defer

Postponed to the next RTF

Issue: Representation of nested object nodes in activity diagrams. Discussion: It is desirable to be able to represnt nesting of object nodes on activity diagrams to reflect one or more levels of nested properties of the classifier that types the object node. For example, if water is shown as an object node, and it is desired to refer to the temperature of water, then it should be possible to reflect this property on the activity diagram using the notations that are used on ibd's. In particular, one may want to use either a nested rectangle to represent the property, or the dot notation. Proposed update. In the diagram extensions for activity diagrams in Section 11.3.1.4, add a clarifying statement that nested properties of the classifier that types an object node can be represented on activity diagrams either using the nested rectangle notation or the dot notation similar to the use of nesting on ibd's and parametric diagrams.

Defer

Postponed to the next RTF

Information for facilitating the partner integration within the specification and requirements definition process (requirements interchange) are missing (e.g. meta information like version, access rights).

Remark: There is a specification already addressing this topic, the Requirements Interchange Format (RIF). It is available for download as ProSTEP iViP Recommendation PSI 6 at www.prostep.org. This specification was introduced to the SE DSIG by Rupert Wiebel from HOOD (a paper is available) and presented by Dr. Steven Vettermann from ProSTEP iViP and discussed at the ManTIS meeting on December 11th.

Defer

Postponed to the next RTF

SysM:L: Operations on Activities need to be callable (e.g., start, restart, cancel)

Defer

Postponed to the next RTF

SysML: Activity Properties should be accessible in Activity diagrams for decision making

Defer

Postponed to the next RTF

SysML: Align SysML Activities with Foundational UML

Defer

Postponed to the next RTF

Do parametric bindings observe derived and read-only constraints on properties?

.

In SysML if I bind a read-only property value to a parameter, I would expect that any evaluation of the parametric model would not be able to update the property value. If I wanted to have such a value calculated, I would expect to take off the read-only constraint

Similarly, if I bind a derived property value to a parameter, I would expect that any evaluation of the parametric model would not use that value as an input, but only as an output.

However, this is answered (and I hope it is answered positively), the SysML specification should clarify this behavior

Defer

Postponed to the next RTF

In parametrics, one cannot currently bind a constraint parameter in a constraint expression to a multiplity. For example, one may need to include the number of tires in the constraint expression that constraints braking force. However, if the model includes a Vehicle, composed of Tire with multiplicity 4, one must be able to access the number of tires (i.e. the multiplity) in the expression.

Defer

Postponed to the next RTF

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

Postponed to the next RTF

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

Defer

Postponed to the next RTF

Flow port compatibility with behavior. Semantics of flow ports need to be clarified as they relate to behavior. In particular, need to clarify how flow properties are passed to behavior (classifier behavior, owned behavior) including to the parameters of operations and activities.

Defer

Postponed to the next RTF

When one needs to reference a value of a specific property of part in a composition hierarchy in order to bind it to a constraint parameter, one uses the dot notation shown in section 8.3.1.2. (Example: a box labeled myCar.myEngine.currentTemp in a parametric diagram). When such a box is binded to a constraint parameter a nested connector end may be used to reference this property in the context of the composition hierarchy. However this poses a serious implementation issue for tools since until the box is binded it has no real model element behind it, also if one copies this box or the diagram to another hierarchy in the model then the tool has to complicated analysis. We propose to have a stereotype for reference nested property similar to nested connector end in which the path in the composition hirerchy is specified (i.e. propertyPath: Property [1..*] (ordered) - like in section 8.3.2.6). This will make it easier for tools to implement backed by the standard meta-model.

Defer

Postponed to the next RTF

Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect. Replace <<requirement>> Client with Named Element (no stereotype). Figure 16.1 (top of pg. 148): Recommend adding Refine stereotype (as specialization of Trace stereotype); otherwise note that it comes directly from UML metaclass rather than as a UML extension. Recommend reordering specializations of trace in alphabetical order on UML class diagram (e.g., Copy, DeriveReq, [Refine], Satisfy, Verify). Section 16.3.2: Should reintroduce Refine relationship description and contraints, even though a UML metaclass and not an extension. It is an important relationship with respect to requirements. Perhaps introduce prior to Sect 16.3. Section 16.3.2.3 (middle of pg. 150): Change cardinality of /derived: Requirement attribute from [0..1] to [*]. Also, add right bracket to cardinality of /master: Requirement attribute. Currently shows as [0..1 with not closing right bracket.

Defer

Postponed to the next RTF

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

Defer

Postponed to the next RTF

Allocations should not generate dependencies The Allocate stereotype extends the Abstraction UML meta-class, which is a Dependency. It is in contradiction with the following description (cf. p133: "This concept requires independent models if “function” (behavior) and “form” (structure)") If we refere to EIA-632 the logical solution that will be allocated to the physical solution only depends from upstream requirements. In some cases, one may have some (upstream) requirements to use a given implementation platform, but this cannot be considered generic and anyway the dependendcy is still on the requirement not directly on the platform. A logical solution makes abstraction of the implementation to focus on issues strictly related to the missions of the system. Then, by definition a logical solution is semantically dependent from the need and not from the implementation. In most times, several logical solutions are possible. Their are more or less effective against each of their requirements, that's why the design work includes tradeoff activities. Saying that a given logical solution is not convenient to be implemented on a given platform doesn't mean that it's not a logical solution to the need. More, the current stereotype implementation biases the impact analysis. The objective of this analysis is to parse the model and to report what model elements should be reviewed (i.e. are potentially impacted) in case of modification of a given model element to preserve the model integrity and consistency. If the platform is modified, what has first to be checked is whether or not the modified elements of the platform can still play the role they have been assigned by the allocation (with the required QoS, etc...). If the answer is "yes", then nothing to do. If the answer is "no", then they are several potential choices: a) if possible modify the allocations only, b) select another logical solution (i.e. modify it) and define the new allocations, b) select another platform and define the new allocations. This is matter of tradeoff. The only point that has always to be checked is the allocations. Then the only "thing" that actually depends on the "from" and "to" sides of an allocation is the allocation itself.

Defer

Postponed to the next RTF

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

Postponed to the next RTF

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

Postponed to the next RTF

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

Postponed to the next RTF

A binding connector used in parametrics should allow for decomposition via association blocks in a similar way that other connectors support decomposition. The specification currently includes a constraint on Block that precludes this as follows: “The number of ends of a connector owned by a block must be exactly two. (In SysML, a binding connector is not typed by an association, so this constraint is not implied entirely by the preceding constraint.)”

Defer

Postponed to the next RTF

We have issues with SysML primitive value types - Real, Integer, Boolean, String etc.

The problem is that these types are not inherited from corresponding UML primitive types - Real, Integer, Boolean, String.
That means, UML tool can't understand, what kind of ValueSpecification should be created for values of properties typed by these value types.
Should it be LiteralString or LiteralInteger or OpaqueExpression?
Constraints can't check if slot values are compatible with property types, as it is not clear what kind of value specification it should be also.
There are issues in parametrics solving also, as values must be compatible with property types.

I think, SysML primitives must be directly inherited from UML primitives - Real subtype of UML Real, String subtype of UML String etc.

Defer

Postponed to the next RTF

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

Postponed to the next RTF

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

Postponed to the next RTF