By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,315 Members | 1,611 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,315 IT Pros & Developers. It's quick & easy.

How To Do Flow Charts Fast and Do Them Right

P: 171
In my School swimming team, my coaches decided to pull my leg, they gave the award for asking the most questions. I think someone in bytes is going to give me that award soon....

I have currently found how usefull flow charts are in programming, like the slow kid in school finds out in University the importance of doing an outline before writing the essay.

The issue is it's taking me a while to make the flow charts, can someone recommend a good reference guide which can increase the efficiency as well as the effectiveness of making flow charts in terms of articulating the details of the subroutines, flows of data and methods to not allow erraneous data entry in my program.

As always I appreciate your help immensley.
May 22 '09 #1
Share this Question
Share on Google+
5 Replies

Expert Mod 15k+
P: 31,707
I can't help here, but I'm wondering if this is an Access question at all. We have various experts here, some of whom may be able to help, but I suspect moving it to Miscellaneous questions may prove more appropriate.

I'll leave it here for now, but if no-one replies then let me know & I'll move it over for you.
May 23 '09 #2

P: 171
Hi NeoPa, The only reason I put it in Access was that I thought there may be an Access specific way of doing Flow Charts, due to Access having the capability to write SQL through the GUI, plus the other unique features that Access may have. I am just shooting in the dark here
May 24 '09 #3

Expert Mod 15k+
P: 31,707
No worries.

Flag me up if/when you want it moved.
May 24 '09 #4

Expert Mod 2.5K+
P: 2,545
Wikipedia is a good source of further reading if you are interested (see for example their article on flowcharts. However, flowcharts are rarely used by developers these days, as it is virtually impossible to enforce rules of good design using them, and they cover just the procedural aspects of program design.

The debates on what constitutes good design (in the context of structured versus unstructured programming) took place more than three decades ago, leading to the development of languages such as Pascal (developed by Niklaus Wirth in the late 1960s). Visual Basic and its cousin Visual Basic for Applications use Pascal-like constructs a lot (Do-While, IF-Then-Else, Select Case, etc).

The principles of structured programming included breaking programs down into reusable modules, each of which has a single entry point and a single exit point; the formation of all modules from just three types of program structure: sequences of instructions, selections from alternatives within the sequences, and iteration (looping) of instructions; explicit definition of the types of all variables, and enforcement of type checking at all stages of processing ('strong typing').

Flowcharts can clarify the procedural steps (the sequences, selections and iterations) of a program up to a point - but they have many disadvantages. They are time-consuming to draw (even now when using Visio or similar tools to do so), difficult to maintain, can be used in such a way that unstructured (spaghetti) code results, and they do not cover the type allocations (and event handling) which current languages require.

I used to design using pseudocode myself, which mapped easily to the Pascal programming I used to teach.

These days, there are more powerful modelling languages which implement object-oriented forms of data abstraction - in particular UML, short for Unified Modelling Language, that handles events and object states as well as program flow.

I should mention that programming languages such as VB, VBA, C and many others are procedural languages - implementing the transformation of data by applying defined processing steps in sequence. Languages such as SQL are not procedural at all - they are set-processing languages which do not define in procedural terms how to achieve the end result. The representational techniques we have discussed - flowcharts, pseudocode, UML etc - simply do not apply to non-procedural languages such as SQL.

Similarly, in designing databases the most important aspect of the design is decomposing the tables and their interrelationships. This often involves the use of entity-relationship modelling or similar techniques, but never the use of flowcharts. UML can model table interrelationships, but I use a variant of ERDs myself for their simplicity and ease of use (crows-foot notation).

May 25 '09 #5

P: 171
Thanks Stewart Ross Inverness,
Wow! That's a great answer, better than my question actually. I will have to read it a couple of times to understand, but it's good that you have told me, so now I can stop using Flow charts and work on creating better code.
May 28 '09 #6

Post your reply

Sign in to post your reply or Sign up for a free account.