The way I see it if you create one before you get the advantage of:
but you lose:
On the other hand, I could just create them all after writing my code just to keep it as a reference for future developers.
Which one serves the purpose of class diagrams and which is more advantageous?
If you create them before, they will be part of the design phase.
If you create them after, you can just use them for documentation. But documenting is better and faster if you do that during design and coding.
By the way, you don't lose time in doing design! The coding part will be faster. And better.
After all, you think that doing design of a skyscraper or of a bridge is a loss of time instead of just starting building it?
A compromise is to starting creating some dummy code during the design phase (just prototypes of classes/functions) and use this code skeleton to build the class diagrams.
When I've had them created before coding, we view them as "temporary" documents. That is, we create the diagrams and get our thoughts onto paper. We start coding from those class diagrams. We then throw them out. It's not worth spending the time to maintain them once coding has started. And if you want up-to-date class models, use a tool to create them from the code.
In either case they will stick around as part of the documentation. Nobody will update them when changes are made to the implementation. The diagrams won't have dates on them so you won't even know what version of the code they refer to. When a new person is added to the project you will give him or her the diagrams saying "Here are some diagrams that were created at some point during the design or implementation. We don't know how up-to-date they are."
This is part of design and therefore should be created prior to implementation. This is not to say they cannot be refined during/after implementation to reflect the current implementations state.
Providing a design after implementation is what I would call "cowboy coding," and sure you can thrive in the wild wild west but remember cowboys usually end up dead at some point or another.
It depends on the depth of the design. Some people insist on writing class diagrams for even the most trivial classes, because "it's good practice." I think it's a waste of time to draw something when you already know exactly how it's going to be implemented. When creating a new design, something that's unfamiliar, it's definitely useful to draw some diagrams first.
I never use UML tools though, because the design usually changes so much during implementation that I have to redraw the diagram. I suppose a good two-way tool would handle these changes, but I've never used a good one (I've only used free ones, though). Instead, I draw on paper or on a whiteboard to help me sort through the design. After I've implemented it and am reasonably sure that it's sound, I'll do a more formal diagram.
Also, let's not forget the other types of diagrams. I've always found sequence diagrams to be among the most useful, and I use them often when there's a lot of communication between components.
Before Implementation. As one of my former co-workers once said 'I like to do as much programming as possible before I start coding', and I think that's a good approach to it.
I find that the act of drawing a diagram usually alerts me to missing information. This will also happen if I am just typing in a code editor without having drawn the diagram, but the instances will be spaced further apart (because I will spend time writing algorithms and calculations and tests and such) and so I might allow more time to go by before getting my missing information.
Also, if the design you vaguely have in your head turns out to be crap, you will notice that more quickly if you diagram it first. Therefore I at least draw something quick and informal. Whether it turns into an electronic diagram others can use for reference will depend on the project.
Class diagram creation should be done, during and after because the model should be interactive with the code and requirements modifications. First you need to create a class diagram to start your project. It would help to visualize at a higher level of abstraction your objects. You will be able to create a stable and intelligent software architecture. Then you need to code and sometimes you will notice that the architecture which seems to be well in UML is not really possible in the code. You then change you code and architecture. Finally you update your model with code modification and generate documentation.
In my last project decision makers have changed my requirements over 50 times in the last year. It is really painful and UML help me to keep traceability of changes and why. UML should allows model and code merge at any time in an iterative way (e.g. from code to model, from model to code, from both, from code after refactoring etc...) I use Omondo EclipseUML for Helios and I am really happy with this tool. My favorite feature is the model merge which allows me to update my model at any time without loosing model information. I also like entities modeling directly in the class diagram and create the database using stereotype and hibernate. Really powerful and complete from object to database !!
Before: it will help get your thoughts organize and communicate your intent. Don't go into details here.
After: it's automatically generated from the code as part of the build process, obviously (hope you're not too attached to uml)
Both are useful, but the before stuff can be thrown away as soon as it's implemented... it's already out-dated anyway at this point.
With Topcased, I create my class diagrams during design phase. Then I click on "Generate code" button for producing a canvas of my implementation. Then I fill in the placeholders with code.
I'm going to vote for answer (C) Don't bother.
They're largely unnecessary. Personally, I never bother to look at them when they are provided.
They're unnecessary before development, because the design will change anyway. And if you don't think the design of your classes will change, then you're already handcuffing yourself and preventing your future self from being able to properly solve the problem. If you think you have to stick to some pre-existing class diagrams, then you either work for NASA or you're shooting yourself in the foot.
Afterwards, they're unnecessary documentation. If you can't figure out what the classes are doing or how they're related to each other with a little code inspection, then you have a hole in your skill set as a software developer.
Of course, this answer sounds really arrogant and opinionated; oh well.
With Eiffel and associated tools this is just a difference of viewpoint all pointing to the same underlying files.
