Pages: [1]   Go Down
Author Topic: Tip for newbies: flowchart your ideas  (Read 1739 times)
0 Members and 1 Guest are viewing this topic.
Atascadero, CA
Offline Offline
Sr. Member
****
Karma: 2
Posts: 468
Arduino addict
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Once in a while I remember the right way to do something.  smiley-wink  This evening I was trying to figure out how to get my sketch to go through some steps and I remembered one of my favorite tools: the flowchart.

For those of you who don't know what a flowchart is, it's simply a diagram of all the things (or a subset) your program does, and how the execution of the code "flows".  It includes decision points, states, process flows and such.  Entire courses are taught on flowcharting, but you don't have to have anything fancy to get your ideas out on paper.

The key to flowcharting is to put all the details down in the chart, with arrows and lines that show where to go next and why.  Then you don't have to think about how to solve problems while you're writing your code.  You only have to think about the code itself and writing in your comments and stuff.  Much easier when you're still learning how to just write code.

You can draw it on paper or use a program for it.  I use the drawing program in Open Office http://www.openoffice.org/ and it works well.  And you should break up your ideas into sections and do flowcharts for each.  Include points where one flowchart leads into another.

Here's a couple examples:
http://www.chesterfamily.org/pictures?g2_itemId=10096
http://www.chesterfamily.org/pictures?g2_itemId=10100

In starting this thread, I'm hoping to draw out some knowledge from other folks on the forum.  So if you have some flowcharting expertise to share with the n00bs, please reply.

And if you're interested, feel free to post questions about flowcharting.  I can help get you started.

Cheers!
Logged

What about elevensies? Luncheon? Afternoon tea? Dinner? Supper?

B0100111001000011, USA
Offline Offline
Edison Member
*
Karma: 0
Posts: 1503
I'm confused.  Wait, maybe not..
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have found that making flow charts helps organize my ideas into something usable.

I like how yours are color coded and neat, unlike mine ;D!
Logged

Phoenix, Arizona USA
Offline Offline
Faraday Member
**
Karma: 39
Posts: 5557
Where's the beer?
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

If you ever want the ultimate in flow charting, check out Six Sigma.

Actually, Six Sigma goes waaaay beyond flowcharting; its a methodology that encompasses a vast amount of knowledge on understanding processes, process flow, and how and why errors accumulate in processes, and how to measure for these errors in order to correct them effectively and efficiently.

Flowcharting (known in Six Sigma as "process mapping"), when done properly, can do much more than map out how something works; it can quickly tell you, visually, whether your process is correct and efficient.

Your first step is to define your problem; you must do this in a concise, logical, and complete (to the best of your knowledge) manner. Every detail of the process to address the problem shouldn't be written down at this stage, but the general idea should be there.

Write it down on paper; think about it, does it seem complete? Does it feel correct?

Once you have done that, work from that description to generate your first process mapping iteration. Use boxes for the processes within the overall process, diamonds for decision/branching, circles for start and end - parallelograms can be used to represent data in and out; be sure to use arrowheads at the end of lines connecting each item to show the direction of flow (never put two arrowheads on the end of the same line; use two separate lines with individual single arrowheads).

At this stage, you should only have a minimum of boxes and branches, because the problem was so generally (but accurately) defined. If you have way more than needed (and this can't be defined; it depends on the problem domain and the skill of the person or group involved in creating the process map - you get better as you practice), or if things are defined incorrectly in some manner, you will be able to see it on the flowchart. A sure sign of a problem is if you have lines all over the place or crossing each other too many times; it is a visual version of "spaghetti code". Indeed, if you flowcharted such a piece of code, you would instantly see the real visualization of the process; it isn't pretty!

Once you have this first iteration concise and clean, look at each box on the diagram. Can they individually be broken down into their own processes? Most likely, they can, if you think about it carefully and logically. Take those areas, and process map them (in the same general manner to the best of your ability and knowledge as you can). You will either want to fuse this detail of the map within the same structure as the first iteration, or you will want to note in the process boxes on that iteration a note for a the detail (ie; see "flowchart_1b"); many programs that allow you to flowchart provide a method whereby you can link from the process box to the flowchart which represents it.

After process mapping, perform the same check again on the map: Is it too complicated? Are there lines crossing? Does it look messy?

Once again, you'll generally be able to spot problems visually. Correct them (if you can) and move on. Sometimes, these problem areas might actually be caused by missing a step, or not thinking the problem domain for that area of the overall problem completely through.

Continue this iterative approach to the problem in order to study the entire domain in detail; the level you ultimately want to try to strive for is something akin to understanding the process to  take apart a brick until you reduce it to atoms. This degree of  attention to detail isn't always practical or possible, but always try to strive for it.

If you process map a problem domain effectively (especially if it is a process involving human interaction and effort; processing mapping the problem of bug tracking is an interesting area), you will quickly find areas of the problem where people honestly don't know (and don't generally think about) how the process worked, until you ask them and discuss it with them. In many cases, the problem or part of the problem is solved in a "soft" manner; which generally involves a social aspect or something (ie, calling and discussing an issue with somebody) outside hard inputs and outputs - even so, they should be properly process mapped; they are a part of the process.

That leads to the final piece; one that leads more into the meat of Six Sigma: Every process has inputs, and outputs. Know these items for every process in your problem domain. Know and understand how the outputs of one process flows into the inputs of the next. Once you know them, you can then apply numbers to them, as well as devise a process scoring system.

This scoring system (which are almost always customized; though I think there is a Sig Sigma Patterns book for some common problem domains and such) ultimately allows you to see how well a process is working, and how changes to one or more inputs of a system affect the other parts (via propagation and otherwise).

This is just a high-level overview, one in which I probably missed something or got something else wrong; I never studied Six Sigma in any depth, I just worked for a membership organization here in the Phoenix, AZ area as a web developer for their website (which was an amazing project in and of itself, actually). I will gladly defer to anyone's deeper understanding of this topic. It is a very complex system of systems and methodologies, as I noted previously.

Hope this helps someone!  smiley

if you lay out your problem efficiently, starting with a general overview
Logged

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Sweden
Offline Offline
Jr. Member
**
Karma: 0
Posts: 74
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I am "all in" to know what to do before actually doing it!.
Workflowing is a good old way to sucess.
Currently I am trying to use RTH, Requirements and Testing Hub.
Not as graphic as flowcharts, but helps me to do a better job when other programmers/testers works in my project.
But tell us about Six Sigma: Is there any good open source tools for using it? Looks like many adopted it, wich is a good point of using it.
« Last Edit: February 14, 2010, 06:14:05 am by srylul » Logged

0
Offline Offline
Full Member
***
Karma: 5
Posts: 229
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Wouldn't it be a better idea to use flowcharts directly when programming ?? check out YENKA (google it)
Logged

Phoenix, Arizona USA
Offline Offline
Faraday Member
**
Karma: 39
Posts: 5557
Where's the beer?
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
But tell us about Six Sigma: Is there any good open source tools for using it? Looks like many adopted it, wich is a good point of using it.

I am not personally aware of any open source tools; 6S is really a methodology that encompasses quite a lot of areas, flowcharting being one of them.

Since 6S is focused on reducing errors in processes and increasing output, it is very management and higher-level oriented; most tools that are marketed toward 6S professionals (of which, I am not one; I only worked briefly for a business that acted as a "membership society" for the 6S community - http://www.isssp.com/) tend to reflect this, and their cost trends toward the upper end of the scale...

That doesn't mean such tools don't exist - or couldn't be developed. Really, much of what we did at ISSSP didn't involve software - flowcharting and such was typically done in round-table discussions on whiteboards and large flip-charts. This facilitated a quick exchange of ideas and thoughts on flows and how to best capture them. If something was wrong, it was easy to see in the flow, and could be updated rapidly. We found that once we could settle on a flow, we would then capture it with Visio (perhaps with extra notes and documentation). We could then represent that entire flow as a simple "sub-process" box in a larger flow, and continue with capturing the rest in future meetings.

Ultimately, it worked well, but was probably waaay overkill for anything like you would do on an Arduino - but could be used for larger/more complex processes, of which the Arduino might only be a small part of.

 smiley
Logged

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Phoenix, Arizona USA
Offline Offline
Faraday Member
**
Karma: 39
Posts: 5557
Where's the beer?
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Wouldn't it be a better idea to use flowcharts directly when programming ??

Sure, just like it is a great idea to architect a house as you build it...

 :smiley
Logged

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

UK
Offline Offline
God Member
*****
Karma: 13
Posts: 903
Twitter: @simonmonk2
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Flowcharting, how quaint!

I love hearing electronic engineers talk about programming smiley-wink

Actually for the few dozen lines of code you can squeeze into an Arduino, its fine. Minimal quantities of classes, and no multiple threads of execution to worry about (apart from the occasional interrupt).

Its a useful way of expressing thoughts, other useful ways that 'real' software engineers use are: state diagrams, sequence diagrams and use cases. Have a look at UML for lots of other nice thinking tools.

Can I feel the flames flickering around my feet?
Logged

--
My New Arduino Book: http://www.arduinobook.com

SE USA
Offline Offline
Faraday Member
**
Karma: 41
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Can I feel the flames flickering around my feet?

they make a spray for that you know
Logged


Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 200
Posts: 12772
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


...other useful ways that '[glow]un[/glow]real' software engineers use are: imagining objects as living entities traveling about in a silicon world talking with each other and occasionally get into fist fights.

 ;D
Logged

0
Offline Offline
Jr. Member
**
Karma: 0
Posts: 81
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

flowchart meet life, life meet flowchart


wish me luck... [smiley=beer.gif]
« Last Edit: September 14, 2010, 03:15:28 pm by whiskey » Logged

Atascadero, CA
Offline Offline
Sr. Member
****
Karma: 2
Posts: 468
Arduino addict
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
wish me luck...

More importantly: have fun!   smiley-wink
Logged

What about elevensies? Luncheon? Afternoon tea? Dinner? Supper?

Norway@Oslo
Offline Offline
Edison Member
*
Karma: 12
Posts: 2033
loveArduino(true);
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Sometimes I use postits to denote each step in my process. This might be helpful when you deal with very abstract problems.

Microsoft Visio is a great tool in my opinion, although I still prefer to do the early flowcharting (and other mindmapping) with physical material.


@Coding Badly: it's even better when the fistfight stops, and the flyswatter gets its turn to dominate. Bugs away!
Logged

England
Offline Offline
Full Member
***
Karma: 0
Posts: 211
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Have a look at UML for lots of other nice thinking tools.
I was going to say the same thing, too bad the are no good open source tools for that either.  The open source netbeans and eclipse plugins for it are dire.
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

hi! i am new here. is there some introduction section? I have been searching for it.
Logged

Pages: [1]   Go Up
Jump to: