13

I am doing out some flow charts and am wondering if I am approaching this correctly. In essence, I have several method calls and I am flowcharting each separately. However, several of these methods make a method call for some info and then continue. See this example:

enter image description here

I have 3 other methods that also call GetQueue() and I am wondering if I am representing this correctly. The AddQueue() flow visually looks like it is broken.

NOTE: Changes made in my flowchart:

enter image description here

Aaron Hall
  • 5,895
  • 4
  • 25
  • 47
Keith Barrows
  • 303
  • 1
  • 2
  • 8
  • Is this level of pictorial detail really necessary? I know that, at one time, flowcharts like this were popular, but they seem to have fallen out of favor nowadays for many reasons... Essentially they are a redundant form of documentation; you have to keep them up to date, and the code should already adequately represent what is shown in the flowchart anyway (meaning: the time is better spent producing more code). – Robert Harvey May 12 '11 at 17:45
  • It was requested of me before I move on to another client. – Keith Barrows May 12 '11 at 18:32
  • @Robert Harvey: Flowcharts were useful in the old days, when people wrote machine or assembler code directly. They may have been useful to early FORTRAN and BASIC programmers, who didn't have a good array of control structures. Nowadays, well, the only reason I'd do them is if a client wanted them as a deliverable and was willing to pay me adequately. – David Thornley May 12 '11 at 20:08
  • When developing these from scratch I have found it very helpful to use yellow stickies, turning the 90 degrees for decisions. This lets you move them around and insert processes inbetween. When you are all don, then enter them into your software. – Michael Riley - AKA Gunny May 12 '11 at 22:33
  • I still use flowcharts occasionally, although I find unit test are often better for the same purpose. They aren't deliverables, though; I use them to get a control flow right in my head. – Michael K May 13 '11 at 13:20
  • Surely the whole point of a DESIGN is to decide what is to be done BEFORE cutting code - especially in determining interfaces between modules/classes/methods? – Andrew Dec 31 '12 at 19:34

2 Answers2

13

Use a subroutine symbol for the method call (predefined process)

enter image description here

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
2

I've recently done some flow-charting and struggled with the same issue, how to present subroutine calls, or perhaps method- and function -calls as you might call them these days.

I settled on a convention that I separate subroutine CALLS from subroutine REFERENCES. For the former I use an ordinary rectangle showing the call with arguments being made, using whatever variables that are in effect at that point in program execution.

I use the doubly sided "predefined process" rectangle simply as a reference to another flowchart which contains the definition of that function or sub-routine. The sub-routine rectangle need not show the arguments of the sub-routine since that is part of the defining flow-chart of the sub-routine in question, but it may be helpful to add them in the reference already so whoever reads it can see the meaning of the actual arguments used in a call.

This increases the number of rectangles but it makes it clearer that those other flowcharts exist to look up the definition of some of the called functions from. Often if a function is simple I will not create a separate diagram for it but just document it verbally.

I also use the "document" symbol to say that details should be looked up from the code-listing.

The point of a flowchart to me is not to create a program, but to make it easier for others to understand a program. I think the help as a birds-eye view and that purpose of them should be kept in mind. They are not for visually describing EVERY detail of your program,details are visible from the code when needed. The flow-chart is just one picture of your program from the high-level view-point.

Keeping flowcharts high-level also means there is less need to keep them up-to-date as code is modified.

They are pictures. Like any good story software documentation should have pictures too which give an alternative viewpoint to the code.

Panu Logic
  • 121
  • 3