Do you use UML o or a domain specific modelling language(DSML)?
Do you make up your own modelling language? (A DSML)
Does it help getting code written?
Do you use them for code generation (or are they otherwise runnable )?
Do you use them to make pictures of your system (or do you draw them directly)?
When writing a technical design I use UML to transform the words in the functional specification into something visual. It helps me see the overall picture that can get lost in the text. Also, it helps you think through the design a bit more and spot high level deficiencies.
Does it help get code written? Directly? no. Indirectly? Yes, since I write the best code when I know exactly what I'm trying to accomplish.
I am not a big fan of UML but i believe that DSMLs may be a good help, as long as it is completely integrated in the development process, which means that it is used to generate code. Otherwise i consider that there will eventually be differences between the model and the code (the same way differences appear between code and comments).
So yes, i do use my own DSML.
While I have used UML diagrams to put in technical documents, I find that they often must be managed carefully to be a useful aid in development.
The reason?
For any system, there may be many entities interacting. However, only a few of those entities are really important, and many interactions are rather trivial. However, if you attempt to diagram everything, you get a poster big enough to wallpaper your bathroom.
So what I do is sketch out some diagrams at a higher level of abstraction, using design patterns. For example, if it is a workflow, I may model it as a series of stations, a manager, a router, etc. Just enough detail so we can talk about it.
This lets the people writing code break it up as they see fit. Developers shouldn't be constrained too much by object diagrams and so forth.
Most often, I see UML diagrams being written after the system is built, as documentation. This is useful, but it certainly doesn't help get the code written.
I can highly recommend the Eclipse Modeling Framework (EMF). Rather than UML it provides a low level entry to modeling (simple class-based models, no hassle). It helps me a lot as I get get top-notch customizable (java) code for my datamodels, and much more, but see for yourself.
It always help to have a blueprint before you start constructing.
I use UML for modeling only, UML helps when I try to understand/create/re-call architecture of an OO application. As a visualized approach, UML make these tasks easier.
I don't use code generation tools simply because I don't design to that detail level. But I like functions to sync from code back to UML diagrams.
Such intermediate forms are best when they really help communication between members of a team. If the purpose is just to help you think clearly, then use whatever works, but be careful of tools that require too much time and maintenance. Often, quick sketches on a white board, plus lots of talking, is all you really need.
My main complaint is that any intermediate form is work, and keeping such intermediate forms up to date with the code becomes even more work. It is the code that counts. Is this tool really helping you get to the code faster? Is it making the code better?
In my experience, most good programmers think in code. If you think in some other diagrammatic language, OK, use it. If you need to communicate with someone else, you must find a common language.
I've never found much use for UML or similar models. My criterion for using a modeling langauge is simple: the model should generate a useful checker or a tool for exploring the design.
An example of a tool that generates a useful checker is SPIN, which is useful only for finding bugs in concurrent software, but for those bugs it is absolutely indispensible---great at finding bugs and for simple models can often guarantee absence of bugs by exhaustive search.
An example of a tool that helps explore a design is the Alloy Analyzer. Alloy is a bit harder to learn than SPIN, but in an Alloy model you describe the properties you expect your data structures to have, and then it runs off and shows you a bunch of examples that have those properties. If you realize that you're seeing something you don't want, or you're not seeing something you want, you play with the model until it's right. After that the model becomes something you can use to document invariants and check assertions in the code. With Fred Brooks, I believe that representation is the essence of programming, and any tool that helps me understand the relationships among my data is a tool I'm in favor of.
Questioner also asked about pictures of a system. If I'm designing a system I generally draw pictures on the whiteboard. These get photographed and put under source control with the rest of the documentation.
Once or twice in my career I have had to refactor a big system that was getting out of hand. In those cases I have rolled my own tool to extract dependency information and then used dot from the AT&T graphviz toolset to try to visualize what was going on. I have usually had to tweak visualizations by hand to get the understanding I really wanted, but when I have had to do this, dot has been a lifesaver.
In summary: build a model only if there's a tool that will do something useful with the model. If you want visualizations and pictures, extract visualizations from the code you actually run.
I use the UML sequence diagram format when I'm trying to understand a new "long algorithm" kind of thing like a windows service or a "main loop". I once did a sequence diagram for a program that makes use of a Genetic Algorithm, and it was very, very helpful to understand the existing code.
When doing a UML sequence diagram I don't always put the class/actor/responsible-thing across the horizontal, sometimes I'll just break an algorithm down into sub-steps and pretend they're the classes/actors/responsible-things. I always annotate the hell out of the sequence diagram and I'm pretty loose about where to draw the arrows for call/return asynch/synch and other relationships. Sometimes I blend these with class diagrams and CRC (class responsibility collaboration) cards. Very big mashup by the end and I have to admit I probably never update it afterwards.
I find that when a client asks for storyboarding as part of the design process they are happy with UML swimlane/actor diagrams for the most part. Generally, it doesn't help the developers, but the benefit of keeping the client happy can't be overstated.
Maybe UML is good for some jobs, like banking networks. I'm shy of UML because 1) it doesn't map well onto the kind of projects I work on, and 2) I don't like to code/describe things twice.
The idea of a DSML is a great one, but I want my DSML to be not just a design language, but an implementation language. That's not always easy, but my favorite coding method is to try to accomplish it, usually by some kind of code generator.
(This feeds into the comment-free code discussion.)
UML is all but useless, but I like DSLs - or, rather, I like visual designers that let me work with horrendously complicated code in a visual (and thus more understandable) manner.