The Unified Modeling Language (UML) is the successor to the wave of object-oriented analysis and design (OOA&D) methods that appeared in the late '80s and early '90s. It most directly unifies the methods of Booch, Rumbaugh (OMT), and Jacobson, but its reach is wider than that. The UML went through a standardization process with the OMG (Object Management Group) and is now an OMG standard.
The UML is called a modeling language, not a method. Most methods consist, at least in principle, of both a modeling language and a process. The modeling language is the (mainly graphical) notation that methods use to express designs. The process is their advice on what steps to take in doing a design.
The process parts of many methods books are rather sketchy. Furthermore, I find that most people, when they say they are using a method, use the modeling language, but rarely follow the process. So in many ways, the modeling language is the most important part of the method. It is certainly the key part for communication. If you want to discuss your design with someone, it is the modeling language that both of you need to understand, not the process you used to get to that design.
The three amigos have also developed a unified process, which they call the Rational Unified Process (RUP). You don't have to use the Rational Unified Process in order to use the UMLthey are distinctly separate. In this book, however, I talk a little bit about process in order to put the techniques of the modeling language in context. Within this discussion, I use the basic steps and terms of the Rational Unified Process, but the text is not a description of the the Rational Unified Process. I find that I use many different processes, depending on my client and on the kind of software I am building. Although I think that a standard modeling language is valuable, I don't see a comparable need for a standard process, although some harmonization on vocabulary would be useful.