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?"
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).
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.
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.
this is really easy to do with Omni Graffle. It's a sweet program for UML design, and it comes with OS X
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...
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.