UML started life as a notation. Back in the days of CASE there were dozens of different approaches to modelling: Rumbaugh, LSDM, Schlaer-Mellor, Booch, Information Engineering, Bachman, Coad/Yourdan, Merise and a bunch of others. All of these espoused a different approach and all of them used different notations with different diagrams.
UML set out to provide a consistent notation across a common set of diagrams. By gaining backing from vendors across the sector, this is exactly what it achieved. However, it did more than that: because UML was adopted as an agreed standard for notation, the set of diagrams that was supported by UML became the foundation upon which modelling solutions were to be built. In effect, it mandated a methodology based on the diagrams and models supported by the UML standard.
Thus UML ended the so-called "methodology wars" that had bedevilled the CASE era, by more or less forcing all the suppliers to adopt a common platform. One has to wonder, of course, whether this was Rational's (now a part of IBM) intention all along, when it developed UML and pushed it through as a standard to be managed by the Object Management Group.
And now to contradict myself: UML has not ended the "methodology wars". Today, Rational has its own methodology (the Rational Unified Process), Select has the Select Perspective, MEGA has Moka, Microsoft will be shipping two methodologies with Visual Studio 2005 and so on and so forth. Thus there are still lots of methodologies. However, the big difference today is that methodologies are all extensible: they simply represent a starting point from which you can develop your own approach, if that is what you want to do. So, UML did its job of getting rid of the rigid methodologies of the past, it is no longer necessary to do so for today's more flexible approaches.
This isn't the only point. Consider UML as she is implemented today. The Atlantic release of IBM's Rational suite is based on the 2.0 standard. But that standard has yet to be ratified. Select has built extensions to the UML standard where it does not feel that the standard has sufficient functionality, and Microsoft supports the standard only up to version 1.1 and it, too, has added all sorts of extra stuff that goes beyond the standard. Other suppliers are doing the same thing.
In other words, UML is a bit like SQL – useful as a lowest common denominator but you shouldn't expect much more of it. Indeed, the length of time that version 2.0 is taking suggests that UML is falling into the trap that has categorised all long-lived standards: too little, too late.
Just like SQL standards, UML has its uses, but it shouldn't be treated as a be-all and end-all standard to adhere to. Perhaps it's not past its sell-by date - but it is certainly showing signs that it is not as sprightly as it once was.