views:

421

answers:

4

The very first step i created a DFD. Then i moved on to create a Class Diagram. And while doing that i felt that i should create the ER diagram first. As there were many details which could not be captured in a Class diagram. So, my question should i create ERD first OR Class Diagrams ?

your valuable inputs are appreciated guys!!! thanks for reading

A: 

ER diagrams suck as start - because they contain LESS Information than the object diagram, which includes a lot more information about methods on objects and inheritance trees - both elements the ER diagram will miss.

As such, you better start with the object hierarchy (class diagram) and then mov on to the mapping side of things ;)

TomTom
why is starting with less (more general) information bad? It is a common way to start at a higher level and provide more detail as you go along. You start by making design decisions such as whether a person should be related to a pet, not whether we shoud include a persons first and last name in the object model.
Russell
Russell, thanks for ur thoughts. This makes sense.
isthatacode
But ignorance does not pay of. Ignoring inheritance means you end up with stupid designes like an object "customer" in a customer table, an object "employee" in an employee table etc.
TomTom
+3  A: 

When modeling, I tend to think in terms of doing the diagrams in whatever order makes the most sense to me at the time. Sometimes that's the class diagram first, sometimes that's the entity-relationship diagram, sometimes that's even the sequence diagram. The main thing to remember is that you're trying to understand things and write them down so that other people can understand them too; fretting about what is the best way to order your thoughts isn't nearly as helpful as just getting down to it and writing those parts that you do understand.

[EDIT]: FWIW, I also tend to start my modeling on paper or a whiteboard and only switch to using a computer when I'm getting closer to what I understand to be going on. (I guess I just don't like drawing on computers.) The key is that modeling is about understanding, and not (very much) about computers.

Donal Fellows
Donal, good insight. thanks
isthatacode
Yep I agree that you be as specific as you can be at the time. If you havent yet fleshed out properties, you may find mapping relationhips is the logical first step.
Russell
+1  A: 

OO purists tend to do the Class diagram first. People with a database background do the ER diagram first and "derive" the class diagram from this (this approach is frowned upon by OO purists)

I prefer an hybrid approach.

Identify the entities first. This should be same from both the database and application (classes) point of view.

Once you have agreed on the entities at a high level, proceed with class diagram and ER diagram in parallel directions - because the "relationships" are different in each. (If you are the only person working on them, then start with the class diagram first and then the ERD. But identify the entitied first).

In my opinion the high level entities should be same, both on the database and the application (Java/C#...). And it is very easy to proceed with the common base - especially if there are different people working on different parts (classes, database).

Nivas
+1  A: 

I would say it really depends on your application. &I know a bit about UML and I know you can model relation multiplicity as well as primary keys just using standard UML class diagrams, so often class diagram is enough. I like starting with class diagram, because I like to use object oriented analysis and design, use cases, use case realizations and analytical classes. On the other side, good database design asks for normalization and sometimes denormalization, different optimizations for data querying... But for that, first I would need to know what I will be querying for and possibly how. I personally see the relational part of most of application just as a storage mechanism, I think about the system in terms of object oriented programming. This is especially usefull with for example Ruby on Rails, which thanks to the Active Record pattern totally abstracts from the relational model, so I don't have to model twice.

Gabriel Ščerbák