UML vs. ER modelling (long)

From: abcd <abcd_68_at_yahoo.co.uk>
Date: 29 Dec 2002 04:44:51 -0800
Message-ID: <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. 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:

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?

Thanks a lot in advance,
andy Received on Sun Dec 29 2002 - 13:44:51 CET

Original text of this message