Slashdot Mirror
How Do OOP Programmers Flowchart?
Lew Pitcher queries: "I recently attended a presentation of a code documentation tool that, among other things, produced a flowchart of the analyzed code. The vendor sells this one product for analyzing both mainframe code (COBOL, 390 Assembler, PL1, etc.) and 'distributed' code (C#, Java, C++, Smalltalk, etc). I haven't kept up with the 'modern' techniques (I prefer Nassi-Shneiderman charts, but I still have my flowcharting template), and wondered if modern 'OOP' programmers use flowcharts. If they don't, what is the preferred technique for diagramming an OOP program?"
A lot of folks will tell you that they use UML in place of flowcharts for OO design. I say that the UML emperor is naked.
Chip designers (I used to be one) in the old days (before about '92) used to use schematics which are pictorial representations of their designs. But in the early 90's HDLs (hardware description languages) bagan to creep in. Now you rarely find schematics used for digital design. It's all done in HDLs. Why did this happen? Mainly because it's a whole lot easier and more powerful to describe a circuit with an HDL. You don't have to draw all those wires to connect everything. You can describe things at a very high level, such as an adder to add two 32bit values: A + B (where A and B are 32 bit vectors). What could be simpler.
Another reason that schematics were abondoned is that it's a lot easier to parse text than graphics. The UML promoters should take note.
Now the UML folks are essentially trying to take software design back to the schematic age. The hardware people learned that schematics are not the best representation.
The answer is to program at a higher level of abstraction. This might mean chosing a higher-level language to prototype in (I like prototyping in Ruby) or it might mean using techniques like state machines, for example.