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

Legos

[Anonymous Coward]

I build my objects out of legos.

Never used them

[Scarblac]

I've been programming for 19 years now; started my CS study 12 years ago; programming professionally for a few years. I used Java, and fast development languages like Python. I've never seen a flow chart in practice, let alone used one. So it's a bit hard to say.

Somehow flow charts seem fit only for relatively short programs, that have a clear flow from A to B. My programs are web apps that constantly react to requests from web forms that are sent in, supported by a bunch of scripts running from cron to periodically update database stuff. Program-wide, there is no single flow.

On the method-level (or the Action level, I build a large J2EE app with Struts), we could use flow charts I suppose. But they look pretty cumbersome; mostly I just write out what the method is going to do in a comment in English and/or pseudocode, and from that I write down the code.

What each action is supposed to do, and what each method of an object is supposed to do, that is (should be) designed beforehand. There you get tools like UML, if you want to use something like that. What we design is the data objects, and the interface they should expose, and so on.

How those methods do their work is decided at coding time, and is the only place where traditional flow charts seem applicable.

Just some thoughts, I don't know if I'm making sense, since mostly I get very little time for any design at all, in reality...

Here's the new "modern technique"

[illuminatedwax]

Here's the new "modern technique"... pay attention, it gets complicated!

.______________.
| o o o o o o o|
| Outsource to |
| o .India. o o|
|______________|
o o o o|o o o o
o o o .V. o o o
o o o END o o o

--Stephen

Whiteboard...

[SuperChuck69]

When I have a complicated problem that requires some design (which is, unfortunately, not very often), I use a very complex system which involves sketching some boxes on a whiteboard, often connecting them with vague lines. I occasionally jot some method names down next to or inside the boxes

Personally, I'm wary of any formalized system of object design (UML being the prevailing method at the moment). UML is a beast designed to design the hell out of anything that got in its path. Learning UML is roughly as complicated as learning Hebrew, with the drawback that more people actually understand Hebrew.

Most of my experience with UML and other formal object languages involve one individual scrawling archaic symbols (which may well be astrology charts) on a whiteboard whilst everyone else in the room constantly ask "what does that symbol mean?" The designer invariably explains the symbol, in as condescending a tone as possible.

I don't believe I've actually met anyone who uses formal modelling languages because it makes design easier; most seem to learn them solely for demeaning those who don't know them.

Given that the goal of these languages is to communicate design, they must be failures. Rather than simplify the communication of a design, they complicate it. Really, it makes no more sense than me using Latin for all my design notes, just to insult my barbarus coworkers. Well, that does no good.

I've found that using simple symbols such as "abstract" to denote an abstract class works just fine. Works fine for me, saves explaining what a lambda symbol means, and clearly explains its intent as an abstract class...

Why do you need a graphical representation?

[CatGrep]

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.