I was taught to draw diagrams in UML to see the interactions between classes, objects, and participants/the system and so on. However, I've seen several answers here stating the UML is a documentation tool and not a design tool.
How do you depict designs graphically if you don't use UML?
I use quick UML-esque sketches as a design tool, and then full UML diagrams generated from code as documentation. A full, accurate UML diagram as design isn't really possible (at least not until UML is a full graphical programming language) so this seems the best method to me.
I tend to use Pen(cil) and Paper. Or possibly Sticky Notes and Whiteboard, depending on complexity.
Boxes and arrows on paper or whiteboard. All the baggage UML forces on you is overkill in many situations, especially at the early stages of a design.
Of course there's a level, after a few iterations, when it starts being useful (and even necessary) to document the previous decisions in detail with a standard format.
UML is a documentation tool and not a design tool.
I'd call crap on that statement. UML is a proven design notation, provides a great amount of depth across its various diagrams, and is standardized. It's great if you have a large team and need to make sure everyone is on the same page regarding the architectural decisions.
I'm guessing whoever made that statement is simply tired of UML, doesn't understand how to use it, or both.
Scott Ambler has a great table on his website that lists all the diagrams typically used on software projects, with links to examples.
I find the UML diagrams useful but am continually annoyed by the 'everythings a box' mentality.
EDIT: I tend to stay away from UML modelling tools as much as possible, because the act of creating a formal diagram inevitably creates pressure to 'polish' it till it looks like a quality product (regardless of how much value is in the diagram itself).
It doesn't help that until recently most UML editors provided little help in tidying diagrams, e.g. draw a straight line between two boxes and a 'kink' appears in the middle because the elements are not absolutely horizontal. I've seen developers waste hours just trying to get all the lines horizontal or at 45 degrees. My personal favourite editor is MagicDraw, but Enterprise Architect seems to be very popular so I use it a lot as well.
When I do modelling inside the team I use UML + DFD + User Interface sketches till everyone is happy, then take a digital photo and post it on the project website. If it proves very useful it may last long enough to be 'formalized' - but most don't.
UML is a language of communications. When people say they use boxes and arrows on paper, they are either using UML or they are using something they have to explain to whoever they are talking to.
If they are just talking to themselves, then they probably shouldn't be doing design--design needs genetic variety if it isn't going to come out brain-damaged, I don't care how good the architect is.
I use CRC cards: http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card
Some GREAT words about software engineering, by Richard Feynman, can be found here. Really a lesson to take by heart...
EDIT: moved my ramblings below... better to listen to Feynman! :)
IMHO there are much design choices which are poorly served by UML.
UML is fine when is not overkill! Maybe some quick sketches are the first step, refined later to became complete UML.
Just please don't peruse the Top-down methodology that UML (tends to) encourage too much (again IMHO).
I start with the whiteboard, then I move to GraphViz once the design has stabilized. It's easy to share the source with others to examine alternate ideas or clarify roles.
Then you can keep a copy of the graphviz source open in your editor and tweak the diagram as you go to keep the details current with your code.
I think most people start by drawing free-form diagrams that are basically UML, but not as rigid or well-defined.
If the diagrams need to progress beyond this stage, then they can be turned into proper UML diagrams which adhere to all the rules.
I've seen very few alternatives to UML diagrams. Most of them seem to be older formats, which have direct successors in UML.
(BTW I absolutely refuse to always write "the UML" in sentence mangling ways!)
I generally try to start with a simplistic sketch on a piece of paper because as I build up the design I find that things are often better fitted elsewhere and writing it down will help me remember it better later.
I don't always fill in types at the beginning either because I don't always know what I need (e.g. a boolean for a checkbox, or an enum for a tri-state checkbox).
After my basic design I tend to implement the classes and connections then flesh out details on an index card class by class before doing any real implementation
I read somewhere that people would outline with post-it notes, but were not allowed to actually write anything on them, and when the design go so complex that you couldn't remember which post-it not was which class/module/architectural feature then it would need to be simplified.
I thought that was neat. I personally use the UML-esque class and sequence diagrams. Real UML is just too much work, in my opinion.
My own custom quirky notation. boxes for hunks of data whether arrays, files etc. Sketchy ideas for classes are just the class name with members and methods written underneath. I deal with hardware often, so the data acquisition system sitting in a car undergoing a test is just a cute little drawing of a car. Duh, simple!
There's a pitch-fork looking thing - a cow prod - indicating when one things provokes another into action, or controls its activity. Arrows for flows of data, sometimes passing through hoops indicated regulation, guidance, redirecting of that data.
I do use arrows of the type used in UML to indicate class inheritance. That is the only thing i stole from UML. (Whatever did i use before i encountered UML?) My background is electronics, so my personal notation is probably based on seeing block diagrams of radios and TVs as a kid.
I am lucky in that about 90% of my work is solo, source code entirely under my command, only giving finished or test versions of executables to others. If i were in a big corporation, i'd be getting a lot of weird looks, like a circus freak!