12.2 Introducing the Unified Modeling Language

Introducing the Unified Modeling Language

It's necessary to analyze and model applications before starting the actual implementation for an obvious reason: Modern applications are simply too complex to start implementing them out of the blue. You have to collect requirements, analyze the problem, come up with an attack plan, and finally implement the solution.

Most programmers are concerned with only the last step: implementation. Many different tools and languages, including Visual FoxPro, are available to implement solutions. Choosing an analysis tool is rather simple. It can be a word processor or even a simple sheet of paper. Choices become more complex when it comes to modeling tools, which help to create the "attack plan." Many different modeling methods and tools have been created, each of which has been treated almost religiously. However, differences in notation, methodology and processes among these modeling languages have made it difficult for programmers to arrive at a common standard for designing solutions.

Some modeling history

In the beginning, the three most popular modeling methods were OMT (Rumbaugh), Booch (yes, the method and the man are the same) and OOSE (Jacobson). Each method had different strengths and weaknesses. OMT was powerful for design but weak for analysis. Jacobson's notation was strong in the analysis phase but didn't work as well for design. Over time, the creator of each notation looked over the fence and added strengths of other methods to his own. The methodologies started to converge. However, differences in some notation details made it difficult to switch from one notation to the other. One notation used a small circle to indicate aggregation, while another used the same symbol for multiplicity. This was extremely confusing.

This was the time when so-called notation war began. Looking back, the issues were rather trivial. Was it better to represent a class using a cloud or a rectangle? What was the right symbol for inheritance? I personally couldn't care less. These questions can never be answered because they are based on personal opinions and preferences. However, the need for a uniform way of drawing these items was rather pressing.

The creation of the Unified Modeling Language (UML) brought an end to the notation war. The first draft (version 0.8) was introduced in October 1995 and was created mostly by Grady Booch and James Rumbaugh. For the next version, the public's input was added to the notation as well as the experiences of Ivar Jacobson, who became the "third father" of UML. This version was released in July 1996 (version 0.9) and the next in October 1996 (version 0.91). Version 1.0 was presented to the Object Management Group (OMG) for standardization in July 1997.

To serve everyone's needs, version 1.1 was introduced in September 1997. This version included input from many other well-known object people such as "the Gang of Four" (patterns), Odell (classifications), Shlaer-Mellor (object life cycles), Embly (singleton classes), Fusion (operation descriptions and message numbering), Wirfs-Brock (responsibilities), Harel (state charts), Mayer (pre- and post-conditions), and others.

The ideas behind UML

UML aimed to take the best parts of each existing notation and combine them into one widely accepted and more powerful standard. In addition, the biggest problem, the difference in notations, was resolved elegantly. Everyone had a chance to give their own input and address their own concerns.

UML is a modeling language, not a method. Most methods consist of both a modeling language and a process. The language is the (mostly graphical) notation that the method uses to draw diagrams or describe a model in other ways. The process is the guideline for doing a design and getting to the diagrams (or other parts of the language).

We can compare the situation to Visual FoxPro, which should clarify the topic, since this is a more familiar world to most of us. The language would be the Visual FoxPro syntax. The process would be certain wizards (like the Application Wizard), builders, or just general steps that help to achieve the goals.

Usually, the description of the modeling process is rather sloppy. Also, I found that most people (including myself) who say they use a method really only use the language and rarely ever follow the process. In fact, I purposely don't follow the process. I think most processes are great, but I usually do things a little differently when I discover that the process doesn't entirely match my needs. I'll compare this to Visual FoxPro one more time: The Application Wizard is a great tool to create applications quickly. However, I still use my own framework, which matches my needs a lot better than the code created by the Application Wizard.

When talking about object design, it's not important to understand the process used to create the design. It is important, though, to understand the notation. Every process can only be a suggestion. Most of those suggestions are good, and you should familiarize yourself with them to get more out of object modeling. But do not treat these processes religiously.

UML does not have a standardized process. However, the "Three Amigos" (Booch, Jacobson and Rumbaugh) are also working on a unified process called Objectory. UML and Objectory don't depend on each other but they do work well together. I suggest taking a look at Objectory as soon as the Three Amigos publish their book, The Objectory Software Development Process.

UML tools

Many tools are available to help create UML models. Compare this to the fact that there are several different tools (compilers) available to implement certain programming languages, like C++. I personally prefer to use Rational Software's Rational Rose.

The Three Amigos work for Rational Software, so they have a very good idea what UML is about. It seems that Rational plays the same role in the object-modeling world that Microsoft plays in the software business. Both companies work together quite closely. Rational even licensed a special version of Rose, called the Visual Modeler, to Microsoft. This is a "light" version of Rose that is optimized for Visual Basic programmers. Unfortunately, Visual Modeler can't handle the entire UML specification.

Both tools are integrated tightly into Visual FoxPro through the Visual FoxPro Modeling Wizards, which I'll discuss in Chapters 16 and 17.

All diagrams used in this book were created using Rational Rose.