From scott.ambler@ronin-intl.com Sat Feb 7 08:34:14 2004 To: Bob Lechner From: "Scott W. Ambler" Subject: Re: agiledata.org/essays/umlDataModelingProfile.html RJLRef: $PH/umlInfo04s522/ScottAmblerFdbk040207.txt At 02:18 AM 2/7/2004 -0500, you wrote: > > To: Bob Lechner > > From: "Scott W. Ambler" > > Subject: Re: dataModeling101 - and Agile DB Techniques > > >... > > > > Great. Any feedback you may have about the UML data modeling profile > > (www.agiledata.org/essays/umlDataModelingProfile.html) would be > > appreciated. My hope is to have a viable profile by the end of the year. > > >Hello again, Scott. I haven't studied your <> in detail, >so these recommendations are probably not what you wanted. There's more to the DM profile than stereotypes. The other OO folks have been misleading the industry for years regarding what needs to be done for a data modeling profile, likely because they haven't thought it through. ----------------------------------- >[The info below is copyright 2004 by R Lechner; you can re-distribute >with the usual attribution and copyright notice.] > >I have another ax to grind: simplifying UML class diagrams, >for pedagogical and MDA implementation reasons. >I teach OOAD to CS and EE majors and want data models >to become a lingua franca to a much wider audience. > >These recommendations represent my frustrations with overly complex >UML class diagrams that IMHO can be more readable AND precise.. Have you looked at www.modelingstyle.info/classDiagram.html at all? >I would reduce the number of alternate diagram topologies and reduce >the number of ways to interpret a relation link between two entities >or associative classes. > >(My (subjective) complexity metric represents my middle ground >as information and behavior modeler; it may not be the analyst's >best communication medium or the power-programmer's class design tool. > > >I believe OMG/ADTF made two serious mistakes in defining UML class models: >its diagramming conventions are overly complex; its many degrees of freedom >hinder readability and especially comparison for reuse. You don't need to use the entire notation. The challenge that the OMG faced is that they needed to define a notation that covered all the bases, but any single project doesn't need the entire notation. > >3. It goes without saying, that an ordered topology should be agressively >attempted when laying out an EERD or class diagram. Unfortunately >even here there is disagreement: as an engineer I favor a top-down, >right-to-left sort direction as most natural; David Hay prefers >Oracle's bottom-up, right-to-left ordering. You'll probably like my style guidelines referenced above. >4. Extend UML to allow arrowheads AND tails (crows-foot) >to denote maxmult > 1 as an alternate to or redundant with UML's '*'. I really like crow's feet myself, in fact the first edition of The Object Primer (1995) suggested such a notation. But this is never going to happen, although there's nothing stopping you from introducing visual stereotypes I suppose. >This old and useful convention (arrowhead in Bachman DSD's, crows-foot or >arrow-tail in IDEF-1X) was abandoned by later standards (e.g. CDIF). >I recommend that EITHER ONE should optionally be allowed >at the many end of a one to many relation link. There is no reason >why they cannot co-exist to denote alternate navigational directions. Most UML modelers know the 1..* notation now, not the crow's foot notation. All this change would do is confuse things for people. > Have you considered posting this material to the web? A white paper might be interesting, and you might even want to get a discussion going on the AM mailing list (www.agilemodeling.com/feedback.htm). - Scott ==================================================== Scott W. Ambler Senior Consultant, Ronin International, Inc. www.ronin-intl.com/company/scottAmbler.html www.agiledata.org www.agilemodeling.com www.ambysoft.com www.enterpriseunifiedprocess.info www.modelingstyle.info www.ronin-intl.com