Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
The only problem with UML is that it was used as a method of intellectual masturbation by people who love massive class hierarchies. There's a lot of good stuff in UML, the problem is that the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code. There are the same guys who spent years building up formalisms in tools like Rational Rose and other pseudo-engineering tools.
When used by good programmers to illustrate specific hard-to-reason about components of the system, it is a useful tool. Activity diagrams, sequence diagrams, use case diagrams and communication diagrams are all useful.
Sounds like the same people who became Agile consultants in the early 2000's. Perhaps they realized activity and sequence diagrams can get fairly complicated soon enough, so they looked for a bandwagon requiring no technical chops whatever.
I co-wrote a book on UML years ago, used to be an enthusiast. Now I write some sequence diagrams, and once in a while might write a high level class diagram.
It is all about communication, and a sequence diagram is good for that.
and http://www.umlet.com/ (if you need to do more then just sequence diagrams)
After that it usually turns out to be simpler to create a prototype or wireframe than UML diagrams these days (IMO).
For example, check out this 100% legit Wikipedia reference:
OMG (2011). OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1, p. 507.
OMG is short for Object Management Group, but the acronym has obviously not aged well, so what we are left with is a really funny, but totally unintentional joke. Like, check out these certificiations:
OCEB - OMG Certified Expert in Business Process Management (BPM)
OCUP - OMG Certified UML Professional
OCSMP - OMG Certified Systems Modeling Professional
OCRES - OMG Certified Real-time and Embedded Systems Specialist
Who wouldn't want to be OMG Certified?
Personally, in about a decade of programming, I've only had call to say "You know what we need right now? A UML diagram, that's what." about two or three times, and it is always about a sequence diagram for fairly complicated protocols.
Despite what some have said here I don't think using UML is an sign of technical chops, or otherwise. It's just a tool. Some people use it sensibly. Some people use it stupidly. Thus has it ever been.
People drew and draw representations of data, structure and flow long before UML was around, and will continue to do so in years to come.
People wasted a bunch of time writing diagrams which would have been more effectively spent writing code before UML was around, and will continue to do so in years to come.
People wasted a bunch of time writing code when they should have spent five minutes drawing a diagram to make sure they were building the right thing before UML was around, and will continue to do so in years to come.
I'd say the more important skill is being able to talk about data and structure and flow visually - and to know when the right time to do that is. UML is a nice common language to throw on top of that skill.
But UML is certainly not used everywhere. Never has been.
Of course it is! Now the verbose, overblown specs are only really useful for propping up your monitor (see http://www.omg.org/spec/) but fundamentally UML is all about a common way of discussing code, patterns, architectures and algorithms visually.
It's kinda handy to be able to sketch out something on a whiteboard and have everyone in the room be able to read what you have drawn.
[Showing my age] I was around before UML and there were any number of conflicting notations used to describe things... total chaos.
There are like 14 different types of UML diagrams which is complete overkill. You only really need to understand a few (at a high level) and you are sweet...
Roughly in order of usefulness:
* Sequence diagrams
* Deployment diagrams
* Use case model
* State diagram
* Activity diagram
* Class diagram
See more http://creately.com/blog/diagrams/uml-diagram-types-examples...
Like everything enterprise, before it UML was wrapped in a three ring binder and sold by consultants it was created to solve a problem. That problem is; at the beginning of a project(or at cross-team-collaboration-bs-meetings) you'll have an idea in you head, a fist full of markers, and an empty whiteboard. How do you go about explaining that idea to everyone in the room? UML was an attempt at standardizing some of the boxes-with-lines schemes everyone invented.
If you're asking about designing UML diagrams for tools that will automagically generate your application from diagrams, then I think that's definitely a different question. I haven't looked at what the current state of the code generation tools are, but when I looked at it several years ago, it didn't look very promising.
Since then, I've become a lot more realistic and use the diagrams when they're the best method of communicating a conceptual or concrete thought. I rarely use class diagrams, but I find myself using sequence diagrams and deployment diagrams a few times a month. Occasionally I also use Use-Case diagrams when there's more complexity than can be easily included in a single user story.
Interesting though, Grady Booch - the man who wrote the Ada text book I had to learn for university - is behind UML. Glad it failed.
For instance add object oriented or test driven development: http://www.google.com/trends/explore#q=%2Fm%2F07x3g%2C%20%2F...
I would say that it's much more likely that UML is just one of the many tools that developers use, it just isn't generating any "buzz"
Whether they are worth being designed will very much depend on who you ask. The architect who spends a lot of time on designing them will of course be very much in favor. He might feel they properly communicate his architecture.
Certain business types might favor them, on a more simple account - they look deliciously technical and can be used to persuade a customer "we really know what we are doing".
My personal opinion is that certain diagrams can be useful. In general though, way too much time is wasted on doing these diagrams, which aren't going to be at all representative of the end system.
It's not a good communication tool, and it'll in most cases be hopelessly out of date just a few weeks or months into the project.
UML also smells of a top-down approach where the star architect is sitting in an ivory tower handing down blueprints to lowly developers. That kind of approach goes against what I believe about successful software development.
There's useful elements in UML and you definitely won't be worse off if you understand it. But I do not think it's in any way required unless your aspirations are to be developer /architect #2032 in BigCorp.
But again, it'll depend on who you ask.
Disclaimer: I work for the company behind Eclipse Sirius.
The author interviewed people from 50 different major companies, and found people's use fit within the following:
Category of UML Use, Instances of Declared Current Use
no UML, 35
automated code generation, 3
From the conclusion: "The majority of those interviewed simply do not use UML, and those who do use it tend to do so
selectively and often informally."
In my own experience and research, people draw extensively, but have their own shorthand for writing things specific to their domain.
FWIW, contractor working on government projects (DOD).
Different companies doing development (pure tech to Fortune level corporations) all have different requirements and environments. A small, fast-pivoting, ever changing start-up isn't going to need, want or have the time for all the detailed documentation a large, regulated Fortune X company will require.
That said, I think a knowledge of UML is beneficial to all levels, if just having a common modeling "language".
Start-ups can use selected diagrams (eg, sequence, deployment, component) to develop, work out and "document" the high-level vision, and maybe major bugs. Keep them light on details and flexible. Like a paper road-map, they show only the major things, and don't require much time to update.
Large and maybe regulated corporations (and even start-ups in regulated industries) will not only need, but require deeper levels of detail. Class, state and other diagrams. They get into the city-street level maps. But again, they can afford the levels of bureaucracy staffing (like "enterprise architects") required to maintain all the documentation.
I'm not sure how any big team can work without using some UML diagram of some sort. SCRUM boards dont help writing code.
Over many years as a indie developer, corporate developer, architect, engineering manager, product manager, technical founder, and CTO, I've never found the specifics of UML (which arrows and box types mean what, or its distinctions between different types of containment and relationships) to be useful. I've never been in a room with someone who admitted knowing UML, or where UML made a discussion shorter or easier. I've never seen architecture diagrams or sequence diagrams, in whitepapers, technical documentation, or engineering discussion, use UML. I'd hoped that at the least UML would introduce a shared vocabulary, but within my experience it hasn't.
Reading Fowler's “UML Distilled”, on the other hand, did teach me a lot about software architecture and design, and it also taught me to read the rest of Fowler's work, which has been equally rewarding.
also, uml with a tool like enterprise architect (which is basically a set of gui interfaces onto a database, where you construct a design in the database using the views, and are forced to be consistent) is very different from sketching a few diagrams.
it's not for me, but with a good tool you can see the attraction in certain scenarios.
Learn how to diagram sequences and that's about it. The rest is just a fancy way to charge $150/hr consulting fees for 'architecture.' Utterly useless these days.
I think UML is a nice communication tool for the general purpose development (just the basic syntax of UML). But not more than that, please don't specify an app in UML, is just bullshit.
However, in embedded software development it makes sense to specify the system using UML (like some very important controller software). Why? Because the system is very small (so you can model it) and you need a high certainty that it will perform as it it supposed to (you can perform model checkings and validation).
Otherwise UML is just a nice way to have a common language in the whiteboard.
I once did create fully compliant UML diagrams for a requirements document. The next day half the team emailed me back asking what all the box types, arrow heads and broken lines meant. Honestly, simple sketches with annotations have served me so much better than following the rigid rules of UML.
For database designs, textual schemas, E/R diagrams or plain SQL are sufficient. I've drawn plenty of state diagrams without crediting UML handbooks. E/R diagrams can double as "class diagrams" in the sense that you don't need all the complexity of properties and methods in a diagram to convey which classes exist and how they're related.
People who think that drawing bubbles with arrows between them is a language, in more than a philosophical-linguistic sense, should probably take some more certificates.
To be fair, and to repeat some answers I've read so far: Of course, some diagrams are very useful. But to credit UML because individuals find it useful and necessary to draw things is stretching it.
All non-bullshit UML diagram types are going to be valuable sooner or later in one's career; basic familiarity with all of them is a useful language skill.
It is a little difficult to get a hang of, but with familiarity it greatly increases the speed at which I can iterate on designs.
I am not affiliated with Quantum Leaps, but I have found the tools to be very useful.
It's a really useful skill.
...but "UML" as a brand to add to your resumé is pretty much useless.
However, there is one element that I still use and find very useful--time sequence diagrams. Like tracking web requests and responses and communications with back ends, for example.
And often used, but not really exclusive to UML are state diagrams. Certain problems are elucidated nicely that way.
There may be some enterprise, governmental, or aerospace environments that benefit from it or are required to use them.
I made a UML cheatsheet a while ago for a talk:
"Worth to be designed?", depends on your situation, you tell me. If you don't know if you need you probably don't need at all.
ERDs? Documentation tools? Or do you simply tell the engineer to read the code?
(via Erik Meijer on Twitter)