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.

as already mentioned by others

[jeffy124]

The Unified Modeling Language.

Start Here, then try google for more introductory articles that are out there.

If you want books on the topic, I recommend UML Distilled by Martin Fowler for a quick intro, then branch out from there. (There's hte Object Technology series from Addison-Wesley, which are usually very good, but they're not the only UML books out there) I also recommend you download a UML tool (there are a bunch out there - free as in beer, Open Source, or try a commercial trial version)

As for flowcharting, there are several model types in UML to handle it. Activity diagrams come immediately to mind (these are very close to the classic flowcharting techniques), but state charts and sequence diagrams are useful also to supplement an activity chart. Also look into the structural models - class diagrams, deployment charts, etc. when assembling/designing your program.

UML is language independent - meaning it's not explicitly tied down to one specific language. Although, it is useful to keep in mind what language you plan on using when authoring in UML.

Re:Nobody uses flowcharts any more

[abrotman]

You dont use them because you're a programmer. There's a big difference between a software programmer and a software engineer.

Please try going to IBM/HP/Oracle and tell them to implement you a 10 million dollar software solution but tell them you don't want them to spend time doing any actual planning. You'd just like them to start coding immediately.

Every large project should use some sort of diagramming/planning. Can you get away with no flow-chart for a website or maybe even a 100,000 line program .. sure. Try something 10-100 times larger. While you're at it .. don't bother commenting your code either.

Programming/Developing/Engineering is still a science. There is a certain inherent "art" which makes some people better than others. But it is still a science.

Re: How Do OOP Programmers Flowchart?

[manavendra]

OO programming defines and to some extent mandates more concrete and phased flow-control diagrams than a regular flowchart.

In typical structured programming, there is more emphasis on control flow. Furthermore, for any modestly sized software, you will need flowcharts withy varying detail - those depicting the overall flow, flow for a particular user, flow within a particular module, and so on. This essentially leaves the decision of detail to each organization and/or author, and we can thus argue this approach introduces a certain vague-ness.

OOP, on the other hand, provides more detailed and clearer demarcation for each of these entities.

• Use Cases - model the functionality of system and the path of interaction of different users with it.
• Activity Diagrams - depict the dynamism of the system and model the control flow from activity to activity. You can use these to model workflow and business processes.
• Statechart Diagrams - depicts the dynamic response of the system in response to external stimuli.
• Sequence Diagram - describes the interactions between different components (classes) in terms of message/data exchange over time.
• Class Diagram - some call it the backbone of OOP. These diagram depict the various entities in your system and the relationships/associations among them.
• Object Diagram - describe the snapshot of entities in the system at a given time. You can use these to examine the overall system state at any time, and verify your class diagram
• Package Diagram - More useful for teams/people responsible for managing deployment and building the system, package diagrams describe the grouping and packaging of your classes.
• Deployment Diagram - depicts the physical resources in the system and how they are deployed (locally, remotely, whether as nodes, connections, etc.)

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.

Re:On the mac...

[Joe Tennies]

OmniGraffle doesn't come w/ OSX. It's either $70 or $120 (standard or professional).