"Austin Ziegler" <halostatue@gmail.com> schrieb im Newsbeitrag
news:9e7db91105021806141135f8c5@mail.gmail.com...
> "Austin Ziegler" <halostatue@gmail.com > schrieb im Newsbeitrag
> news:9e7db91105021804385d91a8ac@mail.gmail.com...
>> [...]
>>> "[...]This is a far different approach than UML's general,
>>> wide-purpose models. For example, UML class diagrams can be used
>>> for conceptual modeling, object-oriented analysis modeling,
>>> object-oriented design modeling, logical data modeling and
>>> physical data modeling.[...]"
>> FWIW, the author of that statement is wrong. UML cannot be
>> effectively used for either logical or physical data modeling.
>> It's too based in object modeling. People who use UML for ER/data
>> modeling are making a huge mistake. There's far better modeling
>> methodologies out there than UML.
> Just curios: what do you think are the major shortcomings of URL
> that make it inappropriate for ER modeling?
I laid out much of this in a response to Markus in the first Ilias
thread, but I'll repeat it here.
Thank you for investing that effort. I'm neither an UML expert nor an UML
devotee. Still, I think not all your arguments against UML are valid.
Everything. UML has a bunch of problems, ranging mostly from the
fact that it tries to be capable of modeling everything all the
time.
True, that's one big source of problems. See my personal UML drawback
list at the end.
That means that to attempt to do ER/data modeling, you have to
repurpose the class diagram. Except that tables don't have methods,
so you have to ignore that entirely. And that UML uses C/C++/Java
types explicitly, which aren't as rich as or don't map well to SQL
databases by and large.
You probably used an UML tool that makes use of Java, C++ etc. types - but
that's not a feature of UML itself. It's just something that makes code
generation possible / easier for a concrete programming language and I
think that's the reason why vendors do this.
Object oriented mechanisms are generally good at what I call "one-
way browsing." That is to say that there's generally only one way to
access certain pieces of information in a given object model. A
perfect example would be the case of a cellular phone company's
billing policies. Typically, a customer (C) will have one or more
rate plans (P) that can also be assigned to other customers; a
standard many-to-many relationship.
I'd say you're right with regards to OOPL: most of them do in fact lack
proper mechanisms for modeling relationships. I don't subscribe to this
statement with regard to OO modeling: UML does quite a good job at
modeling all differnt kinds of relationships - even n-ary relationships.
<snip/>
UML is based on Jacobsen, Booch and Rumbaugh; they are all object
oriented theorists. And they're wrong when it comes to the supremacy
of OO design over proper ER design.
Do they actually claim that?
But UML encodes that bias and
forces you to make choices that you should not have to make in your
ER modeling if you're making the mistake of using UML for that
instead of the established models for ER. (Indeed, for some types of
database design -- typically data warehousing, ER isn't appropriate
either -- you need what is called Dimensional Modeling, and I know
very little about that.)
Note that I'd *never* suggest that ERD should be used for object
modeling. UML Class Diagrams are perfectly good for that. But that's
about *all* they're good for, and they're not always good for that
in all languages because they make assumptions about the language
that will be used.
UML itself is quite general in fact, I assume you are rather talking about
specific tools.
Products like ArcStyle might be able to help with
that, but they'll still never produce a good database schema from an
object model. Never.
Hm, I have the impression that you've worked with awful UML tools (or UML
tools that were not suited to the task you wanted them to fulfill) and now
you blame UML. IMHO we should keep that separate.
Here's my UML drawback list (TM)
- Too many versions
- UML is used for modeling *and* graphical programming. IMHO it's better
suited to modeling than to programming; the difficulties getting a proper
UML tool with working reverse engineering are a good indication for this
point.
- People often do not distinguish between these two use cases of UML and
that creates some confusion.
I still find UML (or rather a subset of it) quite useful to sketch or
design certain aspects of a system. I never use it for direct code
manipulation as I've experienced too many problems with this. Also I
think it's not productive to model a complete system down do every detail
with UML - which is what you would have to do if you wanted to get code
out of this.
Kind regards
robert
···
On Fri, 18 Feb 2005 22:09:47 +0900, Robert Klemme <bob.news@gmx.net> > wrote:
>> On Fri, 18 Feb 2005 18:34:51 +0900, Phil Tomson > >> <ptkwt@aracnet.com> wrote: