RJLRef: $PH/OMG/BPDMvsUML2_cc_eb_cc.061104.txt Here are two conflicting views from very highly qualified OMG/ADTF contributors. It reveals risks in design by concensus. Note Cory C's BP[D]M[N] is Business Process [Data/Design?] Modeling [Notation]. Ed B is more into the automated manufacturing CAD area. The truth lies somewhere in the middle. Forwarded message: > From omg-list-errors@amethyst.omg.org Sat Nov 4 07:50:23 2006 > From: "Cory Casanave" > To: > Cc: "'A&D TF \(OMG\) '" , > Subject: RE: Fixing the meta-muddle (was RE: BPMN, BPDM, and UML discussion forum: a proposal ) > Date: Sat, 4 Nov 2006 08:07:28 -0500 > Organization: Data Access Technologies, Inc. > > Ed, > You are certainly consistent in your world view! Your description of the > challenges of providing a unified environment have merit, but ignore the > situation of the users, who are faces with a quagmire of non-interoperable > languages (or diagrams within the same poorly integrated language) to > describe different viewpoints of the same systems and organizations. The > users model the same "entity" in such systems or organizations using > different meta elements, and since this is then a manual effort - can not > maintain inconsistency. Point to point transformation between multiple > languages in the same system is a very difficult environment that is not > user friendly. Certainly we can have some unification of the elements > describing that "entity". > > The problems we have created are simply an artifact of politically driven > poor engineering, not logical necessity. For example, In the course of BPDM > we have been faced with trying to reuse UML elements, the problem was not > that we couldn't find matching concepts, it was that the ones presented are > unnecessarily bound together - you get "baggage" with every UML element. > Sure, their are new concepts that don't match - but given a properly > engineered UML core we could have merged much much more, and that would give > the users the integrated tool set and we would not have had this silly UML > or MOF debate. I have worked on a sufficient number of these meta models to > be confident a better abstracted set of concepts is perfectly practical. > > In fact, many commercial tools normalize these XMI forms into their internal > and more unified tool model and project that unified model onto the standard > of the day. If it can be done in such tools we could do it in OMG. You are > suggesting the perfect is impossible and thus preventing the practical and > useful. > > -Cory > > -----Original Message----- > From: Ed Barkmeyer [mailto:edbark@nist.gov] > Sent: Friday, November 03, 2006 12:35 PM > To: Cory Casanave > Cc: 'A&D TF (OMG) '; bmi@omg.org > Subject: Re: Fixing the meta-muddle (was RE: BPMN, BPDM, and UML discussion > forum: a proposal ) > > Cory Casanave wrote: > > > As fellow long timers in OMG we have watched this ongoing debate in > > many forms, the MOF "domain specific language" approach Vs. the > > "Universal Model Language" (Yes, I know that is not what UML is > > supposed to stand for). And, for as long as there have been these > > arguments we have the same poor tradeoffs either way. The root cause > > is we don't have common properly factored concepts or interoperability - > how embarrassing! > > > > One of the goals of the UML 2 Infrastructure work was to make a first > > pass at fixing this problem, an original intent was that this was a > > library of abstract syntax components that could be used across > > multiple languages. I think it is well accepted that this goal was > > not achieved - and thus we continue to have these problems and arguments. > ... > > > > Perhaps it is time to revisit the root cause of these problems, that > > we don't have our meta concepts properly factored and interoperable to > > allow for projections onto different languages, such as BPMN, UML or > > even more diverse forms of expression. > > 5 years ago, I subscribed to this idea as well. But now that I have seen > what comes of it, not only at OMG, but in ISO 19440 and ATHENA and in PSL, > the bloom is off that rose. The library of standard reusable modeling > concepts has to take one of two forms: > - precise component concepts that are used verbatim off the shelf, like > reusable objects and ebXML Core Components > - high-level abstract classes and properties that are subtyped/refined for > use in a given metamodel. > > The use of precise component concepts, like the use of "reusable objects", > is a design choice. And they cannot be reused by a metamodel for an > off-the-shelf language unless the independent designers had exactly the same > idea, and recognize the terminology used to describe the component. > > High-level abstract classes and properties are just an "upper ontology" by > another name. Like any integrated conceptual schema, an "upper ontology" is > only as good as the ability of the knowledge engineers to abstract from the > application schemas that went into it. In our case, it represents > integration/abstraction of a set of concepts from a certain set of languages > from one viewpoint. It may be difficult for the designers of the languages > in that set to recognize their concepts in that abstraction. (Many of us > have that problem with the UMLv2 metamodel.) And it may be that the common > abstraction conveys no useful semantics. It really makes no difference that > we all agree that "entity", "UML class", "OWL class", "aspect", "datatype" > and "role" are all "classifiers" (unary relations), because the only modeled > property of "classifier" is "hasProperty". And as soon as we distinguish > "class" from "role", we have no consistency across languages. As a general > rule, "upper ontologies" have failed the cost/benefit test. > > Everything else is a combination of undefined terms, deliberately imprecise > abstractions, precise properties, and unintentional ambiguities that are all > characteristic of "language". > > I believe that the owners of a language should define an exchange model for > that language in the terms used in the manual for that language, with the > definitions of those terms that are given in that manual. That way, there > is no question what model in that language is expressed by an M1 instance of > the metamodel. The primary goal of OMG metamodels is to foster > interoperability of tools that use the language. > > Whether the model in that language is unambiguous in a highly precise > reference ontology like PSL is an entirely different question, as is whether > it *needs* to be. And what model most closely corresponds to that one in a > different modeling language is yet another question, and the answer probably > depends on your means of measuring "most closely corresponds", which may > relate to the *purpose* of the translation. > > So I don't see value in trying to build the "common reference meta-component > library" for the set of languages OMG has standardized in 2006. Rather I > think we should render to Caesar the things that are Caesar's. Every > metamodel has a scope -- a set of languages whose concepts it integrates. > UMLv2 has its own overcomplicated metamodel and it should only live with it. > > Other languages should have formal metamodels that match their own > specifications, like ODM and BPMN. Then we can talk about formal mappings > that match certain interchange purposes. > > There is no "gold standard" here. UMLv2 is not one, and there isn't going > to be one. And, to paraphrase William Jennings Bryan, we will not crucify > modeling on the cross of "the universal metamodel". > > -Ed > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology Manufacturing Systems > Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." >