hi everyone,

I was wondering, for the class diagrams do i have to create for each use case one class diagram or it doesnt depend on use case....

thank you

http://atlas.kennesaw.edu/~dbraun/cs...rial/class.htm

Here you go.

http://img476.imageshack.us/img476/5171/cut20ln.png
Piworld ™
[Tis simple as Pie]

hi,

thanks for the link

A class diagram has no direct relationship to the usecase diagrams.

A single usecase may use classes from several class diagrams (typically you'd have one class diagram per package for example, plus several linking packages together maybe).
similarly a single class diagram may provide classes that are used on several use cases (or even all use cases in case of highlevel classes and interfaces).

thank you

hi everyone,

ok I have another question. You see when you are doing a project, you need to do your class diagram first then implement the code. You obviously have to follow the class diagrams to implement it. But what happens when the created class diagrams are different then the implemented code? If you change it and do it exactly like the java classes then wouldn't people suspect that you have reverse engineered it.....

thank you

Well, code is always evolving. So, its ok for the uml diagrams to change too. I would recommend though keeping a diagram saying this is where we are (a snap shot of the current code) and a diagram showing what the final goal is.

hi,

thanks for the reply. So what you mean is the final class diagram should be exactly like the final code.

thank you

I don't use diagrams (especially implementation diagrams like class diagrams) that ridigly.

They're great for visualising concepts and planning things, but don't see them as the final product.
For me they're more quick sketches of what I'm intending to do, rather than a dictate of what's really there.

They'll therefore also be rather sketchy, often containing only the bare minimum in fields and methods needed to convey the core functionality of a class rather than every smallest detail.

Overly complet diagrams are a pain, precisely because of the effort needed to keep them in synch with the code.
And remember that documentation that's out of synch with the thing it documents is often worse than no documentation at all as people will not know the documentation is incorrect and therefore assume that your code does what the documentation says it does (which obviously it won't if the two are out of synch).

Class diagrams should be thrown away IMO after the code is complete.
When needed they can always be recreated from the code, every halfway decent UML system has an import feature for that.

A major problem in many large organisations though is too great a separation between the people thinking up the system architecture and the people implementing it.
A mass of documents and diagrams (often way too detailed for a document that should be an architectural overview rather than documentation for an existing system) is shoved down the throat of the development team, who are then expected to implement it literally.
This usually leads to software that doesn't work and/or performs so poorly it might as well not work. The software is then changed to match the things that work in the real world, but the documentation is owned by someone who sits high in his ivory tower possibly hundreds of miles away and doesn't want to hear about his "design" being less than perfect.
I've learned over the years that in such environments there usually exist 2 separate documentation and design cycles. The development group will often silently ignore the dictates from on high and go their own separate way, then produce a nice fake document which for the bureaucrats makes it seem they did what they were told to do.

hi,

I totally agree with you....