Flow charts

Thread Starter

Saviour Muscat

Joined Sep 19, 2014
147
Hello all,
Currently I am doing an engineering course in electronics, I acquired fair knowledge of c programming but lack in knowhow about c programming designing flowcharts, please can someone suggest a webpage(tutorial) or good book regarding flow charts that can I follow.


Thanks
Smuscat
 

Papabravo

Joined Feb 24, 2006
13,909
Don't waste your time. Flowcharts are mostly useless, can't be maintained, and are never as accurate as the code. They are an anachronism of a bygone era. Let's leave them buried.
 

Thread Starter

Saviour Muscat

Joined Sep 19, 2014
147
Don't waste your time. Flowcharts are mostly useless, can't be maintained, and are never as accurate as the code. They are an anachronism of a bygone era. Let's leave them buried.
Yes you might be correct but I have a criteria in the subject that flowcharts are stated please can you give me a hand!
 

Papabravo

Joined Feb 24, 2006
13,909
... I have a criteria in the subject that flowcharts are stated please can you give me a hand!
I don't quite understand your reply. Do you mean: "I have a stated requirement that I need to use and understand flowcharts"
I'd like to help you out, but I'm not quite sure how to do that. Can you give me some insight into any difficulties you are having with the idea and practice of creating and using flowcharts?
 

Thread Starter

Saviour Muscat

Joined Sep 19, 2014
147
I don't quite understand your reply. Do you mean: "I have a stated requirement that I need to use and understand flowcharts"
I'd like to help you out, but I'm not quite sure how to do that. Can you give me some insight into any difficulties you are having with the idea and practice of creating and using flowcharts?
Many thanks for your help. Yes you are correct you understood well!
 

Papabravo

Joined Feb 24, 2006
13,909
A simple flow chart is very much like a paragraph composed of declarative sentences. Graphically you represent this with a sequence of rectangular blocks connected with arrows that flows from the top of the page to the bottom. Each block contains one declarative sentence. Are you OK with that?
 

shteii01

Joined Feb 19, 2010
4,644
I don't quite understand your reply. Do you mean: "I have a stated requirement that I need to use and understand flowcharts"
I'd like to help you out, but I'm not quite sure how to do that. Can you give me some insight into any difficulties you are having with the idea and practice of creating and using flowcharts?
Part of the course material is use of a flow chart. So they would have an assignment where they are required to turn in a flow chart. I had similar assignments in my Software Engineering class (one of the Technical Electives that I took my senior year).

The thing is... they should have some examples in the textbook. And just googling flow chart with connection to programming should have brought plenty of examples. Also software engineering standards have some more specific guidelines for flow charts.
 

jpanhalt

Joined Jan 18, 2008
9,663
Here are just some of the shapes that can be used:
upload_2016-4-23_14-11-14.png

Obviously the rectangle (process) and diamond (decision) are most common, but the TS needs to help us answer his question by telling us what shapes have been taught.

John
 

Papabravo

Joined Feb 24, 2006
13,909
In a career that spanned half a century it was obvious from the beginning that maintaining flowcharts was a waste of time because the code was changing so fast in order to meet production requirements, that we just never got around to doing anything with them. By the time the code was done and committed to ROM there was scant motivation to backfill the documentation.
 

shteii01

Joined Feb 19, 2010
4,644
In a career that spanned half a century it was obvious from the beginning that maintaining flowcharts was a waste of time because the code was changing so fast in order to meet production requirements, that we just never got around to doing anything with them. By the time the code was done and committed to ROM there was scant motivation to backfill the documentation.
That sort of thing is one of the things we talked about in that Software Engineering class. There are at least two or three approaches to writing software and depending on the internal company policy/environment the approach to documentation can be strong or weak. I know I will sound like total jackass, but what you described sounds like really poor documentation process/practice. The fact that code was changing that fast also points out to very poor original/early design. But! Design depends more on the management and how the customer is handled by the management so the people who actually write the code don't really have any power, all they can do is follow the orders from the management and "roll with the punches". Like I said, I am sorry I sound like a jackass and wet eared puppy, but they talked to us about this sort of thing in school.
 

Papabravo

Joined Feb 24, 2006
13,909
That sort of thing is one of the things we talked about in that Software Engineering class. There are at least two or three approaches to writing software and depending on the internal company policy/environment the approach to documentation can be strong or weak. I know I will sound like total jackass, but what you described sounds like really poor documentation process/practice. The fact that code was changing that fast also points out to very poor original/early design. But! Design depends more on the management and how the customer is handled by the management so the people who actually write the code don't really have any power, all they can do is follow the orders from the management and "roll with the punches". Like I said, I am sorry I sound like a jackass and wet eared puppy, but they talked to us about this sort of thing in school.
You're absolutely right. This was 1972-1975 and the practice of software engineering was in the genesis phase. Most of the work was done by a small handful of people and we wrote extensive technical specifications that went to 200-300 pages that coverd the functional aspects of the design; but not the implementation. I never said there was no documentation, I just said we never used flowcharts. We used secretaries to maintain the typed master copy of the specification because they knew how to use typewriters, scissors, and Scotch tape, and they had no skill at drafting, and computer graphics was still a pipe dream.
 
Top