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?"
I build my objects out of legos.
In uml, with activity diagrams, and class diagrams.
-
ping -f 255.255.255.255 # if only
- state diagrams
- message sequence charts
Neither are flowcharts, and if you try to use them as flowcharts (which I have seen donePersonally, 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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
UML State Diagrams come from David Harel's work on Statecharts. Statecharts constitute a broad and popular extension of finite state diagrams
While there are some differences between original statecharts and UML state diagram, the best introduction remains imho David Harel's paper : Statecharts: A Visual Formalism for Complex Systems (Science of Computer Programming 8-3, 1987). It is available onlline here on David's home page.
You can also rely on any good book about the UML (i recommend Addison-Wesley Object Technology Series).
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...
I believe posters are recognized by their sig. So I made one.
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
--Stephen
Did you ever notice that *nix doesn't even cover Linux?
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.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
You dont use them because you're a programmer. There's a big difference between a software programmer and a software engineer.
.. sure. Try something 10-100 times larger. While you're at it .. don't bother commenting your code either.
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
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.
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.
Thankse s
for
adding
your
own
newlines
it
mak
things
so
much
easier
to
read.
[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
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.
http://efil.blogspot.com/
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:
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.
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:
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).
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
I prefer a less formal design approach best exemplified by this guiding principle:
;)
A design should be written on the smallest napkin possible, but not smaller.
Anything more than that is gravy.
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)
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
What if I outsourced my *own* job to India? Pay some guy $100 per month to do my job, so I can sit on my ass all day and play games? Heck - get two guys - it's time for a raise!
Anybody try it? Can it be done?
You can accomplish anything you set your mind to. The impossible just takes a little longer.
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...
:wq
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.
OmniGraffle doesn't come w/ OSX. It's either $70 or $120 (standard or professional).
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.
There is no straight analogy in OO for a flow chart or DFD. But activity diagrams (here, here, and here) serve a similar function. They provide a high level of abstraction that can be done with a picture.
One poster said to use a "high level language". I agree, at least with the first two words. I mildly disagree at the word "language". Some people think better in words, others think better in pictures.
What's important is that you don't try write your detailed code using pictures. People who map one set of things to a picture will map a different set of things to a language. So it is difficult to draw pictures that then create exactly the code (language) desired.
Keep the pictures (activity diagrams) high level but leave the details for coding by hand.
Having said that, I shall now waffle: If you're very good at thinking in pictures, UML does provide some detailed diagrams for run-time aspects of software.
- State Diagrams (here and here)
- Sequence Diagrams (here and here)
- and
- Collaboration Diagrams (here and here)
are all ways to describe run-time state and behavior. I tend to believe programmers generally are better with languages when they need to describe details.Drew
Be careful what you wish for...
Where your treasure is there is your heart also...
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.
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.
While I have a lot of sympathy for the view that pencil and paper are an under-rated combination these days, I think that's going a bit far.
I've recently spent a fair amount of time drawing reasonably complex class diagrams to document the major design features of one of our systems. To give an idea of scale, these probably have 10-20 classes per page, and can usefully indicate a few key methods and data members on some of the classes.
I found having a good diagramming tool (in this case, the Pacestar UML Diagrammer I mentioned elsewhere in this thread) to be a great timesaver. It has the key advantage that you can adjust things after you've sketched most of the diagram. That might mean moving classes up a bit so you can fit another layer of a hierarchy in at the bottom, or extending one of the boxes to highlight where a couple of methods are over-ridden, for example. If I start using pencil and paper, I frequently find myself drawing the same diagram twice, once where I expected it to fit, and then a second, better laid out copy when I've seen which parts didn't fit the first time.
A good diagramming tool also produces better looking output, and in a more convenient form which can easily be included with design documentation if you like. That beats a cramped diagram with illegible handwriting scanned into a fixed graphic any day.
Of course, it's taken me several years to find a decent UML diagramming tool. Most of the freebies are bug-ridden and hard to use, and produce horrible output. Actually, some of the expensive ones (Rational Rose being a prime example) are among the worst. Certainly pen and paper is better than these...
If it's going to be in serious documentation, then yes, it should be smarter than a scanned napkin. Good visual layout that reflects the logical structure is half the value of something like a class or state diagram. Without that, you might just as well write it in words or a big table.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
UML lets you use an Activity Diagram for this as well. Typically activity diagrams are used to document a business process. Activity diagrams explicitly include synchronization and timing information. Sometime that's better than using a DFD as you know that a particular action must complete before its successor starts. Sometimes, it's worse because you may represent synchronization in the model that is simply an artifact of the current process. For example, I worked on cell phone point of sale system that would not let the sales rep take money until the phone activation was completed. This syncrhonization point was't really required for the business process (and actually caused lost sales when the activation system was slow or down), but had crept in through an activity diagram that listed activation as a pre-requisite for billing.
Activity diagrams are actually part of the UML replacement for flowcharts. State diagrams and sequence diagrams (plus, to a lesser extent collaboration diagrams (which are sort of a translation of sequence diagrams mapping objects spatially and time through notation) nostly complete the picture of UML things that replace flowcharts.