How relevant is UML modeling today?
codebetter.com
codebetter.com
Not that I've ever worked at Microsoft or any massive "pure software" groups; I've basically worked in "get stuff done" smaller software groups. However, I suspect these small groups are far more common. When push comes to shove, code is the design documentation.
Beyond that, I've always had practical issues with UML's need to specify everything. How often is that valuable? Any given box-and-stick-diagram-with-labels is bound to be pretty clear, whether or not it does things the UML way. I would be annoyed if someone wasted extra time (and, likely, money) on a UML-aware tool, when it would have been faster and as useful to just sketch something.
I've also tended to rely on automatically-generated-and-therefore-always-correct diagrams (e.g. Doxygen, through GraphViz). This is especially true given that the majority of my documentation, even outside the code, leans toward plain text formats (e.g. man pages, simple text files, reStructuredText, or HTML). My reliance on those formats forces documents to be on the short side, which also helps avoid the risk of inconsistency with the code.
UML is a tool, a language. It's not a process, nor does it require that you specify anything. It's just a way of talking at a technical level.
I've been in the software field for 25 years delivering production code in a lot of venues. I always use UML as a way of doodling and talking about the way we're going to attack a problem.
Remember the four Cs of modeling: communication, coordination, collaboration, and consensus. There is a 5th C, Control, but it's bad medicine. Once you think that UML controls stuff, you run off in to architect astronaut land drawing lots of complicated diagrams with lots of little details.
That's what people think of when they think of UML, and it's about the furthest thing from the truth as you can imagine.
Just to rant a little bit more, a couple of years ago I wrote an agile project management tracking tool. As part of that, my customers and I had a 30-minutes requirements meeting. From that I created an analysis model. From that I created a database and a DAL. The whole process took about 2 hours. When people wanted changes, I could change the model and have the database and code change in 5 minutes. It left me to work on the UI and Business Logic and not be wiring stuff up everywhere.
UML can be nothing more than a bunch of boxes with arrows between them. In fact, 95% of UML is never or very rarely used by effective projects.
Tools can be very useful or they can cut your arms off. Doesn't make the tool bad or good. It's just a tool.
I do tend to think of your 4 Cs as all the same, though. In my experience, a team is either working together effectively or it isn't, and either achieves all of those "Cs" or none of them. I would even add that, often, a team lead must forego the "consensus" and simply make a decision. (This can even be true when dealing with customer requirements; occasionally, a software architect's design decision ultimately delivers a better thing than what the customer technically specified.)
For communication, a lot of times I'll be describing something to another programmer on the phone -- or he'll be describing it to me. As they talk, I jot down what I think he's saying in lighweight UML. Then I show it to him by email or webcam or something. It identifies a lot of discrepancies very quickly.
For collaboration, many times in a group we'll tag-team a problem by drawing up our idea of what we think it looks like. Either we trade-off, or everybody draws separately, or one person leads until the group replaces him.
For consensus-building, a lot of times you'll have a subcontractor or person who's remote who is proposing some kind of work for the team. They can do a stand-up, or a presentation, or whatever, but the key thing is usually when they communicate their technical solution in terms of a diagram. This is very useful when talking about how a screen should flow, for instance, or about how a third-party tool acts.
For coordination, a lot of times external groups want to be "in the loop" but don't have time to attend meetings and don't want a lot of paperwork. A lot of times an email with a couple of pictures attached can give them the gist of what's going on technically without a 50-page doc being there.
To differentiate between the Cs, ask yourself: is the communication two-way? One-way? Formal? Informal?
Modeling is just a high-bandwidth version of talking, that's it. I can say more in a model in 10 minutes than I could in 4 hours of explaining.
But, like every freaking thing else in software engineering, people become too attached to it and it has developed all these features that nobody needs. And so it gets abused.
To specifically answer your question, class or domain models seem to work for a LOT of stuff. Sequencing is good at showing things in layers, and Activity Diagrams is just flowcharting on steriods. To give a concrete example of using them, many times when the team is estimating a story and isn't comfortable with the details, we'll take 15 minutes or so and sketch out an activity diagram of how it's supposed to work. That usually either fixes the problem or gives us more questions to go answer :)