UML 2.0 by Ivar Jacobson

For many years I travelled regularly to Japan. I became acquainted with many companies and many individuals. Several of my books were translated to Japanese so I got many “friends” there. However, since 2001 I have not been back to Japan, so I was very excited to return when I hit the ground in Japan two days ago.

I was invited to give a keynote at a UML conference in Tokyo. My presentation was on the Essential Unified Process with the Essential Unified Modeling Language, EssUP+EssUML. You already know what EssUP is from my previous postcards, but I have so far not described our work on EssUML.

UML was originally developed by a very tight team with Grady Booch, Jim Rumbaugh and I as members. We were nicknamed The Three Amigos – a term I never really adopted myself. Once we had defined what we wanted to achieve other methodologists from around the world were invited to participate. The core of the UML came from the work by the three of us, no doubt about that, but several other individuals made significant contributions. Grady, Jim and I had regular teleconferences in which most decisions were taken. We worked very efficiently. The first reasonably well-defined version of the language was UML 1.1 which was adopted by OMG in the fall of 1997, which was less than a year after we started to work seriously together. This must be a record for any kind of language standardization effort.

UML 2.0 was the next step in the evolution of UML and it was achieved in a very different way following standard OMG procedures. Now a committee with more than twenty persons took over. While we worked on UML 1 in an agile way, the committee worked on UML 2 in any other way than agile. At the UML World conference in Austin, Texas, June 16, 2005, during a panel discussion on UML, Steve Cook said something to the effect “UML 1 was excellent, whereas UML 2 is terrible.”

UML 2 is too big. Its specification is about 1,000 pages long! It includes many good ideas but it is written by tool vendors for tool vendors. No practitioner will read this specification.

There is a lot to be said about what happened in moving from UML 1 to UML 2. UML 1 needed a consolidation period for experience gathering and fine tuning, which it unfortunately never got. Instead the work on UML 2 started with a, too a large extent, new group of persons willing and wanting to change anything they didn’t fancy.

Grady and I were not involved in the UML 2 work. Many questionable changes were made. As an example, I found out that the committee had decided to change use cases from being what they always had been since I first introduced them to being something completely different. They claimed that I really didn’t understand what use cases were, and they had to fix it! Yes, this is a true story.

Once the decision to change use cases was taken, and I was informed about it, I wrote an email to the committee and expressed my severe concerns. I told them that I would not be able to support UML 2 if they changed the fundamental meaning of use cases. That email had no effect, the committee knew better! Thus I had to bring my concerns to top management at Rational. Rational made it clear to the committee that if changes of this nature were made, the user community would react very negatively and the reputation of the language would be seriously damaged. Rational expressed that this was unacceptable and more or less threatened to walk away from the UML 2 effort. Our two participants in the UML 2 committee were instructed to be very cautious with changes and to consult with a team of Rational experts before accepting any changes.

As you can understand this period was quite dramatic for anyone involved. There was a time when I believed I would have to publicly denounce UML 2. Fortunately, the UML committee came to their senses and I didn’t need to take such a dramatic step. Still, UML grew too much under the influence of a large committee. Today all UML fans suffer from this mistake.

However, at its roots UML is good. The basic techniques are proven as practical for many years. As an example, Ericsson could claim that it used UML already in 1969, because at that time we used component diagrams, sequence diagrams, collaboration diagrams, state charts and state transition diagrams (a combination of state charts and activity diagrams).

Thus on one hand UML has a sound base but on the other hand it has become too bulky. We know that with less than 20% of UML you can model more than 80% of all software systems. What we need to do is to extract these 20% that people need and define it precisely. We have started doing this and we call these 20% EssUML. EssUML is not a new language. It doesn’t even change UML. It is just a proper subset of UML.

EssUML is one more thing though. It presents UML in a way attractive to developers, quite unlike the UML 2 specification which intended audience is meta-modellers and tool builders. To achieve this we use a similar technique as when presenting EssUP. Every language element is represented by a card or a set of cards, and its description is usage centric (or use-case centric).

Now you may ask yourself, what are those 80% that we don’t need in the UML? In this case the expression “the devil is in details” could not be truer. The UML elements and their graphical representation in diagrams are simply overloaded with too many nice to haves that rarely are useful (or used). Essential UML is, as the name indicates, about extracting what is truly essential. What this exactly means in terms of diagram types and element types is a bit early to say but my personal opinion is that, e.g., Activity Diagrams (and all their associated element types and detail) do not qualify as essential. The experience is that it is not cost effective to develop and maintain this kind of diagram, especially if you also produce textual flow-of-events descriptions.

While they are not really defined as part of the language there is often (at least in tools) an artificial division into various types of structural diagrams, such as class diagrams, component diagrams, deployment diagrams, and package diagrams. I think this division often misleads people to believe that they need all these diagram types and that they are distinctly different from each other and that is of course not true. Anyway, going forward we will define this and also specifically what the 80% that we don’t need are. Every diagram and element type will eventually have a card describing its essentials, child elements, relationships and so on. In particular the card should focus on describing the use cases of the diagram/element.

As an example a card representing the component diagram (if we choose to have such a diagram type) could look like this:

Of course a card doesn’t contain enough information about the component diagram so we provide a guideline that goes a bit deeper. In most cases this is enough as developers will learn more as they use the diagram in practice.

The guideline is 2-4 pages and it describes the essential content of the diagram, its use cases, hints and tips and common mistakes. It also references the OMG specification and other UML books. However, in general developers don’t read much. There is a law of nature:

Law of Nature: People don’t read books

Over the years I have come to realize that even if people may buy books it does not necessarily mean that they read them. This is certainly true for manuals such as process manuals or language specifications. I believe we can get everyone in a team to read the cards. If we write really well we might get up to 25% of the developers to read the guidelines, but almost no one will read the books being referenced. Additionally we of course have to acknowledge that the Essential 20% varies a bit depending on the specific situation at hand, i.e., the underlying business reason for modelling in the first place can vary.

  • Are the diagrams/models key ingredients in driving the understanding and design as we go, or are they primarily useful as documentation to, e.g., the next project?
  • Is our intent to generate code for large parts of the system or do we model to simply illustrate key aspects of the system and its design?
  • What is the size, complexity and longevity of the product/project?

The answers to questions such as these will of course have an impact on the process we use and follow, the amount of documentation we produce, and of course how much and how detailed we model.

As you know, I am a strong believer in that intelligent agents is the most efficient way to capture and disseminate knowledge and that is of course applicable for practices as in EssUP as well as for technological underpinnings like EssUML. I strongly believe in having intelligent agents to provide context-sensitive advice and training on line. They can help you by performing mundane tasks, recognize design patterns that you may want to apply, review your work, etc. These are some of the things that WayPointer can help you with.

My keynote in Tokyo was very well received. I was invited to come back to this exciting city and I will be back real soon. It was five years since I was here the last time. As it looks like now I will be back almost every month. This is wonderful and I really look forward to it.