Issues for OMG SysML 1.5 Revision Task Force

To comment on any of these issues, send email to sysml-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 19757: RequirementRelated is present in the summary but no more in the document Jira Issue SYSMLR-163
Issue 19764: Requirement ID should be immutable Jira Issue SYSMLR-165
Issue 19783: Expand use of rake symbol for all decompositions Jira Issue SYSMLR-166
Issue 19813: NestedConnectorEnd violates UML "roles" constraint Jira Issue SYSMLR-167
Issue 19817: Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 Jira Issue SYSMLR-169
Issue 19836: Activity should not be included as graphical node included in activity diagrams Jira Issue SYSMLR-178
Issue 19858: layout error for compartment name Jira Issue SYSMLR-209
Issue 19859: Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? Jira Issue SYSMLR-210
Issue 19862: Missing one right parenthesis in the constraint equation Jira Issue SYSMLR-211

Issue 19757: RequirementRelated is present in the summary but no more in the document (sysml-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
RequirementRelated is present in the summary (16.3.2.4) but no more in the document 


=> The problem put all the section 16.3.2 in disorder


Also RequirementRelated is still present (as Deprecated) in the profile I'm working with 
(The one that will be used in eclipse-Papyrus).

Resolution:
Revised Text:
Actions taken:
May 11, 2015: received issue

Issue 19764: Requirement ID should be immutable (sysml-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:
Requirement IDs, as currently specified by the standard and implemented by vendors, are not adequate to ensure robust traceability outside MBSE models. The standard describes ID as "The unique Id of the requirement”. I would suggest replacing this sentence with "The unique and immutable Id of the requirement." This immutable characteristic is key to ensure robust traceability throughout a project with external stakeholders and documents. 


The current practice of using a hierarchical number for the ID is bad practice that should be discouraged, because a hierarchical ID will necessary change when the hierarchy is refactored, which is almost guaranteed to happen. This breaks traceability. I recognize that there is also a need for a hierarchical ID, mainly to be used to sort requirement tables properly using this property. For that use case, I would suggest a new ID called HID with the following description: “A unique hierarchical identifier, used to organize requirements within a package”


Since we now have two different IDs that serve two different purposes, we should give guidance for which one should be used as the prefix in front of the name, depending of the context. My suggestion is as follows:
- In a traceability context, the ID should be the prefix shown in front of the name. For example, when showing the table column "Derived From", the ID should be the prefix shown, not the HID.
- In a hierarchical context (for example, in the containment tree), the HID should be shown as the prefix in front of the name.
- When in doubt, use the ID in preference over HID.

Resolution:
Revised Text:
Actions taken:
May 29, 2015: received issue

Issue 19783: Expand use of rake symbol for all decompositions (sysml-rtf)

Click
here for this issue's archive.
Source: Booz, Allen & Hamilton (Mr. Michael J. Vinarcik, michael.vinarcik(at)incose.org)
Nature: Enhancement
Severity: Significant
Summary:
I’d like to advocate for rakes on Call Operation nodes (that have associated methods) in the next SysML rev.  We’re using operations extensively because they inherit nicely and have inputs/output parameters.  By moving to Call Operations from Call Behaviors, we lose the rake that’s a visible sign you can drill deeper…so by using Call Operations with methods instead of Call Behaviors, we lose that visual cue.  
I put a stereotype with icons on the nodes as a fix, but I’d love to see it as a native function.

I suggest that rake symbols should be expanded to include call operations on activity diagrams with methods attached (or any other situation in which drill-down is available).

Resolution:
Revised Text:
Actions taken:
June 9, 2015: received issue

Issue 19813: NestedConnectorEnd violates UML "roles" constraint (sysml-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
UML's constraint "UML::Connector::role" specifies that ConnectorEnds need to point to roles/parts owned by the Connector's structuredClassifier (direct or inherited).


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


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


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

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

Resolution:
Revised Text:
Actions taken:
June 30, 2015: received issue

Issue 19817: Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 (sysml-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Spec document says:
7.3.2.6 Stakeholder


Description


A stakeholder represents a role, group or individual who has concerns that will be addressed by the View of the model.


Attributes


• concernList: Comment [*]


The interests of this stakeholder.


• /concern: String [*]


The interests of this stakeholder displayed as the body of the comments from concernList.


--
XMI file says something completely different


Stereotype Stakeholder
  concern: Comment [1..*]
  /concernlist : Comment

Resolution:
Revised Text:
Actions taken:
July 17, 2015: received issue

Issue 19836: Activity should not be included as graphical node included in activity diagrams (sysml-rtf)

Click
here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Clarification
Severity: Minor
Summary:
Table 11.1 includes a set of concrete syntax symbols that are "graphical nodes included in activity diagrams."  One of these represents an Activity diagram.  Activity diagrams do not include activities as one of the possible nodes in the meta-model.  I suggest you remove that line of the table to make is clear that Activity Diagrams do not contain activities.

Resolution:
Revised Text:
Actions taken:
September 24, 2015: received issue

Issue 19858: layout error for compartment name (sysml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
The "part" (name of the third compartment of the block Block1 in Table 8.1) exceeds its scope/space.                                                  Name:            Jingang Zhou
Employer:        Neusoft
mailFrom:        zjg_robin@hotmail.com

Resolution:
Revised Text:
Actions taken:
November 25, 2015: received issue

Issue 19859: Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? (sysml-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
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...

Resolution:
Revised Text:
Actions taken:
November 30, 2015: received issue

Discussion:


Issue 19862: Missing one right parenthesis in the constraint equation (sysml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The constraint "{v(n+1 = v(n)+a*32*3600/5280*dt}" for the containt block VelocityEquation in Figure D.34 lacks a right parenthesis, which results in error of the contraint.

Resolution:
Revised Text:
Actions taken:
November 26, 2015: received issue