Issue 11493: Lack of notation for units and dimensions on values. (sysml-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Lack of notation for units and dimensions on values. There are no samples at all Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: September 19, 2007: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred Discussion: Issue 12219, “suggest need Quantity stereotype and definition,” is proposing changes to the current SysML support of value types with units and dimensions (and is renaming the current Dimension stereotyp to QuantityKind). These changes provide an important foundation for supporing notations on values, including a distinction between symbols for units vs. unit names. A new normative Annex C.5 also defines a Quantity value type which could be used to carry values that include the identification of a dynamically selected unit within the value itself. Issue 12219, however, does not change the underlying structure of value types or provide new forms of value specfications. As part of alignment efforts between SysML and MARTE, the MARTE Value Specification Language (VSL) continues to offer a possible long-term direction for expressions and other, more complete forms of value specifications that might be considered in future revisions of SysML. Until MARTE VSL can be considered in more detail, and more experience is gained with the new capabilities included in Issue 12219, this issue is being deferred. Disposition: Deferred End of Annotations:===== ssues From: "Nerijus Jankevicius" This is issue # 11493 Lack of notation for units and dimensions on values. Subject: RE: update of draft Ballot 4, Issue 11493 Date: Tue, 6 May 2008 15:47:35 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: update of draft Ballot 4, Issue 11493 Thread-Index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gAAyZmCAAEgOSsAAN1YMgAAETTvAAAeOwsA== From: "ESPINOZA Huascar 218344" To: "Friedenthal, Sanford" , "Burkhart Roger M" , X-OriginalArrivalTime: 06 May 2008 13:47:36.0476 (UTC) FILETIME=[BE142DC0:01C8AF7F] Hi again, Issue 11493 (Closed No Change): Lack of notation for units and dimensions on values à Using a .quantity. or a .unit. name as ValueType name should be normalized in SysML. Leaving users to decide if they will use .Weight. or .Kg. as ValueType name seems to not be a good practice in whatever language. Furthermore, the indistinct use of both in the SysML spec, makes its comprehension very hard. This is related to defining a clear semantics for value types, quantities, quantity kinds, dimensions and units. So I.d propose to defer this issue together with the other .quantity, unit, dimension. issues. Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 6 mai 2008 14:25 À : Burkhart Roger M; sysml-rtf@omg.org Objet : RE: update of draft Ballot 4 Roger Relative to the scope issue for the timing diagrams, I suggest we hear back from other vendors for thier input as well as others. I Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Tuesday, May 06, 2008 1:44 AM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: RE: update of draft Ballot 4 Sandy-- In reply to your comments below: I've corrected the Disposition line in Issue 12157 to read Resolved. Thanks for the catch. Issues 11653, 11627 (and 11117 which you suggest could be associated), 10642, 10539, 10472, and 10073 all have resolutions of Deferred. I've given a Deferred resolution to all issues for which I've received no proposed resolutions to date, but which were received before the RTF Issue deadline of January 1, 2008 (later issues will be automatically deferred). Any Discussion notes on Deferred issues are only a brief summary which is by no means complete or authoritative, since their whole point is that more work is required to develop a resolution. While more discussion could always be added to a Deferred issue, the point of the resolution is that sufficient work was not completed to resolve the issue and that further work should continue a follow-on revision. Since the whole point of Deferred resolutions is that a more complete resolution was not developed by the cutoff date for the current RTF, I don't see a need for adding more to these resolutions (such as links to other issues) prior to voting. All further work can be continued by the task force responsible for the next revision. On Issue 10342, I'll leave any response to your comment on Issue 10342 to Eldad Palachi, who prepared the initial draft of this resolution. > The following statmenet does not appear to be correct since item flows are directed relationships and are not typed "Item Flows CAN be typed by any classifier as written in the second paragraph of section 9.3.2.6. Thanks for calling attention to the significant change in Issue 11654, to add a timing diagram to SysML to support timelines as referenced by Chapter 11 Activities. Do you think this scope of change should be considered within a revision update of the SysML 1.0 spec? --Roger -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Monday, May 05, 2008 5:37 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: RE: update of draft Ballot 4 Roger Comments on Draft Ballot 4 Issue 12157 The last statement in the resolution says "Closed, no change". This should say "Resolved" Issue 11654 This issue adds a UML timing diagram to SysML. It also enables a timing diagram representation for an activity diagram. This is a significant change and attention should be called to this proposed resolution. Issue 11653 The discussion should be elaborated to refer to the comment below in Annex A, and possibly include a resolution that proposes a change to the reference to the formal BNF. I suggest a change to the following on pg 176: FROM SysML diagrams including the enhancements described in this section is intended to conform to the Diagram Interchange Standard to facilitate exchange of diagram and layout information. A more formal BNF has been introduced in selected chapters to facilitate diagram interchange, which is referred to in the Language Formalism chapter. TO SysML diagrams including the enhancements described in this section are intended to conform to the Diagram Interchange Standard to facilitate exchange of diagram and layout information. [Deleted 2nd sentence] Issue 11627 This can be associated with issue 11117 by Eldad Pelachi regarding sending data via a message on a sequence diagram. A similar issue has been raised by M. chonoles with the need to enable sequence diagrams to be used with flowports. I would suggest tieing these issues together. Issue 10642 This should refer to proposed resolution for Issue 11654 which does add timing diagrams. Tie these two issues together. Issue 10539 I think this issue is resolved by the proposed resolution to issue 11501 Issue 10472 Suggest adding the statment on applicability of instance semantics and not deferring this. I think this will provide needed clarification. We can address broader issues related to instance semantics in future revisions. Issue 10342 The following statmenet does not appear to be correct since item flows are directed relationships and are not typed "Item Flows CAN be typed by any classifier as written in the second paragraph of section 9.3.2.6. Issue 10073 Seems like this is a duplicate issue (need for templates in SysML) but I did not check to confirm Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 11:13 AM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4. Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Date: Sun, 11 May 2008 22:27:51 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: sysml-rtf@omg.org, Nerijus Jankevicius Subject: Ballot 4: 11493_closednochange: Lack of notation for units and dimensions on values : request defer X-Virus-Scanned: ClamAV 0.91.2/7086/Sun May 11 16:55:01 2008 on mail.nomagicasia.com X-Virus-Status: Clean I understand the submitter Nerijus is away on leave, so I hope to represent him well enough by requesting a Deferral. We have a number of genuine concerns, many of which I already voiced at the OMG TM in Washington DC in March, and they have not been sufficiently addressed by the Discussion and Disposition of ClosedNoChange. -------------------------------------------------------------------------------- Firstly, there is a fundamental flaw with the practice of using the ValueType to indicate a Unit's symbol: Since it seems that the (UML-compliant) idea of showing the ValueType also in Slots (and IBDs) has been for now rejected, and considering that "secondary stereotypes" (11496) be displayed in IBDs, it in fact leaves no consistent way at all to indicate the Unit of a value shown in an IBD initial values compartment because the Unit "metadata" belongs to the ValueType that types the defining feature (property) of a Slot ! (This is not a problem for :values, which is feature based.) BTW in MD15.5 we have introduced the ability to show the Type on values in Slots and IBDs so we can now in fact communicate a Unit symbol well enough to engineers using the tool. This (as I have pointed out in many recent emails) is in fact consistent with UML2 options for displays of Slots; one may (optionally) show the type of the defining feature. I already made this point at the OMG TM in Washington DC. SysML needs to at least admit the ability to show a ValueType in compartments of an IBD (as we already can) and it needs to clarify the matter of "secondary stereotypes" or "stereotypes of related elements", also raised by Nerijus (11496)) This alone is grounds for deferral. -------------------------------------------------------------------------------- One can (only just) get away with the naming options described in the Discussion, however the spec really does need something to clarify these conventions/practices (I know of many readers of the spec who have found this very confusing). Just relying on the example diagrams showing quite different (and in parts inconsistent) usages is not enough. They need to be supplemented. SysML currently leaves up to the user the naming conventions by which a ValueType may identify its unit and/or dimension. This is not enough; a clear example of usages is required. The word 'symbol' does not even appear anywhere in either the specification of 8.3.2.10 ValueType or 8.3.2.9 Unit, or in the surrounding material, (and because there is no explicit ValueProperty stereotype, there is no point of documentation for it there, either). There is no notation for the unit or dimension of a value property apart from the value type which types the property. I have elsewhere suggested the inclusion of a symbol attribute, and my substantial Quantity/Value/Unit/Dimension metamodel proposal and analysis includes it: http://school.nomagic.com/*Quantity has an attribute 'symbol:String' http://school.nomagic.com/*Unit correctly extends Quantity, so it inherits symbol Please also defer this issue to enable inclusion/merge with a much improved Quantity-based metamodel. -------------------------------------------------------------------------------- Even if an explicit 'symbol' attribute is not included to support Unit, at least the spec should have somewhere in the definition of 8.3.2.10 ValueType some description of possibly naming practices. I have some examples that match the (otherwise good) description in the Discussion. In the Usage Examples in Chapter 8, Blocks, such as the Wheel Hub Assembly example in Figure 8.8, value types are named after the unit, such as psi for pressures and ft-lb for torque. http://school.nomagic.com/UnitLikeValueType HOWTO define a custom ValueType to indicate a chosen Unit Other examples, such as those in Chapter 10, Blocks, name the value type after the quantity type or dimension, such as Time, Weight, or Horsepwr. Such value types could also carry a specific unit in their definition, but are less explicit by not specifying a particular unit in their name. HOWTO define a custom ValueType as a system-wide "kind of quantity" (or after its Dimension) http://school.nomagic.com/QuantityKindValueTyp The latter contains a clear warning, which should also be stated somehow in the spec. namely: You may use a ValueType to define a "kind of quantity" that is not bound to a specific block. In the example below, the ClockFrequency ValueType is defined for an entire system. It may then be used to type a specific ValueProperty representing a specific quantity in a block, such as the frequency of a Processor. In this case, the ValueType is named to indicate the kind of quantity (rather than the symbol of the chosen Unit ). The same principle can be used to name a ValueType after its Dimension. WARNING: Changes to the chosen Unit will propagate throughout the system, so special care must be taken with statement of values and defaults ! An overview of both usages is given here: http://school.nomagic.com/ValueTypeRealWorld Use the SysML ValueType, Unit, Dimension system to model real-world quantities http://school.nomagic.com/ValueType -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Lack of notation for units and dimensions on values. There are no samples at all