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?"

Comments

In uml

[sporty]

In uml, with activity diagrams, and class diagrams.

If you've got any sense you don't use flowcharts

[WolfWithoutAClause]

The nearest thing to flowcharts that are used in OO are:

• state diagrams
• message sequence charts

Neither are flowcharts, and if you try to use them as flowcharts (which I have seen done :-( ), bad things (tm) happen to your design. (States on state diagrams are states that parts of the system are supposed to be in for extended periods- message sequence charts are different because the flow is usually multitasking/parallel processing).

Personally, if I see somebody drawing a flowchart, I know they aren't currently up to scratch (which doesn't mean that they can't get better).

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.

UML Sequence diagrams

[cogpp]

UML sequnce diagrams can be pretty useful to show these things. Especialy if you have asyncronus events, or multiple threads or processes, which ordinary flow charts dont model very well. PDF on sequnce diagrams.

Re:If you've got any sense you don't use flowchart

[sartin]

For a system that takes in data, performs computations, and spits out answers, a structured design using flowcharts is often appropriate

This goal is often achieved with a Data Flow Diagram which many people mistake for a flow chart. Structured analysis/design techniques from the 1970s and 1980s developed the DFD concept as part of the problem analysis phase. Search for the likes of Coad, Yourdon, DeMarco, Gane and Sarson. Some of these names are still familiar in the OO design world. The key differences between a DFD and a flow chart are:

• DFD does not imply sequencing of operations. Processes in a DFD can run in parallel.
• Definition of the data stores. A DFD typically includes definitions of the data stores and not simply the steps that will be taken to process the data.

In the 1980s, lots of people tried to slap object-oriented deisgn onto structured analysis using various techniques (like making the processes or data stores the objects). It didn't work out so well. Eventually, we got to UML from there after 10-15 years of haggling and stumbling; some argue that it still isn't working out so well.