Flowchart software that supports top down development?

[LurfysMa]

I am looking for a flowcharting program that will allow me to design
my code top down:

1. Start with a very high level (functional) flowchart consisting of a
few functional modules. For example, (a) Start, (b) User Logon, (c)
Load Data, (d) Select Test, (e) Administer Test, (f) Logoff. (g) Exit.

2. Each of the "modules" (shapes) would be identified as having a
lower level or not. If they have a lower level, the program would
generate an "open link" to another flowchart, probably on another
page, having that name.

3. Until the lower level routine is written, the link would be
"unresolved" and a list of unresolved links could be generated to
identify work remaining to be done.

4. When the lower level routine is written and linked, both the parent
and the child would show page references and become hyperlinks.

This could continue for as many levels as needed until the modules
become actual lines of code or close to it.

Does anything like this exist?

Thanks

--

 

[Phlip]

I am looking for a flowcharting program that will allow me to design
my code top down:

1. Start with a very high level (functional) flowchart consisting of a
few functional modules. For example, (a) Start, (b) User Logon, (c)
Load Data, (d) Select Test, (e) Administer Test, (f) Logoff. (g) Exit.

2. Each of the "modules" (shapes) would be identified as having a
lower level or not. If they have a lower level, the program would
generate an "open link" to another flowchart, probably on another
page, having that name.

3. Until the lower level routine is written, the link would be
"unresolved" and a list of unresolved links could be generated to
identify work remaining to be done.

Does anything like this exist?

Nobody does top-down like that any more. That technique was once promoted as
"structural programming". It has a major flaw.

The flaw is you can't test the program and get perfect behavior until you
code everything. (And the system you describe is _coding_, not designing or
planning. If you get the flowchart wrong, the result will have bugs.

Writing bugs and detecting them a long time later is a very bad practice.

To learn the most modern technique to design, google for "Test-Driven
Development". It will feel like the system you envision, but no bugs.

 

[CBFalconer]

.... snip ...

Nobody does top-down like that any more. That technique was once
promoted as "structural programming". It has a major flaw.

The flaw is you can't test the program and get perfect behavior
until you code everything. (And the system you describe is _coding_,
not designing or planning. If you get the flowchart wrong, the
result will have bugs.

Bosh. You aren't writing your 'structured' programs properly. You
can fill in levels with a simple dummy function that just prints
"galomphing the flugel". This way you will rapidly get to
something that just processes its input, and you can see any flaws
there. Then you get around to expanding the other areas.

The point is that you get to something that runs and accepts input
very quickly. As you continue refinement it does more and more,
with the various stubs reminders of what is yet to be done.
Banishing the refinements to stub functions means you establish
those functional interfaces early. Since they are still stubs you
can usually refine the interface without causing major upheaval.

 

[LurfysMa]

Bosh. You aren't writing your 'structured' programs properly. You
can fill in levels with a simple dummy function that just prints
"galomphing the flugel". This way you will rapidly get to
something that just processes its input, and you can see any flaws
there. Then you get around to expanding the other areas.

The point is that you get to something that runs and accepts input
very quickly. As you continue refinement it does more and more,
with the various stubs reminders of what is yet to be done.
Banishing the refinements to stub functions means you establish
those functional interfaces early. Since they are still stubs you
can usually refine the interface without causing major upheaval.

I agree that it can work if done properly.

Now, do you know of a flowcharting tool that will do most of the
clerical part of keeping track of the links (stubs)?

--

 

[Richard Heathfield]

[Followups set to comp.programming]

LurfysMa wrote:

Now, do you know of a flowcharting tool that will do most of the
clerical part of keeping track of the links (stubs)?

No, but I can think of an easy way to do it yourself. In each function,
write a line to a dot file, documenting the function. If it's a stub, make
the label stand out (e.g. colour it red). Whenever you call a function,
write a line to the dot file, documenting the call. So, for example, you
might end up with a dot file like this:

digraph "G" {
main [label="main" fontcolor="white" color="blue" style="filled"];
main -> foo;
main -> bar;
foo [label="foo" fontcolor="white" color="red" style="filled"];
bar [label="bar" fontcolor="white" color="blue" style="filled"];
bar -> foo;
bar -> baz;
baz [label="baz" fontcolor="white" color="red" style="filled"];
};

(I've written this in the same order that I would expect it to be
generated.)

In this example, I've used red for stubs and blue for non-stubs. The exact
details of how you actually write the dot file code does, of course, depend
on the language you're using, but the good news is that it should
modularise nicely.

To generate the dot file itself, of course, you simply run the program. Then
you pipe the resulting output through dot:

me@here:~/dev/scratch> cat scratch.dot | dot -Tps -o scratch.ps

or, if you're using an Imperial system:

c:\dev\scratch> type scratch.dot | dot -Tps -o scratch.ps

How you view the resulting image depends on which output format you chose.
Here, I chose PostScript, so I can just do:

me@here:~/dev/scratch> gv scratch.ps &

Just one annoyance - if, say, bar calls foo MANY times (i.e. more than
once), you'll get many arrows joining them in your diagram. The fix is
either to ensure that your call-generating code only gets called once
regardless of how often the subsidiary function is called, or to pour the
program through a uniqueness filter that preserves line order. Fortunately,
it's fairly trivial to write such a filter (or of course you could nose
around on the Net for one).

Last I checked, you could get dot from: http://www.graphviz.org

 

[Rob Thorpe]

I agree that it can work if done properly.

Now, do you know of a flowcharting tool that will do most of the
clerical part of keeping track of the links (stubs)?

If you write the code as you go, and comment each function, then
Doxygen (http://www.stack.nl/~dimitri/doxygen/) should do document
roughly what you need. It has lots of features for OO programming, but
you can always ignore them if you don't want to use them.

 

[Richard Heathfield]

If you write the code as you go, and comment each function, then
Doxygen (http://www.stack.nl/~dimitri/doxygen/) should do document
roughly what you need. It has lots of features for OO programming, but
you can always ignore them if you don't want to use them.

That's a good idea iff the OP is using a language that doxygen can parse.
The OP seems to be using VB (see crosspost list). Can doxygen parse VB? I
don't know.

 

[Chris Sonnack]

Nobody does top-down like that any more.

False. In fact, I'd say it's pretty difficult to decompose a problem
without it.

That technique was once promoted as "structural programming".

False, also, I think, but I'm not sure if "structural"=="structured".

Top-down (or bottom-up or left-to-right or right-to-left or inside-out)
is a composition technique that really has little to do with the
specifics of the code. It's how you analyze a problem.

The flaw is you can't test the program and get perfect behavior until
you code everything.

This I know is false. As CB said, you can easily test "top" functions
by using stubs.

In fact, you should recognize this fits quite well with your obsession
with TDD. Write the simplest possible "top" function. Test it. Now
write a called function. Test it. Repeat until done.

To learn the most modern technique to design, google for "Test-Driven
Development". It will feel like the system you envision, but no bugs.

I'm sure TDD-obsessed programmers write bugs, too. They just find them
sooner, one presumes.

 

[Scott Moore]

The flaw is you can't test the program and get perfect behavior until you
code everything. (And the system you describe is _coding_, not designing or
planning. If you get the flowchart wrong, the result will have bugs.

Writing bugs and detecting them a long time later is a very bad practice.

To learn the most modern technique to design, google for "Test-Driven
Development". It will feel like the system you envision, but no bugs.

So you are saying you would design a building by putting together each room
at a time, stacked one on the other, until you get a 20 story building.

Good thing there is nothing similar between the building trades and programming,
since designing buildings like that gives you a building that collapses of
its own weight!

Wait a minute.. maybe programming is like that.....

 

[Phlip]

So you are saying you would design a building by putting together each room
at a time, stacked one on the other, until you get a 20 story building.
No.

Good thing there is nothing similar between the building trades and programming,
since designing buildings like that gives you a building that collapses of
its own weight!

I'm saying you build a tiny hut, and it stands up. Then you build a slightly
larger hut, and it stands up. Then you improve your materials a little, and
build another hut. Keep going, one tiny change at a time, until you have a
big building.

Note that process takes millenia. Software, fortunately, is proton-free.
Each compile is a bit faster.

 

[LurfysMa]

If you write the code as you go, and comment each function, then
Doxygen (http://www.stack.nl/~dimitri/doxygen/) should do document
roughly what you need. It has lots of features for OO programming, but
you can always ignore them if you don't want to use them.

Thanks for that pointer. Doxygen appears to be tightly linked to the
programming langauge. I am looking for a language-independent
development tool. I am writing a spec for a project and the
programmers will choose the language. I am just doing a functional
flowchart. We might get down to the code level eventually, but that is
not required.

I was really looking for a tool like Visio, but with some ability to
keep track of the parent-child links and the stubs.

Thanks

It does not appear to support Visual Basic. I

--

 

[Scott Moore]

Scott Moore wrote:




I'm saying you build a tiny hut, and it stands up. Then you build a slightly
larger hut, and it stands up. Then you improve your materials a little, and
build another hut. Keep going, one tiny change at a time, until you have a
big building.

Which is why the analogy is a good one. Your building will fall down, even
though you built each "hut" very carefully.

The reason why is that buildings rely more on their skeleton and overall
design for strength than the design of each individual room. In fact, designing
a building is a classic case for top down design. The entire building and its
skeleton are designed first, then the details, like floorplanning, plumbing,
walls, etc.

 

[Rob Thorpe]

Thanks for that pointer. Doxygen appears to be tightly linked to the
programming langauge. I am looking for a language-independent
development tool. I am writing a spec for a project and the
programmers will choose the language. I am just doing a functional
flowchart. We might get down to the code level eventually, but that is
not required.

I was really looking for a tool like Visio, but with some ability to
keep track of the parent-child links and the stubs.

Thanks

It does not appear to support Visual Basic. I

There are a few scripts around on the web that allow it to parse Visual
Basic. But that's not a particularly satisfactory solution.

I must admit, I haven't been able to find a tool to do what you
describe. Most case tools I've seen recently are very complicated and
based around diagrams no-one really quite agrees on the meaning of. I
would be very interested if you manage to find one.

 

[LurfysMa]

There are a few scripts around on the web that allow it to parse Visual
Basic. But that's not a particularly satisfactory solution.

I must admit, I haven't been able to find a tool to do what you
describe. Most case tools I've seen recently are very complicated and
based around diagrams no-one really quite agrees on the meaning of. I
would be very interested if you manage to find one.

I did find one link that might have some promise.

http://office.microsoft.com/en-us/assistance/HA010744141033.aspx

I haven't had a chance to check it out yet. If someone else has time,
I would be interested in the results.


--