I mean, do you use formal “traditional” flowcharts, with symbols that represent the start and end of a process, and the inputs, decisions, processing steps, and outputs?
If yes, then what specifically do you use for creating the flowcharts?
If not, then what “better” tools do you use for laying out the overall software design?
Sure do, though not terribly often. I find them most useful when I’m in the position of having to tease apart a very complicated procedure, or alternatively when I’m breaking down a procedure for a non-technical person.
Visio is my tool of choice for flowcharts. Some time back when I didn’t have access to Visio I did a big search for freeware chart tools and couldn’t find anything I liked.
I use UML sequence diagrams. They help me to plan the application first, and when I forgot my flow of data and dependencies, they save my ass. The traditional flow-chart? Not so much now.
Not really. Pseudocode, for designing a process algorithm.
I’ll use Visio every once in a blue moon, but I don’t really like it. Sometimes I’ll just use MS Paint, as I find it far easier to to use.
Usually I’ll just scribble it out on paper. It’s usually for no one’s benefit but my own anyway.
I’m only a functional consultant (read: the guy who tells the programmers what does the program have to do), does it count?
I’ve used flowcharts to represent the complete process. My last client wanted us to make them for the whole program and step-by-step (they wanted boxes that said “click button”, with a little pic of the button), but then, they also wanted to test every possible value of every possible variable. In a program that was to be used to manage a multinational, throw-billions-at-stuff company. Right…
The programs I’ve used have been Visio and Enterprise Architecture. In both cases, what the client had available. Sometimes I’ve just drawn on a piece of code or written pseudocode, if it was for our own use and not something the client required.
Not too much. Sometimes, if it will help the client better understand his requirements, but rarely. There are better ways to design now. If I do a formal design I probably will do UML.
Not too often. I may use them a little when roughing out a project, but then I shift to pseudocode.
I do find them quite useful when deconstructing a tricky bit of existing code with a lot of logic.
I don’t use Visio or anything, because I loath it; I do them by hand.
Much of the time, though, one finds oneself using APIs which hide all the complicated stuff. So the code is “call this api, if it doesn’t work, handle it or bail, otherwise go to the next api.” There’s not much to chart there.
I had never heard of UML. Does that mean that I shouldn’t even consider any of the UML tools?
I’m overseeing a fairly complex software project that is designed to automate some business processes. I am not a software engineer but I have fairly good knowledge of software development. We’ve sometimes used Visio for laying out the design but it doesn’t seem to be a good tool for handling the detail of software development. Likewise with SmartDraw.
I prefer drawing out a diagram by hand but the problem is that I need to share the diagram easily with a few other team members, and I need to be able to modify it easily. Also, it becomes awkward to lay out and view a complex design over multiple pages so I thought that there’s some software that allows me to “zoom in and out” at various levels of detail.
Thanks for your responses so far. They’ve been helpful.
Mainframe developer here. I use Visio to document process flows.
Sometimes, I use flow charts when a boss or client requires it, but I usually prefer sequence diagrams however since they allow for better representation of objects, actors, and use cases. Flowcharts are not an adequate tool for describing more than one simultaneous process, or when describing interactions which take place between two actors with process as a middle.
I’ve never used sequence diagrams, at least not formally. Do you you use a specific tool for creating them? Could you offer any suggestions that go beyond the Wikipedia article Sequence diagram and UML Sequence Diagrams?
Not since forced to in school. They can’t even represent the kinds of programs I write.
I taught programming for many, many years and neither I nor any other prof taught flowcharts. Lots of diagrams of various sorts, but never flowcharts.
A combination of these, depending on how complicated the algorithm is. I don’t think I’ve ever used formal flowcharts.
Not the formal sort. I often sketched informal flows on whiteboards during process analysis meetings, and much of the time they ended up in the final specs. We used pseudocode too.
Nope. No punch cards either.
Yeah, me too. I always keep pencils and plenty of paper handy, and I tend to do a lot of somewhat informal graphs for high-level processes, along with more complex and detailed sketchings for working through complicated low-level processes. I don’t use any formal modeling scheme, just whatever symbology seems to be most appropriate to the problem being solved.
I like to do a lot of pseudocode as well, but for some problems I just feel like I can think better on paper, and that’s when the sketches start flying.
Not in 35 years. The stuff that flow charts could help with is not stuff that is ever an issue. Since I’m my own customer, no one requires it. Data structures and data manipulation are the tricky things, and flow charts are not too useful in that regard.
I do use pseudocode, and have often found that the exercise of working through the process finds bugs before I start coding. I also document everything I do during development and debug in a text file I keep open in EMACS, which is really useful for long term projects I might be called away from for some emergency.
Enterprise Architect is in the list of UML tools, and I know it was UML… but it does include flowcharts. It just happens to include more stuff than flowcharts, but the whole thing started with a flowchart.
Not really. I just have my own notes that would be impossible for anyone else to understand or read. That is just the way I think and work.