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?"
OO programming can be procedural, and follow a normal flow chart. All OO does is make it easy to create data structures with built in rules/procedures on how to perform various operations on them (such as addition on strings). It's just as simple flowcharting an OO program as any other procedural language.
Event triggered programs can be a little different, but each event is simply a string of operations - a procedure which is easy to flow chart. You simply have lots of little flowcharts instead of one large one.
OO does have data structures which are handy to document in a visual way. These would not be flowcharts, but they may include flowcharts to properly document the methods/functions/operations effective on the data. The documentation of the data itself would not be flow chartable - this is where UML is handy.
Since a program is a sequence of instructions with loops and conditional operators, whether it's procedural or event triggerred, it's fairly strightforward to flow chart it. The mere definition of a program also defines a flow chart. It's going to be awhile before we get reasonable processors which perform work without following a logical sequence of steps - mainly because it's hard for us humans to understand how something can be done in a way that we can't easily visualize or do ourselves. The real machine intelligence won't happen because machines will be smarter at doing the things we do, it's because they will do things we can't do.
-Adam
I've tried a lot of the fancy UML tools, but they're really not any better than a very simple drawing program. The purpose of a diagram is to convey information. For that purpose simpler is usually better, and a diagram that uses too many specialized symbols to denote subtle nuances is not simple; that stuff should be described in the text. Maybe a case can be made for the extra symbology in a class diagram, but not in a flowchart or timeline. If your flowchart has more than about twenty items, or more than four types of items, or can't be drawn without crossing lines, it needs to be broken apart into a top-level flow and separate diagrams for secondary flows. Any simple box-and-line drawing program should be able to handle that, though a little bit of intelligence in routing lines doesn't hurt. Focus on the information, not the tools.
Slashdot - News for Herds. Stuff that Splatters.
[Looks up from flowchart] None taken...
Actually, flowcharts are good for telling users what to do, and for similar reasons, might be appropriate for designing test scripts. But for the system- nope.
This depends strongly on the system.
For a system that takes in data, performs computations, and spits out answers, a structured design using flowcharts is often appropriate.
That said, implementing part of that design using OO code can be useful. For example, using C++ with a matrix class to do geometry based processing. The actual process may best be described as a flowchart though.
OOA/OOD/OOP are not the silver bullets. I've seen a major revision of a large commercial computational program wither on the vine due to misunderstanding how to best apply object based thinking. 'Everywhere' is not the right answer.
Help children born unable to swallow - www.tofs.org.uk
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.