UML vs. ER modelling (long)
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:
logic only covering the remaining 15-20%
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