Flow Charting or something

[Dave Morley]

Learning JAVA has it's trials and tribulations but I am starting to get the picture. What I really need is some help on flow charting or where to start when you want to develop a plan before coding. I am having to do ome excercises on the course that I am doing. I have tried to write down all my inouts and outputs etc but it would be better if I could get some info on flow charting or how to go about, in a logical manner, setting down the processess before coding. Or basically point me in the right direction or explain how programmers preparing the code they need to write. I have allready worked out you can get into a hell of a mess if you try to remember it all. Preparation must play an important part in all programming ?

Thank you in advance.

Dave M
cape Town

[Shashank Agarwal]

Well, first of all u've got to understand that there are real people who are going to use you java applet or application. So first try and get the application organized. You may use comments along side the actual code so that you can keep a track of what you are (were) coding even after you take a months break. Your idea to start of with a flow chart is excellent. After you are done with the "paper work", first try and find out what methods u'll use. Then i'm sure you'll be sailing smooth the rest of the way.

And remember, The answer to life's most complex problems is SIMPLE.

[Francis Siu]

Hi Dave Cape Town

Preparation must play an important part in all programming ?

Sure
Before prgramming the requirement which collected from the end user, some documents should be created in order to confirm the final requirement.

Flow chart is a tool to help analysis the application, it is also a big picture for your development, it shows out number of input and ouput (data), function (process) ,data store and external entities which involved in your application.

According to what you had drew, then try to write down the suedocode or try to create a prototyping. My suggestion is to create a prototyping, the prototyping can be given to end user to identify the requirement (business logic, input and output data). After the feedback is given and then you can modify the prototyping.

If programmers preparing the code they need to write, they will do the suedocode, suedocode shows out the details of function (process), details of function includes the business logic, which input data involved from data store or external entity and which data will be produced out to the interface or store the data into the database.

hope this help
[ August 14, 2004: Message edited by: siu chung man ]

[Stan James]

Flow charting is a useful technique but I gave up on it in most cases because it was too hard to change - lots of erasing and rerouting lines or starting over from scratch. Even with a reasonably good electronic tool like Visio it's a pain.

I find pseudocode much more compact and easier to produce and change with a text editor.

If you're just starting out, an ancient technique called "functional decomposition" can be a big help. Try describing your problem in 3 to 5 lines. Maybe you have an assignment to read a file that contains two columns of numbers, print the sum for each line and a total for the whole file. Break up the parts:

program:
  open file
  process all lines
  close file

Back in my COBOL days, lots of people wrote batch programs that all started with initialize, process and finalize. It's pretty easy to break writer's block and get started with that!

Now "decompose" each statement into more details:

process all lines:
   while more lines
      read one line
      process one line
   end while
 
process one line:
   find the numbers
   compute the sum
   print the sum
   add sum to a grand total

After you do this with pencil and paper and translate to Java for a while, you'll discover you can do it almost exactly the same in code. Hope that helps!

By the way: This is not very "object oriented". When you get ready for sophisticated object designs (and don't rush it) scroll down to the UML etc forum further down the page.

[Tom Hill]

The best thing to do is say: What objects does my system need, What does each object have to do - then say how do i go about getting the objects to do it eg. What other objects will i need - are they pre written? Then think about method access (private, public, abstract, static etc).
Then you can think about the rewards:

[Dirk Schreckmann]

Moving this to the OO, Patterns, UML and Refactoring forum, where they love to talk about such design things.