Differences between a conceptual UML class diagram

Question

If I create a conceptual class diagram such that each class captures 'name' and 'attributes' but not 'operations', have I not basically created what would be otherwise considered an ERD? I'm trying to gain an understanding of what the differences are between creating a conceptual class diagram as I have described versus calling it a ERD? If these are still two different animals, can somebody please explain what the differences are?

Answer 1

The class diagram contains just the classes in your object model with eventual links/relationships connecting diagram elements. However those links don't necessarily correspond to physical relationships like in an ERD diagram, but instead they represent logical connections.

The class diagram is just the object model of your application and does not contain any persistence-specific information. When you think about the class diagram forget about the database or any other storage you may use.

The ERD diagram on the other side, is a persistence-specific diagram which display the entities (tables) existing in a (most often) relational database. It also displays the physical relations (and cardinalities) between those tables and all other database-specific information. The ERD diagram can sometimes look similar to the class diagram, but that doesn't mean is the same as a class diagram.

Answer 2

Design class diagrams are made from conceptual model and collaboration diagrams. Design class diagrams include:

1. Classes, associations and attributes
2. Methods
3. Types of attributes
4. Navigability
5. Dependencies

Answer 3

The ER diagrams I've seen (most frequently ERWin IE notation) have focused on the design for a database. They are concerned with primary keys, foreign keys, have unnamed relationships, and usually have no generalization / specialization.

A good UML conceptual class diagram, on the other hand, is not concerned with keys, reflects the problem domain, and has association-end properties that at least hint at the semantics of why things are related. This helps communicate the domain down to more junior developers so they don't have to guess.

Answer 4

It depends on the situation where you may not like to do the ER-D. But imagine if you have a seperate data layer where the data logic is handled. In this case many details of data shall not be shared with the application layer. And you class diagram shall not go beyond the application layer. I must stress that both the diagrams are not equal. And there are situations where you need to do both, mainly in multi-tier architecture, and there are situations where you may be able to just use class diagram; e.g. single-tier application.

I strongly advocate the view that class diagram doesn't abrogate the E-R diagram.

Answer 5

There´s little difference in the expressiveness of both (if we just focus on the attributes, classes and associations part) if you use Extended Entity Relationship diagrams (the most common case nowadays)

True, they look very different at the graphical level since they use different symbols for the elements but the "semantics" are quite similar. They both allow inheritance (again, I´m talking about EER), n-ary associations, association classes, ...