From lechner Mon Sep 23 21:58:54 2002 Subject: RE: UML Model Driven Architecture Criticism - (fwd2CGeggis)) To: cgeggis Date: Mon, 23 Sep 2002 21:58:54 -0400 (EDT) RJLRef: $PH/05f523/uml2mdacritique020923.txt Forwarded message: >From lechner Fri Sep 20 02:07:00 2002 From: Bob Lechner Subject: RE: UML Model Driven Architecture Criticism - is DBRGrp interested? To: kajal (Kajal Claypool), sieg, heines (Jesse M. Heines), cchen (Cindy Chen) Date: Fri, 20 Sep 2002 02:06:58 -0400 (EDT) Cc: lechner (Bob Lechner), ntansala (Naiyana Tansalarak) Hello all. I'm responding to Kajal's invite to DBRG's Mon 1PM meetings. I might attend this Mon (when I also could clean out my office before the move this coming week). I don't propose this for a discussion topic (yet). I know that DB and SE is each broad enough to keep lots of things off the table, while DBRG focuses on other priorities. So don't worry if this is out of scope. However if this does overlap your interests enough, I would welcome your comments. This is my first attempt to articulate a response to the attached correspondence thread; I hope it doesn't try your patience:-) (The rest of this thread, 2600 lines in ~lechner/Mail/omgmdavsmdc, is a long-winded discussion of varying opinions re: 'is MDA just Model-driven-code-generation?' and 'what is Architecture?'. MDA is scheduled for UML2.0; UML 1.5 is now online as 967 pp,.pdf :-) I have in mind a [hopefully constructive?] contribution to this discussion, somewhat along the lines of Cory and Pete: IMHO, UML is over-complicated, precisely because OMG/ADTF tried to accomodate OOPLs (class diagrams with innumerable decorations) prematurely: before they figured out how to retain specification and design and info modeling and dynamic behvior artifacts following persistent RDB precepts. Along the way, they had to give up the old military KISS principle (Keep It Simple, Stupid). I believe that UML needs a core of primitive concepts from which other more elaborate models can be extended. The key is to insure that the artifacts (model instances) used by today's elaborate modeling approaches can be mapped to/from this common core. After proof of concept, it would be up to all the vendors to insure that their tool outputs are mappable or give up UML compatibility. Nowadays XML is proposed as this common denominator, but XML is blind to semantics. There are other simpler and less general ways to preserve structural lexical content (e.g. any RDB). MDA also needs to preserve dynamic behavioral (semantic) content, at multiple concentric layers of the system architecture. As the discussion below points out, semantics is a moving target, is NOT standardized, and probably will never be. The MIT talk I heard tonight (from nikhil@sandburst.com) re: Bluespec toolset for VLSI design is one example of semantics as a moving target. Sandburst translates Haskell specs to Verilog simulations using Term Rewriting System (TRS) techniques from Arvind/MIT and compiler optimization algorithms from James Hoe, CMU (Hoe is talking at MIT next Wed 330PM). They did 100K gates so far, 1M gates is the target for this fall. I don't know whether OMG/UML can get to their level of semantic sophistication. IMHO OMG prematurely tried to move beyond a common core that prioritizes persistent (static) relational content and standardize (runtime) inheritance and other O-O concepts, which mixed in too many implementation issues. (I don't know enough organizational theory to say if this mixed policy with mechanism.) I can't say whether my core/minimalist approach will satisfy OOPL tool designers or the ORDB community. I contend that an EERD for an info model that is refined manually or automatically by the Optional- Max principle [Sanders: Data Modeling, B-F 1995] needs only two metadata content tables (and 1..many relations with parent fkeys) to provide reflective and self-describing design descriptions together with executable prototypes for OOPL/ORDB applications that reside in an ordinary RDB. Whether the universe of OOPL apps is severely over-constrained by this RDB strait-jacket is still an open question. My apps tend to be engineering/manufacturing systems and framework tools to aid their software developers. UML 2.0 (or even 1.5) might enrich my minimalist approach beyond my wildest dreams - who knows? My problem is that UML is so verbose and comprehensive that I can never get to fully appreciate how useful are its many degrees of freedom. I know that DB and SE is each broad enough to keep lots of things off the table, while DBRG focuses on other priorities. So don't worry if this is out of scope. However if this does overlap your interests enough, I would welcome your comments. Regards, Bob Lechner ------------------------------------------ Forwarded message: > From omg-list-errors@emerald.omg.org Thu Sep 19 17:23:13 2002 > Message-ID: <9E046A6BAA18D61189240000E85123F507E22D@EMAILER> > From: Cory Casanave > To: "'Pete Rivett'" , > "'BERRISFORD, Graham'" > > Cc: adtf@omg.org > Subject: RE: MDA = MDC? - UML for business/architecture modeling? > Date: Thu, 19 Sep 2002 17:07:28 -0400 > X-Mailer: Internet Mail Service (5.5.2650.21) > MIME-Version: 1.0 (Generated by Clearswift ES version 4.7.0.120) > Content-Type: text/plain; charset="iso-8859-1" > > Pete, > While it usually doesn't happen - I'm going to have to disagree with you. I > think this should be and must be "UML" and yes, this would put UML in the > position of the "Universal Modeling Language". But, I don't think that is > the UML of today for all the valid reasons you point out. The proper > solution is exactly the "Family of languages" approach that has been a > strong goal of UML-2, but the UML-2 we see emerging misses this mark by a > long shot. > > First, I absolutely agree that users concerned with a specific viewpoint or > domain should see a modeling language tuned to their needs, terms and > concepts. I also agree that complex systems will integrate a set of these > models from these different viewpoints at various levels of abstraction. > Everything from your business architecture to your Java expression should be > "connectable" in this environment. Further, many of the models will be > derivatives of others in the MDA sense. > > However, if each of these models is a "pure" Meta-model of that domain, how > will we connect them? We have a common "mechanism" in the MOF without > common semantics. The central problem to be solved is how the viewpoints > interact and relate. What we really have is a single model with views on it > from various perspectives. We have to understand that a model element from > "view a" is the same element as one found in "view b". We have to be able > to relate the common semantics. For this to work these models need to be > constructed from a "semantic library" such that the concepts are reused > across these various views. We can then relate the models based on their > common semantics, regardless of how they are expressed for a given purpose. > While there has been good work on "abstracting the Meta model" for UML-2, it > has never been done sufficiently to be able to construct these various > languages while retaining the common semantics. > > I would also propose that we should have graphical and non-graphical > notations the go with the elements in the semantic library. At least by > default we should show the same concept the same way. These core semantics > and the notations are the heart of UML - so I would think it appropriate to > build UML as a family of languages related by common semantics and > notations. It is also very reasonable to have generic tools that will allow > the experts to construct and refine these languages for the users. > > MOF alone is not sufficient, we need people to be able to buy generic tools > that can be tailored as well as the purpose-specific ones. We should also > have more commonality of notation than a MOF only solution would normally > offer. So while MOF can be the core, it would seem that the semantics, > notations and tooling together make it UML. For one thing, working with 8 > different tools is impractical - even if they can share models in the MOF. > Ultimately this must be brought together under a common suite - the generic > analysis/modeling/development tool that encompasses everything from > architecture to objects to data models. Producing this is not a "technology > problem" - it can be implemented. UML seems like the best candidate to > become this universal environment, but I fear that a compromised UML will do > more harm than good - it will stall the marketplace. > > The final issue is one of market presence - UML is the modeling "market > leader", it is what people think of when "architectures" need to be done. > Trying to offer an alternative will be fighting the market - I know about > that one :) So if its modeling it will be UML - at least for the next few > years. Our only option is to make UML-2 sufficient for the job. > > -Cory > > > -----Original Message----- > > From: Pete Rivett [SMTP:pete.rivett@adaptive.com] > > Sent: Thursday, September 19, 2002 12:19 PM > > To: 'BERRISFORD, Graham' > > Cc: adtf@omg.org > > Subject: RE: MDA = MDC? - UML for business/architecture modeling? > > > > Hi Graham, > > I'm interested in why you think *UML* should be extended to cover the very > > important business/architecture areas you describe (and to which I could > > add > > several more). > > These are a number of quite varied areas of modeling, often carried out by > > people with quite different skills and backgrounds. > > Clearly it should be possible to integrate/link and trace between these > > various models, but I can foresee the danger that if UML is inflated to > > become a 'Universal' Modeling Language then: > > - it could become too bloated and unwieldy for anyone to bother to learn; > > - or for anyone but a few 'software giants' to meaningfully support in a > > single tool; > > - it could put off business people through the inclusion of the necessary > > technical modeling aspects; > > - it could mean different communities having to learn different > > vocabularies (as overlapping concepts are merged); > > - tying standardization of all these areas to the same timeline could > > mean > > premature or delayed standardization for a particular area; > > > > and finally: > > - it will become impossible to bring together all the specific interests > > to > > achieve a respectable unified standard (and majority voting would mean the > > spec for a specialized area being decided upon by non-specialists). > > > > I'm not saying all the above is inevitable (though the danger signs are > > there with UML2 even - the current U2P Superstructure alone is 670 pages): > > just that such an endeavor seems very risky hence my question about what > > you > > see as the benefits. > > > > An alternative is to have (comparitively) small focused groups working on > > their area of specialism (e.g. process modeling, business rules, software > > deployment) and standardizing appropriate notations, metamodels and tool > > support as their area reaches sufficient maturity. But based on a common > > metadata/tool integration framework which will allow more loosely-coupled > > linking and traceability between the different models: in effect allowing > > metamodels to be like 'components' with relatively small integration > > points > > and hence minimizing the coupling to facilitate differing rates of change. > > > > An example of such a specialist/focused group is around information > > modeling > > with CWM (despite its name not restricted to Warehousing) though this has > > not addressed the area of notation. Even though independent of UML it has > > arguably not gone far enough and has suffered from over-use of UML > > concepts > > which has added baggage (e.g. a Relational Table has Generalizations) and > > to > > some extent slowed its acceptance into the data modeling community. > > > > This approach is maybe what some people refer to as a 'family of > > languages' > > though I have seen no generally accepted definition for this. One approach > > also called 'family of languages' I would certainly reject for most > > 'business' models is of applying profiles/stereotypes to UML's > > object-oriented system modeling concepts (e.g. to model <> as a > > stereotype of Class and <> as a stereotype of Package). > > I'd hope the arguments for rejecting this are obvious (this email is long > > enough already). > > > > Pete > > > > Pete Rivett (pete.rivett@adaptive.com) > > CTO, Adaptive > > 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: BERRISFORD, Graham > > > [mailto:Graham.BERRISFORD@london.sema.slb.com] > > > Sent: 16 September 2002 20:03 > > > To: adtf@omg.org > > > Subject: RE: MDA = MDC? > > > > > > > > > FYI - our requirement - as an OMG member organisation > > > > > > We would like to see UML made more useful for high-level 'architecture > > > definition' of the kind covered by our in-house guidance - > > > especially our > > > business, system and technology views. > > > > > > Our business view might correspond to a CIM. > > > Our system view is related to a PIM, but at a much higher level. > > > Our technology view is more to do with Platform than CIM, PIM or PSM. > > > > > > We need things like context diagrams, data flow diagrams, data flow > > > structures (Jackson structures?), richer deployment diagrams, richer > > > business processs/workflow diagrams and so on. > > > > > > The MDA glitter (that's a kind word for it) is dazzling us so > > > much that we > > > can't see if such requirements are being addressed. Where > > > should I look > > > please? > > > > > > Graham > > > > > > -----Original Message----- > > > From: Daniel Duffy [mailto:dduffy@datasim.nl] > > > Sent: 16 September 2002 06:19 > > > To: Mullins, Chalon; Jeffrey Mischkinsky; jishnu@hp.com > > > Cc: eseidewitz@intelidata.com; adtf@omg.org > > > Subject: RE: MDA = MDC? > > > > > > > > > > And people react in predictable ways: I have talked about > > > MDA to a number > > > of > > > > folks. There eyes light up when you tell them the name. > > > But when you > > > > explain what's really there, there is much less interest. > > > > > > This is what happens a lot! remember when XML was hot? > > > > > > We do indeed need substance behind the glitter. > > > > > > Daniel > > > > > > > > > _________________________________________________________ > > > This email is confidential and intended solely for the use of the > > > individual to whom it is addressed. Any views or opinions > > > presented are > > > solely those of the author and do not necessarily represent those of > > > SchlumbergerSema. > > > If you are not the intended recipient, be advised that you > > > have received > > > this email in error and that any use, dissemination, > > > forwarding, printing, > > > or copying of this email is strictly prohibited. > > > > > > If you have received this email in error please notify the > > > SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600. > > > _________________________________________________________ > > > > > > > > > The information contained in this email and any attached files are > > 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. > > > ----------------------------------------------------------------------- > > The contents of this message have been scanned for viruses by > the Clearswift ES Policy Server, and no viruses were found. >