Issue 18269: SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit (sysml-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind. There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK. Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself. This notation could suggest that one could change the tag/values shown on the value property itself. It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself. This tool-specific practice in fact suggests that there is a missing capability; that is: QUDV unit and quantityKind could be specified on the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them) The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind) A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property) However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit. Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property. This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType) Suggest the following: Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind Add a new stereotype: ValueProperty extending UML::Property with: ValueProperty::unit : QUDV::Unit[0..1] ValueProperty::/effectiveUnit : QUDV::Unit[0..1] -- it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] -- it is derived from the ValueType::quantityKind of the type of the ValueProperty. Add a new stereotype: QuantityValue extending UML::ValueSpecification with: QuantityValue::unit : QUDV::Unit[0..1] QuantityValue::/unitConstraint : QUDV::Unit[0..1] -- if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue Resolution: Revised Text: Actions taken: November 20, 2012: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "sysml-rtf@omg.org" Subject: SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit Thread-Topic: SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit Thread-Index: AQHNx0UZuAqoC8OjeU+/V7KneY8DcA== Date: Tue, 20 Nov 2012 17:33:06 +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.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind. There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK. Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself. This notation could suggest that one could change the tag/values shown on the value property itself. It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself. This tool-specific practice in fact suggests that there is a missing capability; that is: QUDV unit and quantityKind could be specified on the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them) The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind) A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property) However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit. Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property. This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType) Suggest the following: Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind Add a new stereotype: ValueProperty extending UML::Property with: ValueProperty::unit : QUDV::Unit[0..1] ValueProperty::/effectiveUnit : QUDV::Unit[0..1] -- it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] -- it is derived from the ValueType::quantityKind of the type of the ValueProperty. Add a new stereotype: QuantityValue extending UML::ValueSpecification with: QuantityValue::unit : QUDV::Unit[0..1] QuantityValue::/unitConstraint : QUDV::Unit[0..1] -- if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue - Nicolas. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=GCrJJEveJ+AE/OncicmZxlNKQtc55f1Ai9m4qJSvKLQ=; b=0rs0qj+LRzBeprSdtW+fVBOD8lDhwFPCVm4p11gZSnAVuQg87q1iRU5B2VNtWuwDnQ wECzx1jngv5NuxX5r5rfq+T94g4bLBYiXhnCdzpG4X5Aatskf+k8C5lNmZ0V4nJBcoHk 0YLcoCA1C8XT8ei5XUpl14YGRX7fqijH0mUJNpUITpo4Mb0teq+Hvp8NslbPCIS2UpTd LHjNm9H6PmRClZeUpiclw0OLK6s7sL2JHmLOmxq0OtK+66fE7Mgxu43ffgcO1smF10Ab mFcjlqN7nSCoKyQW2EgVry4jJUE/GvSqGfhH7AmMIiR2/q0NSoJZr5l5540mcDKJuPpO OVmA== X-Received: by 10.66.86.71 with SMTP id n7mr15381452paz.77.1360316506796; Fri, 08 Feb 2013 01:41:46 -0800 (PST) From: "Sanford Friedenthal" To: "'Rouquette, Nicolas F \(313K\)'" Cc: Subject: RE: 18269 resolution Date: Fri, 8 Feb 2013 04:40:57 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOBRHlVFpLAy694U+flD2ZEqUGdJhvsuGQ X-Virus-Scanned: amavisd-new at omg.org Nicolas I have a general question regarding the proposed resolutions related to value types, units, values, and QUDV. Do the proposed resolutions address structured value types. In particular, assume a property .r. is typed by a value type called .Range. that contains 3 value properties x, y and z each typed by a value type called Kilometer (unit=meter and quantity kind=distance). We need to be able to assign values to r, x, y, and z. Does this resolution and the other updates support this use case? I have not been tracking closely enough, but want to make sure this is addressed. Thanks. Regards, Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, February 07, 2013 4:03 AM To: Conrad Bock; Grimes, James M (313A) Cc: sysml-rtf@omg.org Subject: 18269 resolution Here's an update of the resolution. It's on SVN along with the updated SysML 1.4 model in MagicDraw 17.0.2 http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR-v1.doc http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG.SysML1.4 RTF.mdzip - Nicolas. 18269_resolved-NFR-v11.doc Disposition: Resolved OMG Issue No: 18269 Title: SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Summary: In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind. There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK. Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself. This notation could suggest that one could change the tag/values shown on the value property itself. It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself. This tool-specific practice in fact suggests that there is a missing capability; that is: QUDV unit and quantityKind could be specified on . the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them) . The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind) . A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property) However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit. Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property. This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType) Suggest the following: 1. Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind 2. Add a new stereotype: ValueProperty extending UML::Property with: 1. ValueProperty::unit : QUDV::Unit[0..1] 2. ValueProperty::/effectiveUnit : QUDV::Unit[0..1] -- it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type 3. ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] -- it is derived from the ValueType::quantityKind of the type of the ValueProperty. 3. Add a new stereotype: QuantityValue extending UML::ValueSpecification with: 1. QuantityValue::unit : QUDV::Unit[0..1] 2. QuantityValue::/unitConstraint : QUDV::Unit[0..1] -- if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit 4. Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue Discussion: There are two separate aspects to this issue: 1) the duplication of the concepts of Unit and QuantityKind from the SysML profile and from the QUDV library 2) the notation for ValueType including TypedElements (e.g. Property, ValueSpecification) whose type is a ValueType Resolving the 2nd aspect of this issue depends on resolving the 1st aspect. Discussion about the duplication of the Unit and QuantityKind concepts Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the new ISO 80000-1 standard and a new conceptual model of Quantities, Units, Dimensions and Values (QUDV) was introduced only in the document as Annex C.5. The specification-level duplication became a practical problem in SysML 1.3 where the QUDV conceptual model became available as a non-normative machine-readable XMI artifact. With SysML 1.3, users and tool vendors have several options for modeling definitions of Units and QuantityKinds: - use the normative SysML stereotypes from the Blocks chapter - use the non-normative QUDV libraries from Annex D.4 - use both in combination (e.g., apply the <> stereotype to InstanceSpecifications classified by QUDV::Unit) These options multiply the cost of developing and maintaining libraries of Unit and QuantityKind definitions. The 3 different options above apply for defining a Unit or a QuantityKind. This means that there are 9 different options for defining the same pair of Unit/QuantityKind. Within the International System of Units alone, there are 20 decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has 14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table 5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed units and quantity kinds. It would be counter-productive and prohibitively expensive to attempt supporting nearly 10x different options of defining the same 1,260 pairs for just ISO 80000-1. SysML needs to adopt one option. Which one? Since the SysML Unit and QuantityKind stereotype provide a strict subset of the functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively replaces the SysML::Blocks::{Unit,QuantityKind} stereotypes with their QUDV Block counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being a Class stereotyped by SysML.s Block. Similarly, SysML::Blocks::QuantityKind changes from being a Stereotype to being a Class stereotyped by SysML.s Block. Having changed the nature of Unit and QuantityKind from a Stereotype to a Class means that Unit and QuantityKind are M1-level classes, not M2-level stereotype extensions of metaclasses, it is important to clarify how the new Class-based Unit and QuantityKind concepts are intended to be used for defining particular Units and QuantityKinds. In principle, there are three ways to define Units and QuantityKinds: 1. as M1-level InstanceSpecifications classified by SysML::Blocks::{Unit,QuantityKind} 2. as M1-level Classes specializing SysML::Blocks::{Unit,QuantityKind} 3. as M1-level Classes that are instances of M2-level metaclasses Unit and QuantityKind The 3rd approach is outside the scope of the nature of SysML as a profile (a profile cannot define new metaclasses). The 2nd approach requires fairly sophisticated tool support for specializing the associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind. This specialization requirement carries over to definitions of new ValueTypes where the association between ValueType and Unit/QuantityKind would have to be similarly specialized. This approach invites complications for users because it leads to asking what are the instances of Class-based definitions of a particular Unit or QuantityKind are and what InstanceSpecifications models of such instances mean. The 1st approach based on InstanceSpecifications approach avoids the complexity of the Class-based specialization of the 2nd approach. However, this InstanceSpecification-based approach requires careful attention that the UML tool provides adequate support for modeling link instances of associations as InstanceSpecifications with Slots for all the Association.s ends regardless of their ownership. This tool support is important for the unambiguous interpretation of an InstanceSpecification classified by an Asscoation as a representation of an instance of that Association between the InstanceSpecifications interepreted as representations of instances of the related Classifiers typing the ends of that Association. This resolution adopts the 1st approach, i.e., the M1-level InstanceSpecification based paradigm for defining Units and QuantityKinds. This approach then entails the following changes: - Changing the associations between SysML::Blocks::ValueType and SysML::Blocks::{Unit,QuantityKind} such that the ValueType::{unit,quantityKind} properties are typed by InstanceSpecification rather than the Unit/QuantityKind Stereotypes from SysML 1.3 (this involves adding OCL constraints such that a ValueType::unit must be an InstanceSpecification classified by a kind of Unit and a similar constraint for ValueType::quantityKind). - Separating the Unit and QuantityKind Block definitions from the QUDV annex so that they can be included in the normative SysML profile. This separation requires either refactoring the concept of QUDV::Scale to avoid making SysML::Blocks::QuantityKind in the normative profile depend on QUDV::Scale in the non-normative library or bringing in the concept of QUDV::Scale into the normative SysML profile. Problems with modeling scales in current SysML 1.3 From the point of view of the separation of the normative SysML profile with the non-normative QUDV annex, Figure 8.4 in 8.3.2 would change from the following in SysML 1.3: to the following: Because of the directed association from QuantityKind to Scale, moving QuantityKind from QUDV to the SysML profile requires also moving Scale and ScaleValueDefinition so as to maintain the normative SysML profile independent from the non-normative QUDV annex. However, this approach is undesirable due to 3 problems: a) This effectively makes the QUDV model of Scale and ScaleValueDefinition normative without having sufficient evidence to confirm that this is adequate b) Conceptually, defining a scale involves an InstanceSpecification classified by Scale. However, using a scale as the type of a SysML value property would require defining the same scale as a ValueType. The dual definition of a scale is impractical. c) In practice, defining a value for a scale involves an InstanceSpecification classified by ScaleValueDefinition and specifying a Number for its ScaleValueDefinition::value slot. However, this introduces a redundancy with a capability already available from UML via InstanceSpecification::specification : ValueSpecification[0..1]. If both capabilities are used, there could be differences that could be confusing for users. The following example illustrates these 3 problems: To address the usability three problems described abobe, Figure 8.4 above is refactored so that a scale (called .Measurement Scale. or .Quantity-Value Scale. in VIM3) becomes a kind of SysML ValueType with the added capability to specify an ordered set of values for that scale as shown below: With this capability, the simple example shown above that was problematic in SysML 1.3 becomes considerably simpler and more precise with this resolution: Discussion about the notation for ValueType Although SysML has had the basic concepts of Unit and QuantityKind (formerly known as Dimension in SysML 1.0 and 1.1), the SysML specification is surprisingly silent about the notation for a ValueType.s unit and quantityKind properties when the ValueType is used as the type of a value property of that of a value specification. The revisions address this gap in the SysML notation tables. Revised Text: In 2 Normative References, add the following: VIM Edition 3 (VIM3) .International vocabulary of metrology . Basic and general concepts and associated terms (VIM)., JCGM 200:2012 (JCGM 200:2008 with minor corrections). http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2012.pdf In 8.2.1, Table 8.1, change the entries showing SysML value properties with value specifications to reflect the possible combinations of concrete syntax notation explained in the following change. In 8.3.1.1 change the paragraph .Unit and QuantityKind definitions., currently: Unit and QuantityKind elements are defined using a rectangular box notation similar to a block, in which only the .unit. or .quantityKind. stereotype keyword, the name of the Unit or QuantityKind, and optionally the .quantityKind. property value of a Unit may appear. Even though the base metaclass of Unit and QuantityKind is InstanceSpecification, the name of a QuantityKind or Unit is not underlined, and no other graphical elements of a UML InstanceSpecification may be shown. The optional .quantityKind. property of a Unit and the .quantityKind. and/or .unit. properties of a ValueType are specified using standard stereotype property notations, which must refer by name to a QuantityKind or Unit which has already been defined separately and which is available for reference in the local namespace. A sample set of predefined quantity kinds and units is given in Annex C, Figure C.2. with the following: Unit and QuantityKind elements are defined using the rectangular box notation for InstanceSpecifications. Any InstanceSpecification that is classified by SysML.s Unit or a SysML Block that is a specialization of SysML.s Unit effectively defines a Unit. Two distinct InstanceSpecifications classified a kind of SysML Unit define the same Unit if their definitionURI are equivalent. Any InstanceSpecification that is classified by SysML.s QuantityKind or a SysML Block that is a specialization of SysML.s QuantityKind effectively defines a QuantityKind. Two distinct InstanceSpecifications classified by a kind of SysML QuantityKind define the same QuantityKind if their definitionURI are equivalent. The following diagram illustrates the principle of equivalence of InstanceSpecifications reprensenting the same Unit: In 8.3.1.1, change the 2nd paragraph of .Initial values compartment., currently: Values are specified in an initialValues compartment by lines in the form = or : = , each line of which specifies the initial value for one property owned either by the block that types the property or by any of its supertypes. This portion of concrete syntax is the same as may be shown for values within the UML instance specification notation, but this is the only element of UML InstanceSpecification notation that may be shown in an initial values compartment. See Section 8.3.2.2, .Block. for details of how values within initialValues compartments are represented in the SysML metamodel. with the following: Values are specified in an initialValues compartment by lines of the form = , each line of which specifies the initial value for one property owned by a block, a value type or any of their supertypes. A represents the concrete syntax of a SysML property as one of the following: (p1) (p2) : (p3) (p4) : Forms (p1) must always be applicable. Forms (p2) and (p4) must be applicable if and only if the has a non-null type. Forms (p3) and (p4) are applicable if and only if the type of the has the SysML ValueType stereotype applied. A represents the concrete syntax of a SysML value as one of the following: (v1) (v2) : (v3) (v4) : Forms (v1) must always be applicable. Forms (v2) and (v4) must be applicable if and only if the has a non-null type. Forms (v3) and (v4) are applicable if and only if the type of the has the SysML ValueType stereotype applied. The form represents the information about the value type that is typing a , a or both. This form can be one of the following: (uq1) {unit=} (uq2) {quantityKind=} (uq3) {unit=, quantityKind=} Form (uq1) must be applicable if and only if the value type has only a non-null unit and null quantityKind. Form (uq2) must be applicable if and only if the value type has only a non-null quantityKind and null unit. Form (uq3) must be applicable if the value type has a non-null unit and a non-null quantityKind. The forms and refer to information about the InstanceSpecification defining a Unit or QuantityKind respectively. Preference is for these forms to refer to the value of the symbol slot if available otherwise to the name (possibly qualified as a tool option) of the InstanceSpecification defining the Unit or QuantityKind respectively. This portion of concrete syntax is the same as may be shown for values within the UML instance specification notation, but this is the only element of UML InstanceSpecification notation that may be shown in an initial values compartment. See Section 8.3.2.2, .Block. for details of how values within initialValues compartments are represented in the SysML metamodel. The difference among these 5 forms depends on whether the property and its default value are typed by a SysML ValueType definition or not. In 8.3.2.2, change Figure 8.4, currently: with the following: In 8.3.2.8 QuantityKind, replace the 3rd sentence and following parenthesis, currently: QuantityKind is defined as a stereotype of InstanceSpecification, but it uses this metaclass only to define supporting elements for ValueType definitions. (The reuse of InstanceSpecification to define another metaclass is similar to the EnumerationLiteral metaclass in UML.) with the following: QuantityKind is defined as a non-abstract SysML Block. QuantityKind, or a specialization of it, serves for classifying an InstanceSpecification as a means of representing the definition of a particular QuantityKind in the sense of an .aspect common to mutually comparable quantities. [VIM3-1.2] where a SysML value property is understood to correspond to the VIM concept of .quantity. [VIM3-1.1] defined as a .property of a phenomenon, body or substance, where the property has a magnitude that can be expressed as a number and a reference. [VIM3-1.1]. The SysML concept of ValueType, and its quantityKind reference establishes the associative relationship between the VIM3 concepts of .quantity. modeled as a SysML value property and of .kind of quantity. modeled as the InstanceSpecification classified by a kind of SysML QuantityKind referenced in the value property.s ValueType definition. The semantics of InstanceSpecification classified by a kind of SysML QuantityKind is that two such InstanceSpecifications (in the same or different models) represent the same QuantityKind if and only if their definitionURI values are equivalent. In 8.3.2.9 Unit, replace the 2nd paragraph, currently: Unit is defined as a stereotype of InstanceSpecification, but it uses this metaclass only to define supporting elements for ValueType definitions. (The reuse of InstanceSpecification to define another metaclass is similar to the EnumerationLiteral metaclass in UML.) with the following: Unit is defined as a non-abstract SysML Block. Unit, or a specialization of it, serves for classifying an InstanceSpecification as a means of representing the definition of a particular Unit in the sense of a .real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ration of the two quantities as a number. [VIM3-1.9] where a SysML value property is understood to correspond to the VIM concept of .quantity. [VIM3-1.1] defined as a .property of a phenomenon, body or substance, where the property has a magnitude that can be expressed as a number and a reference. [VIM3-1.1]. The SysML concept of ValueType, and its unit reference establishes the associative relationship between the VIM3 concepts of .quantity. modeled as a SysML value property and of .real scalar quantity, defined and adopted by convention. modeled as the InstanceSpecification classified by a kind of SysML Unit referenced in the value property.s ValueType definition. The semantics of InstanceSpecification classified by a kind of SysML Unit is that two such InstanceSpecifications (in the same or different models) represent the same Unit if and only if their definitionURI values are equivalent. In 8.3.2.9 Unit, Attributes, replace .quantityKind., currently: quantityKind: QuantityKind [0..1]. A kind of quantity that may be stated by means of defined units, as identified by an instance of the QuantityKind. stereotype. with the following: quantityKind: QuantityKind [1..*]. A Unit may be associated to several QuantityKinds. This one-to-many association capability reflects a subtle but important note in [VIM3-1.9, NOTE2] which states that .measurement units of quantities of the same quantity dimension may be designated by the same name and symbol even when the quantities are not of the same kind. For example, joule per kelvin and J/K are respectively the name and symbol of both a measurement unit of heat capacity and a measurement unit of entropy, which are generally not considered to be quantities of the same kind.. primaryQuantityKind: QuantityKind [0..*] { subsets quantityKind }. If a Unit is associated to several QuantityKinds, this property supports designating a particular QuantityKind as primary for the Unit. In 8.3.2.10 ValueType, Attributes, replace quantityKind and unit, currently: quantityKind: QuantityKind [0..1]. A kind of quantity that may be stated by means of defined units, as identified by an instance of the QuantityKind. stereotype. A value type may optionally specify a quantity kind without any unit. Such a value has no concrete. representation, but may be used to express a value in an abstract form independent of any specific units. unit: Unit [0..1]. A quantity in terms of which the magnitudes of other quantities that have the same quantity kind can be stated, as. identified by an instance of the Unit stereotype. with the following: quantityKind: InstanceSpecification [0..1]. A kind of quantity that may be stated by means of defined units, as identified by an InstanceSpecification classified by a kind of SysML QuantityKind Block. A value type may optionally specify a quantity kind without any unit. Such a value has no concrete. representation, but may be used to express a value in an abstract form independent of any specific units. Due to the equivalence of QuantityKind-classified InstanceSpecifications with equivalent definitionURIs, distinct ValueTypes whose only differences are due to equivalent QuantityKind-classified InstanceSpecifications for their quantityKind properties should be considered equivalent as well. unit: InstanceSpecification [0..1]. A quantity in terms of which the magnitudes of other quantities that have the same quantity kind can be stated, as. identified by an InstanceSpecification classified by a kind of SysML Unit Block. Due to the equivalence of Unit-classified InstanceSpecifications with equivalent definitionURIs, distinct ValueTypes whose only differences are due to equivalent Unit-classified InstanceSpecifications for their unit properties should be considered equivalent as well. In 8.3.2.10 ValueType, constraints, add the following: [2] The unit of a ValueType must be an InstanceSpecification classified by SysML.s Unit Block or a specialization of it. inv: unit->notEmpty() and unit.classifier->notEmpty()implies unit.classifier->forAll(c | c.oclIsKindOf(Unit)) [3] The quantityKind of a ValueType must be an InstanceSpecification classified by SysML.s QuantityKind Block or a specialization of it. inv: quantityKind->notEmpty() and quantityKind.classifier->notEmpty() implies quantityKind.classifier->forAll(c | c.oclIsKindOf(QuantityKind)) Add the following after 8.3.2.10: 8.3.2.11 MeasurementScale Description A MeasurementScale is a kind of ValueType with the additional capability to specify an ordered set of scale values. This capability corresponds to the VIM concept of .quantity-value scale. or .measurement scale. [VIM3-1.27] defined as an .ordered set of quantity values of quantities of a given kind of quantity used in ranking, according to magnitude, quantities of that kind.. Attributes quantityValues : ValueSpecification[0..*] {ordered} When set, this property represents an explicit definition of the ordered set of quantity values for a measurement scale. If unset, the ordered set of quantity values is not explicitly represented, it is implicit in the definition of the measurement scale itself. Constraints [1] every quantity value specified must be classified by the measurement scale. inv: quantityValues->notEmpty() implies quantityValues->forAll(qv | qv.type = self) In 8.4.2, replace Figure 10, currently: with the following: Replace all of Annex D.4 .Model Library of SysML QuantityKinds and Units for ISO-80000-1. with the following: D.4 Model Library of SysML/QUDV QuantityKinds and Units for ISO-80000-1 - InstanceSpecifications based on SysML/QUDV for ISO-80000-1 - ValueTypes for legal combinations of PrefixedUnit + QuantityKind as specializations of SysML Number. Disposition: Resolved From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Fri, 8 Feb 2013 11:54:40 -0500 Subject: RE: 18269 resolution, alternative unit systems Thread-Topic: 18269 resolution, alternative unit systems Thread-Index: Ac4GHO1WgmgDncilRsKT/4xOJ8fhhg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Michael, > I second Sandy's request and also wish to add my issue that requires us to be > able to define alternative unit systems (e.g., English) and use both with a > SysML model. Nicolas can answer for 18269, but again remember the only problem being directly addressed in ballot 4 for units is to eliminate the redundancy between QUDV and SysML (it will also show how to give units to valuespecifications, which is just by example). If alternative unit systems fall out of eliminating redundancy, great, otherwise check that an issue is filed for the future. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Fri, 8 Feb 2013 08:05:15 -0500 Subject: RE: 18269 resolution, structured value types Thread-Topic: 18269 resolution, structured value types Thread-Index: Ac4F/Fy7m1BkEvsKRwGoaGGvycGbkA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Sandy, > I have a general question regarding the proposed resolutions related to > value types, units, values, and QUDV. Do the proposed resolutions address > structured value types. In particular, assume a property 'r' is typed by a > value type called 'Range' that contains 3 value properties x, y and z each > typed by a value type called Kilometer (unit=meter and quantity > kind=distance). We need to be able to assign values to r, x, y, and z. > > Does this resolution and the other updates support this use case? I have not > been tracking closely enough, but want to make sure this is addressed. This wasn't part of the discussion, so can't be in ballot 4 (see the end of the email below for what is covered in the units portion of this ballot). Check that you have an issue filed for your concern. Conrad -----Original Message----- From: Bock, Conrad Sent: Thursday, January 24, 2013 3:31 PM To: sysml-rtf@omg.org Subject: SysML RTF ballot 4 content and schedule SysMLers, The schedule and an overview of content for ballot 4 is appended below. Vendors: Review the WG material already posted (see links below) and send any major objections right away. Do not wait for resolutions to be written up from this material. WG leads: Update resolutions pulled from past ballots and any others you would like to address. Circulate drafts within the workgroup first, see schedule. Thx, Conrad Schedule: - WG leads circulate drafts in WG's by Feb 5. - WG leads send resolutions to Roger by Feb 15. - Chair posts draft ballot to RTF for review by Feb 18. - Voting starts March 4, ends March 18. Content: - Units: Redundancy of SysML and QUDV, and units on values, see topics 1 & 2 and links in http://tinyurl.com/bhk9zr5. - Common reference path: binary dependency restriction and unary/binary property paths, see slides 4-7 in http://tinyurl.com/bzcm2fr - Other issues WG leads provide, eg, issues pulled from previous ballots. http://www.omg.org/archives/sysml-rtf/msg03357.html http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Agroups%3Acommon_reference_path%3Aindex&cache=cache&media=rtf4:groups:common_reference_path:common-path-discussion-130124a.ppt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Rv21tJU7VPh2Me576DLG/xKT4U+6OOEzFuRQuVKQWwI=; b=PQ7IeCCekZRpATWsY7Mr8Fcq/nu5iIG1SevFdIpNqSpspNnHm2J1y5owMQc4zEQgLn 3kIzBU3GgCkxY5CmGPN8xZN1puc5Dte8+ihP2jA6K6Nqr6nttbHL++jrDYKzHf0pK2S9 dw6CBW7gFsc8Ivn3bIIcernS2I5TthDNbl1PwbWPJ2Aau/LMbmpXRqd8s7THEsMlLzvb owBGpWjHqilBhv2RypAVY6I73kFT3n4hb/+suihMRACUGdxKWISzxfeWg1hzv3lZWaza SQQg1OwWvWVj2seXlh/xB/RdXHt1N3INKGrlEyMqobLtV8O+ffXQF1lvBNxmAFJUr1kW CeEw== X-Received: by 10.66.85.161 with SMTP id i1mr19863865paz.67.1360351878161; Fri, 08 Feb 2013 11:31:18 -0800 (PST) From: "Sanford Friedenthal" To: "'Bock, Conrad'" , Subject: RE: 18269 resolution, structured value types Date: Fri, 8 Feb 2013 14:31:06 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4F/Fy7m1BkEvsKRwGoaGGvycGbkAANm6Ug X-Virus-Scanned: amavisd-new at omg.org Conrad I will but first want to hear back from Nicolas as to whether this is an issue or not. Sandy -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, February 08, 2013 8:05 AM To: sysml-rtf@omg.org Subject: RE: 18269 resolution, structured value types Sandy, > I have a general question regarding the proposed resolutions related to > value types, units, values, and QUDV. Do the proposed resolutions address > structured value types. In particular, assume a property 'r' is typed by a > value type called 'Range' that contains 3 value properties x, y and z each > typed by a value type called Kilometer (unit=meter and quantity > kind=distance). We need to be able to assign values to r, x, y, and z. > > Does this resolution and the other updates support this use case? I have not > been tracking closely enough, but want to make sure this is addressed. This wasn't part of the discussion, so can't be in ballot 4 (see the end of the email below for what is covered in the units portion of this ballot). Check that you have an issue filed for your concern. Conrad -----Original Message----- From: Bock, Conrad Sent: Thursday, January 24, 2013 3:31 PM To: sysml-rtf@omg.org Subject: SysML RTF ballot 4 content and schedule SysMLers, The schedule and an overview of content for ballot 4 is appended below. Vendors: Review the WG material already posted (see links below) and send any major objections right away. Do not wait for resolutions to be written up from this material. WG leads: Update resolutions pulled from past ballots and any others you would like to address. Circulate drafts within the workgroup first, see schedule. Thx, Conrad Schedule: - WG leads circulate drafts in WG's by Feb 5. - WG leads send resolutions to Roger by Feb 15. - Chair posts draft ballot to RTF for review by Feb 18. - Voting starts March 4, ends March 18. Content: - Units: Redundancy of SysML and QUDV, and units on values, see topics 1 & 2 and links in http://tinyurl.com/bhk9zr5. - Common reference path: binary dependency restriction and unary/binary property paths, see slides 4-7 in http://tinyurl.com/bzcm2fr - Other issues WG leads provide, eg, issues pulled from previous ballots. http://www.omg.org/archives/sysml-rtf/msg03357.html http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Agroups %3Acommon_reference_path%3Aindex&cache=cache&media=rtf4:groups:common_refere nce_path:common-path-discussion-130124a.ppt From: "Rouquette, Nicolas F (313K)" To: Sanford Friedenthal , "'Bock, Conrad'" , "sysml-rtf@omg.org" Subject: Re: 18269 resolution, structured value types Thread-Topic: 18269 resolution, structured value types Thread-Index: Ac4F/Fy7m1BkEvsKRwGoaGGvycGbkAANm6UgAAGdqoA= Date: Fri, 8 Feb 2013 20:17: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-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r18KHHHY022528 Sandy, There is nothing special about the case you mentioned - it boils down to a SysML value type defining 3 value properties (x,y,z). So, specifying a value involves a UML InstanceValue (a kind of ValueSpecification) that refers to a UML InstanceSpecification where values for the structural features can be specified with UML Slots. Since 18269 will refactor Unit, QuantityKind in the profile and in QUDV, we will need to have a resolution for refactoring the ISO-80000-1 library. I am hesitant to refactor the ISO-80000-1 library (including ValueType definitions) before we vote on ballot 4 because any change to Unit/QuantityKind have a huge impact on that library. As I explained in the discussion of the v1 resolution document, there are literally thousands of combinations of prefixes/units/quantity kinds. We have to proceed methodologically, one step at a time. - Nicolas. On 2/8/13 11:31 AM, "Sanford Friedenthal" wrote: >Conrad >I will but first want to hear back from Nicolas as to whether this is an >issue or not. >Sandy > >-----Original Message----- >From: Bock, Conrad [mailto:conrad.bock@nist.gov] >Sent: Friday, February 08, 2013 8:05 AM >To: sysml-rtf@omg.org >Subject: RE: 18269 resolution, structured value types > >Sandy, > > > I have a general question regarding the proposed resolutions related >to >> value types, units, values, and QUDV. Do the proposed resolutions >>address >> structured value types. In particular, assume a property 'r' is typed >>by a >> value type called 'Range' that contains 3 value properties x, y and z >>each >> typed by a value type called Kilometer (unit=meter and quantity > >kind=distance). We need to be able to assign values to r, x, y, and z. > > > > Does this resolution and the other updates support this use case? I >have >not > been tracking closely enough, but want to make sure this is >addressed. > >This wasn't part of the discussion, so can't be in ballot 4 (see the end >of >the email below for what is covered in the units portion of this ballot). >Check that you have an issue filed for your concern. > >Conrad > > >-----Original Message----- >From: Bock, Conrad >Sent: Thursday, January 24, 2013 3:31 PM >To: sysml-rtf@omg.org >Subject: SysML RTF ballot 4 content and schedule > >SysMLers, > >The schedule and an overview of content for ballot 4 is appended below. > >Vendors: > > Review the WG material already posted (see links below) and send any > major objections right away. Do not wait for resolutions to be > written up from this material. > >WG leads: > > Update resolutions pulled from past ballots and any others you would > like to address. Circulate drafts within the workgroup first, see > schedule. > >Thx, > >Conrad > > > Schedule: > > - WG leads circulate drafts in WG's by Feb 5. > > - WG leads send resolutions to Roger by Feb 15. > > - Chair posts draft ballot to RTF for review by Feb 18. > > - Voting starts March 4, ends March 18. > > Content: > > - Units: Redundancy of SysML and QUDV, and units on values, see > topics 1 & 2 and links in http://tinyurl.com/bhk9zr5. > > - Common reference path: binary dependency restriction and > unary/binary property paths, see slides 4-7 in > http://tinyurl.com/bzcm2fr > > - Other issues WG leads provide, eg, issues pulled from previous > ballots. > >http://www.omg.org/archives/sysml-rtf/msg03357.html > >http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Agrou >ps >%3Acommon_reference_path%3Aindex&cache=cache&media=rtf4:groups:common_refe >re >nce_path:common-path-discussion-130124a.ppt > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=1n6DwRvfHHpQF3TxCbdRLUaWQbmJdRziBmKm2YBh6SI=; b=JPmUx8yNHxjX0lzz6UeBNhUYClLbN+r9Efxva3OuHeNGAitT/+hgfFmf8iY/X3D/ud oTcsyGvgrFNHEDS1VWjQeXWP/lN9g4vRdQlUjGvHt620T7E0pwSYduO+yzYqpkuVs5A9 PvL/Sjr0AdmtiOJEj6iBFh+6vUhzSbVEJDC/9vlpFFVdV03zUNh5POWGWCIp1b4mRWIi wIcCYb3Bi9nxtuGKlWNOih0Q+Cu+Wh9qGP705w5aM1xDd5VcJFhXaUfKEt12M84y/Yxe Zu9PkVE+nJEQ3+N3ig1HJ7dsHYqPzVe09QD9Pk5qPoCvNYH1+So6WmjaH3yQTwIN8Z2x nXjQ== X-Received: by 10.66.73.164 with SMTP id m4mr33590039pav.12.1360497713781; Sun, 10 Feb 2013 04:01:53 -0800 (PST) From: "Sanford Friedenthal" To: "'Rouquette, Nicolas F \(313K\)'" , "'Bock, Conrad'" , Subject: RE: 18269 resolution, structured value types Date: Sun, 10 Feb 2013 07:01:40 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4F/Fy7m1BkEvsKRwGoaGGvycGbkAANm6UgAAGdqoAAU0Ho4A== X-Virus-Scanned: amavisd-new at omg.org Nicolas Thanks for the clarification and I am glad there is the structured value type use case is covered. Regards, Sandy -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, February 08, 2013 3:17 PM To: Sanford Friedenthal; 'Bock, Conrad'; sysml-rtf@omg.org Subject: Re: 18269 resolution, structured value types Sandy, There is nothing special about the case you mentioned - it boils down to a SysML value type defining 3 value properties (x,y,z). So, specifying a value involves a UML InstanceValue (a kind of ValueSpecification) that refers to a UML InstanceSpecification where values for the structural features can be specified with UML Slots. Since 18269 will refactor Unit, QuantityKind in the profile and in QUDV, we will need to have a resolution for refactoring the ISO-80000-1 library. I am hesitant to refactor the ISO-80000-1 library (including ValueType definitions) before we vote on ballot 4 because any change to Unit/QuantityKind have a huge impact on that library. As I explained in the discussion of the v1 resolution document, there are literally thousands of combinations of prefixes/units/quantity kinds. We have to proceed methodologically, one step at a time. - Nicolas. On 2/8/13 11:31 AM, "Sanford Friedenthal" wrote: >Conrad >I will but first want to hear back from Nicolas as to whether this is >an issue or not. >Sandy > >-----Original Message----- >From: Bock, Conrad [mailto:conrad.bock@nist.gov] >Sent: Friday, February 08, 2013 8:05 AM >To: sysml-rtf@omg.org >Subject: RE: 18269 resolution, structured value types > >Sandy, > > > I have a general question regarding the proposed resolutions > > related >to >> value types, units, values, and QUDV. Do the proposed resolutions >>address structured value types. In particular, assume a property 'r' >>is typed by a value type called 'Range' that contains 3 value >>properties x, y and z each typed by a value type called Kilometer >>(unit=meter and quantity > >kind=distance). We need to be able to assign values to r, x, y, and z. > > > > Does this resolution and the other updates support this use case? I >have >not > been tracking closely enough, but want to make sure this is >addressed. > >This wasn't part of the discussion, so can't be in ballot 4 (see the >end of the email below for what is covered in the units portion of this >ballot). >Check that you have an issue filed for your concern. > >Conrad > > >-----Original Message----- >From: Bock, Conrad >Sent: Thursday, January 24, 2013 3:31 PM >To: sysml-rtf@omg.org >Subject: SysML RTF ballot 4 content and schedule > >SysMLers, > >The schedule and an overview of content for ballot 4 is appended below. > >Vendors: > > Review the WG material already posted (see links below) and send any > major objections right away. Do not wait for resolutions to be > written up from this material. > >WG leads: > > Update resolutions pulled from past ballots and any others you would > like to address. Circulate drafts within the workgroup first, see > schedule. > >Thx, > >Conrad > > > Schedule: > > - WG leads circulate drafts in WG's by Feb 5. > > - WG leads send resolutions to Roger by Feb 15. > > - Chair posts draft ballot to RTF for review by Feb 18. > > - Voting starts March 4, ends March 18. > > Content: > > - Units: Redundancy of SysML and QUDV, and units on values, see > topics 1 & 2 and links in http://tinyurl.com/bhk9zr5. > > - Common reference path: binary dependency restriction and > unary/binary property paths, see slides 4-7 in > http://tinyurl.com/bzcm2fr > > - Other issues WG leads provide, eg, issues pulled from previous > ballots. > >http://www.omg.org/archives/sysml-rtf/msg03357.html > >http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Ag >rou >ps >%3Acommon_reference_path%3Aindex&cache=cache&media=rtf4:groups:common_r >efe >re >nce_path:common-path-discussion-130124a.ppt > From: "Chonoles, Michael J" To: "safriedenthal@gmail.com" , "'Rouquette, Nicolas F (313K)'" CC: "sysml-rtf@omg.org" Subject: RE: EXTERNAL: RE: 18269 resolution Thread-Topic: EXTERNAL: RE: 18269 resolution Thread-Index: AQHOBRHlVFpLAy694U+flD2ZEqUGdJhvsuGQgAB0hWA= Date: Fri, 8 Feb 2013 16:25:38 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.81] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2013-02-08_07:2013-02-08,2013-02-08,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org I second Sandy.s request and also wish to add my issue that requires us to be able to define alternative unit systems (e.g., English) and use both with a SysML model. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Friday, February 08, 2013 4:41 AM To: 'Rouquette, Nicolas F (313K)' Cc: sysml-rtf@omg.org Subject: EXTERNAL: RE: 18269 resolution Nicolas I have a general question regarding the proposed resolutions related to value types, units, values, and QUDV. Do the proposed resolutions address structured value types. In particular, assume a property .r. is typed by a value type called .Range. that contains 3 value properties x, y and z each typed by a value type called Kilometer (unit=meter and quantity kind=distance). We need to be able to assign values to r, x, y, and z. Does this resolution and the other updates support this use case? I have not been tracking closely enough, but want to make sure this is addressed. Thanks. Regards, Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, February 07, 2013 4:03 AM To: Conrad Bock; Grimes, James M (313A) Cc: sysml-rtf@omg.org Subject: 18269 resolution Here's an update of the resolution. It's on SVN along with the updated SysML 1.4 model in MagicDraw 17.0.2 http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR-v1.doc http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG.SysML1.4 RTF.mdzip - Nicolas. From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , Burkhart Roger M CC: "sysml-rtf@omg.org" Subject: Primitive Types & Values WG: 18269 resolution v2 (units/qk) Thread-Topic: Primitive Types & Values WG: 18269 resolution v2 (units/qk) Thread-Index: AQHOB9feEojvM0WHiEaPrF32mMgZ6Q== Date: Sun, 10 Feb 2013 21:44:57 +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 Following the SysML RTF discussion on 2013-02-07, I revised the resolution for 18269 to address only the duplication of Unit/QuantityKind. The attached document is also available on the Primitive Types & Values WG page and in SVN where there is a MagicDraw 17.0.2 model of OMG SysML 1.3 with the changes for 18269 applied. http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR-v2.doc http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG-SysML1.3+18269.mdzip - Nicolas. 18269_resolved-NFR-v2.doc Disposition: Resolved OMG Issue No: 18269 Title: SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Summary: In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind. There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK. Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself. This notation could suggest that one could change the tag/values shown on the value property itself. It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself. This tool-specific practice in fact suggests that there is a missing capability; that is: QUDV unit and quantityKind could be specified on . the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them) . The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind) . A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property) However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit. Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property. This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType) Suggest the following: 1. Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind 2. Add a new stereotype: ValueProperty extending UML::Property with: 1. ValueProperty::unit : QUDV::Unit[0..1] 2. ValueProperty::/effectiveUnit : QUDV::Unit[0..1] -- it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type 3. ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] -- it is derived from the ValueType::quantityKind of the type of the ValueProperty. 3. Add a new stereotype: QuantityValue extending UML::ValueSpecification with: 1. QuantityValue::unit : QUDV::Unit[0..1] 2. QuantityValue::/unitConstraint : QUDV::Unit[0..1] -- if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit 4. Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue Discussion: This resolution addresses only the issue of the duplication of the concepts of Unit and QuantityKind between the SysML profile and the QUDV library. A separate resolution will address the issue of the notation for ValueType, including TypedElements (e.g. Property, ValueSpecification) typed by a ValueType. Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the new ISO 80000-1 standard and a new conceptual model of Quantities, Units, Dimensions and Values (QUDV) was introduced only in the document as Annex C.5. The specification-level duplication became a practical problem in SysML 1.3 where the QUDV conceptual model became available as a non-normative machine-readable XMI artifact. With SysML 1.3, users and tool vendors have several options for modeling definitions of Units and QuantityKinds: - use the normative SysML stereotypes from the Blocks chapter - use the non-normative QUDV libraries from Annex D.4 - use both in combination (e.g., apply the <> stereotype to InstanceSpecifications classified by QUDV::Unit) These options multiply the cost of developing and maintaining libraries of Unit and QuantityKind definitions. The 3 different options above apply for defining a Unit or a QuantityKind. This means that there are 9 different options for defining the same pair of Unit/QuantityKind. Within the International System of Units alone, there are 20 decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has 14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table 5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed units and quantity kinds. It would be counter-productive and prohibitively expensive to attempt supporting nearly 10x different options of defining the same 1,260 pairs for just ISO 80000-1. SysML needs to adopt one option. Which one? Since the SysML Unit and QuantityKind stereotype provide a strict subset of the functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively replaces the SysML::Blocks::{Unit,QuantityKind} stereotypes with their QUDV Block counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being a Class stereotyped by SysML.s Block. Similarly, SysML::Blocks::QuantityKind changes from being a Stereotype to being a Class stereotyped by SysML.s Block. Having changed the nature of Unit and QuantityKind from a Stereotype to a Class means that Unit and QuantityKind are M1-level classes, not M2-level stereotype extensions of metaclasses, it is important to clarify how the new Class-based Unit and QuantityKind concepts are intended to be used for defining particular Units and QuantityKinds. In principle, there are three ways to define Units and QuantityKinds: 1. as M1-level InstanceSpecifications classified by SysML::Blocks::{Unit,QuantityKind} 2. as M1-level Classes specializing SysML::Blocks::{Unit,QuantityKind} 3. as M1-level Classes that are instances of M2-level metaclasses Unit and QuantityKind The 3rd approach is outside the scope of the nature of SysML as a profile (a profile cannot define new metaclasses). The 2nd approach requires fairly sophisticated tool support for specializing the associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind. Modeling association specialization is a challenging topic in UML because the mechanisms involved (i.e., generalization, redefinition, subsetting) have subtle distinctions (e.g., subsetting and redefinition are, respectively, in the domain of extensional vs. intentional semantics respectively) and the consequences of their combinations are difficult to analyze (e.g., disjoint vs. overlapping specialization). These modeling challenge carry over to definitions of new ValueTypes where the associations between ValueType and Unit/QuantityKind have to be specialized as well. The specialization approach is particularly challenging to understand because it inherently leads to asking questions about the meaning of the class-based specializations of Unit/QuantityKind and about the existence and meaning of instances of these classes. The 1st approach based on InstanceSpecifications approach avoids the complexity of the Class-based specialization of the 2nd approach. However, this InstanceSpecification-based approach requires careful attention about the UML tool support for modeling link instances of associations. In particular, such links must be fully specified with slots for each association.s end property regardless of its ownership by the association or classifier typing the opposite end. This tool support is important for the unambiguous interpretation of an InstanceSpecification classified by an Association as a representation of an instance of that Association between the InstanceSpecifications interepreted as representations of instances of the related Classifiers typing the ends of that Association. This resolution adopts the 1st approach, i.e., the M1-level InstanceSpecification based paradigm for defining Units and QuantityKinds. To maintain the separation between the normative SysML profile and the non-normative QUDV conceptual model, this approach entails separating the part of QUDV.s Unit and QuantityKind Blocks that correspond to the capability of the SysML 1.3 Unit and refactoring the rest as QUDV specializations. Because this resolution effectively promotes the QUDV concepts of Unit and QuantityKind into the normative SysML profile, the relationship between these concepts and the VIM3 terminology is also clarified. Revised Text: In 2 Normative References, add the following: VIM Edition 3 (VIM3) .International vocabulary of metrology . Basic and general concepts and associated terms (VIM)., JCGM 200:2012 (JCGM 200:2008 with minor corrections). http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2012.pdf In 8.2.1, Table 8.1, change the entries showing SysML value properties with value specifications to reflect the possible combinations of concrete syntax notation explained in the following change. In 8.3.1.1 change the paragraph .Unit and QuantityKind definitions., currently: Unit and QuantityKind elements are defined using a rectangular box notation similar to a block, in which only the .unit. or .quantityKind. stereotype keyword, the name of the Unit or QuantityKind, and optionally the .quantityKind. property value of a Unit may appear. Even though the base metaclass of Unit and QuantityKind is InstanceSpecification, the name of a QuantityKind or Unit is not underlined, and no other graphical elements of a UML InstanceSpecification may be shown. The optional .quantityKind. property of a Unit and the .quantityKind. and/or .unit. properties of a ValueType are specified using standard stereotype property notations, which must refer by name to a QuantityKind or Unit which has already been defined separately and which is available for reference in the local namespace. A sample set of predefined quantity kinds and units is given in Annex C, Figure C.2. with the following: Unit and QuantityKind elements are defined using the rectangular box notation for InstanceSpecifications. That is: 1) Any InstanceSpecification classified by SysML.s Unit or one of its specializations effectively defines a particular Unit identified by its definitionURI. That is, two InstanceSpecifications classified by a kind of SysML Unit represent the same Unit conceptually if their definitionURI are the same. 2) Any InstanceSpecification classified by SysML.s QuantityKind or one of its specializations effectively defines a particular QuantityKind identified by its definitionURI. That is, two InstanceSpecifications classified by a kind of SysML QuantityKind represent the same QuantityKind if their definitionURI are the same. From the perspective of instances representing the definition of the SysML Unit and QuantityKind blocks, two distinct models, Model1 and Model2, can each have a representation of the SI metre. These two representations are distinct (because they are in distinct models); however, semantically, they are representations of the same conceptual Unit, i.e., the SI metre defined by the Bureau des Poids et Measures (BIPM): In 8.3.2.2, change Figure 8.4, currently: with the following: In 8.3.2.8 QuantityKind, replace the 3rd sentence and following parenthesis, currently: QuantityKind is defined as a stereotype of InstanceSpecification, but it uses this metaclass only to define supporting elements for ValueType definitions. (The reuse of InstanceSpecification to define another metaclass is similar to the EnumerationLiteral metaclass in UML.) with the following: QuantityKind is defined as a non-abstract SysML Block. QuantityKind, or a specialization of it, serves for classifying an InstanceSpecification as a means of representing the definition of a particular QuantityKind in the sense of an .aspect common to mutually comparable quantities. [VIM3-1.2] where a SysML value property is understood to correspond to the VIM concept of .quantity. [VIM3-1.1] defined as a .property of a phenomenon, body or substance, where the property has a magnitude that can be expressed as a number and a reference. [VIM3-1.1]. Two InstanceSpecifications classified by a kind of SysML QuantityKind represent the same QuantityKind conceptually if their definitionURI are the same. The SysML concept of ValueType, and its quantityKind reference establishes the associative relationship between the VIM3 concepts of .quantity. (modeled as a SysML value property typed by such a ValueType) and of .kind of quantity. (the ValueType::quantityKind reference, which is an InstanceSpecification classified by a kind of SysML QuantityKind). In 8.3.2.9 Unit, replace the 2nd paragraph, currently: Unit is defined as a stereotype of InstanceSpecification, but it uses this metaclass only to define supporting elements for ValueType definitions. (The reuse of InstanceSpecification to define another metaclass is similar to the EnumerationLiteral metaclass in UML.) with the following: Unit is defined as a non-abstract SysML Block. Unit, or a specialization of it, serves for classifying an InstanceSpecification as a means of representing the definition of a particular Unit in the sense of a .real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ration of the two quantities as a number. [VIM3-1.9] where a SysML value property is understood to correspond to the VIM concept of .quantity. [VIM3-1.1] defined as a .property of a phenomenon, body or substance, where the property has a magnitude that can be expressed as a number and a reference. [VIM3-1.1]. Two InstanceSpecifications classified by a kind of SysML Unit represent the same Unit conceptually if their definitionURI are the same. The SysML concept of ValueType, and its unit reference establishes the associative relationship between the VIM3 concepts of .quantity. (modeled as a SysML value property) and of .real scalar quantity, defined and adopted by convention. (modeled as the InstanceSpecification classified by a kind of SysML Unit referenced in the value property.s ValueType definition). In 8.3.2.9 Unit, Attributes, replace .quantityKind., currently: quantityKind: QuantityKind [0..1]. A kind of quantity that may be stated by means of defined units, as identified by an instance of the QuantityKind. stereotype. with the following: quantityKind: QuantityKind [0..*]. A Unit may be associated to several QuantityKinds. This one-to-many association capability reflects a subtle but important note in [VIM3-1.9, NOTE2] which states that .measurement units of quantities of the same quantity dimension may be designated by the same name and symbol even when the quantities are not of the same kind. For example, joule per kelvin and J/K are respectively the name and symbol of both a measurement unit of heat capacity and a measurement unit of entropy, which are generally not considered to be quantities of the same kind.. In 8.3.2.10 ValueType, Attributes, replace quantityKind and unit, currently: quantityKind: QuantityKind [0..1]. A kind of quantity that may be stated by means of defined units, as identified by an instance of the QuantityKind. stereotype. A value type may optionally specify a quantity kind without any unit. Such a value has no concrete. representation, but may be used to express a value in an abstract form independent of any specific units. unit: Unit [0..1]. A quantity in terms of which the magnitudes of other quantities that have the same quantity kind can be stated, as. identified by an instance of the Unit stereotype. with the following: quantityKind: InstanceSpecification [0..1]. A kind of quantity that may be stated by means of defined units, as identified by an InstanceSpecification classified by a kind of SysML QuantityKind Block. A value type may optionally specify a quantity kind without any unit. Such a value has no concrete. representation, but may be used to express a value in an abstract form independent of any specific units. Due to the equivalence of QuantityKind-classified InstanceSpecifications with equivalent definitionURIs, distinct ValueTypes whose only differences are due to equivalent QuantityKind-classified InstanceSpecifications for their quantityKind properties should be considered equivalent as well. unit: InstanceSpecification [0..1]. A quantity in terms of which the magnitudes of other quantities that have the same quantity kind can be stated, as. identified by an InstanceSpecification classified by a kind of SysML Unit Block. Due to the equivalence of Unit-classified InstanceSpecifications with equivalent definitionURIs, distinct ValueTypes whose only differences are due to equivalent Unit-classified InstanceSpecifications for their unit properties should be considered equivalent as well. In 8.3.2.10 ValueType, constraints, add the following: [2] The unit of a ValueType must be an InstanceSpecification classified by SysML.s Unit Block or a specialization of it. inv: unit->notEmpty() and unit.classifier->notEmpty()implies unit.classifier->forAll(c | c.oclIsKindOf(Unit)) [3] The quantityKind of a ValueType must be an InstanceSpecification classified by SysML.s QuantityKind Block or a specialization of it. inv: quantityKind->notEmpty() and quantityKind.classifier->notEmpty() implies quantityKind.classifier->forAll(c | c.oclIsKindOf(QuantityKind)) inv: quantityValues->notEmpty() implies quantityValues->forAll(qv | qv.type = self) In D.5.2, QUDV Abstract Syntax, replace Figure D.8 currently: with the following: Replace Figure D.9, currently: with the following: Replace Figure D.10, currently: with the following: In D.5.2.10, QuantityKind, replace the description, currently: A QuantityKind is an abstract classifier that represents the [VIM] concept of .kind of quantity. that is defined as .aspect common to mutually comparable quantities.. A QuantityKind represents the essence of a quantity without any numerical value or unit. Quantities of the same kind within a given system of quantities have the same quantity dimension. However, quantities of the same dimension are not necessarily of the same kind. with the following: In QUDV, the concept of QuantityKind is an abstract specialization of SysML QuantityKind to support designating a primary QuantityKind for a given Unit within the scope of a system of units and quantities and to support a richer vocabulary for defining QuantityKinds. In D.5.2.10, QuantityKind, Properties, delete the following: . symbol: String [0..1]. Short symbolic name of the kind of quantity. . description: String [0..1]. Textual description of the kind of quantity. . definitionURI: String [0..1]. URI that references an external definition of the kind of quantity. In D.5.2.20, Unit, replace the description, currently: A Unit is an abstract classifier that represents the [VIM] concept of .measurement unit. that is defined as .real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the two quantities as a number.. with the following: In QUDV, the concept of Unit is an abstract specialization of SysML Unit to support designating a primary QuantityKind for a given Unit within the scope of a system of units and quantities and to support a richer vocabulary for defining Units. In D.5.2.20, Unit, Properties, delete the following: . symbol: String [0..1]. Short symbolic name of the unit. . description: String [0..1]. Textual description of the unit. . definitionURI: String [0..1]. URI that references an external definition of the unit. . quantityKind : QuantityKind[0..*]. Since a Unit is a particular value for a quantity of a given kind, every Unit must be the measurementUnit of at least. one QuantityKind. In D.5.3, References, replace the first reference, currently: [VIM]. JCGM 200:2008, International Vocabulary of Metrology - Basic and General Concepts and Associated Terms (VIM), 3rd edition, 2008, BIPM, Paris, France. Available for download in PDF format from BIPM's website http://www.bipm.org. This third edition is also published on paper by ISO (ISO/IEC Guide 99-12:2007, International Vocabulary of Metrology . Basic and General Concepts and Associated Terms, VIM). with the following: [VIM3]. JCGM 200:2013, International vocabulary of metrology . Basic and general concepts and associated terms (VIM), 3rd edition (JCGM 200:2008 with minor corrections), 2012, BIPM, Paris, France. http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2012.pdf Disposition: Resolved From: "Rouquette, Nicolas F (313K)" To: Conrad Bock , Burkhart Roger M CC: "sysml-rtf@omg.org" Subject: 18269 resolution, v3 Thread-Topic: 18269 resolution, v3 Thread-Index: AQHODAfd7hd6xKWnhESuyoR8KWab7w== Date: Sat, 16 Feb 2013 05:38:36 +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 It's on the wiki: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:primitive_types_values:index It's also in SVN: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR-v3.doc There is an updated OMG SysML 1.3 + 18269 model in MagicDraw 17.0.2 here: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG-SysML1.3+18269.mdzip There is an updated Visio file for the entries in Table 8.1 here: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/SysML V1.4 Chapter 8 Blocks NFR.vsd - Nicolas. From: "Rouquette, Nicolas F (313K)" To: Conrad Bock , Burkhart Roger M CC: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Subject: 18269, v4 and 18456, v1 Thread-Topic: 18269, v4 and 18456, v1 Thread-Index: AQHODK3C6AO2kPzwgUG7nNoCc7T2dQ== Date: Sun, 17 Feb 2013 01:26:06 +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.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Attached is an update for 18269 (v4) which also solves 18456 (v1) The resolutions are on the wiki: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:primitive_types_values:index http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:cover_preface_part_i:index And in SVN: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR-v4.doc http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18456_resolved_NFR_v1.doc There is an updated MagicDraw 17.0.2 model for 18269 and 18456 as well: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 JPL/OMG-SysML1.3+18269+18456.mdzip If you open this model, you may get some problems . it's difficult to avoid confusing modeling tools in general when we work on models of OMG specs they implement! - Nicolas. 18269_resolved-NFR-v4.doc 18456_resolved_NFR_v1.doc X-Virus-Scanned: Content Filter at mail-gw.estec.esa.int To: "Rouquette, Nicolas F (313K)" Cc: Burkhart Roger M , Conrad Bock , "sysml-rtf@omg.org" Subject: Re: 18269, v5 X-KeepSent: 950D1922:FE116659-C1257B1C:0046D4B3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Hans-Peter.de.Koning@esa.int Date: Sun, 24 Feb 2013 15:26:39 +0100 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 8.5.2FP1|November 29, 2010) at 24/02/2013 15.26.52 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Nicolas, Finally I got round to reviewing the resolution. (In the meantime my wife had a small bicycle accident, broke her finger and we spent a whole night in the hospital Friday...) I have reviewed the resolution as attached, v4 because I do not have access to the OMG wiki / svn. I only have some minor corrections and suggestions, they may overlap with v5, but the overall resolution looks very sound to me. 1) There were some misspellings of Dybkaer's name, probably originating from my own misspellings (Dykbaer, Dybkear, ...) in my earlier mail referencing his work. 2) There remains another small issue with allowing only Rational numbers to define the conversion factor for LinearConversionUnit and AffineConversionUnit. We need to allow also Real numbers, e.g. to define the conversion factor with value ð0 for the "degree" LinearConversionUnit with respect to the "radian" DerivedUnit (derived from unit "one") as a referenceUnit. We can resolve this by replacing the references to Rational in QUDV definitions of specializations of Unit with Number, so conversion factors can be expressed as Real, Integer or Rational numbers, i.e.: - in LinearConversionUnit factor : Number - in AffineConversionUnit factor : Number offset : Number 3) In line with [VIM3-1.7] it would be good to disambiguate "Dimension" by renaming it to "QuantityDimension". Dimension by itself is of course a heavily overloaded concept / homonym in science and engineering. 4) It is still my opinion that in a future upgrade of the QUDV we need to give measurement scale (or "quantity-value scale" as it is defined in [VIM3-1.27]) the proper prominence to achieve a fully generic definition of numerical value types and properties. I have now a fully elaborated version of such a QSUDV (Quantities, Scales, Units, Dimensions and Values) module in our ECSS E-TM-10-25 data model, also including any kind of composite (i.e. non-scalar) value types. I guess there is no time to get this into the current SysML v1.4 RTF, so I will propose it for SysML v2. 5) The attached document 18456_resolved_NFR_v1.doc in your earlier mail actually contained a resolution numbered 18435. Its content looks ok to me. Best regards, Hans Peter ESA - European Space Agency Hans Peter de Koning System Engineer Systems and Concurrent Engineering Section (mail code: TEC-SYE) Systems, Software and Technology Department ESTEC (European Space Research and Technology Centre) Keplerlaan 1, 2201 AZ Noordwijk, The Netherlands (visits & courier) P.O. Box 299, 2200 AG Noordwijk, The Netherlands (regular mail) Hans-Peter.de.Koning@esa.int | http://www.esa.int/cdf T: +31 71 56 53452 | F: +31 71 56 56024 From: "Rouquette, Nicolas F (313K)" To: Conrad Bock , Burkhart Roger M , Cc: "sysml-rtf@omg.org" , "Hans-Peter.de.Koning@esa.int" Date: 2013-02-17 23:45 Subject: 18269, v5 -------------------------------------------------------------------------------- Hopefully, v5 is last revision of 18269 for ballot 4. It's on the wiki: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:primitive_types_values:index And in SVN: http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR-v5.doc No change to the model. - Nicolas. This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. 18269_resolved-NFR-v4-HPdK.doc From: "Chonoles, Michael J" To: "nicolas.f.rouquette@jpl.nasa.gov" , Burkhart Roger M , Conrad Bock , Lonnie VanZandt CC: "sysml-rtf@omg.org" Subject: RE: SysML RTF telecon, Feb 28, ballot 4 notes Thread-Topic: SysML RTF telecon, Feb 28, ballot 4 notes Thread-Index: Ac4V1hN9M2uNya/9QIWAeDHdAAXSfAAv7pcAAAEcw4AAGOUuQA== Date: Sat, 2 Mar 2013 04:59:11 +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.9.8327,1.0.431,0.0.0000 definitions=2013-03-02_02:2013-03-01,2013-03-02,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r224xXQP015907 18269 Questions 1) The 8.4 diagram supplied indicates that a ValueType has an optiona unit and an optional qualitykind. However, 8.3.2.10 the OCL seems to say that the unit must be there. Please clarify the text with the optional nature of the Unit. Also look at quantitykind. 2) IF the URI is optional, does that mean the model-interchange won't recognize that the units/kinds are the same, or that a model will also have that problem internally. 3) BTW, I didn't see a constraint that the unit and quantitykinds are part of the same system of units or system or quantities. This is ok with me though 4) Figure D8. I'm probably dense, but I don't understand how the base Unit is abstract yet is subclass of the concrete Unit -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, March 01, 2013 11:32 AM To: Burkhart Roger M; Conrad Bock; Lonnie VanZandt Cc: sysml-rtf@omg.org Subject: EXTERNAL: Re: SysML RTF telecon, Feb 28, ballot 4 notes Another update that fixes the visibility in other figures in the resolution. The updated document is also on the wiki and in SVN along with the updated model. - Nicolas. On 3/1/13 7:59 AM, "Rouquette, Nicolas F (313K)" wrote: >Attached is the updated 18269 resolution per the telecon discussion. > >I managed to remove all MagicDraw-illities; the figures should be kosher >with the spec. > >It's on the wiki: >http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:primitiv >e >_types_values:index >and in SVN: http://svn.omg.org/repos/SysML/branches/SysML 1.4 >RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR3.doc >along with the updated model: >http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 >JPL/OMG-SysML1.3+18269+18456.mdzip > >- Nicolas. > >On 2/28/13 9:08 AM, "Bock, Conrad" wrote: > >>SysMLers, >> >>Notes from the review of ballot 4 today are at >>http://tinyurl.com/c4vbore. Main points: >> >> - Final changes for the ballot must be sent to Roger by COB tomorrow >> (Friday, March 1). >> >> - Corrections for Units and QK are on Slide 5 (four for Nicolas, one >> for Roger). >> >>We also had a shorter version of the Variant WG overview, see >>http://www.omg.org/archives/sysml-rtf/msg03512.html (was actually Feb >>27). >> >>Conrad >> >>http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Amee >>t >>ing_minutes&cache=cache&media=rtf4:meetings:rtf-general-130228_b.ppt > From: "Chonoles, Michael J" To: "Chonoles, Michael J" , "nicolas.f.rouquette@jpl.nasa.gov" , Burkhart Roger M , Conrad Bock , Lonnie VanZandt CC: "sysml-rtf@omg.org" Subject: RE: SysML RTF telecon, Feb 28, ballot 4 notes Thread-Topic: SysML RTF telecon, Feb 28, ballot 4 notes Thread-Index: Ac4V1hN9M2uNya/9QIWAeDHdAAXSfAAv7pcAAAEcw4AAGOUuQAAxWwmA Date: Sun, 3 Mar 2013 04:13:04 +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.9.8327,1.0.431,0.0.0000 definitions=2013-03-03_01:2013-03-01,2013-03-03,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r234DRPO031323 X-Brightmail-Tracker: AAAAAx0YzSgdGb8NHRnTgw== X-Brightmail-Tracker: AAAAAA== Another question about the definitionURI The proposal says that the two units are the same if there definitionURIs have the same value. I didn't see any discussion on how that would be evaluated. For example, are they checked as strings or as they checked by where they point to. For example, would www.lmco.com match http://166.21.32.81/? This should be made explicit how the equality is expected to work. Thanks Michael -----Original Message----- From: Chonoles, Michael J [mailto:listmanager@omg.org] Sent: Friday, March 01, 2013 11:59 PM To: nicolas.f.rouquette@jpl.nasa.gov; Burkhart Roger M; Conrad Bock; Lonnie VanZandt Cc: sysml-rtf@omg.org Subject: EXTERNAL: RE: SysML RTF telecon, Feb 28, ballot 4 notes 18269 Questions 1) The 8.4 diagram supplied indicates that a ValueType has an optiona unit and an optional qualitykind. However, 8.3.2.10 the OCL seems to say that the unit must be there. Please clarify the text with the optional nature of the Unit. Also look at quantitykind. 2) IF the URI is optional, does that mean the model-interchange won't recognize that the units/kinds are the same, or that a model will also have that problem internally. 3) BTW, I didn't see a constraint that the unit and quantitykinds are part of the same system of units or system or quantities. This is ok with me though 4) Figure D8. I'm probably dense, but I don't understand how the base Unit is abstract yet is subclass of the concrete Unit -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, March 01, 2013 11:32 AM To: Burkhart Roger M; Conrad Bock; Lonnie VanZandt Cc: sysml-rtf@omg.org Subject: EXTERNAL: Re: SysML RTF telecon, Feb 28, ballot 4 notes Another update that fixes the visibility in other figures in the resolution. The updated document is also on the wiki and in SVN along with the updated model. - Nicolas. On 3/1/13 7:59 AM, "Rouquette, Nicolas F (313K)" wrote: >Attached is the updated 18269 resolution per the telecon discussion. > >I managed to remove all MagicDraw-illities; the figures should be kosher >with the spec. > >It's on the wiki: >http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf4:groups:primitiv >e >_types_values:index >and in SVN: http://svn.omg.org/repos/SysML/branches/SysML 1.4 >RTF/Documents/Resolutions/1.4/Ballot4/18269_resolved-NFR3.doc >along with the updated model: >http://svn.omg.org/repos/SysML/branches/SysML 1.4 RTF/Models/1.4/MD17.0.2 >JPL/OMG-SysML1.3+18269+18456.mdzip > >- Nicolas. > >On 2/28/13 9:08 AM, "Bock, Conrad" wrote: > >>SysMLers, >> >>Notes from the review of ballot 4 today are at >>http://tinyurl.com/c4vbore. Main points: >> >> - Final changes for the ballot must be sent to Roger by COB tomorrow >> (Friday, March 1). >> >> - Corrections for Units and QK are on Slide 5 (four for Nicolas, one >> for Roger). >> >>We also had a shorter version of the Variant WG overview, see >>http://www.omg.org/archives/sysml-rtf/msg03512.html (was actually Feb >>27). >> >>Conrad >> >>http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Amee >>t >>ing_minutes&cache=cache&media=rtf4:meetings:rtf-general-130228_b.ppt > From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Sun, 3 Mar 2013 09:31:24 -0500 Subject: RE: SysML RTF telecon, Feb 28, ballot 4 notes, primitive type comments, late Thread-Topic: SysML RTF telecon, Feb 28, ballot 4 notes, primitive type comments, late Thread-Index: Ac4YGrTasAO9XA+VSjS6HHD/+KU23Q== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Michael, Thanks for the input, but you're very late. Could you send your comments in earlier in the review period so we can prepare the ballot? Some replies below. Roger, A minor update for the ballot is at http://tinyurl.com/cd8wdaf. Conrad http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Agroups%3Aprimitive_types_values%3Aindex&cache=cache&media=rtf4:groups:primitive_types_values:18269_resolved-nfr4-cb.doc > 1) The 8.4 diagram supplied indicates that a ValueType has an optiona unit > and an optional qualitykind. > > However, 8.3.2.10 the OCL seems to say that the unit must be there. Please > clarify the text with the optional nature of the Unit. Also look at > quantitykind. The OCL allows unit->notEmpty(), so doesn't require a value. The text says what the unit must be, not that it must be there. However, I've attached a minor wording update. > 2) IF the URI is optional, does that mean the model-interchange won't > recognize that the units/kinds are the same, or that a model will also have > that problem internally. Will leave this one to Nicolas. > 3) BTW, I didn't see a constraint that the unit and quantitykinds are part of > the same system of units or system or quantities. This is ok with me though This can be added in a later ballot if needed. > 4) Figure D8. I'm probably dense, but I don't understand how the base Unit is > abstract yet is subclass of the concrete Unit Abstractness is a property of classes, rather than instances, so only applies on a class-by-class basis, rather than to a class an all its subclasses. A class can be instantiatiable even though it's subclasses aren't. This isn't typical, but not incorrect. > The proposal says that the two units are the same if there > definitionURIs have the same value. > I didn't see any discussion on how that would be evaluated. For > example, are they checked as strings or as they checked by where they > point to. For example, would www.lmco.com match http://166.21.32.81/? > This should be made explicit how the equality is expected to work. This can be added in a later ballot if needed. 18269_resolved-NFR4-CB.doc