Class diagram

[Pradeep bhatt]

Does the class diagram capture all the classes in the system?

[Ilja Preuss]

Most probably not - depends on what you are drawing it for.
What are you drawing it for?

[Pradeep bhatt]

If all classes are not displayed then how will the programmer be able to use the class diagram to create classes?

[Lasse Koskela]

If all classes are not displayed then how will the programmer be able to use the class diagram to create classes?

This is again a question of how one intends to use UML. If you're just designing with UML, the developers only need to communicate using UML diagrams and they can leave the obvious transfer objects, etc out of the diagrams to improve the efficiency of communication. The developer will know how to glue the overall design together by adding the details on the fly. If you're using UML as a programming language, you need to tell the tool everything so that it can generate working code for you.

[Ilja Preuss]

Originally posted by Pradeep Bhat:
If all classes are not displayed then how will the programmer be able to use the class diagram to create classes?

In the same way they would create classes in the diagram - by thinking about which classes they will need. Actually I think this is often easier to do with code, because in fact it *is* the code which needs the classes, not the diagram. Drawing classes in diagrams *always* is somewhat speculative (unless, as Lasse pointed out, you use UML as a programming language).
In my humble opinion, the true strength of UML is being able to *abstract* from the code. When doing this, I want to filter classes from the diagram which I don't need to make my current point.
Did that help?

[Pradeep bhatt]

In the same way they would create classes in the diagram - by thinking about which classes they will need.

Each one will have his/her own way of defining i.e. some attributes/methods may be missed. I had faced that problem some time ago.

[Ilja Preuss]

Originally posted by Pradeep Bhat:

Each one will have his/her own way of defining i.e. some attributes/methods may be missed. I had faced that problem some time ago.

Interesting. Can you elaborate a little bit? What happened?

[Pradeep bhatt]

Foe e.g. Some guys used long for some attributes when it was supposed to be int.
Every one had they own way of interpreting the domain knowledges.
It is really a long story.

[Allan Halme]

Lasse's distinction between designing in UML as opposed to programming in UML is crucial.
A good example: if you're programming in UML and you want an EJB, you'll need to specify all the ancillary interfaces in addition to the component class itself, whereas if you're designing in UML (which is what I do -- I program in Java), then I find it sufficient and significantly more clear to just draw a single class, give it the name that the remote interface will eventually have, and give it an "EJB" stereotype.
Class diagrams that pedantically include all the EJB interfaces are often just cluttered and detract from the understanding of the system that a parsimonious diagram can convey.

[Stan James]

A model is generally at some level of abstraction - leaving out details to better communicate the big picture. A model that captures 100% of the details (say reverse engineered from source) may not communicate large-grained concepts any better than the code itself. So models and diagrams rarely have EVERYTHING.
A neat concept that I learned with Rose but applies everywhere is to separate the model from the diagram. The model is all the information you know or have recorded about a system - all the classes, relationships, etc. A given diagram shows a subset of the model with a specific communication goal. So if your goal is to explain a particular class or subsystem to someone, a class diagram with only a few related classes would be perfect.
An advantage to using a tool like Rose instead of a whiteboard is that all diagrams are views of the same model and are much more likely to be consistent. If a class appears on several diagrams, you KNOW it's the same class every time. Does that matter? Is it worth thousands of dollars per seat? You get to choose!

[Robert Martin]

Originally posted by Pradeep Bhat:
Does the class diagram capture all the classes in the system?

A class diagram is a tool for you to use, not a declaration of souce code. In a class diagram you only draw those classes that you are interested in exploring. What's more, you constrain the topic of the diagram so that only a few classes are relevant. We want a class diagram to have less than a dozen or so classes on it. Nothing is worse than a sprawling tangle of classes and relationships on a huge wall-sized diagram.
By the same token we do not put all the methods and attributes inside the classes in a class diagram. Often we simply list the name of the class. There are times when it makes sense to list one or two methods or attributes, but that is rare.
Keep your diagrams small, clean, and expressive. Make sure that each diagram has one reason to exist, and that it communicates that one reason well. And don't feel that you must communicate every topic with a diagram. Many topics are better described with code.