Writing code--whether it is Java, SQL, C++, or any other computer language--is all about communication. Via the computer language, you are communicating to the computer exactly what you would like done. We use computer languages because English and other human languages are inherently ambiguous. This type of ambiguity is known as structural ambiguity, the classic example of which is "I saw the man with the telescope." This statement could mean either I used a telescope to look at a man or the man that I was looking at had a telescope.

People who design computer languages use a system of rules known as Formal Language Theory to mathematically prove that their languages are unambiguous. After all, if you are writing a computer program for anything from a banking account system to a missile guidance system, ambiguities can be disastrous. We humans think and communicate using abstractions and actually deal rather well with most ambiguities. In most cases, the key to the success of a project is not the communication between the programmer and the machine, but rather the communication between team members. Computer languages are not generally well-suited for this because they are very concrete in nature. Although computer languages may contain an abstraction mechanism, such as objects, their level of abstraction is limited. Abstractions help us in three ways. First, abstractions are a way of hiding the details, which allows you to just focus on what is important. So when you design a system, you can concentrate on the concepts and leave the details to the implementation. Second, because we don't have to worry about details, abstractions can be used to communicate our designs to other people. Imagine how impossibly tedious it would be to explain how an entire system worked using just code. By the time you had finished your explanation, you would have written the entire system. The third way abstractions help us is by documenting what we have done. In most cases, documentation is used to communicate with other people, but it can also be very useful for helping you remember what you did.

UML Is Our Language of Communication

So we know we want to communicate using abstractions, but how do we do it? In order to do this, we need a common language. That language is UML. UML is different from what most people think of as being a language. UML is a modeling language, and rather than being constructed of words and letters, it is very graphical in nature. A lot of people struggle with the concept of a language that is graphical in nature. Just think of a language as a structured form of communication. Given this premise, a graphical language is not only just another type of language, but also a highly efficient one. Everyone who works with software uses diagrams of one type or another. When you diagram, one fundamental truth becomes immediately apparent. No one type of diagram can adequately represent a software system. The designers of UML were acutely aware of this and came up with nine types of diagrams to help you model your systems:

1. Class diagrams
2. Object diagrams
3. Use case diagrams
4. Sequence diagrams
5. Collaboration diagrams
6. Statechart diagrams
7. Activity diagrams
8. Component diagrams
9. Deployment diagrams

Class Diagrams

Class diagrams are probably the most common type of diagram, and even people who don't know they are using UML create class diagrams. Class diagrams, as the name suggests, show classes and the relationships between them. Classes are represented by a box separated into three horizontal sections. The top section contains the class name; the middle section lists all attributes and their types; and the bottom section lists class operations, including their name, parameters, parameter types, and the operation's return type if any. In addition, each attribute and operation is prefixed with a symbol to denote its access modifier: a plus sign (+) for public, a pound sign (#) for protected, and a minus sign (-) for private.

Class diagrams may also contain interfaces. Interfaces are represented the same way as classes, except the class name is rendered in italics.

Relationships in UML terms are called generalizations, aggregations, and dependencies. Generalizations are inherited relationships; a parent class is a generalization of its child class. Generalizations are noted through the use of an arrow with a triangular head which points to the parent class. These are also commonly known as is a relationships, as in "the child class is a type of parent class." Aggregations are composite relationships; an aggregate class is composed of one or more component classes. This is also sometimes referred to as a whole-and-part relationship or a has a relationship, as in "the aggregate has a component." Aggregations in UML are denoted by a line connecting the two classes with a diamond at the end of the line connecting to the aggregated class. Cardinalities are also often used to show how many of a component may be included in the aggregate. Dependencies show the usage of one class by another. Dependencies are represented by a dashed line with a V-shaped arrow head pointing from the class doing the using to the class being used. Below is a sample class diagram that illustrates each of the items discussed above.



(Click images to enlarge.)

This diagram has six classes: DVDPlayer, Television, DVDPlayerRemoteControl, Housing, Button, and Screen. It also has one interface called ElectronicDevice. The interface ElectronicDevice is a generalization for both DVDPlayer and Television. In other words, both DVDPlayer and Television inherit the ElectronicDevice interface and must therefore implement it. The class DVDPlayer has seven public operations. It must implement two--powerOn() and powerOff()--because it inherits them from ElectronicDevice. The other five--play(), pause(), fastForward(), fastReverse(), and stop()--are its core functionality. DVDplayer also has one private attribute called counter, which is used to internally store where in the movie the DVDPlayer is currently playing. Note the '-' prefix denoting that it is a private attribute.

Television is an aggregate class composed of a Housing object, a Screen object, and an unspecified number of Button objects. We can tell this from the cardinalities, which also tell us that Housing, Button, and Screen objects cannot exist outside of Televisions.

This diagram also shows that DVDPlayerRemoteControl depends on DVDPlayer. In other words, we are going to use DVDPlayerRemoteControl to control our DVDPlayer.

Although UML does not specify a color scheme, I have used one here to differentiate between classes and interfaces. I recommend this as a best practice for all UML writers.

Class diagrams by their very nature model the static structure of a system. This static nature makes them easy for tools to reverse engineer. In fact, one of the first things that I do when faced with a system that I haven't seen before is to reverse engineer all or part of it into a class diagram.

Object Diagrams

Object diagrams are similar to class diagrams except that they show the relationship between objects rather than classes, and they show this relationship at a specific instance in time. In general, I haven't found object diagrams to be very helpful, and not all tools have built-in support for them, which can make generating and keeping them up to date tedious.

Use Case Diagrams

Use case diagrams can be used to model the behavior of a system and are often one of the first steps in designing a new system. Use case diagrams describe what the system will be doing without describing how it will be implemented. Use case diagrams introduce the concept of an actor, which is basically the user of the system, and the concept of a use case, which is a sequence of actions. Actors are represented by stick-figure people and use cases by circles containing text. Actors and use cases can have the same type of relationships as classes in class diagrams. So, for example, you can have one type of actor, like a user, be a generalization for a particular actor, like an administrator.

In addition, use case diagrams add two new types of relationships between use cases. The first type is the include relationship. It basically says that one use case includes another; in other words, for the use case to complete, it must complete all of its included use cases. It is most often used when you have use cases that are used by multiple other use cases. The second type of relationship is the extend relationship. Extend relationships between two use cases are how we control optional flows of control. The following is a simplified use case diagram for a user to watch a movie on a DVD player.



When reading use case diagrams, you always start with the actor. In this case, the actor is the Consumer who wishes to watch a DVD. However, to complete the Watch DVD use case, the three other use cases that it includes must also be completed. In addition, the consumer may choose trick play when watching the movie thus invoking the trick play use case. Trick play is when you pause, fast rewind, fast forward, or stop a movie. So if we wanted to do an even more detailed use case diagram, we could break down the trick play use case into multiple smaller use cases. In general, use cases can recursively break down into more and more detailed interactions, depending on the level of detail required.

Sequence Diagrams

Sequence diagrams show flow of control. In object-oriented programming, flow of control can often be hard to trace without a sequence diagram. They can be used to trace the flow of control in both synchronous and asynchronous environments. They can also be used to show object lifespan. The following sequence diagram implements the Watch DVD use case described in the previous section.



In this example, we have an instance of the Consumer actor calling operations on the myDVDPlayerRemoteControl instance of the DVDPlayerRemoteControl class, which is passing off the operations to the myDVDPlayer instance of DVDPlayer to handle.

Collaboration Diagrams

Collaboration diagrams are similar to sequence diagrams, but they look more like traditional flowcharts, except that they have a numbering scheme on the vertices to show the order in which things happen. I never use collaboration diagrams because sequence diagrams give me the same essential functionality in a more structured form. In addition, some tools will generate your code for you based on how you draw sequence diagrams, thus always keeping your model and implementation in lockstep.

Statechart Diagrams

Statechart diagrams are probably the most underutilized of UML diagrams. Often, we are exposed to them only in our academic endeavors as part of classes in compiler construction or finite automata theory. However, they can be very useful in everyday applications. Take for example the DVD player application that we have been using so far. If we assume that our DVD player acts like some VCRs in that it can only fast-forward and fast-reverse after first being stopped, we could create the following statechart diagram.



I have found statechart diagrams to be invaluable because they can be easily understood by both developers and customers. They often help sort out and document complex interactions. The statechart diagram above shows that the DVD player cannot transition from fast-forward to fast-rewind. If this was a desired behavior, it would be obvious to the customer that it had been left out and could be corrected early in the systems development.

Statechart diagrams scale well. The above diagram could easily have states added to it for scene selection, single frame advance, single frame reverse, 2x speed play, and 2x speed reverse. Trying to describe all the possible behaviors with text would lead to a combinatorial explosion and would be very susceptible to errors.

Activity Diagrams

Call it what you like, but an activity diagram is just the term that consultants use for flowcharts so that you have to pay them extra. After all, who would pay big bucks for a flowchart? Well...actually, I would. Activity diagrams are a crucial part of UML; they document the process that you go through to get something done in a system. However, since they follow a notation that most people are used to, I will not delve into an example here.

Component Diagrams and Deployment Diagrams

Component diagrams and deployment diagrams are types of physical diagrams. Component diagrams show dependencies between components. In Java systems, components generally map to packages, so component diagrams can be used to show dependencies between packages. On the other hand, deployment diagrams show dependencies between hardware and software, so deployment diagrams depict which hardware components the software components are deployed on and how the two interact.

Communicate Better Using UML

UML is a powerful language that lets developers communicate with one another and document their systems in ways that are more efficient than writing code and less ambiguous than speaking English. UML consists of nine types of diagrams. Class diagrams communicate the static structure of a system and are very helpful when reverse engineering. Object diagrams are similar to class diagrams, but they show the relationships between objects at runtime. Use case diagrams are excellent for communicating the desired behaviors of a system. Sequence diagrams show the flow of control in a system, which can be hard to follow otherwise in an object-oriented environment. Collaboration diagrams are another way of expressing flow of control, but they are less structured and therefore less useful. Statechart diagrams are the most underutilized UML diagram; they show the states an object can be in and how it can get into those states. Statecharts are often a good way for developers and customers to communicate. Activity diagrams are very similar to flow charts, but they should not be discounted. It is impossible to build a system without knowing the processes it is required to implement. Component diagrams and deployment diagrams are physical diagrams that communicate dependencies between software components and between software and hardware components. All the various types of UML diagrams complement one another and give us a powerful vocabulary with which to express our systems. UML is an expressive and comprehensive language for communicating abstractions, and it is important that we all strive for fluency.

Where to Go for More Info

For a quick overview of UML, the best book is UML Distilled by Martin Fowler. But if you have more time, the most comprehensive book is The Unified Modeling Language User Guide by Booch, Rumbaugh, and Jacobson. For Java programmers, I also recommend Java Modeling in Color with UML: Enterprise Components and Process by Peter Coad.

Michael J. Floyd is an Extreme Programmer and the Software Engineering Technical Lead for DivXNetworks. He is also a consultant for San Diego State University and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Michael J. Floyd is the Vice President of Engineering for DivX, Inc.

Also Read

Practical Java: Start Your Java Engine!

Practical Java: Making Java Work for You

Book Review: Java for RPG Programmers