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

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...

Re:Nobody uses flowcharts any more

[Twylite]

You're probably a troll, but I'll bite.

Flowcharts are an incredibly useful tool, but as with all tools the trick is not knowing how to use them, but when to use them.

There are at least two core areas where flowcharts are still pertinent in modern development:

1. Modeling user interaction.
   UML does not offer an adequate solution for modeling user interaction. A Use Case gives a high level name to interaction, and can be described, but often the description is inadequate to satisfy the user's requirements. Sequence and collaboration diagrams present the message flow between objects, but do not succinctly present the user experience.
   In the analysis phase, understanding the user expierience is vital. Developers and non-technical customers can easily understand Use Case diagrams (what you can do with the system) and flowcharts of interaction explaining the Use Cases (how you do it).
2. Modeling atomic processes or algorithms.
   Under the hood, every OO language has a core that provides for sequential execution of instructions with branching and looping. A flowchart can graphically clarify a complex process or algorithm that cannot be further reduced into objects (at best it may be functionally decomposed), and would be poorly described by pseudocode.

Web interfaces and embedded systems are examples of other areas where flowcharting can be invaluable.

In the case of user interaction (the more common use of flowcharts Information Systems) a developer will seldom see or directly use the flowchart. Instead the interaction described by the flowchart will be translated by a designed into class, sequence and collaboration diagrams that describe the implementation of the operation the user is trying to achieve.

Re:Nobody uses flowcharts any more

[Mr. Slippery]

Every large project should use some sort of diagramming/planning.

Planning, of course; diagramming, not so much. Design should be done primarily using English (or your local language) text, supplimented with diagrams.

Software is a linguistic construction; blueprints or schematic diagrams are not as useful as they are in electronics or building construction. The fetish for diagrams over text usually indicates someone who can't write decent prose. And if you can't write decent prose well, you can't write decent code. (Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer. -- Dijkstra)

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...

Re:Why do you need a graphical representation?

[CatGrep]

I'd wondered why there was this whole XMI thing that was running around the UML editor industry

OK, so UML editors are now able to spit out XML. That makes the concept a bit more usable. Now we have something to grep.

A prototype and a spec are two completely different things. They each have their place, and they aren't wisely exchanged.

Perhaps, but add 'test-first' development with unit tests to the mix and you've got an executable spec. If I can use the same set of unit tests for both my prototype and my final code (which I can) then I know that my final code behaves exactly as it should according to the executable spec.

What good does the graphical representation do me, I've got to keep my graphical representation in sync with my actual code. The two representations could be completely different at some point if I'm not careful and when that happens the graphical representation is worse than useless.
This continual syncing between code and pictures becomes burdensome at some point. Unless you can use UML to completely genereate your code this will be a problem (I realize that this is now possible to some extent, but not completely.

There were similar issues in the hardware world when synthesis tools came on the scene: If your representation wasn't synthesizable to hardware then you were doing twice as much work - you had to keep your schematics up to date with your synthesizable HDL code, eventually people wondered why they were drawing the schematic at all and it wasn't long after that that they stopped drawing schematics. The holdouts wanted to hold onto schematics as documentation, but soon people realized that the code itself was documentation.

Re:Twisted technique...

[Rick the Red]

Sure, it can be done. What you're describing is setting up your own consulting firm and outsourcing the technical work to India. So you're traiding your technical job for one in Sales and Marketing, something that can't be easily outsourced. But if you think you'll "sit on my ass all day and play games" you're sadly mistaken.

What design?

[Anonymous Coward]

I haven't worked with an OOP programmer yet who has used flowcharts, let alone a design beforehand. Heck, I haven't interviewed with a company yet that used designs to model a program. These days, it's all seat-of-the-pants.

That's not to say that there aren't real engineers out there, or that designs are a bad thing. Just that whenever I talk of actually designing a product/project to nail it down, people look at me like I'm crazy. Who would have thought that wanting a specific goal to shoot for was so foreign a concept.

Nobody wants to do research. Employers change feature lists with the whim of the customer du jour on the phone. Programmers waste time by throwing useless gadgets and doo-dads into software that never works properly, and would never have gotten past the design stage.

In these insane times, you get your head handed to you if you demand designs, documentation, and working code. Fix or make reliable software and you're out of a job.

Re:What design?

[hInstance]

My experiences have been very similar. As a rule my employer (now ex-employer, because as you suggest, I'm out of a job) would always prefer/reward programmers who produced shoddy work quickly (with some unspecified amount of QA time needed afterward) over programmers who spent more time planning up front (with very few bugs in the implementation).

Hidden costs are a bitch. (Or as Robert Glass puts it more eloquently in Facts and Fallacies of Software Engineering, "the hard drives out the soft").

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

[WayneConrad]

A design should be written on the smallest napkin possible, but not smaller.

That's as insightful as it is funny.

Programmers should resist the urge to pull out a computerized tool when modeling. If it doesn't fit on a napkin, it's probably not abstracted enough to be useful to those who need it. If you need to "zoom in" on one of the boxes on the napkin, pull out another napkin.

Do you need to archive it on a computer, perhaps on an internal Wiki? Scan it. Does it need to be prettier than a scanned napkin? Ask why. Those who want it prettied up are usually those who wouldn't know what to do with it in any format.

Don't overlook the enormous mnemonic value of a napkin. That stain on the side where Jim spilled his drink immediately brings back memories of the meeeting, including all the things that were said but aren't written on the napkin.

For those who find napkins hard to draw on, use small sheets of paper instead. Just don't reach for that drawing tool! You'll end up spending all of your time figuring out how to make that font bigger and how to keep the lines from crossing inappropriately rather than just getting on with it and drawing the model.

Re:KISS

[Salamander]

A UML tool can do two things a simple diagramming tool can't: * generate source code * reverse engineer source code

The poster wasn't asking about source-code generators. He was asking about diagrams. In terms of diagrams the UML-oriented tools are no better than simple alternatives, even if they offer other features as well. Is a text editor no good just because it's not a full-blown IDE? Not if you just want to edit text.

Furthermore: how much time do you spend analizing? How much time designing? How much time coding? You sound as if you would analyze/design one week and code after that 6 weeks. So you spend in total 7 weeks.

You have absolutely no basis for that self-serving assumption. FYI, I'm the chief software architect at my company, with technical oversight for the work of 30-some engineers, and that work seems to be going rather well. Don't expect me to be intimidated by your empty claims.

With an aditional 3 days of testing I made a 24 days sprint where you made a ~49 days coding marathon.

I haven't had to do a 24-day "sprint" for years. Anybody who does screwed up earlier in the process. Of course you push UML tools because you have a business interest in doing so; maybe you should have skipped that dozenth UML class and taken an ethics class instead.