Re: Disadvantages ORM/UML/ER
Date: Thu, 09 May 2002 20:02:24 GMT
Message-ID: <MPG.1744a05c63dbe8e9989707_at_news.easynews.com>
In article <ce7804bc.0205091034.4143972a_at_posting.google.com>,
a_vaeter_at_hotmail.com says...
> Thanks for the links. I've read some parts very fast to get an
> overview. Because that site is all about ORM I think it is a little
> bit coloured about the (dis)advantages.
>
> I hoped the newsgroupreaders could tell what they like or dislike
> about UML, ORM and ER. Maybe you can tell someting about your
> experiences?
UML has many disadvantages for proper data modeling. It's good for relating a data model in a form beneficial to an OO developer for implementation use, but otherwise it is bad for requirements gathering. In the latter case, UML is symbol-rich yet still has problems with illustrating some relational concepts.
The main complaint about ORM tends to be the visual complexity of a fully-utilized ORM diagram. ORM has many symbols too, but not as many as UML.
The complexity arises from the fact that attributes aren't grouped nicely under an entity. In fact, attributes aren't really considered as such in ORM. That is an implementation distinction. In ORM, you'll convert a conceptual object to an enity or an attribute based on the nature of the roles it has. This is a real advantage. As soon as you decide somthing is an attribute (ER) or property (UML), you've constrained the system somewhat. However, this also means you have a ton of ovals on your diagram.
The truth is that elements of the ORM notation are independant of each other, and a proper tool that supports ORM should be able to hide/show various levels of complexity. Microsoft's VSEA does this to some degree. You should be able to show only the symbols you need to show.
The real beauty of ORM is that it is based on predicate logic and natural language theories. It holds together well and can flip from textual and graphical forms very easily. It can also turn into ER and UML models just as easily.
ER lies somewhere in between the two. It is attractive, minimal but not too much and has has an asthetic, organized look that can easily be explained to the business people from whose domain expertise you are gathering and modeling. It doesn't do any meaty constraint modeling in its common form. It's main disadvantage is that it almost isn't enough for requirements gathering and isn't enough for implementation, especially for OO practitioners. "Jack-of-all-trades, master of none" one might say. It usually has to somehow be converted to something else.
I used to model data exclusively in ER, suppliment with UML diagrams for the application layer, but I find myself using ORM more and more. Thanks to its constraint-rich, "atomic" notation, I can model a lot of complexity and I can easily get the physical ER for pushing out to a db, I can get the UML (not yet, but I am thinking of how to get it out of Visio) for developers to use and I can get the textual assertions or simplified diagrams for requirements gathering and signoff by principals.
(Any opinions expressed are strictly mine only and not my employer's)
Paul Tiseo, Intermediate Systems Programmer Reply To: 123tiseo.paul_at_123mayo.edu (drop the numbers) Received on Thu May 09 2002 - 22:02:24 CEST