Issue 17470: SMM metamodel contains class "MofElement". (smm-rtf) Source: Cordys (Mr. Henk de Man, hdman(at)cordys.com) Nature: Revision Severity: Summary: SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element Resolution: Revised Text: Actions taken: July 13, 2012: received issue Discussion: End of Annotations:===== s is issue # 17470 From: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element From: Larry Hines To: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" Subject: RE: issues 17469 - 17471 -- SMM RTF issues Thread-Topic: issues 17469 - 17471 -- SMM RTF issues Thread-Index: AQHNYQ97PbCntgGHlUuiKaSao/zVY5cqqruw Date: Sun, 15 Jul 2012 19:21:57 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.11.7] X-OriginalArrivalTime: 15 Jul 2012 19:21:58.0955 (UTC) FILETIME=[1AAEC7B0:01CD62BF] With respect to #17469: A measure is not well defined without a scope. The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires thaat the objects be instances of a single class. Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scope.s class. With respect to #17470 and 17471: I don.t know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section. Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues This is issue # 17469 From: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470 From: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471 From: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself . and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=FVUwGIJ+AHGmpAukOVA79rdDUMY5ehHUnUvVlIid+VI=; b=Rr8TqPy5E5xdX+pct5H36pSu4svQUrDVND9CyJ02rzok0GgbWiYYD21y/wickV9pHc Avs9oc39AyJ/Iv307cHJjBZxhBbD4WmpNHJPJxtUdwmrJd83koK/GitmzpAKjp4xWwPP WAHMNx6s0z6eIJ4+VTwztrE51LAWgsxKDEr2FynORKrkD8GkQyMt2M9ztYcSX6GO3z1A eWpe4AeXycowuUkGHvm5rMdp+BVQMei3RQxZihgRVbk67Yccy6QuzUBPrQcU81wUSw4V DS0WirjapsFBpUjR40cJRL0C/iUqWeOhM9tVBf4SVHmSJi1J4Xlfm19mOwlDYo6gifDq WtTw== Date: Tue, 17 Jul 2012 14:03:07 +0200 Subject: Re: issues 17469 - 17471 -- SMM RTF issues From: Henk de Man To: Larry Hines Cc: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre , Henk de Man X-Gm-Message-State: ALoCoQmTvfJBbmU6ZplVbRfgK8bjSTXbuqoixxiZfTbF8VYlItA1dHpjJ7S6R3zo5TXJgmOoo3+/ Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope.  The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires that the objects be instances of a sinngle class.  Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scopeâs class. [hdm] RegardingÂissue # 17469:ÂFrom VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  With respect to #17470 and 17471: I donât know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section.  Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] RegardingÂÂissue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected.ÂÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  [hdm] Regarding issueÂissue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete.ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues  This is issue # 17469ÂÂÂFrom: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470ÂÂÂFrom: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471ÂÂÂFrom: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself � and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController.   Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org  -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Busiiness Operations From: Larry Hines To: Henk de Man CC: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre Subject: RE: issues 17469 - 17471 -- SMM RTF issues Thread-Topic: issues 17469 - 17471 -- SMM RTF issues Thread-Index: AQHNYQ97PbCntgGHlUuiKaSao/zVY5cqqruwgAL+dYD//8bDYA== Date: Tue, 17 Jul 2012 16:13:02 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.26.13] X-OriginalArrivalTime: 17 Jul 2012 16:13:03.0603 (UTC) FILETIME=[0B1CD430:01CD6437] The scope defines the domain of the measure. Defining the domain is not optional. Issues 17470 and 17471 appear to provide a different route to define the domain by narrowing MofElement down to a class of elements. If that it is case, then I.m all for it. But why keep scope at all? Wouldn.t it be redundant? Also, I would like to see a concrete example. From: Henk de Man [mailto:hdman@cordys.com] Sent: Tuesday, July 17, 2012 7:03 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope. The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires thhat the objects be instances of a single class. Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scope.s class. [hdm] Regarding issue # 17469: From VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. The VDML submission, in its section 6.1 imposes this as requirement on SMM. With respect to #17470 and 17471: I don.t know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section. Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] Regarding issue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected. The VDML submission, in its section 6.1 imposes this as requirement on SMM. [hdm] Regarding issue issue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete. The VDML submission, in its section 6.1 imposes this as requirement on SMM. From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues This is issue # 17469 From: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470 From: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471 From: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself . and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Busineess Operations This message has been scanned by MailController. X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Bbl4SrrlFylCt2n7/+SBIL+J1t49wbk0GUUlUR9pAcs=; b=locrDDUrnvz3EZXjSFehm/4zIP4EVe7ZO0jNY0WyOXZHMtFcmvUgtPfm1SD4ivlGyz fvhc9PoGwyB4vfI395gCp+b0w0E9W+UgzJ2w3VnPlpgzmfC0+ilo4Dw+NtRQpXmSOLSa tfHU5mpE1995Z8nYfh0ZvwbQ+g53EQkNBy+exJlPwO/A69fs5wzpYho3DbssGTVXL20I yxR+r8yMiBXlbOIPmgzsnkSiNksPXE32ykyJNZGbX7vqVE3QKpMzbZzFG9IHG8mHujjs OxO+icw3rEI8o2rF6uSanwXjKJUwmfSHfDIcZoDGAsPKrS4FVTLQDScGwXO+zOWN5Tol yNAQ== Date: Wed, 18 Jul 2012 16:20:20 +0200 Subject: Re: issues 17469 - 17471 -- SMM RTF issues From: Henk de Man To: Larry Hines Cc: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre , Henk de Man X-Gm-Message-State: ALoCoQmvcQgbP4di84VvBK2yNcRVtKdvoPPeu+a7ZlYEvdldOu/wd/GzECDsnm+3CKfEyHkiWE86 Larry, The point is that the way SMM defines scope of a measure (just by a meta-class that just have a MOF class as attribute) is not meaningful for our VDML purpose (integraing SMM as part of business models). We aren't opposed to it, but only if it is made optional. Removing it is fine with us also. That's up to you. But if we keep it, it should be made optional. That's also what we agreed with Alain Picard earlier. There will be plenty examples. For instance a measure of Resource cost. The measure library will contain a measure, related characteristic, the measure has a unit, etc. But there is no meaningful definition of scope here. At least not in the way SMM defines it. It is not needed either. Regards, Henk de Man On Tue, Jul 17, 2012 at 6:13 PM, Larry Hines wrote: The scope defines the domain of the measure. Defining the domain is not optional. Issues 17470 and 17471 appear to provide a different route to define the domain by narrowing MofElement down to a class of elements. If that it is case, then Iâm all for it. But why keep scope at all? Wouldnât it be redundant? Also, I would like to see a concrete example.   From: Henk de Man [mailto:hdman@cordys.com] Sent: Tuesday, July 17, 2012 7:03 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues  Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope.  The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires that the objeects be instances of a single class.  Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scopeâs class. [hdm] RegardingÂissue # 17469:ÂFrom VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  With respect to #17470 and 17471: I donât know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section.  Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] RegardingÂÂissue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected.ÂÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  [hdm] Regarding issueÂissue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete.ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues  This is issue # 17469ÂÂÂFrom: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470ÂÂÂFrom: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471ÂÂÂFrom: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself � and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController.   Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org   -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Business Operations  This message has been scanned by MailController.  -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Busiiness Operations From: Larry Hines To: Henk de Man CC: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre Subject: RE: issues 17469 - 17471 -- SMM RTF issues Thread-Topic: issues 17469 - 17471 -- SMM RTF issues Thread-Index: AQHNYQ97PbCntgGHlUuiKaSao/zVY5cqqruwgAL+dYD//8bDYIAB8egA///WNsA= Date: Wed, 18 Jul 2012 20:08:36 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.26.13] X-OriginalArrivalTime: 18 Jul 2012 20:08:37.0951 (UTC) FILETIME=[1E40ECF0:01CD6521] Henk, All I need is a statement that 17470 and 17471 definitely define the domain of the Measure. I would also like to see an example of the small metamodel package "MOF" (or CMOF), containing at least "Element". Larry From: Henk de Man [mailto:hdman@cordys.com] Sent: Wednesday, July 18, 2012 9:20 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues Larry, The point is that the way SMM defines scope of a measure (just by a meta-class that just have a MOF class as attribute) is not meaningful for our VDML purpose (integraing SMM as part of business models). We aren't opposed to it, but only if it is made optional. Removing it is fine with us also. That's up to you. But if we keep it, it should be made optional. That's also what we agreed with Alain Picard earlier. There will be plenty examples. For instance a measure of Resource cost. The measure library will contain a measure, related characteristic, the measure has a unit, etc. But there is no meaningful definition of scope here. At least not in the way SMM defines it. It is not needed either. Regards, Henk de Man On Tue, Jul 17, 2012 at 6:13 PM, Larry Hines wrote: The scope defines the domain of the measure. Defining the domain is not optional. Issues 17470 and 17471 appear to provide a different route to define the domain by narrowing MofElement down to a class of elements. If that it is case, then I.m all for it. But why keep scope at all? Wouldn.t it be redundant? Also, I would like to see a concrete example. From: Henk de Man [mailto:hdman@cordys.com] Sent: Tuesday, July 17, 2012 7:03 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope. The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires that the objects be instances of a single class. Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scope.s class. [hdm] Regarding issue # 17469: From VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. The VDML submission, in its section 6.1 imposes this as requirement on SMM. With respect to #17470 and 17471: I don.t know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section. Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] Regarding issue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected. The VDML submission, in its section 6.1 imposes this as requirement on SMM. [hdm] Regarding issue issue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete. The VDML submission, in its section 6.1 imposes this as requirement on SMM. From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues This is issue # 17469 From: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470 From: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471 From: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself . and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Business Operations This message has been scanned by MailController. -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Business Operations This message has been scanned by MailController. X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Bcy+cBNtCZx7qMksfMDRM6Ekn9xtwC8supOVk0J9e+0=; b=TEFBsrloBlq705nDCWdK/PFuN/ZqYJO8acQ20sVubOOuI6XShPBTsMkYSn16niRkeB zY6msIog/z05zBikrGASGFcTph5Kw+Chiozb5mlM0Cb3pYmHQUYlHjLrpb5XrRsWiR4h 6g4mbrliVg/DTSZbhLHh1DT8X+Ac5QpYOQjgF8o4SWVA3sipxAL+CBMtd75R+eJxIJXw NyFe3Q5SFiZKWjfDaMnP09Qxv6IMTznQqZparqmGAb8YIaEFIi3yO71rIK4dWBpv/IRL QBhtYwS4uAbhUcKEGb+QFi/xHVjxTjgFfg5ilZgz8SvL60Jp8E3eyRDrjY/SKetqPTXx K4sA== Date: Thu, 19 Jul 2012 15:20:36 +0200 Subject: Re: issues 17469 - 17471 -- SMM RTF issues From: Henk de Man To: Larry Hines Cc: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre , Henk de Man X-Gm-Message-State: ALoCoQmZqEL6heDjOb/m6enpoxs6obFJ4VM+9LmdS8q8zuy0O7DoGIWlKl7ZyVwCCgjgyXq7sVkp Larry, In reaction to your response below. See attached. It contains a subset of SMM meta-model only. Look to the class "Element (CMOF)". That relates to issue 17470. Rather than having a specific class MofElement (in SMM package itself), we have here the class Element from MOF (or CMOF). To achieve this, in my MagicDraw file I have a "dummy" package MOF, containing just this class Element, and I use it for association from Measurement in SMM. This is also what has been acknowledged by Alain Picard as the proper way. This is nothing special. Not functional either. It is just applying the right OMG meta-model technicalities. Also issue 17471 relates to the attachment. Note that the measurand end of the association (from Measurement (SMM) to Element (CMOF)), is now owned by the association itself, and not by the class Measurement. The UML "dot" notation is showing that. This is required for good integration, as the issue text itself explains in detail. This is what is meant in 17471. I don't see how these two meta-model-technical issues do relate to the topic of "domain of Âa measure" as you suggest. Regards, Henk de Man On Wed, Jul 18, 2012 at 10:08 PM, Larry Hines wrote: Henk,  All I need is a statement that 17470 and 17471 definitely define the domain of the Measure. I would also like to see an example of the small metamodel package "MOF" (or CMOF), containing at least "Element".  Larry  From: Henk de Man [mailto:hdman@cordys.com] Sent: Wednesday, July 18, 2012 9:20 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues  Larry,  The point is that the way SMM defines scope of a measure (just by a meta-class that just have a MOF class as attribute) is not meaningful for our VDML purpose (integraing SMM as part of business models). We aren't opposed to it, but only if it is made optional. Removing it is fine with us also. That's up to you. But if we keep it, it should be made optional. That's also what we agreed with Alain Picard earlier.  There will be plenty examples. For instance a measure of Resource cost. The measure library will contain a measure, related characteristic, the measure has a unit, etc. But there is no meaningful definition of scope here. At least not in the way SMM defines it. It is not needed either.  Regards,  Henk de Man  On Tue, Jul 17, 2012 at 6:13 PM, Larry Hines wrote: The scope defines the domain of the measure. Defining the domain is not optional. Issues 17470 and 17471 appear to provide a different route to define the domain by narrowing MofElement down to a class of elements. If that it is case, then Iâm all for it. But why keep scope at all? Wouldnât it be redundant? Also, I would like to see a concrete example.   From: Henk de Man [mailto:hdman@cordys.com] Sent: Tuesday, July 17, 2012 7:03 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues  Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope.  The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires that the objeects be instances of a single class.  Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scopeâs class. [hdm] RegardingÂissue # 17469:ÂFrom VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  With respect to #17470 and 17471: I donât know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section.  Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] RegardingÂÂissue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected.ÂÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  [hdm] Regarding issueÂissue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete.ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues  This is issue # 17469ÂÂÂFrom: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470ÂÂÂFrom: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471ÂÂÂFrom: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself � and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController.   Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org   -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45< CORDYS . Improving Business Operations<  This message has been scanned by MailController.   -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS â Improving Business Operations  This message has been scanned by MailController.  -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Busiiness Operations Content-Type: image/jpeg; name="SMM Main Concepts.jpg" Content-Disposition: attachment; filename="SMM Main Concepts.jpg" X-Attachment-Id: f_h4tv9sfd0 SMM Main Concepts.jpg From: Larry Hines To: Henk de Man CC: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre Subject: RE: issues 17469 - 17471 -- SMM RTF issues Thread-Topic: issues 17469 - 17471 -- SMM RTF issues Thread-Index: AQHNYQ97PbCntgGHlUuiKaSao/zVY5cqqruwgAL+dYD//8bDYIAB8egA///WNsCAAatuAP//xx+A Date: Thu, 19 Jul 2012 14:06:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.26.13] X-OriginalArrivalTime: 19 Jul 2012 14:06:05.0330 (UTC) FILETIME=[A3181F20:01CD65B7] Henk, I think I understand now. But if I do then there.s a problem. A function (which is what the measure.s evaluation process should be) is not well defined without specifying its domain (what the measure applies to). May I suggest we make scope more flexible, but still required. Let.s give scope a couple of new attributes, name and description. We can then say that a scope is well defined by if it has a class or has a name. Would a required scope with just a name work for VDML? Larry From: Henk de Man [mailto:hdman@cordys.com] Sent: Thursday, July 19, 2012 8:21 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues Larry, In reaction to your response below. See attached. It contains a subset of SMM meta-model only. Look to the class "Element (CMOF)". That relates to issue 17470. Rather than having a specific class MofElement (in SMM package itself), we have here the class Element from MOF (or CMOF). To achieve this, in my MagicDraw file I have a "dummy" package MOF, containing just this class Element, and I use it for association from Measurement in SMM. This is also what has been acknowledged by Alain Picard as the proper way. This is nothing special. Not functional either. It is just applying the right OMG meta-model technicalities. Also issue 17471 relates to the attachment. Note that the measurand end of the association (from Measurement (SMM) to Element (CMOF)), is now owned by the association itself, and not by the class Measurement. The UML "dot" notation is showing that. This is required for good integration, as the issue text itself explains in detail. This is what is meant in 17471. I don't see how these two meta-model-technical issues do relate to the topic of "domain of a measure" as you suggest. Regards, Henk de Man On Wed, Jul 18, 2012 at 10:08 PM, Larry Hines wrote: Henk, All I need is a statement that 17470 and 17471 definitely define the domain of the Measure. I would also like to see an example of the small metamodel package "MOF" (or CMOF), containing at least "Element". Larry From: Henk de Man [mailto:hdman@cordys.com] Sent: Wednesday, July 18, 2012 9:20 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues Larry, The point is that the way SMM defines scope of a measure (just by a meta-class that just have a MOF class as attribute) is not meaningful for our VDML purpose (integraing SMM as part of business models). We aren't opposed to it, but only if it is made optional. Removing it is fine with us also. That's up to you. But if we keep it, it should be made optional. That's also what we agreed with Alain Picard earlier. There will be plenty examples. For instance a measure of Resource cost. The measure library will contain a measure, related characteristic, the measure has a unit, etc. But there is no meaningful definition of scope here. At least not in the way SMM defines it. It is not needed either. Regards, Henk de Man On Tue, Jul 17, 2012 at 6:13 PM, Larry Hines wrote: The scope defines the domain of the measure. Defining the domain is not optional. Issues 17470 and 17471 appear to provide a different route to define the domain by narrowing MofElement down to a class of elements. If that it is case, then I.m all for it. But why keep scope at all? Wouldn.t it be redundant? Also, I would like to see a concrete example. From: Henk de Man [mailto:hdman@cordys.com] Sent: Tuesday, July 17, 2012 7:03 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope. The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires that the objects be instancess of a single class. Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scope.s class. [hdm] Regarding issue # 17469: From VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. The VDML submission, in its section 6.1 imposes this as requirement on SMM. With respect to #17470 and 17471: I don.t know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section. Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] Regarding issue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected. The VDML submission, in its section 6.1 imposes this as requirement on SMM. [hdm] Regarding issue issue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete. The VDML submission, in its section 6.1 imposes this as requirement on SMM. From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues This is issue # 17469 From: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470 From: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471 From: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself . and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 433 09 45 CORDYS . Improving Business Operations This message has been scanned by MailController. -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Business Operattions This message has been scanned by MailController. -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 511 43 09 45 CORDYS . Improving Business Operations This message has been scanned by MailController. X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cVCd2k9WWdU7y7ITWvqcnvh3YNCo0l4eeGZDcAn48lE=; b=gkfM/5+CA/3yOfIVlYGaKF7ReUVLklY6IxUHKgKeWMnLGiEh5rAZ9vhynVC12Jtd2B SEuEz42QyDTQLBv5JJ1EzA2foggWExHeE88xqP+6L05QBW6pZdwtSnX3iP8eUiLLzOW5 loroJ33NuxbtmE+XtVh9Jubgj8KxklDMwNnMI0mfNX0FwwQqhnCBNTmT86mH0+sQLoz2 05KHAw5SnRBq8OM+xHqB079hE3j+y7mgUUgo3GqnyKgpodh6bGYI4Sjdayx944UY+Bge PTKFhaB0iovZ7VXlUVDr7KJFMrT/DDqEGYfH4WCUzNxOLUUMOt2Jm+nV9WGX9VtpdaB7 smvQ== Date: Thu, 19 Jul 2012 16:46:30 +0200 Subject: Re: issues 17469 - 17471 -- SMM RTF issues From: Henk de Man To: Larry Hines Cc: Juergen Boldt , "issues@omg.org" , "smm-rtf@omg.org" , Alain Picard , Pete Rivett , "fred.a.cummins" , Arne Berre , Henk de Man X-Gm-Message-State: ALoCoQlzFmLL6etP6r5yQQK/nWlq0z6ZAjqAQfRQh6y76kyXhAirI48li42TqWhS3ir0I9L6gaNT Larry, I am very fine with keeping measure scope mandatory, as long as you will allow scope to be defined, or optionally defined, in different ways. The reason why VDML cannot work with measure scope is not because we don't want any concept of scope (or domain, which is better Âname), but because the way it is currently defined in SMM. Note that in SMM the Scope class has a mandatory attribute called "class". And this is what is not in harmony with how VDML applies SMM. We cannot have a business analyst specifying a metamodel class name as part of a measure in a library. So, you can do a proposal of how to define Scope differently, and we can discuss how it may fit best to VDML. My first question would be: when you On Thu, Jul 19, 2012 at 4:06 PM, Larry Hines wrote: Henk,  I think I understand now.  But if I do then thereâs a problem. A function (which is what the measureâs evaluation process should be) is not well defined without specifying its domain (what the measure applies to). [hdm] but in what terms do you want to specify a "domain" for a measure? E.g. when we have Shipment Cycle Time Measure, what would be its domain? Not a MOF class, as Measure Scope is currently enforcing. ..* [hdm] Can't you make Measure Scope as flexible as Observation Scope, namely 0 ..* (though 0..1 is maybe better) ?  May I suggest we make scope more flexible, but still required. [hdm] You can suggest something, and we can discuss whether it would conflict with VDML-SMM integration (and application of SMM in VDML context) or not. So, I am not per se against any Scope class, but the way its is currently defined is making it a hindrance to VDML (... note that VDML is applying almost everything of SMM extensively, and is very fine with core concepts, but a thing like this is just in the way...) ÂLetâs give scope a couple of new attributes, name and description. We can then say that a scope is well defined by if it has a class or has a name. Would a required scope with just a name work for VDML? [hdm] That would indeed be much better, but still then: what would it bring ? E.g. what would be the domain of ÂShipment Cycle Time Measure, and why can't we do without such a domain?  Larry  From: Henk de Man [mailto:hdman@cordys.com] Sent: Thursday, July 19, 2012 8:21 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues  Larry,  In reaction to your response below.  See attached. It contains a subset of SMM meta-model only. Look to the class "Element (CMOF)". That relates to issue 17470. Rather than having a specific class MofElement (in SMM package itself), we have here the class Element from MOF (or CMOF). To achieve this, in my MagicDraw file I have a "dummy" package MOF, containing just this class Element, and I use it for association from Measurement in SMM. This is also what has been acknowledged by Alain Picard as the proper way. This is nothing special. Not functional either. It is just applying the right OMG meta-model technicalities.  Also issue 17471 relates to the attachment. Note that the measurand end of the association (from Measurement (SMM) to Element (CMOF)), is now owned by the association itself, and not by the class Measurement. The UML "dot" notation is showing that. This is required for good integration, as the issue text itself explains in detail. This is what is meant in 17471.  I don't see how these two meta-model-technical issues do relate to the topic of "domain of Âa measure" as you suggest.  Regards,  Henk de Man On Wed, Jul 18, 2012 at 10:08 PM, Larry Hines wrote: Henk,  All I need is a statement that 17470 and 17471 definitely define the domain of the Measure. I would also like to see an example of the small metamodel package "MOF" (or CMOF), containing at least "Element".  Larry  From: Henk de Man [mailto:hdman@cordys.com] Sent: Wednesday, July 18, 2012 9:20 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues  Larry,  The point is that the way SMM defines scope of a measure (just by a meta-class that just have a MOF class as attribute) is not meaningful for our VDML purpose (integraing SMM as part of business models). We aren't opposed to it, but only if it is made optional. Removing it is fine with us also. That's up to you. But if we keep it, it should be made optional. That's also what we agreed with Alain Picard earlier.  There will be plenty examples. For instance a measure of Resource cost. The measure library will contain a measure, related characteristic, the measure has a unit, etc. But there is no meaningful definition of scope here. At least not in the way SMM defines it. It is not needed either.  Regards,  Henk de Man  On Tue, Jul 17, 2012 at 6:13 PM, Larry Hines wrote: The scope defines the domain of the measure. Defining the domain is not optional. Issues 17470 and 17471 appear to provide a different route to define the domain by narrowing MofElement down to a class of elements. If that it is case, then Iâm all for it. But why keep scope at all? Wouldnât it be redundant? Also, I would like to see a concrete example.   From: Henk de Man [mailto:hdman@cordys.com] Sent: Tuesday, July 17, 2012 7:03 AM To: Larry Hines Cc: Juergen Boldt; issues@omg.org; smm-rtf@omg.org; Alain Picard; Pete Rivett; fred.a.cummins; Arne Berre; Henk de Man Subject: Re: issues 17469 - 17471 -- SMM RTF issues  Larry, see below, for my comments. On Sun, Jul 15, 2012 at 9:21 PM, Larry Hines wrote: With respect to #17469: A measure is not well defined without a scope.  The scope of a measure identifies a set of objects as the domain of the measure. . SMM requires that the objeects be instances of a single class.  Basically, the scope indicates the class of the measurands of the measurements of this measure. Put more succinctly, the measure is applicable to instances of the scopeâs class. [hdm] RegardingÂissue # 17469:ÂFrom VDML perspective (integrating SMM), Measure Scope, as defined in SMM is redundant. It is also unwanted. From a business analyst perspective it is not useful to specify scope as a meta-model class. Looking to the various metric libraries that are common in Industry, there's not such a scope definition. It must be made optional so that applications that want to use it, can use it, but applications that cannnot use it, aren't hindered. Alain Picard has acknowledged that it is better indeed to make Measure Scope optional, and that this has been asked for by others as well. ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  With respect to #17470 and 17471: I donât know what is being accomplish with the small metamodel package. SMM already specifies the class of the measurand. See Semantics subheading under Measurement Class section.  Semantics Measurand must be in the scope of measure. Specifically, measurand must be an instance of the class named in measure.scope.class. If measure.scope.recognizers is given then the recognizer applied to the measurand must return true. [hdm] RegardingÂÂissue # 17470: "MofElement" is an imprecise and, in fact, wrong identification of the class Element (from CMOF). Alain Picard has ackknowledged that this should be corrected.ÂÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  [hdm] Regarding issueÂissue # 17471: This is necessary to enable better integration of SMM with other specifications, such as VDML. In VDML context, and with Alain Picard, this has been discussed extensively. The text as provided in the issue has been carefully designed by Pete Rivett, and is precise and complete.ÂThe VDML submission, in its section 6.1 imposes this as requirement on SMM.  From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, July 13, 2012 10:52 AM To: issues@omg.org; smm-rtf@omg.org Subject: issues 17469 - 17471 -- SMM RTF issues  This is issue # 17469ÂÂÂFrom: Henk de Man Scope of a measure should be made optional. =============================================== This is issue # 17470ÂÂÂFrom: Henk de Man SMM metamodel contains class "MofElement". SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element ================================================ This is issue # 17471ÂÂÂFrom: Henk de Man The measurand of Measurement, which references Element (MOF), is owned by Measurement The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself � and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly). This message has been scanned by MailController.   Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org   -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45< CORDYS . Improving Business Operations<  This message has been scanned by MailController.   -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improoving Business Operations  This message has been scanned by MailController.   -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS â Improving Business Operations  This message has been scanned by MailController.  -- Henk de Man Research Director hdman@cordys.com www.cordys.com T +31 (0)341 37 5541 . M +31 (0)6 51 43 09 45 CORDYS . Improving Busiiness Operations