As all programming books say “Good programmers plan their program flow.” Yup, I could like to do that too, but I just couldn’t find a flowcharting method which suit my needs.
The software I am working on now a massive project. It’s also events-based now the flowcharting methods taught in school (there was this generic flow diagram and JSP, "Jackson’s System Development). I couldn’t figure out how do use this two for event-based programming.
And to top it all, the software is huge (it’s a massive multi-player game - don’t ask me why a relatively inexperienced programmer got this job. Anyway, it’s a voluntary effort)
So, is there a flowchart method that will i) suit an event-based software and ii) handle lots and lots of details and depth?
I can’t offer any help on a good method (I use an ad-hoc assortment of methods myself, mostly gleaned from OO texts and many years experience). I can, however, confirm that JSP is probably not what you need. It’s origins are in olde-worldy Data Processing where real-time often ment before the start of the next working day. Even with more modern refinements (I assume there have been some) event-dirven it is not.
Just keep in mind that flowcharting is for you and those who come after you. Simplicity and consistency are the key elements here. Also, remember to document what, not how: Leave implementation details in your code, and make your code as clear as possible.
A method I used at one time was Warnier-Orr. It is decently high-level, as a flowcharting method should be, and it makes it easy to grasp the big picture without having to read the fine print.
Pseudocode is another way to go. Exactly how your pseudocode looks will be influenced by what languages you like to use. Mine tends to look like a simplified C, but you may be more into Pascal or even FORTRAN (:D), and your pseudocode will reflect that. Just remember to only document the control flow and the logical structures, not the mechanics of getting it all done.
You might be able to dispense with keeping seperate flowcharts: Knuth’s Literate Programming concept and software aim to inline code and documentation much better than traditional commenting methods. CWEB is specific to C and C++, but there exist implementations of the idea that are language-independent (check the FAQ). This involves learning TeX, which, while enjoyable, is somewhat of an undertaking.
As a final note, keep your documentation synched with your implementation. If they fall out of synch, you end up with useless flowcharts and undocumented code, which represents plenty of wasted effort and leads to plenty more. Literate programming alleviates this somewhat, but not completely.
State diagrams would be useful - since the sequence will depend on the state (of the object, I’m presuming).
On Preview:
The local programming oracle just walked past. He said lots of things I don’t understand, but basically, (assuming its a straight Java, distributed application) do UML sequence diagrams for the main/common events, according to each state. He doesn’t recommend standard flowcharting.
Flow charting per se is old school. It’s a throwback to the days when procedural programming was the way things were done, and as such, the “flow” of the program was essentially how the code was structured.
In my experience, it’s much different today. First, event-driven GUI programming came along, and that tossed procedural programming on it’s ear. Today, OO programming involves a different paradigm where software entities interact with one another. This model doesn’t lend itself to classical flow charting, but it does lend itself to other documentation approaches (UML, others described above). This kind of documentation can provide someone with a big picture view of how things are laid out, various classes and their interfaces, key interactions, etc…
Making the code itself self-documenting via strict naming conventions, appropriate commenting, good technique, and consistency all go a long way towards explaining to someone else what’s going on.
But, those flow charts from years ago with the various little shapes and the lines coming in and going out - forget it. It’s obsolete, and doesn’t reflect how OO code is designed or how it works. I’d suggest that you dive into UML and go from there - but I don’t know what language/tools you’re using.
The language is a script of the game engine which we are using (A5 GameStudio). As for tools, beside SmartDraw, Excel, Word and Powerpoint we don’t have anything grand.
The problem is the whole thing is so huge – any tools which will help to bring this thing into smaller pieces would be very welcomed.
You’ve correctly identified the problem, but your question is just oh-so-slightly skewed away from the solution that you need.
“Flowcharting” per se is, as has been noted, outdated. Flowcharts were used to illustrate a single algorithm, but when problems get large and complicated, the software solution consists of a large number of interacting algorithms packed up inside functions, functions packed up into ADTs or objects, ADTs/objects packed up into packages/namespaces, packages/namespaces packed into subsystems, and so on. Depending on just how big & compliated a system is, it may need only a few of these levels of organization or it may need even more than I have listed here.
There are diagramming techniques for capturing and describing these organizations of software components. Most popular these days would be UML (Unified Modelling Language), which is actually a collection of diagramming techniques (including, by the way, the state charts mentioned by Sir Doris) intended to give multiple views of a project. Addison Wesley Publishing produces a whole series of books on UML. I recommend “Using UML” by Stevens & Pooley for beginners.
But diagramming techniques can only document a project’s organization - the diagrams don’t produce that organization. They are useful only when combined with design methods that lead to an organized structure. So, in a sense, I think your question should have been “How do I break this into smaller pieces (and, by the way, how do I use diagrams to document that once I have done so)?” or, if I’m just been telling you something you already know, perhaps your question should have been “I’ve broken this problem down using such-and-such design technique. What diagramming notations work well with this style of design?”
And, of course, the only thing more dangerous to a large software project than working without an organized design method is using that project as a guinea pig while learning a new design method. So if you’vealready begun this project, I’d advise that you stick with what you already know best (but start looking now at some of these alternatives for how to do the next project.)
State diagrams would be useful - since the sequence will depend on the state (of the object, I’m presuming).
On Preview:
The local programming oracle just walked past. He said lots of things I don’t understand, but basically, (assuming its a straight Java, distributed application) do UML sequence diagrams for the main/common events, according to each state. He doesn’t recommend standard flowcharting.