Dispelling Misconceptions about UML

Many developers have several misconceptions about UML. Perhaps you do too, but after reading this book, you’ll have the misconceptions dispelled:

UML is not proprietary. Perhaps UML was originally conceived by Rational Software, but now it’s owned by OMG, and is open to all. Many companies and individuals worked hard to produce UML 2. Good and useful information on UML is available from many sources (especially this book).
UML is not a process or method. UML encourages the use of modern object-oriented techniques and iterative life cycles. It is compatible with both predictive and agile control approaches. However, despite the similarity of names, there is no requirement to use any particular “Unified Process”—and (depending on your needs) you may find such stuff inappropriate anyway. Most organizations need extensive tailoring of existing methods before they can produce suitable approaches for their culture and problems.
UML is not difficult. UML is big, but you don’t need to use or understand it all. You are able to select the appropriate diagrams for you needs and the level of detail based on you target audience. You’ll need some training and this book (of course), but UML is easy to use in practice.
- UML is not time-consuming. Properly used, UML cuts total development time and expenses as it decreases communication costs and increases understanding, productivity, and quality.

The evolution of UML

In the B.U. days (that’s Before UML), all was chaos, because object-oriented developers did not understand each other’s speech. There were over 50 different object-oriented graphical notations available (I actually counted), some of them even useful, some even had tool support. This confusion, interfered with adoption of object-oriented techniques, as companies and individuals were reluctant to invest in training or tools in such a confusing field.

Still the competition of ideas and symbols did cause things to improve. Some techniques were clearly more suited to the types of software problems that people were having. Methodologists started to adopt their competitors’ useful notation. Eventually some market leaders stood out.

In October 1994, Jim Rumbaugh of the Object Modeling Technique (OMT) and Grady Booch of the Booch Method started to work together on unifying their approach. Within a year, Ivar Jacobson (of the Objectory Method), joined the team. Together, these three leading methodologists joined forces at Rational Software, became known as the Three Amigos, and were the leading forces behind the original UML. Jim Rumbaugh was the contributor behind much of the analysis power of UML and most of its notational form. Grady Booch was the force behind the design detail capabilities of UML. Ivar Jacobson led the effort to make UML suitable for business modeling and tying system development to use cases.

The Three Amigos were faced with the enormous job of bringing order and consensus to the Babel of notation and needed input from the other leading methodologist about what works and what doesn’t. They enlisted the help of the Object Management Group (OMG), a consortium of over 800 companies dedicated to developing vendor-independent specifications for the software industry. OMG opened the development of UML to competitive proposals. After much debate, politics, and bargaining, a consensus on a set of notation selected from the best of the working notation used successfully in the field, was adopted by OMG in November 1997.

Since 1997, the UML Revision Task Force (RTF) of OMG—on which one of your authors (okay, it was Michael) served—has updated UML several times. Each revision tweaked the UML standard to improve internal consistency, to incorporate lessons learned from the UML users and tool vendors, or to make it compatible with ongoing standards efforts. However, it became clear by 2000 that new development environments (such as Java), development approaches (such as component-based development), and tool capabilities (such more complete code generation) were difficult to incorporate into UML without a more systematic change to UML. This effort leads us to UML 2, which was approved in 2003.