From omg-list-errors@omg.org Mon May 5 13:14:29 2003 Received: from amethyst.omg.org (amethyst.omg.org [192.67.184.64]) by saturn.cs.uml.edu (8.12.9/8.12.9) with ESMTP id h45HEQNM104061 for ; Mon, 5 May 2003 13:14:26 -0400 (EDT) Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by amethyst.omg.org (8.12.8/8.12.8) with ESMTP id h45HCBeK032033 for ; Mon, 5 May 2003 13:12:12 -0400 Received: from dribble.mel.cme.nist.gov [129.6.71.12] by hobbit.omg.org asmtp(2.1c) id 26627; Mon, 05 May 2003 13:28:03 -0400 (EDT) Received: from nist.gov (polonius.msid.cme.nist.gov [129.6.77.120]) by dribble.mel.cme.nist.gov (8.12.9/8.12.9) with ESMTP id h45HA9rN016511 for ; Mon, 5 May 2003 13:10:09 -0400 (EDT) Message-ID: <3EB69AF0.60004@nist.gov> Date: Mon, 05 May 2003 13:10:08 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en, fr, de, pdf, it, nl, sv, es MIME-Version: 1.0 CC: OMG ADPTF Subject: Re: MOF, OCL and Semantics [was: RE: a question] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Steve Mellor wrote: >> One part of this might be to move the action model from >> superstructure to the infrastructure. The actions are >> defined in the most primitive fashion (eg, CreateObjectAction >> does not run constructors, DestroyObjectAction does not clean >> up dangling pointers, etc). This was done intentionally to >> support building complete languages from it. Pete Rivett wrote: > This is exactly what the 2U Infrastructure submission did! And the 2U > Superstructure had all the different behavioral concepts mapped down to > this concise set of primitive actions. With consequent advantages in > terms of unambiguous definition and having semantic commonality across > the different behavioral diagrams. > There was significant push-back from U2P when we tried to suggest this > as part of submission reconciliation. Kerry Raymond wrote: > I agree entirely that MOF does > not have much support for expressing behaviour semantics. However, the > implication seems to be that this was some oversight in the MOF spec. Did > anyone ever consider that it was a design choice? Kerry is right. When I first railed about the absence of behavioural concepts in the MOF, Conrad and Evan (Ontology SIG) were the first to point out to me that the MOF v2 RFP DID NOT ASK FOR SUPPORT FOR ACTIONS. So the intent of the MOF, as perceived by the MOF implementors, did not require support for actions, and the U2P "pushback" was appropriate. My concern is a bit different, and it matches Pete's intent. We can no longer talk about the MOF as providing "common semantics for modeling languages", because it is the 21st century now, and much of the IT world, and particularly UML, has moved beyond the static data modeling languages of the 1980s. The fundamental action model for the relational database world was well-defined in Codd's treatise, and that is the model that is assumed in the MOF. But there are several notions in the UML Superstructure (and in BPEL and BPSS and WSDL and IDEFn (for n!=1), etc.) that go beyond Codd's relational operations model. It is all well and good that practical considerations demanded that MOF products stay within the database semantics of operations, and the standard was written to support the scope of MOF implementations. But then we must be careful when we talk about the relationship of the MOF to modeling languages: At one level, it captures the "abstract syntax" of the modeling language -- the "deep structure" of utterances in the language in terms of entities/objects, attributes and relationships, whose meaning is defined only in text that accompanies the meta-model. At the "abstract syntax level", there is no "reference semantics" for *any* modeling language construct. At another level, it encourages the mapping of *some* constructs of the arbitrary modeling language into UMLv2 Infrastructure concepts whose semantics is *standardized* in the MOF itself. At that level, the MOF captures the common semantics of constructs in a number of modeling languages, and enables some kind of re-expression of a model in a different language. But this only works for language concepts that have images in the Infrastructure that are "semantically equivalent". The MOF does *not* provide "implicit semantic equivalents" = "reference semantics" for any "action" concept. My concern is that we are careful to distinguish which of these we are talking about -- "capturing abstract syntax" is different from "capturing reference semantics". According to Kerry, the MOF was intended to do the former; the latter is an incomplete afterthought. And then there is the OCL ringer. It would have been possible to base the fundamental semantics of the MOF on the OCL v2 meta-model *instead of* the UML v2 Infrastructure. That would have made the MOF "Core" significantly more powerful, but significantly less manipulable -- another tradeoff. The great advantage of doing this is that the MOF would then have native semantics for the interpretation of pre-conditions and post-conditions, which is an adequate means of defining most actions, although perhaps not a very intuitively tractable one. As it is, the MOF allows the attachment of OCL syntactic strings to MOF objects, with the assumption that the string is parsed into a deep-structure that refers to a meta-model that is partially integrated into the MOF Metamodel. To the extent that I can map EXPRESS (ISO 10303-11) "rules" into the OCL meta-model (about 98%), I could do exactly the same thing with EXPRESS strings or strings, with the same degree of "integration" into "MOF semantics". The MOF standard defines the compliance point in which the *tool* understands OCL, as distinct from any other choice, but that is the only difference. My concern here is that we don't have a "semantic framework", we don't have a unified "reference semantics", and we are pretending that MOF v2 is/has one. UML v2 is closer. What we have done is to patch together several languages with related concerns and purposes, to get a "language system" that is able to do a lot of good things, but also has a lot of strange holes and impedance mismatches. What we have done here strongly resembles the development of "distributed systems" with CORBA-wrapped legacy services and new clients that was common in the 1990s. We didn't design a system with a target scope and well-defined components and engineer to that. The MOF is just a part of the OMG suite -- a powerful patchwork. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8260 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From omg-list-errors@omg.org Mon May 5 15:06:42 2003 Received: from amethyst.omg.org (amethyst.omg.org [192.67.184.64]) by saturn.cs.uml.edu (8.12.9/8.12.9) with ESMTP id h45J6fNM026378 for ; Mon, 5 May 2003 15:06:41 -0400 (EDT) Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by amethyst.omg.org (8.12.8/8.12.8) with ESMTP id h45J5ceK006630 for ; Mon, 5 May 2003 15:05:38 -0400 Received: from post.adaptive.com [195.217.222.156] by hobbit.omg.org asmtp(2.1c) id 30927; Mon, 05 May 2003 15:21:30 -0400 (EDT) Received: from [200.4.76.50] by cobbolds.adaptive.com (NTMail 7.00.0018/NT8312.00.a7d0cefb) with ESMTP id gbybcaaa for adtf@omg.org; Mon, 5 May 2003 20:03:32 +0100 content-class: urn:content-classes:message Subject: RE: MOF, OCL and Semantics [was: RE: a question] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 May 2003 20:03:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MOF, OCL and Semantics [was: RE: a question] Thread-Index: AcMTKUcMN2mxUtdcSgmFbzRLmrLbxwADBRog From: "Pete Rivett" To: Cc: "OMG ADPTF" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by saturn.cs.uml.edu id h45J6fNM026378 Status: RO > So the intent of the MOF, as perceived by the > MOF implementors, did not > require support for actions, and the U2P "pushback" was appropriate. Ed, the 2U submission(s) I referred to were for UML 2.0 InfraStructure and Superstructure not MOF (2U never submitted to MOF). Some other picky points: I don't see why you say the relational model "is that assumed in the MOF" - more accurate would be to say that MOF assumes an early OO model (e.g. as in OMG's original OMA). MOF has nothing like the relational algebra; and it does allow modeling of operations not just data structures. MOF makes use of UML Infrastructure and so allows reference to not only OCL strings but OCL expressions fully modeled using the OCL 2.0 metamodel. The difference between OCL and Express strings is that *OCL itself* is designed to refer to modeled constructs in UML/MOF (there is indeed an explicit compliant level for MOF in OCL) and so can 'deeply' model the expressions with reference to the *actual modeling construct* in the MOF metamodel (or UML model). More substantively, I'd like to understand more what you mean by 'reference semantics'. Are you saying that MOF does provide this for what you call 'database operations' but not for 'actions'? Would incorporating something similar to what 2U proposed in terms of primitive actions into Infrastructure (and its subsequent incorporation into MOF) address your concerns? Architecturally speaking, and regardless of what the MOF 2 RFP actually requested, do you think MOF *should* provide this level of coverage? Finally, do you think that (U2P) UML 2.0 Superstructure provides the reference semantics you're looking for - in particular to the level of precision you think necessary? Regards Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Ed Barkmeyer [mailto:edbark@nist.gov] > Sent: 05 May 2003 18:10 > Cc: OMG ADPTF > Subject: Re: MOF, OCL and Semantics [was: RE: a question] > > > Steve Mellor wrote: > >> One part of this might be to move the action model from > >> superstructure to the infrastructure. The actions are > >> defined in the most primitive fashion (eg, CreateObjectAction > >> does not run constructors, DestroyObjectAction does not clean > >> up dangling pointers, etc). This was done intentionally to > >> support building complete languages from it. > > Pete Rivett wrote: > > This is exactly what the 2U Infrastructure submission did! > And the 2U > > Superstructure had all the different behavioral concepts > mapped down > > to this concise set of primitive actions. With consequent > advantages > > in terms of unambiguous definition and having semantic commonality > > across the different behavioral diagrams. There was significant > > push-back from U2P when we tried to suggest this as part of > submission > > reconciliation. > > Kerry Raymond wrote: > > I agree entirely that MOF does > > not have much support for expressing behaviour semantics. > However, the > > implication seems to be that this was some oversight in the > MOF spec. > > Did anyone ever consider that it was a design choice? > > Kerry is right. When I first railed about the absence of behavioural > concepts in the MOF, Conrad and Evan (Ontology SIG) were the first to > point out to me that the MOF v2 RFP DID NOT ASK FOR SUPPORT > FOR ACTIONS. So the intent of the MOF, as perceived by the > MOF implementors, did not > require support for actions, and the U2P "pushback" was appropriate. > > My concern is a bit different, and it matches Pete's intent. > We can no longer talk about the MOF as providing "common > semantics for > modeling languages", because it is the 21st century now, and > much of the > IT world, and particularly UML, has moved beyond the static data > modeling languages of the 1980s. The fundamental action > model for the > relational database world was well-defined in Codd's > treatise, and that > is the model that is assumed in the MOF. But there are > several notions > in the UML Superstructure (and in BPEL and BPSS and WSDL and > IDEFn (for > n!=1), etc.) that go beyond Codd's relational operations model. > > It is all well and good that practical considerations > demanded that MOF > products stay within the database semantics of operations, and the > standard was written to support the scope of MOF > implementations. But > then we must be careful when we talk about the relationship > of the MOF > to modeling languages: > At one level, it captures the "abstract syntax" of the modeling > language -- the "deep structure" of utterances in the > language in terms > of entities/objects, attributes and relationships, whose meaning is > defined only in text that accompanies the meta-model. At the > "abstract > syntax level", there is no "reference semantics" for *any* modeling > language construct. > At another level, it encourages the mapping of *some* > constructs of > the arbitrary modeling language into UMLv2 Infrastructure > concepts whose > semantics is *standardized* in the MOF itself. At that > level, the MOF > captures the common semantics of constructs in a number of modeling > languages, and enables some kind of re-expression of a model in a > different language. But this only works for language > concepts that have > images in the Infrastructure that are "semantically > equivalent". The > MOF does *not* provide "implicit semantic equivalents" = "reference > semantics" for any "action" concept. > > My concern is that we are careful to distinguish which of > these we are > talking about -- "capturing abstract syntax" is different from > "capturing reference semantics". According to Kerry, the MOF was > intended to do the former; the latter is an incomplete afterthought. > > And then there is the OCL ringer. It would have been > possible to base > the fundamental semantics of the MOF on the OCL v2 meta-model > *instead > of* the UML v2 Infrastructure. That would have made the MOF "Core" > significantly more powerful, but significantly less manipulable -- > another tradeoff. The great advantage of doing this is that the MOF > would then have native semantics for the interpretation of > pre-conditions and post-conditions, which is an adequate means of > defining most actions, although perhaps not a very > intuitively tractable > one. > > As it is, the MOF allows the attachment of OCL syntactic > strings to MOF > objects, with the assumption that the string is parsed into a > deep-structure that refers to a meta-model that is partially > integrated > into the MOF Metamodel. To the extent that I can map EXPRESS (ISO > 10303-11) "rules" into the OCL meta-model (about 98%), I could do > exactly the same thing with EXPRESS strings or language here> strings, with the same degree of "integration" > into "MOF > semantics". The MOF standard defines the compliance point in > which the > *tool* understands OCL, as distinct from any other choice, > but that is > the only difference. > > My concern here is that we don't have a "semantic framework", > we don't > have a unified "reference semantics", and we are pretending > that MOF v2 > is/has one. UML v2 is closer. What we have done is to patch > together > several languages with related concerns and purposes, to get > a "language > system" that is able to do a lot of good things, but also has > a lot of > strange holes and impedance mismatches. What we have done > here strongly > resembles the development of "distributed systems" with CORBA-wrapped > legacy services and new clients that was common in the 1990s. > We didn't > design a system with a target scope and well-defined components and > engineer to that. The MOF is just a part of the OMG suite -- > a powerful > patchwork. > > -Ed > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8260 FAX: +1 301-975-4694 > > "The opinions expressed above do not reflect consensus of > NIST, and have not been reviewed by any Government authority." > > The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company.