Unified Modeling Lan guage Aids Application Quality

Graphical notation helps you visualize complex code

he following article is excerpted from UML Distilled-Applying The Standard Object Modeling Language by Martin Fowler with Kendall Scott, (Addison-Wesley Longman Inc., 1997).

The Unified Modeling Language is the successor to the wave of object-oriented analysis and design methods that appeared in the late '80s and early '90s. It most directly unifies the methods of Grady Booch, James Rumbaugh, and Ivar Jacobson, but its reach will be wider than that. As I write this, the UML is in the middle of a standardization process with the Object Management Group, and I expect it to be the standard modeling language in the future.

The UML is called a modeling languag e, 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 Booch, Rumbaugh, and Jacobson's advice on what steps to take in creating a design.

The explanation of process in many methods books is 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's 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.

Booch, Rumbaugh, and Jacobson also are working on a unified process, which they are going to call Objectory. You don't have to use Objectory in order to use the UML-they are distinctly separate. Here, 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 Objectory, but the text is not a description of the Objectory process. I find that I use many different processes, depending on my client and on the kind of software I am building. While I think 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.

The UML defines a notation and a meta-model. The notation is the graphical stuff you see in models-the syntax of the modeling language. For instance, class diagram notation defines how items and concepts such as class, association, and multiplicity are represented. Of course, this leads to the question of what exactly is meant by an association or multiplicity or even a class. Common usage suggests some informal definitions, but many people want more rigor than that.

Design is all about seeing the key issues in the development. Formal methods often lead to getting bogged down in lots of minor details. Also, formal methods are hard to understand and manipulate.

Most object-oriented methods have very little rigor. Their notation appeals to intuition rather than formal definition. On the whole, this doesn't seem to have done much harm. These methods may be informal, but many people still find them useful-and it's usefulness that counts.

However, object-oriented methods people are looking for ways to improve the rigor of methods without sacrificing their usefulness. One way to do this is to define a meta-model: a diagram, usually a class diagram, that defines the notation.

How much does the meta-model affect the user of the modeling notation? It does help define what is a well-formed model-that is, one that is syntactically correct. As such, a methods power user should understand the meta-model. However, most users of methods don't need such deep understanding to get some value out of using the UML notation.

How strictly should you stick to the modeling language? That depends on the purpose for which you're using it. If you have a CASE (computer-aided software engineering) tool that generates code, then you have to stick to the CASE tool's interpretation of the modeling language in order to get acceptable code. If you're using the diagrams for communication purposes, then you have a little more leeway.

Language-Bending
If you stray from the official notation, then other developers will not fully understand what you are saying. However, there are times when the official notation can get in the way of your needs. I'll admit that in these cases, I'm not at all afraid to bend the language. I believe that the language should bend to help me communicate, rather than the other way around. But I don't do it often, and I'm always aware that a bend is a bad thing if it causes communication problems.

When it comes down to the bottom line, the real point of software development is cutting code. Diagrams are, after all, just pretty pictures. No user is going to thank you for pretty pictures. What a user wants is software that executes.

So when you are considering using the UML, it's important to ask yourself why you are doing it and how the UML will help you when it comes down to writing the code. There's no proper empirical evidence to prove that these techniques are good or bad, but the following subsections discuss the reasons that I often come across for using them.

A lot of people talk about the learning curve associated with object-oriented programming-the infamous paradigm shift. In some ways, the switch to object-oriented methods is easy. In other ways, there are a number of obstacles to working with objects, particularly in using them to their best advantage.

It's not that it's difficult to learn how to program in an object-oriented language. The problem is that it takes a while to learn to exp loit the advantages that object languages provide. Tom Hadfield puts it well: Object languages allow advantages but don't provide them. To use these advantages, you have to make the paradigm shift.

The techniques in the UML were to some degree designed to help people do good object development, but different techniques have different advantages.

One of the most valuable techniques for learning object-oriented methods is Class-Responsibility-Collaboration Cards, which are not part of the official UML but can and should be used with it. They were designed primarily for teaching people to work with objects. As such, they are deliberately different from traditional design techniques. Their emphasis on responsibilities and their lack of complex notation make them particularly valuable.

Interaction diagrams are very useful because they make the message structure very explicit and, thus, are useful for highlighting overcentralized designs, in which one object is doing all the work.

Class diagrams, us ed to illustrate class models, are both good and bad for learning objects. Class models are comfortably similar to data models. Many of the principles that make for a good data model also make for a good class model. The major problem in using class diagrams is that it's easy to develop a class model that is data-oriented rather than responsibility-oriented.

Patterns Matter
The concept of patterns has become vital to learning object-oriented programming because using patterns gets you to concentrate on good object-oriented designs and to learn by following an example. Once you've gotten the hang of some basic modeling techniques, it is time to start looking at patterns.

Another important technique is iterative development. This technique does not help you learn object-oriented programming in any direct way, but it's the key to exploiting object-oriented methods effectively. If you do iterative development from the start, then you will learn the right kind of process and begin to see why d esigners suggest doing things the way they do.

When you start using a technique, you tend to do it by the book. My recommendation is to begin with the simple notations that I talk about here, particularly with class diagrams. As you get comfortable, you can pick up the more advanced ideas as you need them. You may also find you wish to extend the method.

The UML has an extension mechanism that uses stereotypes. I talk about stereotypes only in the context of class diagrams, but you can use stereotypes with any diagram to extend its meaning. Just make sure you really understand what the construct means. Toward that end, I like to look at any construct from three perspectives: conceptual, specification, and implementation.

One of the biggest challenges in development is building the right system-one that meets users' needs at a reasonable cost. This is made more difficult because we, with our jargon, have to communicate with users, who have their own, more arcane, jargon. Achieving good communicati on, along with good understanding of the users' world, is the key to developing good software.

The technique to use in addressing this is use cases-snapshots of one aspect of your system. The sum of all use cases is the external picture of your system, which goes a long way toward explaining what the system will do.

A good collection of use cases is central to understanding what your users want. Use cases also present a good vehicle for project planning, because they control iterative development-which is itself a valuable technique, since it gives regular feedback to the users about where the software is going.

Package diagrams (see diagram) give team members an overview of classes and their relationships. These design techniques are invaluable for providing a graphical view of complex object systems.

Back to News in Review

Send Us Your Feedback

Top of the Page