Flow Charts
SS
I was just curious about something and thought I would throw it
out...
Does anyone here (or HAS anyone EVER) actually written flow charts
when designing/developing
new applications? Does anyone work for a company that requires flow
charts as part of documentation
for projects/systems? I have created system flow charts using Visio
for complex systems (more for my
own use so I would be able to understand how the system worked) but I
would think they would help immensely
when learning/maintaining complex applications. Having worked for
quite a few companies, I found it
interesting to note that none of them had any flow charts for their
systems nor did any of their programmers
even consider developing any. In fact, they all looked at me quite
strangeley when I mentioned this.
Sherry
JC
which required the construction of flowcharts for the initial design of the
programs....
It's what happened afterwards that was interesting, most of them suddenly
found good reasons for dropping the charts as...'the programmer can
determine the structure of the program from the source code'.
There are some packages around that draw program structures..McCabe Toolkit
springs immediately to mind. I downloaded something called Legacy from
www.shareware.com a few days ago, but haven't looked at it yet...
John
SS wrote in message <36EAE354...@yahoo.com>...
SS
>
> I've worked as a contractor for quite a few companies in the UK, all of
> which required the construction of flowcharts for the initial design of the
> programs....
> It's what happened afterwards that was interesting, most of them suddenly
> found good reasons for dropping the charts as...'the programmer can
> determine the structure of the program from the source code'.
I guess the general consensus is that flow charting is a waste of
time..lol.
Until/unless all the experienced programmers leave and the entire
shop is flooded
with new people who are supposed to make "quick fixes" to large,
complex programs
in a short period of time! [been there - done that]
> There are some packages around that draw program structures..McCabe Toolkit
> springs immediately to mind. I downloaded something called Legacy from
> www.shareware.com a few days ago, but haven't looked at it yet...
>
> John
Hmm - I didn't know that. I will have to research those. They could
come in handy
in future! Thanks!
Sherry
Peter Midgley
that they had a policy of designing/documenting programs with flowcharts. I
found this very hard, having been used to designing and writing
simultaneously, to be forced to draw all these boxes and allocate jsp
actions to them. In favour, it certainly made me try to decide up front
exactly what was to happen, and the overall logical structure, but against,
I found myself feeling that while I was doing all that, I could be writing
the actual program. After all, who needs to know what the program is doing
IN MINUTE DETAIL apart from a programmer who should be able to see it in the
code (assumes meaningful data names, not too many strange GO TOs etc), in a
form which is 'language independent'?. To answer my own question, the
'analyst' (where an installation splits the function of analyst and
programmer. Conclusion: I guess it's horses for courses, depending on where
you are working. I find that it also depends on the complexity of the
program. For example a simple file-read, update or print is pretty easy to
understand however it's documented (ergo why bother with boxes) , whereas a
complex program such as a till program is pretty hard to take in, once you
start moving beyond the simplistic 'initialisation, main-process,
termination type of documentation.
As they say, HTH!!
--Pete Midgley
SS wrote in message <36EAF805...@yahoo.com>...
JC
against an IDMSX Database & we are porting into a MicroFocus Cobol
environment & Oracle on Windows NT using a new product called Visual AM.
Have a look at www.xitec-software.com , you might find it interesting if
your company is thinking of development offload or even junking the
mainframes.
I believe they are targetting the IBM market now..
John
JC
We're porting 3 systems (ICL VME/AM/IDMSX) over to MF
Cobol/NetExpress/Oracle using Visual AM...They have this really useful piece
of software that produces the program structure of the original
AM...unfortunately, they don't give you the structure of the generated COBOL
which is all in-line code & that's what the programmers will be animating
against!!!!
John
Peter Midgley wrote in message <7cejl3$se$1...@news5.svr.pol.co.uk>...
>I worked as a contractor at AA Insurance for a couple of years and found
>that they had a policy of designing/documenting programs with flowcharts.
I
>found this very hard, having been used to designing and writing
>simultaneously, to be forced to draw all these boxes and allocate jsp
>actions to them. In favour, it certainly made me try to decide up front
>exactly what was to happen, and the overall logical structure, but against,
>I found myself feeling that while I was doing all that, I could be writing
>the actual program. After all, who needs to know what the program is doing
>IN MINUTE DETAIL apart from a programmer who should be able to see it in
the
>code (assumes meaningful data names, not too many strange GO TOs etc), in a
>form which is 'language independent'?. To answer my own question, the
>'analyst' (where an installation splits the function of analyst and
>programmer. Conclusion: I guess it's horses for courses, depending on
where
>you are working. I find that it also depends on the complexity of the
>program. For example a simple file-read, update or print is pretty easy to
>understand however it's documented (ergo why bother with boxes) , whereas a
>complex program such as a till program is pretty hard to take in, once you
>start moving beyond the simplistic 'initialisation, main-process,
>termination type of documentation.
>As they say, HTH!!
>--Pete Midgley
>
>
>
>
>
Thane Hubbell
>
> I was just curious about something and thought I would throw it
>out...
>
> Does anyone here (or HAS anyone EVER) actually written flow charts
>when designing/developing
> new applications?
I can create a flow chart. It does nothing for me as far as helping
design. I just don't do them. I DO Pseudocode, however. I might
spec out a whole program (in comments) and then code around the
comments.
I did do one flowchart for a process I designed where I worked before
- AFTER the program was written, only to help those who later worked
in the program to understand it.
Flow charts do not work for Event Driven or OO programs.
Warren Simmons
Early on - 1960-65, flow charts were used extensively. One reason was that
between compiles, there was much down time to desk check code. What I'm
saying is that there were few tools to do otherwise. At any rate, "we" had
conventions for charts that had a number system for nodes on the chart that
reflected page number as well as node number, and a node occurred between
each statement. At one site, the program was "written" on a chart, handed
off to a teletype operator where it was typed and made into paper tape
before loaded on the computer for compiling.
One of the "utilities" that Grace's sailors did was a COBOL program to read
COBOL source, and draw a flow chart on the printer. This helped to move the
process to after a compile instead of before a compile. And it allowed this
form of documentation to stay current when program changes were made. I
believe the move to structure code helped reduce the presumed need for the
charts, too.
Warren Simmons
w.g.s...@worldnet.att.net
SS wrote in message <36EAE354...@yahoo.com>...
>
> I was just curious about something and thought I would throw it
>out...
>
> Does anyone here (or HAS anyone EVER) actually written flow charts
>when designing/developing
S R Hart
>- AFTER the program was written, only to help those who later worked
>in the program to understand it.
>
>Flow charts do not work for Event Driven or OO programs.
I agree with you that flowcharts do not help in developing complex
solutions. I am more in favour with PseudoCode, and structure charts. I am
currently developing a very complex system for a company in OO, and i have
to produce some form of logical structure anaysis to show employers, which
in your opinion would be the best method,when dealing with OO logic?
SrHart.
Donald Tees
structured code is always exactly the same. You do one thing, or you do a
list of things. Then you have another list of flowcharts.
The technique has been obsolete for twenty-five years.
SS wrote in message <36EAE354...@yahoo.com>...
>
> I was just curious about something and thought I would throw it
>out...
>
> Does anyone here (or HAS anyone EVER) actually written flow charts
>when designing/developing
> new applications? Does anyone work for a company that requires flow
>charts as part of documentation
JC
Structured programming is based on merging the Input & Output Data
structures together with the list of Conditions & Operations to produce the
program structure.
How many organisations allow programmers the time to go back to the original
structures & modify them properly??
Then again, there's the age-old problem of Structure Clashes in report
programs.
Formal methodologies propose producing an intermediate file & then inverting
the printing module wrt the main processing module. How many organisations
implement that??
John
(Getting back into COBOL after years of 4GL work)
Donald Tees wrote in message <7cgf9o$9bo$1...@news.igs.net>...
Donald Tees
SS wrote in message
<Snippage asking about flowcharts>
After posting to your last message, I thought perhaps the answer was a bit
curt, and decided to write a bit more.
Flow charts are designed to map out program flow. While that observation
may seem trite, it bears examination. Top down methodology is designed to
eliminate, or trivialize flow control. It does so by forcing the programmer
to design simple procedures with one entry point, and one exit point. No
"GOTO"'s is only a rule to enforce that; when gotos are allowed, they are
present because the language forces it. The real rule of structure is
isolation of sub-modules for flow control.
Picture a flow chart where every single box contains one entry point, and
one exit point. There are no triangles, representing GOTO statements, and
absolutely no arrows that do not procede directly to the box immediatey
below. That is structured code. The flow chart is absolutely identical to
the list of paragraph names in the program. The flow chart says nothing; it
documents nothing that is not documented better by well chosen procedure
names.
Flow charting may be a usefull pencil-type methodology for thinking about a
system at the design stage. I often doodle with a pencil with little boxes
and arrows. It may also be a useul method for figuring out a badly written
program. However, DESIGNING the code consists of eliminating all that
complexity, and organizing it into a structured. Every arrow on the
flowchart has to be eliminated. By the time you actually start coding,
design should be well beyond the flowchart stage.
In summary, flowcharts are not used because modern design technique renders
every flowchart trivial. Top down programming methodology is based on the
idea of dividing a project into thousands of tiny, absolutely trivial
flowcharts, each standing in isolation. A non-trivial flowchart is a mark
of poorly designed code.
Donald Tees
>Structured programming is based on merging the Input & Output Data
>structures together with the list of Conditions & Operations to produce the
>program structure.
I do not think I agree with that. (I am also not sure I understand what you
are saying<S>). Structured code is produced by taking a complex process,
and subdividing it into numerous less complex processes. That process is
continued on with the sub-processes, until all processes are simplified to
the point that they are trivial to code.
Flow charting is designed to give a graphical representation to a complex
process, so that one can take it in at a glance. If you have no processes
that complex, then what need for a flow chart, beyond that of a tool to do
the analysis? The output of the design stage should be simplified to the
point that a flowchart is not needed.
That leaves another question, mind you. Is there a graphical method for
representing a well designed top down structure? The design is going to be
a tree-structure, which flow charts do not handle well. However, you can
graphically represent a tree. A tree view, with nodes representing
decisions might very well be a usefull tool, but it would not be a
traditional flowchart.
Twymer
in. Flowcharts were required when I was attending classes (in the early 70's)
to show us how to document. Since then pseudocode has since replaced
flowcharts as that portion of the required documentation. Data flow diagrams
and structure charts round complete the "package". Hope this helps.
Tom Wymer
JC
what the underlying processing is for each screen..
John
Twymer wrote in message <19990314125741...@ng113.aol.com>...
SS
>
> seeing how you have received many response to your query let me put my 2 cents
> in. Flowcharts were required when I was attending classes (in the early 70's)
> to show us how to document. Since then pseudocode has since replaced
> flowcharts as that portion of the required documentation. Data flow diagrams
> and structure charts round complete the "package". Hope this helps.
>
> Tom Wymer
I really liked reading everyone's responses...they were very
enlightening.
I myself prefer pseudo code. I have prepared DFD's - once, but every
other shop
I have ever worked in has not really required either of these. I have
found
that getting my manager to sign off on pseduo code [when nothing is
REQUIRED) is a CYA manuever.
<grin>
Sherry
JC
Ken Foskey
>
> I was just curious about something and thought I would throw it
> out...
>
> Does anyone here (or HAS anyone EVER) actually written flow charts
> when designing/developing new applications? Does anyone work for a
> company that requires flow charts as part of documentation
Yes I have defined a flowchart once. It even seemed silly to do it
then.
>
> for projects/systems? I have created system flow charts using Visio
> for complex systems (more for my own use so I would be able to
> understand how the system worked) but I would think they would help
> immensely when learning/maintaining complex applications. Having
> worked for quite a few companies, I found it interesting to note that
> none of them had any flow charts for their systems nor did any of
> their programmers even consider developing any. In fact, they all
> looked at me quite strangeley when I mentioned this.
>
For defining a system diagrams are great, for detail on a program they
are next to useless and go out of date almost instantly. Have you ever
written a significant program from scratch and got it right first time?
Have you then gone back and updated the doco?
Pseudo code came in and went out fairly quickly. It is not a bad idea
to code your program structure first but using a non-language just
confuses everyone. Show pseudo code to a user one day and what them
fade out of the conversation. Sorry Sherry...
Any large system needs a diagram to see how it interacts:
Data flow diagrams have been round a while and are very good at showing
the flow of data. Getting these right can help your project structure,
it will help you minimize your interfaces. It will help you to
construct a significant functional specification as your FS will follow
the diagrams: define the top layer and how it works then drill a little
into each area, then drilling again as required. To much detail (in
english) is a mistake I am still trying to avoid.
Entity relationship diagrams are great for seeing how the various parts
of a database interacts. This tells a programmer how to get one piece
of information with another piece. Required for any significant
database. (Tip use access to draw the diagram it is simple and a lot of
PC's already come with it installed).
Use cases (from OO land) are great for collecting user requirements. It
focuses the interviewer and interviewee on the system and the goals of
the system. Worthwhile looking into this, great to talk to users
without glazing on their eyes.
Other object diagrams: Has anyone tried these? Probably not useful
until OO cobol is in use. When Rational (or whoever) supplies cobol
generating code same as it does for C I might consider using OO cobol.
Thanks Ken
Twymer
actual work flow. With both part of your institutional documentation it makes
maintenance a whole lot more structured and easier.
Tom Wymer
Howard Brazee
> other shop
> I have ever worked in has not really required either of these. I have
> found
> that getting my manager to sign off on pseduo code [when nothing is
> REQUIRED) is a CYA manuever.
> <grin>
>
> Sherry
And where I have seen pseudo code used, the pseudo code writer basically
wrote the program!!! I'd hate to have the boring job cleaning up the
syntax. Maybe there's a way to be useful without being so detailed.
With structured coding, I can do my design much easier.
Howard Brazee
What would such a graphic tell us? A structured program can show us in
one screen, what it does - the main paragraph with a series of
PERFORMs. If we want more detail, we page down to the PERFORM in
question and look at it. Sure we could make a flow chart and print it
out, but do we gain any understanding which is easier to see than a well
written program? And which is more trustworthy - the code itself, or
the translation of that code into a different medium?
Thane Hubbell
> Pseudo code came in and went out fairly quickly. It is not a bad idea
> to code your program structure first but using a non-language just
> confuses everyone. Show pseudo code to a user one day and what them
> fade out of the conversation. Sorry Sherry...
Ken,
I'm not sure about the others here, but when I say I "Pseudocode" I
don't mean the "official recognized" Pseudocode syntax. I mean
something more like this:
* Open the input file
* read records until end
* Close the input file
Then I code around these comments. The actual syntax of the
pseudocode is unimportant - what matters is that by doing this you
have thought through the process.
As Donald does, the method I use involves breaking down each
"operation" into smaller and smaller pieces conceptually, until the
code to perform the operation becomes trivial.
Re: your comments on Data Flow Diagrams - I have only seen these in
use in one shop - and it was great to have. I wish I had TIME to do
these more often.
-----------------------
Visit my updated website at
http://www.geocities.com/Eureka/2006/
Donald Tees
Howard Brazee wrote in message
>What would such a graphic tell us? A structured program can show us in
>one screen, what it does - the main paragraph with a series of
>PERFORMs. If we want more detail, we page down to the PERFORM in
>question and look at it. Sure we could make a flow chart and print it
>out, but do we gain any understanding which is easier to see than a well
>written program? And which is more trustworthy - the code itself, or
>the translation of that code into a different medium?
I agree. I could see such a graphic being usefull if it were built
dynamically and maintained as part of the GUI ... in effect I could use it
to find the code in my text editor. However, as a stand-alone document, it
would just become an annoyance to maintain with very little benefit.
Howard Brazee
> don't mean the "official recognized" Pseudocode syntax. I mean
> something more like this:
>
> * Open the input file
> * read records until end
> * Close the input file
>
> Then I code around these comments. The actual syntax of the
> pseudocode is unimportant - what matters is that by doing this you
> have thought through the process.
And what I do is the following:
OPEN INPUT-FILE.
PERFORM 900-READ-RECORDS UNTIL EOF-READ.
CLOSE INPUT-FILE.
It's just as obvious that I've thought through the process, and if the
process changes, so will my statements.
SS
>
> So where do you work, Sherry??
>
> John
John,
Let's just say I have been around...and leave it at that. No
names....lol. It's a small world in the
computer industry as I am sure you are aware. But some things never
change - just the people.
Sherry
Thane Hubbell
wrote:
Yes.. of course. My example was simplified. For complex processes,
before you have distilled them down to actual code, directly coding it
won't work.
Try something like:
* Open the input file and output file, also the cross reference
database table.
* establish a cursor on the intermediate update file that allows
update of
* the status field from the cursor.
* read sequentially through the input file, looking up the actual
descriptive data
* for the record in the cross reference file. Define and read from a
cursor based
* on the returned information, creating output records for each
returned item.
****
For each of the major tasks here I code a paragraph. Within that
paragraph I write similar comments (pseudocode if you will) for each
task within a task - until I get down to the point where the COBOL is
the same as the comments.
-------------------------
Trust the computer industry to shorten "Year 2000" to Y2K. It was
this
kind of thinking that caused the problem in the first place.
Rick Smith
S R Hart wrote in message
<921440452.26247.2...@news.demon.co.uk>...
methods that seem to work well for describing different portions
of a system. Use whatever tools you have at your disposal.
Here are some suggestions:
Data Structure Diagrams: Used to show system wide data and
to show the relationship between data entities. When used within
a network model to describe data, the resulting diagram can be
used to distinguish classes, or to identify the various records
(entities) that exist within a network, heirarchical, or relational
data base; or the records for indexed sequential files.
(I discovered this, on my own, after finding other methods to be
unsatisfactory.)
Warnier-Orr Diagrams: Used to show the temporal structure of
an application; in particular, the sequential processes and data
necessary for an application. It is derived from JSP and is used
with output-oriented design.
Data Flow Diagrams: Though originally developed to show the
flow of data through a complete system, they may still be useful
for describing the data flow within a sub-system.
State Transition Diagrams: Useful for describing the parsing of
inputs to a process. Simple parsing can be described in
psuedo-code or a flow chart; but for complex input, a diagram
may be significantly clearer.
Decision Tables: Useful for listing the actions required for
numerous or complex coditions. May translate directly to
EVALUATE.
Flow Charts: Most useful for describing a complex process with
numerous intermediate calculations or variables.
Psuedo-code: To describe any process for which there is not
another, more satisfactory means.
Finally, the "method du jour" for OO is UML. This is, yet, one more
attempt to create a comprehensive means for designing systems.
I have looked at it, played with it, but I don't like it. You might think
more highly of it. It is backed by many big name software vendors.
< www.rational.com >
HTH
------------------
Rick Smith
Howard Brazee
> time..lol.
> Until/unless all the experienced programmers leave and the entire
> shop is flooded
> with new people who are supposed to make "quick fixes" to large,
> complex programs
> in a short period of time! [been there - done that]
> Sherry
So flow charts are useful for maintenance. That means that as soon as
you get done writing a program or maintaining a program, the flow chart
needs to be updated.
I have done this with system flow charts, and it works quite well. But
I've never seen a program flow chart maintained.