Issue 4111: The Metadata architecture needs to move away from the 4 levels and labels (mof-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Clarification Severity: Significant Summary: The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'. Resolution: Revised Text: Actions taken: December 8, 2000: received issue Discussion: Review section 2.2 and subsections. Develop appropriate introductory MOF material for separate publication; e.g. on the OMG website. The description of the MOF meta-data architecture in section 2.2 and subsections could do with some rewording and rearrangement to the points mentioned in the issue clearer. However, the root problem is that people do not read the MOF spec. What is needed is some (OMG endorsed) introductory or tutorial material on meta-modelling and the MOF. The MOF RTF is best placed to take on the task of developing this material in the first instance. End of Annotations:===== From: webmaster@omg.org Message-Id: <200012081154.eB8BsJE25731@emerald.omg.org> Date: 08 Dec 2000 07:55:21 -0500 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: 1?6!!`*U!!7^Od9lb-e9 Name: Pete Rivett Company: Adaptive mailFrom: pete.rivett@adaptive.com Notification: Yes Specification: Meta Object Facility Section: 2.2 FormalNumber: formal/00-04-03 Version: 1.3 RevisionDate: 09/27/1999 Page: 2-1 to 2-5 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) Description The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'. X-Mailer: exmh version 2.1.0 09/18/1999 To: pete.rivett@adaptive.com, mof-rtf@emerald.omg.org Cc: Joaquin Miller Subject: Re: issue 4111 -- MOF RTF issue In-Reply-To: Message from Juergen Boldt of "Fri, 08 Dec 2000 11:13:24 EST." <4.2.0.58.20001208111225.00aef640@emerald.omg.org> Mime-Version: 1.0 Date: Mon, 11 Dec 2000 12:29:11 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: 600e92TTd9Un\!!k\E!! Pete, I agree with the basis tenet of your issue ... that the MOF meta-data architecture is often mis-described as a rigidly 4-level architecture. To some degree the MOF spec itself is guilty of this, and we should find the places where we have made this mistake and correct them. We could also review the OMG's MOF publicity material, background documents and the slideware for the same mistake ... and suggest fixes. However, I'd be worried by your proposal to rid the MOF spec of references to "M1-level", "M2-level" and so on. In particular, the current MOF spec uses "M-level" labels to disambiguate overloading of terms like class, package, association, operation and so on. I'm afraid that removing the labels willy-nilly would make large parts of the spec meaningless. I think that the real problem is that some people are using the M-level terminology incorrectly. If an RFP states that a submission should supply an M2-level meta-model for something without any further explanation, then it (the RFP) is >>broken<<. Any document that mentions a meta-model should state clearly what is meta-modelled, and what the purpose of the meta-model is. The M-level labels ultimately cannot express this meaning. The MOF spec >>could<< tutorial material on how to use meta-models and MOF meta-modelling terminology. However, it would probably be more appropriate if someone was commissioned to put together a decent MOF tutorial document. [Hint :-)] However, the MOF RTF can't fix broken RFPs and muddled thinking. [I'm not making a judgement on SPE, because I haven't read it.] -- Steve From: "Iyengar, Sridhar" To: Stephen Crawley , pete.rivett@adaptive.com, mof-rtf@emerald.omg.org Cc: Joaquin Miller Subject: RE: issue 4111 -- MOF RTF issue Date: Tue, 12 Dec 2000 02:51:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b&md9&VW!!'@(e9/B0!! I generally agree that some clarification is needed. Dropping the M1, M2 etc labels would confuse enough people that I would not advise it. Making the point that MOF supports a layered architecture and that in practice using upto 4 levels is sufficent is made in the spec. Additional examples and patterns are appropriate. I dont see any need for fundamental changes to the model or interfaces to address this specific comment. -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Sunday, December 10, 2000 6:29 PM To: pete.rivett@adaptive.com; mof-rtf@emerald.omg.org Cc: Joaquin Miller Subject: Re: issue 4111 -- MOF RTF issue Pete, I agree with the basis tenet of your issue ... that the MOF meta-data architecture is often mis-described as a rigidly 4-level architecture. To some degree the MOF spec itself is guilty of this, and we should find the places where we have made this mistake and correct them. We could also review the OMG's MOF publicity material, background documents and the slideware for the same mistake ... and suggest fixes. However, I'd be worried by your proposal to rid the MOF spec of references to "M1-level", "M2-level" and so on. In particular, the current MOF spec uses "M-level" labels to disambiguate overloading of terms like class, package, association, operation and so on. I'm afraid that removing the labels willy-nilly would make large parts of the spec meaningless. I think that the real problem is that some people are using the M-level terminology incorrectly. If an RFP states that a submission should supply an M2-level meta-model for something without any further explanation, then it (the RFP) is >>broken<<. Any document that mentions a meta-model should state clearly what is meta-modelled, and what the purpose of the meta-model is. The M-level labels ultimately cannot express this meaning. The MOF spec >>could<< tutorial material on how to use meta-models and MOF meta-modelling terminology. However, it would probably be more appropriate if someone was commissioned to put together a decent MOF tutorial document. [Hint :-)] However, the MOF RTF can't fix broken RFPs and muddled thinking. [I'm not making a judgement on SPE, because I haven't read it.] -- Steve X-Sender: riehle@ice.inf.ethz.ch X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 13 Dec 2000 00:58:23 -0500 To: issues@emerald.omg.org, mof-rtf@emerald.omg.org, pete.rivett@adaptive.com From: Dirk Riehle Subject: Re: issue 4111 -- MOF RTF issue In-Reply-To: <4.2.0.58.20001208111225.00aef640@emerald.omg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 9Pp!!W2 To: Dirk Riehle , issues@emerald.omg.org, mof-rtf@emerald.omg.org, pete.rivett@adaptive.com Subject: RE: issue 4111 -- MOF RTF issue Date: Wed, 13 Dec 2000 07:26:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,'Yd9iAmd98mVd9Sm`d9 Excellent point Dirk. We should emphasize your points in the spec -----Original Message----- From: Dirk Riehle [mailto:dirk@riehle.org] Sent: Tuesday, December 12, 2000 9:58 PM To: issues@emerald.omg.org; mof-rtf@emerald.omg.org; pete.rivett@adaptive.com Subject: Re: issue 4111 -- MOF RTF issue We address this (and related terminology problems) the following way: by being very clear about the difference between a logical and a technical (implementation) architecture. The four-layer architecture is a logical architecture; for us, the "m-levels" work nicely. They are absolute levels. Also, they don't contradict relative level names as model and model instance. Technical implementation architectures there are plenty then. They should not be prescribed or suggested by the spec. Hence, they should not affect its terminology. Dirk At 11:13 AM 12/8/00 -0500, Juergen Boldt wrote: >This is issue # 4111 pete.rivett@adaptive.com > >The Metadata architecture needs to move away from the 4 levels and labels > >The Metadata architecture needs to move away from the 4 levels and labels: >and refer to them as an example for straightforward cases such as database >modeling. Other non 4-layer examples are also needed. While the MOF spec >does point out that "M1-level and M2-level are relative labels", in >practice the labels are applied quite rigidly and this positively causes >confusion, sterile arguments, and in some cases harm to specifications as >people grapple with whether a class belongs to M1 or M2 and if the former >then it should be excluded "since the RFP asks for a M2 model". An example >of the problems can be found in section 13.2 of the SPE joint submission >(adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML >not MOF. This will not change the MOF spec but how it is applied and >models developed hence the severity of 'significant'. > >================================================================ > >Juergen Boldt >Senior Member of Technical Staff > >Object Management Group Tel. +1-781 444 0404 ext. 132 >250 First Avenue, Suite 201 Fax: +1-781 444 0320 >Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > >================================================================ ---- Publications, work, and other oddities: www.riehle.org Reply-To: From: "Pete Rivett" To: "'Iyengar, Sridhar'" , "'Dirk Riehle'" , , Subject: RE: issue 4111 -- MOF RTF issue Date: Tue, 19 Dec 2000 15:58:57 -0000 Message-ID: <000c01c069d4$9a415510$4b4c04c8@orval.adaptive.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: l85e9aG1!!%0Ud9]SN!! Dirk, While I agree with what you say about the difference between logical and technical architectures, my original point was purely about the logical level. While the 4 'absolute levels' work nicely for stereotypical database design scenarios, assigning an absolute level to a model can quickly become a lot fuzzier. For example, even within the Common Warehouse Metamodel one has traditional M2 classes such as Table, and Column. But also related to a Table (for example) one has classes ResponsibleParty (instances of which might represent an actual human being - hence it's M1 level) and Document (instances of which are real documents - likewise M1 level). So what's the 'M' level of CWM as a whole? And does it matter (I'd say no)? Regards, Pete -----Original Message----- From: Iyengar, Sridhar [mailto:Sridhar.Iyengar2@unisys.com] Sent: 13 December 2000 12:27 To: Dirk Riehle; issues@emerald.omg.org; mof-rtf@emerald.omg.org; pete.rivett@adaptive.com Subject: RE: issue 4111 -- MOF RTF issue Excellent point Dirk. We should emphasize your points in the spec -----Original Message----- From: Dirk Riehle [mailto:dirk@riehle.org] Sent: Tuesday, December 12, 2000 9:58 PM To: issues@emerald.omg.org; mof-rtf@emerald.omg.org; pete.rivett@adaptive.com Subject: Re: issue 4111 -- MOF RTF issue We address this (and related terminology problems) the following way: by being very clear about the difference between a logical and a technical (implementation) architecture. The four-layer architecture is a logical architecture; for us, the "m-levels" work nicely. They are absolute levels. Also, they don't contradict relative level names as model and model instance. Technical implementation architectures there are plenty then. They should not be prescribed or suggested by the spec. Hence, they should not affect its terminology. Dirk At 11:13 AM 12/8/00 -0500, Juergen Boldt wrote: >This is issue # 4111 pete.rivett@adaptive.com > >The Metadata architecture needs to move away from the 4 levels and labels > >The Metadata architecture needs to move away from the 4 levels and labels: >and refer to them as an example for straightforward cases such as database >modeling. Other non 4-layer examples are also needed. While the MOF spec >does point out that "M1-level and M2-level are relative labels", in >practice the labels are applied quite rigidly and this positively causes >confusion, sterile arguments, and in some cases harm to specifications as >people grapple with whether a class belongs to M1 or M2 and if the former >then it should be excluded "since the RFP asks for a M2 model". An example >of the problems can be found in section 13.2 of the SPE joint submission >(adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML >not MOF. This will not change the MOF spec but how it is applied and >models developed hence the severity of 'significant'. > >================================================================ > >Juergen Boldt >Senior Member of Technical Staff > >Object Management Group Tel. +1-781 444 0404 ext. 132 >250 First Avenue, Suite 201 Fax: +1-781 444 0320 >Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > >================================================================ ---- Publications, work, and other oddities: www.riehle.org Reply-To: From: "Pete Rivett" To: "'Iyengar, Sridhar'" , "'Dirk Riehle'" , , Subject: RE: issue 4111 -- MOF RTF issue Date: Tue, 19 Dec 2000 15:58:57 -0000 Message-ID: <000c01c069d4$9a415510$4b4c04c8@orval.adaptive.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: fo3!!@2Ud9M1\d96h@!! Dirk, While I agree with what you say about the difference between logical and technical architectures, my original point was purely about the logical level. While the 4 'absolute levels' work nicely for stereotypical database design scenarios, assigning an absolute level to a model can quickly become a lot fuzzier. For example, even within the Common Warehouse Metamodel one has traditional M2 classes such as Table, and Column. But also related to a Table (for example) one has classes ResponsibleParty (instances of which might represent an actual human being - hence it's M1 level) and Document (instances of which are real documents - likewise M1 level). So what's the 'M' level of CWM as a whole? And does it matter (I'd say no)? Regards, Pete -----Original Message----- From: Iyengar, Sridhar [mailto:Sridhar.Iyengar2@unisys.com] Sent: 13 December 2000 12:27 To: Dirk Riehle; issues@emerald.omg.org; mof-rtf@emerald.omg.org; pete.rivett@adaptive.com Subject: RE: issue 4111 -- MOF RTF issue Excellent point Dirk. We should emphasize your points in the spec -----Original Message----- From: Dirk Riehle [mailto:dirk@riehle.org] Sent: Tuesday, December 12, 2000 9:58 PM To: issues@emerald.omg.org; mof-rtf@emerald.omg.org; pete.rivett@adaptive.com Subject: Re: issue 4111 -- MOF RTF issue We address this (and related terminology problems) the following way: by being very clear about the difference between a logical and a technical (implementation) architecture. The four-layer architecture is a logical architecture; for us, the "m-levels" work nicely. They are absolute levels. Also, they don't contradict relative level names as model and model instance. Technical implementation architectures there are plenty then. They should not be prescribed or suggested by the spec. Hence, they should not affect its terminology. Dirk At 11:13 AM 12/8/00 -0500, Juergen Boldt wrote: >This is issue # 4111 pete.rivett@adaptive.com > >The Metadata architecture needs to move away from the 4 levels and labels > >The Metadata architecture needs to move away from the 4 levels and labels: >and refer to them as an example for straightforward cases such as database >modeling. Other non 4-layer examples are also needed. While the MOF spec >does point out that "M1-level and M2-level are relative labels", in >practice the labels are applied quite rigidly and this positively causes >confusion, sterile arguments, and in some cases harm to specifications as >people grapple with whether a class belongs to M1 or M2 and if the former >then it should be excluded "since the RFP asks for a M2 model". An example >of the problems can be found in section 13.2 of the SPE joint submission >(adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML >not MOF. This will not change the MOF spec but how it is applied and >models developed hence the severity of 'significant'. > >================================================================ > >Juergen Boldt >Senior Member of Technical Staff > >Object Management Group Tel. +1-781 444 0404 ext. 132 >250 First Avenue, Suite 201 Fax: +1-781 444 0320 >Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > >================================================================ ---- Publications, work, and other oddities: www.riehle.org From: Dirk Riehle Message-Id: <200012191626.RAA28672@ice.inf.ethz.ch> Subject: Re: issue 4111 -- MOF RTF issue In-Reply-To: <000c01c069d4$9a415510$4b4c04c8@orval.adaptive.com> from Pete Rivett at "Dec 19, 0 03:58:57 pm" To: pete.rivett@adaptive.com Date: Tue, 19 Dec 2000 17:26:58 +0100 (MET) Cc: Sridhar.Iyengar2@unisys.com, dirk@riehle.org, issues@emerald.omg.org, mof-rtf@emerald.omg.org X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: KV+!!@6=e9bd-e94PJd9 Hi Pete, this is actually a concern I share with you. However, I think it has nothing to do with the M-Levels architecture. If we take a look at specs like the late OIM/BEM or, as you point out, even the CWM, many of the classes that are formally M2-level classes smack like M1-level classes. So, OIM's BusinessUnit class, modeled as a UML extension and hence an M2-level concept, suggests by its very name that it is an M1-level class, instances of which represent real business units in the real world like "Mike's departement". I admit that I have yet to understand how this is to be interpreted. We solve this problem again by being explicit about levels in naming and architecture. Part of our product includes organizational modeling (see www.skyva.com, as I'm writing through my private address), so we have a UML extension in which we make explicit that this is the M2 level. We have subclasses of Class/Classifier called OrgUnitType (could also be OrgUnitClass) rather than OrgUnit, etc. This way it is clear we are talking about classes of user classes rather than classes of user objects. This way we don't confuse the levels which I believe are still a valid view. Dirk > Dirk, > While I agree with what you say about the difference between logical > and > technical architectures, my original point was purely about the > logical > level. While the 4 'absolute levels' work nicely for stereotypical > database > design scenarios, assigning an absolute level to a model can quickly > become > a lot fuzzier. > For example, even within the Common Warehouse Metamodel one has > traditional > M2 classes such as Table, and Column. But also related to a Table > (for > example) one has classes ResponsibleParty (instances of which might > represent an actual human being - hence it's M1 level) and Document > (instances of which are real documents - likewise M1 level). So > what's the > 'M' level of CWM as a whole? And does it matter (I'd say no)? > > Regards, > Pete > > > -----Original Message----- > From: Iyengar, Sridhar [mailto:Sridhar.Iyengar2@unisys.com] > Sent: 13 December 2000 12:27 > To: Dirk Riehle; issues@emerald.omg.org; mof-rtf@emerald.omg.org; > pete.rivett@adaptive.com > Subject: RE: issue 4111 -- MOF RTF issue > > > Excellent point Dirk. We should emphasize your points in the spec > > -----Original Message----- > From: Dirk Riehle [mailto:dirk@riehle.org] > Sent: Tuesday, December 12, 2000 9:58 PM > To: issues@emerald.omg.org; mof-rtf@emerald.omg.org; > pete.rivett@adaptive.com > Subject: Re: issue 4111 -- MOF RTF issue > > > We address this (and related terminology problems) the following > way: by > being very clear about the difference between a logical and a > technical > (implementation) architecture. > > The four-layer architecture is a logical architecture; for us, the > "m-levels" work nicely. They are absolute levels. Also, they don't > contradict relative level names as model and model instance. > > Technical implementation architectures there are plenty then. They > should > not be prescribed or suggested by the spec. Hence, they should not > affect > its terminology. > > Dirk > > > > At 11:13 AM 12/8/00 -0500, Juergen Boldt wrote: > >This is issue # 4111 pete.rivett@adaptive.com > > > >The Metadata architecture needs to move away from the 4 levels and > labels > > > >The Metadata architecture needs to move away from the 4 levels and > labels: > >and refer to them as an example for straightforward cases such as > database > >modeling. Other non 4-layer examples are also needed. While the MOF > spec > >does point out that "M1-level and M2-level are relative labels", in > >practice the labels are applied quite rigidly and this positively > causes > >confusion, sterile arguments, and in some cases harm to > specifications as > >people grapple with whether a class belongs to M1 or M2 and if the > former > >then it should be excluded "since the RFP asks for a M2 model". An > example > >of the problems can be found in section 13.2 of the SPE joint > submission > >(adtf/00-00-05) though they (wrongly IMHO) think the solution is in > UML > >not MOF. This will not change the MOF spec but how it is applied > and > >models developed hence the severity of 'significant'. > > > >================================================================ > > > >Juergen Boldt > >Senior Member of Technical Staff > > > >Object Management Group Tel. +1-781 444 0404 ext. 132 > >250 First Avenue, Suite 201 Fax: +1-781 444 0320 > >Needham, MA 02494, USA Email: juergen@omg.org > > URL: www.omg.org > > > > > > > >================================================================ > > ---- > Publications, work, and other oddities: www.riehle.org > Reply-To: From: "Pete Rivett" To: "'Dirk Riehle'" Cc: , , , Subject: RE: issue 4111 -- MOF RTF issue Date: Wed, 20 Dec 2000 00:59:11 -0000 Message-ID: <000401c06a72$6994a860$4b4c04c8@orval.adaptive.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200012191626.RAA28672@ice.inf.ethz.ch> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >;kd9Z=4!!"&\d9`5bd9 Hi again Dirk, I'm not sure I understand how the approach you suggest would work in practice: you seem to advocate using 'Type' objects such as OrgUnitType to ensure that true M1 objects such as "Customer" Table are linked only to other M1 objects. To continue my previous example down at the instance level, to say that OrgUnit "Mike's Department" is responsible for the Table "Customer" then would you create an instance of OrgUnitType called "Mike's Department Type" which is linked to Table "Customer" (both now nicely at the M1 level)? Which then begs the question as to what sensibly can one say about "Mike's Department Type" as opposed to "Mike's Department" and how one accesses the latter. Or ensures that the Type is deleted if the (M0) Department is deleted. Similarly for the Document "Customer Table Optimization" - would you create an instance of DocumentType (M2) called "Customer Table Optimization Document Type" (M1) which is linked to the "Customer" Table (also nicely M1)? In which case how does one access the actual document contents (M0)? And what is the point of the M1 "Customer Table Optimization Document Type" object which is tightly linked to its one-and-only instance and which would seem to have little in the way of properties or behavior of its own? Alternatively are you saying that one should ignore the fact there should be M0 objects and attach the document contents and all the information about the department to the M1 objects "Mike's Department Type" and "Customer Optimization Document Type" (i.e. just apply a naming trick to give the illusion that these are M1). This would to most users engender confusion rather than clarity and lead to questions like "if this is the document type then where's the actual document then?" and "can I create more than one instance of these types?". Of course it helps if the users have not already been confused by being over-fed the 4 level architecture! My point is that to try to always map a complete model to one and only one of the traditional 4 M levels has little value, causes a lot of frustration and sterile argument, and moreover is not what was originally intended. To quote the MOF 1.3 spec (section 2.2) "The MOF meta-data architecture is typically (though not exclusively) used as a four layer framework". It then goes on to point out (2.2.3)"The number of MOF meta-levels is not fixed. Since meta-levels are conventionally named upwards from the "information" layer, the meta-level at the top of MOF meta-data framework can vary." and "Terms like M1-level and M2-level are *relative* labels of the meta-levels (we assume the reader can mentally adjust the 'meta-ness' to fit the context.)" I believe that the reason for including the 'traditional' 4 layer framework was just to show that MOF can be applied across any of the traditional levels (more accurately to triples of a class, its metaclass and its instances). Cheers, Pete -----Original Message----- From: Dirk Riehle [mailto:riehle@inf.ethz.ch] Sent: 19 December 2000 16:27 To: pete.rivett@adaptive.com Cc: Sridhar.Iyengar2@unisys.com; dirk@riehle.org; issues@emerald.omg.org; mof-rtf@emerald.omg.org Subject: Re: issue 4111 -- MOF RTF issue Hi Pete, this is actually a concern I share with you. However, I think it has nothing to do with the M-Levels architecture. If we take a look at specs like the late OIM/BEM or, as you point out, even the CWM, many of the classes that are formally M2-level classes smack like M1-level classes. So, OIM's BusinessUnit class, modeled as a UML extension and hence an M2-level concept, suggests by its very name that it is an M1-level class, instances of which represent real business units in the real world like "Mike's departement". I admit that I have yet to understand how this is to be interpreted. We solve this problem again by being explicit about levels in naming and architecture. Part of our product includes organizational modeling (see www.skyva.com, as I'm writing through my private address), so we have a UML extension in which we make explicit that this is the M2 level. We have subclasses of Class/Classifier called OrgUnitType (could also be OrgUnitClass) rather than OrgUnit, etc. This way it is clear we are talking about classes of user classes rather than classes of user objects. This way we don't confuse the levels which I believe are still a valid view. Dirk > Dirk, > While I agree with what you say about the difference between logical > and > technical architectures, my original point was purely about the > logical > level. While the 4 'absolute levels' work nicely for stereotypical database > design scenarios, assigning an absolute level to a model can quickly become > a lot fuzzier. > For example, even within the Common Warehouse Metamodel one has traditional > M2 classes such as Table, and Column. But also related to a Table > (for > example) one has classes ResponsibleParty (instances of which might > represent an actual human being - hence it's M1 level) and Document > (instances of which are real documents - likewise M1 level). So > what's the > 'M' level of CWM as a whole? And does it matter (I'd say no)? > > Regards, > Pete > > > -----Original Message----- > From: Iyengar, Sridhar [mailto:Sridhar.Iyengar2@unisys.com] > Sent: 13 December 2000 12:27 > To: Dirk Riehle; issues@emerald.omg.org; mof-rtf@emerald.omg.org; > pete.rivett@adaptive.com > Subject: RE: issue 4111 -- MOF RTF issue > > > Excellent point Dirk. We should emphasize your points in the spec > > -----Original Message----- > From: Dirk Riehle [mailto:dirk@riehle.org] > Sent: Tuesday, December 12, 2000 9:58 PM > To: issues@emerald.omg.org; mof-rtf@emerald.omg.org; > pete.rivett@adaptive.com > Subject: Re: issue 4111 -- MOF RTF issue > > > We address this (and related terminology problems) the following > way: by > being very clear about the difference between a logical and a > technical > (implementation) architecture. > > The four-layer architecture is a logical architecture; for us, the > "m-levels" work nicely. They are absolute levels. Also, they don't > contradict relative level names as model and model instance. > > Technical implementation architectures there are plenty then. They > should > not be prescribed or suggested by the spec. Hence, they should not > affect > its terminology. > > Dirk > > > > At 11:13 AM 12/8/00 -0500, Juergen Boldt wrote: > >This is issue # 4111 pete.rivett@adaptive.com > > > >The Metadata architecture needs to move away from the 4 levels and > labels > > > >The Metadata architecture needs to move away from the 4 levels and labels: > >and refer to them as an example for straightforward cases such as database > >modeling. Other non 4-layer examples are also needed. While the MOF > spec > >does point out that "M1-level and M2-level are relative labels", in > >practice the labels are applied quite rigidly and this positively > causes > >confusion, sterile arguments, and in some cases harm to > specifications as > >people grapple with whether a class belongs to M1 or M2 and if the > former > >then it should be excluded "since the RFP asks for a M2 model". An example > >of the problems can be found in section 13.2 of the SPE joint > submission > >(adtf/00-00-05) though they (wrongly IMHO) think the solution is in > UML > >not MOF. This will not change the MOF spec but how it is applied > and > >models developed hence the severity of 'significant'. > > > >================================================================ > > > >Juergen Boldt > >Senior Member of Technical Staff > > > >Object Management Group Tel. +1-781 444 0404 ext. 132 > >250 First Avenue, Suite 201 Fax: +1-781 444 0320 > >Needham, MA 02494, USA Email: juergen@omg.org > > URL: www.omg.org > > > > > > > >================================================================ > > ---- > Publications, work, and other oddities: www.riehle.org > From: Dirk Riehle To: "'pete.rivett@adaptive.com'" Cc: Sridhar.Iyengar2@unisys.com, dirk@riehle.org, issues@emerald.omg.org, mof-rtf@emerald.omg.org Subject: RE: issue 4111 -- MOF RTF issue Date: Wed, 20 Dec 2000 11:53:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06AA5.6FBE6792" X-UIDL: +0Pd9@O)!!W+Sd9TBgd9 Hi Pete, I think you are pointing to real problems, but try to find the solution in the wrong place. What I've seen in other discussions, and what I think is the underlying thread in your argument, is the need to have M0-level user objects explicitly represented next to their M1 class next to UML Class. UML doesn't give you this; UML only gives you M1 level objects. MOF, the way it is hooked up to the UML spec, doesn't give you this, MOF gives you only M2 level objects. Let me explain my thinking. A certain type of application requires the co-existence of M2, M1, and M0 level objects in the same (logical) space. Our product, and I assume Adaptive's too, can have the objects OrgUnitType (M2), MyCompanyDepartment (M1), MikesDepartment (M0) right next to each other. You can't do this with UML, because there is no way to express MikesDepartment (or OrgUnitType) logically with UML. (Technically, you may play tricks, for example use UML to describe itself, hence giving you M2 level objects, or using UML Instance to represent M0 level objects. However, both of these approaches constrain you in ways that will later come back and haunt you. In particular, I strongly advise against trying to use the UML Instance concept for representing M0 level objects. Bran Selic recently conceeded "Instance" should better have been named "InstanceSnapshot" for it isn't real instances but illustrations of instances to enhance the description of classes.) > To continue my previous example down at the instance level, to say that > OrgUnit "Mike's Department" is responsible for the Table "Customer" then > would you create an instance of OrgUnitType called "Mike's Department Type" > which is linked to Table "Customer" (both now nicely at the M1 level)? Which > then begs the question as to what sensibly can one say about "Mike's > Department Type" as opposed to "Mike's Department" and how one accesses the > latter. Or ensures that the Type is deleted if the (M0) Department is > deleted. Here is my take at the design problem situation you are describing. Assume Mike is a manager at your company (Adaptive). Class AdaptiveDepartment (M1) has a composition relationship with class Table (M1). This tells us that any AdaptiveDepartment has a Table instance associated with it. The composition ensures if you delete the department, the table will go too (how to implement this, bridge oo and relational, is another issue). My AdaptiveDepartment class seems to be what you mean by "Mikes Department Type". Your name for it sounds too specific to me. In our experience, in org modeling, you want to define company-specific types of org units, e.g. AdaptiveSalesDept, AdaptiveDevelopmentDept, AdaptiveServiceDept, but not classes for one specific singleton type. Hence no MikesDepartment class. Of course, if you really need it, and there are singular aspects about MikesDepartment that require modeling, you would want to have a ReallySpecificPlatinumGoldCustomerDepartment class of which there may be only one instance, and this instance may go by the name of "Mike's Department". > Similarly for the Document "Customer Table Optimization" - would you create > an instance of DocumentType (M2) called "Customer Table Optimization > Document Type" (M1) which is linked to the "Customer" Table (also nicely > M1)? In which case how does one access the actual document contents (M0)? > And what is the point of the M1 "Customer Table Optimization Document Type" > object which is tightly linked to its one-and-only instance and which would > seem to have little in the way of properties or behavior of its own? Are these CWM examples? I have no real experience with CWM except on paper, hence I hesitate to interpret the situation. But again, the main point is, UML lets you express user classes, not user objects, and by extension, CWM lets you express user classes, but not user objects. There is no M0 mikesDepartment or M0 theBigCustomerTable object that you can represent with UML/CWM, at least logically. If you do, using hacks, you will eventually run into consistency problems. Now, I will fully support you in saying that we want to represent these M0 level objects too, so we need a standard for it. (We just use our own proprietory API.) However, this is not to be part of the UML or the MOF spec. > Alternatively are you saying that one should ignore the fact there should be > M0 objects and attach the document contents and all the information about > the department to the M1 objects "Mike's Department Type" and "Customer > Optimization Document Type" (i.e. just apply a naming trick to give the > illusion that these are M1). This would to most users engender confusion > rather than clarity and lead to questions like "if this is the document type > then where's the actual document then?" and "can I create more than one > instance of these types?". Of course it helps if the users have not already > been confused by being over-fed the 4 level architecture! I also find your alternative naming trick solution confusing, so I wouldn't use it. All I can say is that the tower of M-levels starting with M0 works for us. (And I have brought up to speed a whole development team on this issue.) My background are 8 years of metalevel architectures, CLOS and otherwise, which are implementation architectures, but which by necessity had to run and be consistent. I'm interpreting from this perspective, and I'm happy to see that MOF and UML are moving into the right direction to logically match the structures from these time-worn architectures. Indicators are: - MOF can describe itself (gaining recursive closure) - MOF is evolving to be a core subset of UML (allowing logical - inheritance) > To quote the MOF 1.3 spec (section 2.2) "The MOF meta-data architecture is > typically (though not exclusively) used as a four layer framework". It then > goes on to point out (2.2.3)"The number of MOF meta-levels is not fixed. > Since meta-levels are conventionally named upwards from the "information" > layer, the meta-level at the top of MOF meta-data framework can vary." and > "Terms like M1-level and M2-level are *relative* labels of the meta-levels > (we assume the reader can mentally adjust the 'meta-ness' to fit the As usual, you can put things to work in many different ways. Within the four layer architecture, MOF occupies level 3 and only level three. Its instances are M2 level objects the UML definition. Now, from a short remark of Sridhar on this list I gather that UREP uses MOF as a representation mechanism for any M-level object, be it M0, M1, M2, or M3. This is an implementation architecture! Think of it this way: Level ModelName Implementation M3 MOF MOF M2 UML MOF M1 M1 MOF M0 M0 MOF Maybe Sridhar wants to confirm or not. We use a different implementation architecture, that is equally valid (CLOS style). We have a different objective than UREP. Dirk