Issue 18681: QUDV's support for measurement scales is impractical (sysml-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Minor Summary: The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to “low”, “medium” and “high” From a metrology standpoint, both definitions of “priority” can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of “priority” can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV “priority” scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of “priority” can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of “priority” is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a “scale”, thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a “scale”, thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. Resolution: Revised Text: Actions taken: April 21, 2013: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: SysML 1.3 QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals Thread-Topic: SysML 1.3 QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals Thread-Index: Ac4+0hqhH91zefiWTDaOuhgl5fHVlg== Date: Sun, 21 Apr 2013 21:14:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.26] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAQr/A04= X-Brightmail-Tracker: AAAAAA== The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to .low., .medium. and .high. From a metrology standpoint, both definitions of .priority. can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of .priority. can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV .priority. scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of .priority. can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of .priority. is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a .scale., thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a .scale., thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. From: "Chonoles, Michael J" To: "nicolas.f.rouquette@jpl.nasa.gov.duplicates.existing.capabilities.with.Enumeration.and.EnumerationLiterals" , "issues@omg.org" CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Topic: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Index: Ac4+0hqhH91zefiWTDaOuhgl5fHVlgACHEmw Date: Sun, 21 Apr 2013 22:25:57 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.94] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-21_07:2013-04-19,2013-04-21,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAgr7SIEdelmo X-Brightmail-Tracker: AAAAAA== Nicolas Sorry, but I thought the enumeration literals always defined a Nominal (sometimes called Categorical) metric in which the only legal operation was to compare for equality. Priority, with its inherent ordering and < and £ operations, is an Ordinal metric. I don.t believe UML / SysML enumerations can have ordered comparisons. Can we define an operation as part of an Enumeration type (whether a datatype or valuetype or QUDV type)? Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 5:14 PM To: issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to .low., .medium. and .high. From a metrology standpoint, both definitions of .priority. can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of .priority. can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV .priority. scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of .priority. can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of .priority. is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a .scale., thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a .scale., thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , "issues@omg.org" CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Topic: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Index: AQHOPt9rDfaYjeePX0iUnozE1OZxQJjhSGaQ Date: Sun, 21 Apr 2013 23:07:31 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAgr7SIEdelmo X-Brightmail-Tracker: AAAAAA== Michael, In UML, the EnumerationLiterals are already ordered in an Enumeration: Enumeration::ownedLiteral : EnumerationLiteral [0..*] { ordered, subsets NamedElement::ownedMember} In UML, an Enumeration can have operations; these could be used for converting values (e.g., 0) into corresponding EnumerationLiterals (e.g., .small.). This could be useful for cases where a scale is defined in terms of intervals that are open/closed on the left or the right. For example, the following left-closed / right-open intervals of real numbers could define the .priority. scale: [0, 1.0[ = small [1.0, 10.0[ = medium [10.0, +inf [ = large In UML, the EnumerationLiterals (small, medium, large) can have an EnumerationLiteral::specification : ValueSpecification[0..1] (it is inherited from InstanceSpecification). This allows, for example, to use a UML Interval for defining the above mapping. In this example, it would make sense to define an operation for mapping a real value (e.g., 42.0) into a corresponding scale value (i.e., medium) - Nicolas. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, April 21, 2013 3:26 PM To: nicolas.f.rouquette@jpl.nasa.gov.duplicates.existing.capabilities.with.Enumeration.and.EnumerationLiterals; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Nicolas Sorry, but I thought the enumeration literals always defined a Nominal (sometimes called Categorical) metric in which the only legal operation was to compare for equality. Priority, with its inherent ordering and < and £ operations, is an Ordinal metric. I don.t believe UML / SysML enumerations can have ordered comparisons. Can we define an operation as part of an Enumeration type (whether a datatype or valuetype or QUDV type)? Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 5:14 PM To: issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to .low., .medium. and .high. From a metrology standpoint, both definitions of .priority. can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of .priority. can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV .priority. scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of .priority. can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of .priority. is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a .scale., thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a .scale., thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. From: "Chonoles, Michael J" To: "Rouquette, Nicolas F (313K)" , "issues@omg.org" CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Topic: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Index: AQHOPuUEQXKFX0hxIkyzbdSuqCOi05jhTSMA Date: Sun, 21 Apr 2013 23:13:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.94] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-21_07:2013-04-19,2013-04-21,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAgr7SIEdelmo X-Brightmail-Tracker: AAAAAA== You.re right (checking the spec after I wrote.) I agree that it.s very useful, just didn.t realize it was possible. I do note that some tools, such as Rhapsody, do not support adding operations to an Enumeration type. This is probably (one of) the sources for my confusion. Thanks Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 7:08 PM To: Chonoles, Michael J; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Michael, In UML, the EnumerationLiterals are already ordered in an Enumeration: Enumeration::ownedLiteral : EnumerationLiteral [0..*] { ordered, subsets NamedElement::ownedMember} In UML, an Enumeration can have operations; these could be used for converting values (e.g., 0) into corresponding EnumerationLiterals (e.g., .small.). This could be useful for cases where a scale is defined in terms of intervals that are open/closed on the left or the right. For example, the following left-closed / right-open intervals of real numbers could define the .priority. scale: [0, 1.0[ = small [1.0, 10.0[ = medium [10.0, +inf [ = large In UML, the EnumerationLiterals (small, medium, large) can have an EnumerationLiteral::specification : ValueSpecification[0..1] (it is inherited from InstanceSpecification). This allows, for example, to use a UML Interval for defining the above mapping. In this example, it would make sense to define an operation for mapping a real value (e.g., 42.0) into a corresponding scale value (i.e., medium) - Nicolas. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, April 21, 2013 3:26 PM To: nicolas.f.rouquette@jpl.nasa.gov.duplicates.existing.capabilities.with.Enumeration.and.EnumerationLiterals; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Nicolas Sorry, but I thought the enumeration literals always defined a Nominal (sometimes called Categorical) metric in which the only legal operation was to compare for equality. Priority, with its inherent ordering and < and £ operations, is an Ordinal metric. I don.t believe UML / SysML enumerations can have ordered comparisons. Can we define an operation as part of an Enumeration type (whether a datatype or valuetype or QUDV type)? Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 5:14 PM To: issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to .low., .medium. and .high. From a metrology standpoint, both definitions of .priority. can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of .priority. can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV .priority. scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of .priority. can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of .priority. is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a .scale., thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a .scale., thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , "issues@omg.org" CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Topic: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Index: AQHOPt9rDfaYjeePX0iUnozE1OZxQJjhSGaQgAB61YD//4+h8A== Date: Mon, 22 Apr 2013 00:34:13 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAgr7SIEdelmo X-Brightmail-Tracker: AAAAAA== Michael, FYI: yes you can, at least with Rhapsody 8.0 The only thing missing in Rhapsody 8.0 seems to be support for UML Interval (a kind of UML ValueSpecification). This would be particularly useful to say things like .EnumerationLiteral small { specification = Interval { min=0, max=1 }}. MD 17.0.2 SP3 can do it all, including using UML::Interval for specifying a scale range (*) Their UI does not have all of the menus to do these things.. So I made my own in QVTO modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1'; transformation AddIntervalValueSpecification(inout selectedInstance:uml); property instanceSpec : uml::InstanceSpecification = selectedInstance.rootObjects()![uml::InstanceSpecification]; main() { instanceSpec.specification := object uml::Interval {}; } modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1'; transformation SetIntervalMinValue(inout selection:uml); property values : Set(uml::ValueSpecification) = selection.rootObjects()[uml::ValueSpecification]; main() { assert fatal (values->size() = 2); var interval := values![uml::Interval]; assert fatal (interval.oclIsKindOf(uml::Interval)); var value := values->excluding(interval)->any(true); interval.min := value; } modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1'; transformation SetIntervalMaxValue(inout selection:uml); property values : Set(uml::ValueSpecification) = selection.rootObjects()[uml::ValueSpecification]; main() { assert fatal (values->size() = 2); var interval := values![uml::Interval]; assert fatal (interval.oclIsKindOf(uml::Interval)); var value := values->excluding(interval)->any(true); interval.max := value; } It.s all legit, really! The OMG specs have not been harmed in any way. - Nicolas. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, April 21, 2013 4:13 PM To: Rouquette, Nicolas F (313K); issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and You.re right (checking the spec after I wrote.) I agree that it.s very useful, just didn.t realize it was possible. I do note that some tools, such as Rhapsody, do not support adding operations to an Enumeration type. This is probably (one of) the sources for my confusion. Thanks Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 7:08 PM To: Chonoles, Michael J; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Michael, In UML, the EnumerationLiterals are already ordered in an Enumeration: Enumeration::ownedLiteral : EnumerationLiteral [0..*] { ordered, subsets NamedElement::ownedMember} In UML, an Enumeration can have operations; these could be used for converting values (e.g., 0) into corresponding EnumerationLiterals (e.g., .small.). This could be useful for cases where a scale is defined in terms of intervals that are open/closed on the left or the right. For example, the following left-closed / right-open intervals of real numbers could define the .priority. scale: [0, 1.0[ = small [1.0, 10.0[ = medium [10.0, +inf [ = large In UML, the EnumerationLiterals (small, medium, large) can have an EnumerationLiteral::specification : ValueSpecification[0..1] (it is inherited from InstanceSpecification). This allows, for example, to use a UML Interval for defining the above mapping. In this example, it would make sense to define an operation for mapping a real value (e.g., 42.0) into a corresponding scale value (i.e., medium) - Nicolas. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, April 21, 2013 3:26 PM To: nicolas.f.rouquette@jpl.nasa.gov.duplicates.existing.capabilities.with.Enumeration.and.EnumerationLiterals; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Nicolas Sorry, but I thought the enumeration literals always defined a Nominal (sometimes called Categorical) metric in which the only legal operation was to compare for equality. Priority, with its inherent ordering and < and £ operations, is an Ordinal metric. I don.t believe UML / SysML enumerations can have ordered comparisons. Can we define an operation as part of an Enumeration type (whether a datatype or valuetype or QUDV type)? Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 5:14 PM To: issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to .low., .medium. and .high. From a metrology standpoint, both definitions of .priority. can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of .priority. can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV .priority. scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of .priority. can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of .priority. is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a .scale., thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a .scale., thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. From: "Chonoles, Michael J" To: "Rouquette, Nicolas F (313K)" , "issues@omg.org" CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Topic: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Thread-Index: AQHOPvEpLioyCxQFHkyIB4mQ1l5i8ZjiBP/A Date: Mon, 22 Apr 2013 10:09:37 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.94] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-22_02:2013-04-22,2013-04-22,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org More incentive for me to get up-to-date. Thanks Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 8:34 PM To: Chonoles, Michael J; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Michael, FYI: yes you can, at least with Rhapsody 8.0 The only thing missing in Rhapsody 8.0 seems to be support for UML Interval (a kind of UML ValueSpecification). This would be particularly useful to say things like .EnumerationLiteral small { specification = Interval { min=0, max=1 }}. MD 17.0.2 SP3 can do it all, including using UML::Interval for specifying a scale range (*) Their UI does not have all of the menus to do these things.. So I made my own in QVTO modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1'; transformation AddIntervalValueSpecification(inout selectedInstance:uml); property instanceSpec : uml::InstanceSpecification = selectedInstance.rootObjects()![uml::InstanceSpecification]; main() { instanceSpec.specification := object uml::Interval {}; } modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1'; transformation SetIntervalMinValue(inout selection:uml); property values : Set(uml::ValueSpecification) = selection.rootObjects()[uml::ValueSpecification]; main() { assert fatal (values->size() = 2); var interval := values![uml::Interval]; assert fatal (interval.oclIsKindOf(uml::Interval)); var value := values->excluding(interval)->any(true); interval.min := value; } modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1'; transformation SetIntervalMaxValue(inout selection:uml); property values : Set(uml::ValueSpecification) = selection.rootObjects()[uml::ValueSpecification]; main() { assert fatal (values->size() = 2); var interval := values![uml::Interval]; assert fatal (interval.oclIsKindOf(uml::Interval)); var value := values->excluding(interval)->any(true); interval.max := value; } It.s all legit, really! The OMG specs have not been harmed in any way. - Nicolas. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, April 21, 2013 4:13 PM To: Rouquette, Nicolas F (313K); issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and You.re right (checking the spec after I wrote.) I agree that it.s very useful, just didn.t realize it was possible. I do note that some tools, such as Rhapsody, do not support adding operations to an Enumeration type. This is probably (one of) the sources for my confusion. Thanks Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 7:08 PM To: Chonoles, Michael J; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Michael, In UML, the EnumerationLiterals are already ordered in an Enumeration: Enumeration::ownedLiteral : EnumerationLiteral [0..*] { ordered, subsets NamedElement::ownedMember} In UML, an Enumeration can have operations; these could be used for converting values (e.g., 0) into corresponding EnumerationLiterals (e.g., .small.). This could be useful for cases where a scale is defined in terms of intervals that are open/closed on the left or the right. For example, the following left-closed / right-open intervals of real numbers could define the .priority. scale: [0, 1.0[ = small [1.0, 10.0[ = medium [10.0, +inf [ = large In UML, the EnumerationLiterals (small, medium, large) can have an EnumerationLiteral::specification : ValueSpecification[0..1] (it is inherited from InstanceSpecification). This allows, for example, to use a UML Interval for defining the above mapping. In this example, it would make sense to define an operation for mapping a real value (e.g., 42.0) into a corresponding scale value (i.e., medium) - Nicolas. From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, April 21, 2013 3:26 PM To: nicolas.f.rouquette@jpl.nasa.gov.duplicates.existing.capabilities.with.Enumeration.and.EnumerationLiterals; issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: RE: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and Nicolas Sorry, but I thought the enumeration literals always defined a Nominal (sometimes called Categorical) metric in which the only legal operation was to compare for equality. Priority, with its inherent ordering and < and £ operations, is an Ordinal metric. I don.t believe UML / SysML enumerations can have ordered comparisons. Can we define an operation as part of an Enumeration type (whether a datatype or valuetype or QUDV type)? Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, April 21, 2013 5:14 PM To: issues@omg.org Cc: sysml-rtf@omg.org; Hans-Peter.de.Koning@esa.int Subject: EXTERNAL: SysML 1.3 QUDV's support for measurement scales is impractical and The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to .low., .medium. and .high. From a metrology standpoint, both definitions of .priority. can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of .priority. can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV .priority. scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of .priority. can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of .priority. is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a .scale., thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a .scale., thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas. From: Burkhart Roger M To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: Ac5LQRlmO63R5VevRK+8TD7XFIKmCg== Date: Tue, 7 May 2013 16:37:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.54.37.221] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-07_06:2013-05-07,2013-05-07,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-07_06:2013-05-07,2013-05-07,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzCw== Date: Tue, 7 May 2013 20:08:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. If SysML 1.4 is based on UML 2.4.1, then you could make a case that this problem is isolated to the spec development. if SysML 1.4 is based on UML 2.5, then there's a real problem because the UML 2.5 and SysML 1.4 conventions are incompatible. UML 2.5 says the keyword for StandardProfile::Metaclass is "Metaclass", not "metaclass" From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzC5j6JqeA Date: Tue, 7 May 2013 20:08:58 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== Sorry, I typed send before I finished editing my message. From: , JPL Date: Tuesday, May 7, 2013 1:08 PM To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. - Nicolas. From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: Burkhart Roger M To: "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" Subject: RE: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzC5j6JqeAgAEVQ+A= Date: Wed, 8 May 2013 12:59:17 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [204.54.37.222] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-08_03:2013-05-08,2013-05-08,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-08_03:2013-05-08,2013-05-08,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Nicolas, My point below is that the block stereotypes do not need to be shown at all in diagrams D.8-D.10, and in fact should not be shown for compatibility with the existing diagrams in SysML 1.2 and 1.3. This is regardless of whether we base SysML 1.4 on UML 2.4 or UML 2.5. Whether or not you happen to have tool support for the valueType keyword (the only one which needs to appear), we can always fix that by final editing on the EPS graphics imported by the spec. That's exactly we've done with the last two SysML versions, so none of this is new. It would require a substantial change across the entire SysML spec to change the capitalization conventions we've followed since SysML 1.0 (when all graphics were produced by Visio, which is at least one tool that supports SysML conventions). Could you produce a version of the diagrams without the block keywords, thus matching the style in diagrams D.8-D.10 in SysML 1.3 as closely as possible, so we can produce a version of the resolution for balloting? (The tool you use does support suppressing the stereotype keyword altogether on the shape.) Then you could send either the model source file or exported EPS graphics which I can put into the resolution. If need be, we can leave any remaining cleanup for the production of the final spec, as we ended up doing in the past. --Roger From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 07, 2013 3:09 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Sorry, I typed send before I finished editing my message. From: , JPL Date: Tuesday, May 7, 2013 1:08 PM To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. - Nicolas. From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger From: "Rouquette, Nicolas F (313K)" To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Topic: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Thread-Index: AQHOS16VLLb/7F3J50CPNN3Sj2DzC5j6JqeAgAEVQ+CAABhjAA== Date: Wed, 8 May 2013 14:08:34 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== Roger, I've used MagicDraw for SysML 1.4. Nerijus informed me about their DSL technique to build support for the SysML lowercase keyword notation for stereotype names; including UML's. I'll update the figures accordingly including your suggestions for which stereotype keywords to show or hide. Nicolas. From: Burkhart Roger M Date: Wednesday, May 8, 2013 5:59 AM To: JPL , "sysml-rtf@omg.org" Subject: RE: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Nicolas, My point below is that the block stereotypes do not need to be shown at all in diagrams D.8-D.10, and in fact should not be shown for compatibility with the existing diagrams in SysML 1.2 and 1.3. This is regardless of whether we base SysML 1.4 on UML 2.4 or UML 2.5. Whether or not you happen to have tool support for the valueType keyword (the only one which needs to appear), we can always fix that by final editing on the EPS graphics imported by the spec. That's exactly we've done with the last two SysML versions, so none of this is new. It would require a substantial change across the entire SysML spec to change the capitalization conventions we've followed since SysML 1.0 (when all graphics were produced by Visio, which is at least one tool that supports SysML conventions). Could you produce a version of the diagrams without the block keywords, thus matching the style in diagrams D.8-D.10 in SysML 1.3 as closely as possible, so we can produce a version of the resolution for balloting? (The tool you use does support suppressing the stereotype keyword altogether on the shape.) Then you could send either the model source file or exported EPS graphics which I can put into the resolution. If need be, we can leave any remaining cleanup for the production of the final spec, as we ended up doing in the past. --Roger From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, May 07, 2013 3:09 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Sorry, I typed send before I finished editing my message. From: , JPL Date: Tuesday, May 7, 2013 1:08 PM To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Re: comments on stereotype keywords in ballot 5 issues 18435 and 18681 Roger, Is SysML 1.4 based on UML 2.4 or 2.5? If it is the latter, then there is a substantive issue because the keywords are incompatible. See UML 2.5, Annex C: At this time, I do not have tool support to produce SysML diagrams with the lowercase initial name for stereotypes that need to be shown, whether it is "block", "valueType", "modelLibrary" or anything else. To produce such diagrams, I would have to temporarily change the name of the stereotypes . that is: SysML::Blocks::block; SysML::Blocks::valueType. - Nicolas. From: Burkhart Roger M Date: Tuesday, May 7, 2013 9:37 AM To: "sysml-rtf@omg.org" Subject: comments on stereotype keywords in ballot 5 issues 18435 and 18681 In both of the most recently updated resolutions for Issue 18435, "QUDV Unit/QuantityKind name redundancy," and Issue 18681, "QUDV's support for measurement scales is impractical and duplicates existing capabilities with Enumeration and EnumerationLiterals," Nicolas added the following new paragraph at the end of the Resolution section: Per the resolution of issue 15729 in SysML 1.4 ballot 1, the SysML stereotype notation requires tool to show applications of stereotypes with their names converted to a lower-case initial name. This tool support is not available for the development of SysML 1.4; consequently, the diagrams below show the UML notation for applied stereotypes. There's no need to include any comments about a completedly unrelated issue (already approved) on stereotype capitalization. In SysML 1.3, the «block» keyword does not appear at all in diagrams D.8-D.10. The diagrams take advantage of the default Block stereotype on any rectangle shown in a bdd, and leave the keywords out entirely. One «valueType» keyword does appear, which uses the SysML convention of lowercase stereotype keywords. Since we have no issue to put such keywords into these diagrams, and we were clearly able to produce the needed diagrams in both SysML 1.2 and 1.3, I suggest we take the path of least resistance and just leave the «block» keywords out of these diagrams. This practice also results in less cluttered diagrams for the QUDV conceptual model. For the «valueType» keyword, we can use the same editorial correction as before in the EPS graphics imported by these diagrams. The proposed new D.9 diagram also incorrectly uses a stereotype keyword of «DataType», which should be replaced by «valueType» to match the existing diagram. I don't know that we've done a survey of which tools do or do not support SysML conventions on keywords, and in any event that's immaterial to the diagram conventions specified by SysML and followed by the diagrams in the specification. --Roger image0012.png