Re: UML vs. ER modelling (long)

Hi,

There will not be any single "rigth" answer in this topic. Please, see my comments below.

AlexV.

"abcd" <abcd_68_at_yahoo.co.uk> wrote in message news:cafa549.0212290444.4e853bf9_at_posting.google.com...
> Hi all,
>
> I recently took over this project, which was started by someone else a
> few months before. All the major architectural and technological
> choices were already made when I joined i.e., J2EE (with a pre-2.0 EJB
> container :-(), Oracle 9i, entirely Web-based system with servlets and
> JSP, OOA&D with UML and a USDP-like methodology.

What is USDP ? something Distributed Programming?

> It's a huge business
> information system for a large multinational company, covering nearly
> all aspects of the company's business, which includes supplies, active
> invoicing, recording of suppliers' invoices, product configuration,
> offers, orders, asset management, etc.
>
> When I joined the project I found out that my predecessor had analysts
> use UML for everything, which means class diagrams for static stuff,
> activity and sequence diagrams for business process modelling, and so
> on. So far, so good. I'm a long-time UML user, and I've succesfully
> applied it to very diverse application domains so I'm entirely
> familiar with it. However, at a closer look this system showed the
> following characteristics:
> - extremely data-centric, the data model being much more complicated
> than the business processes
> - a very very complicated data model, actually one of the most
> intricate I've ever seen
> - most (say about 80-85%) transactions are dumb, CRUD-like, real biz
> logic only covering the remaining 15-20%

Anyway, 99.99% of applications are data-centric and data-model will be more complicated than business model. for sure. From your description, I see possible problems with

(i) abstraction level,
High-level "business" and "conceptual" UML diagrams must be free from data-model

(ii) vertical separation
Good multi-tier design separates persistence layer, so business layer is almost free from CRUD implementation concerns

(iii) horizontal separation:
Complex system must be divided horizontally into several blocks with reasonably small well defined inter-connections.

> Now my question is: What methodology/notation/approach to use?
> Alternatives include:
> 1. sticking to UML for everything. This has the big advantage of
> having one, cohesive environment (for example, you can draw sequence
> diagrams involving objects instantiating classes from the analysis
> diagrams). However, eventually you have to design an e-r model for
> your persistent data, and this means an extra burden (at least while
> the UML profile for data is not finalised)
> 2. using an E-R tool for data (such as E-R Studio, E-Rwin, etc.) while
> still using UML for dynamic diagrams (activity, etc.). This would save
> a lot of time by allowing one to directly defining data at the
> relational level, but would somewhat reduce cohesiveness. "Real" UML
> would be used only for the 15-20% including real business logic. In
> other words: Why should I use UML to model classes that will never
> have a run-time image in the form of Java objects, but that will only
> exist as tables in a DB? Wouldn't it be better to just model those
> directly in E-R and use UML only where it's really needed?
>
> Any suggestions out there?

IMHO, UML is far from entering world of relational databases. DBA must, de-facto, build robust data-model in, say ERWin from UML-based business model. If there is no java class for some tables, than it is NOT business domain and not UML. Many-to-many resolving, inheritance resolving, non-functional requirement like history tables, and similar aspects - all this is part of DBA job with ERWin.

Thus, in theory, UML and ER tool has no overlap as soon as business and data models are separated.

AlexV.

> Thanks a lot in advance,
> andy
Received on Sun Dec 29 2002 - 18:42:05 CET