When should class diagrams, data flow diagrams, and flow charts be made?

This depends a lot on the project methodology your are using (e.g. the Rational Unified Process versus Scrum), and how much you value process documentation in comparison to code.

In some contexts it is important that all requirements and design decisions are traceable: why did we choose this alternative, who decided it, where is it implemented? Usually, this means that a feature is designed separately before it is implemented, and the design is captured with textual descriptions, diagrams, etc.. These documents are deliverables of a design phase. If you have such requirements, then of course the diagrams should be created before writing your classes.

On the other hand, most projects do not need to document each step of their process. In fact, the Agile movement explicitly favours “working software over comprehensive documentation”. The code already contains the design, so it is not necessary to create extra diagrams at all. Whenever changes are made to the code (new features added, bugs fixed), the design changes and the old diagrams would be out of date. Updating all documents to reflect the changes takes a lot of effort that could otherwise be spent on adding value. It slows development down.

There is probably a middle ground between these two extremes that is right for your circumstances. For example, I find that a sketch of a diagram can be a very efficient way to communicate a design idea to other people, and that diagrams and overviews are invaluable for introducing new people to a system they are supposed to work on. The code itself contains too many implementation details that detract from the overall design, so “read the code” is not a good response to “do you have some diagram describing your architecture?”. This does not mean I have to create detailed diagrams for every class.

I use Petri’s net elements and annotations to create JavaScript programs that use the Acrobat/JavaScript API for PDF form applications. The method begins with creating a diagram to establish the input-output relations of net elements (plus a few annotations), continues with specifying other annotations in two forms and culminates with writing the code – based on coding rules, programming is a direct mapping from the annotations in the diagram and entries in the forms to JavaScript codes.

If you begin with requirements for the logical process of your application then you should consider starting with a diagram (with a Petri Net diagram, you can systematically “generate” codes based on the logical annotations and add other types of annotations as part of your documentation/presentation/etc).

If you are pressed for time then I think it is very important to begin with a diagram (such as a Petri Net diagram) that can be mapped directly to codes. With practice I spend less time debugging codes when I apply Petri’s net elements and annotations to computer programming. And the diagram helps me debug the application logic.

Mapping from the diagram and forms to code is systematic. This is why I don’t mind making changes to the diagram and regenerating the codes again. However it is very tedious. It is possible to make changes to the diagram and incrementally change the related code. However incremental changes to code may take longer and may be more challenging compared with complete regeneration of code in certain situations.