Flowchart
-
What flowhcarting programs do people here like to use?
-
What flowhcarting programs do people here like to use?
I don't use flowcharts - I use UML sequence diagrams instead. We use ARTiSAN Studio[^] for SysML/UML modelling, which is pretty much the best UML tool I've used.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
What flowhcarting programs do people here like to use?
Visio mostly, but be patient the learning curve is an interesting one... Once you've gotten used to (and have submitted) to Visio's quirks it works quite well (try to learn the work arounds a quick as possible). Most irritating thing about visio is finding the right stencil, and with the wrong stencil things go really bad (things are hidden and if you find them they behave weirdly on the wrong stencil) Used Enterprise Architect as well, very nice UML tool
____________________________________________________________ Be brave little warrior, be VERY brave
-
I really like the open source DIA, updated recently http://live.gnome.org/Dia[^]
Add 1 for DIA.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
What flowhcarting programs do people here like to use?
Why? Flow charts are pretty much only useful to the person that created them, and that's even suspect. The problem is keeping everything at the same level while still trying to keep it on the page - and without criss-crossing (nearly impossible). Discourage their use by anyone around you, and your life will be soooooo much better!
You are here - through no fault of mine!
-
What flowhcarting programs do people here like to use?
whiteboard
Multi famam, conscientiam pauci verentur.(Pliny)
-
I really like the open source DIA, updated recently http://live.gnome.org/Dia[^]
-
What flowhcarting programs do people here like to use?
-
whiteboard
Multi famam, conscientiam pauci verentur.(Pliny)
+1 Whiteboard. Then digital camera pic. If I need to include it in my documentation, then I will redraw in Visio, but only for pieces that ABSOLUTELY NEED to be modeled to be understood. Flowcharts are useful in some scenarios, never for all.
Proudly drinking the finest Maryland craft beer. Visiting Maryland for business? First round is on me!
-
I really like the open source DIA, updated recently http://live.gnome.org/Dia[^]
Thanks for the link, I'll give it a try. I used to use Visio at my last job but this place won't spend any money so I have to use (gulp) Paint. The worst tool for flow diagrams ever.
-
What flowhcarting programs do people here like to use?
The best flow charting tool I have used is AllClear."[^]"> You write a flow chart script and the tool figures out how to design and draw the flowchart. It usually manages not to do "crossovers" and will connect multipage charts. You can crank out flow charts in no time at all. Since you have the script that created the flow chart you can use it as a document for people who don't do flowcharts. It's not free, not cheap, but then nothing that is any good is. It can reverse engineer the script if the flow chart is modified.
-
Those cool little plastic stencil template thingies that you can draw the charts by hand with!!
I don't have ADHD, I have ADOS... Attention Deficit oooh SHINY!! Booger Mobile Blog Booger Mobile - Official Camp Quality esCarpade Entrant Page
-
+1 Whiteboard. Then digital camera pic. If I need to include it in my documentation, then I will redraw in Visio, but only for pieces that ABSOLUTELY NEED to be modeled to be understood. Flowcharts are useful in some scenarios, never for all.
Proudly drinking the finest Maryland craft beer. Visiting Maryland for business? First round is on me!
IMO the value of a flowchart lies mainly within the actual process of standing up & drawing it. My w/b prints so I sometimes pin a printout on the pin board behind my monitor to reference whilst I'm implementing it. The problem I have with things like Visio, is that they have to be kept in synch with the implementation. This is usually another post implementation make work task. Eventually the files will fall out of synch with the implementation anyway.
Multi famam, conscientiam pauci verentur.(Pliny)
-
Why? Flow charts are pretty much only useful to the person that created them, and that's even suspect. The problem is keeping everything at the same level while still trying to keep it on the page - and without criss-crossing (nearly impossible). Discourage their use by anyone around you, and your life will be soooooo much better!
You are here - through no fault of mine!
Sorry, but this just indicates that you don't know how to use flowcharts properly... and that your coding isn't structured. Properly structured code *never* has any difficulty being drawn without crossing lines (assuming competent drawing). Spaghetti code, not so much. Keeping everything at the same level requires discipline, but then so does writing good, bug-free, code. Trouble keeping a flowchart on one page indicates functions that are too large, that do too much. Divide and conquer. I don't use a flowcharting program because I have never found one that's specifically designed for structured code. It makes a big difference. I started to write one, but decided that the investment of my time was too great and abandoned it. If I thought the market for a good flowcharting program was significant I would have pursued it, but in my experience very few programmers use flowcharts and I thought that was too great a barrier to marketplace success. For me, a flowchart isn't a tool to document what's been coded (past tense), but to help design optimal code first, and additionally to make it easier to understand and debug. Consequently, the flowchart must be easily updatable as the code is debugged or otherwise modified. The various "flowcharting" programs I've seen are for generic drawings. Simply tossing in a few flowcharting shapes is worthless to me. A competent flowcharting program must have an underlying model of a structured program. In other words, you wouldn't use diamonds or rectangles and connecting line primitives, you would use if-then or do-while or switch constructs, for example. Their structure is implicit. Keeping lines from crossing is automatic and trivial. A superior flowcharting program will be able to parse a source code file and produce a flowchart from it. That makes it easy to keep documentation up to date. Unfortunately, I have never found any commercial program that does that. (I wrote one for myself, but that's another story.) A superior flowcharting program will also be able to generate source code from the flowchart. That also makes it easy to keep documentation in sync with program. A really superior flowcharting program will allow debugging a program from the flowchart rather than from the source code... such a program would allow never having to look at source code any more than programmers have to look at the assembly code produced by a compiler or the object code produced by an assembler now. With a flowcharting program like that (it would actually be an in
-
What flowhcarting programs do people here like to use?
Might want to check out http://creately.com/[^]
-
IMO the value of a flowchart lies mainly within the actual process of standing up & drawing it. My w/b prints so I sometimes pin a printout on the pin board behind my monitor to reference whilst I'm implementing it. The problem I have with things like Visio, is that they have to be kept in synch with the implementation. This is usually another post implementation make work task. Eventually the files will fall out of synch with the implementation anyway.
Multi famam, conscientiam pauci verentur.(Pliny)
-
What flowhcarting programs do people here like to use?
I don't flowchart in public. At my first programming job after college, I was laughed at by the whole programming department for flowcharting a large application I was designing. As if flowcharts were crutches needed by noobs, and real programmers don't need a flowchart.
-
Sorry, but this just indicates that you don't know how to use flowcharts properly... and that your coding isn't structured. Properly structured code *never* has any difficulty being drawn without crossing lines (assuming competent drawing). Spaghetti code, not so much. Keeping everything at the same level requires discipline, but then so does writing good, bug-free, code. Trouble keeping a flowchart on one page indicates functions that are too large, that do too much. Divide and conquer. I don't use a flowcharting program because I have never found one that's specifically designed for structured code. It makes a big difference. I started to write one, but decided that the investment of my time was too great and abandoned it. If I thought the market for a good flowcharting program was significant I would have pursued it, but in my experience very few programmers use flowcharts and I thought that was too great a barrier to marketplace success. For me, a flowchart isn't a tool to document what's been coded (past tense), but to help design optimal code first, and additionally to make it easier to understand and debug. Consequently, the flowchart must be easily updatable as the code is debugged or otherwise modified. The various "flowcharting" programs I've seen are for generic drawings. Simply tossing in a few flowcharting shapes is worthless to me. A competent flowcharting program must have an underlying model of a structured program. In other words, you wouldn't use diamonds or rectangles and connecting line primitives, you would use if-then or do-while or switch constructs, for example. Their structure is implicit. Keeping lines from crossing is automatic and trivial. A superior flowcharting program will be able to parse a source code file and produce a flowchart from it. That makes it easy to keep documentation up to date. Unfortunately, I have never found any commercial program that does that. (I wrote one for myself, but that's another story.) A superior flowcharting program will also be able to generate source code from the flowchart. That also makes it easy to keep documentation in sync with program. A really superior flowcharting program will allow debugging a program from the flowchart rather than from the source code... such a program would allow never having to look at source code any more than programmers have to look at the assembly code produced by a compiler or the object code produced by an assembler now. With a flowcharting program like that (it would actually be an in
david_f_knight wrote:
Sorry, but this just indicates that you don't know how to use flowcharts properly... and that your coding isn't structured.
I am not sure why you wanted to make the personal attack, but the rest of your post reinforces my position: Useful flowcharting is next to impossible and NOT worth the hassle. GFY
You are here - through no fault of mine!
