UML Reference Card

Allen I. Holub

Allen I. Holub & Associates
P.O. Box 5769
Berkeley, CA 94705

510/528-2166 (java-1-oo)

Ver. 1.6 (9/12/1999) — ©1999 Allen I. Holub. All rights reserved.
This page was downloaded from Allen Holub & Associates home page, Allen offers a complete Java and OO-design training program and OO-design mentoring services. The web site contains course descriptions and other Java and OO-related goodies.

Static-Model Diagrams

Comments. Any kind of information that isn't easily representable in UML, including comments, implementation-level code, etc. Also used for a long constraint.
Design Patterns
  • Erich Gamma's notation for design patterns, as presented in John Vlissides' book Pattern Hatching (Reading: Addison Wesley, 1998).
  • The Pattern name is on the left, the role the class has within the pattern on the right. A single class can have different roles with respect to several patterns. In the bottom example, the class serves as both the "Concrete Observer" in the "Observer" pattern and also the "Real Subject" in the "Proxy" pattern.
  • C++ namespace.
  • Group together functionally-similar classes.
  • Derived classes need not be in the same package.
  • Packages can nest. Outer packages sometimes called domains. ("Tools," at left, is arguably an outer package, not a domain).
  • Package name is part of the class name. (e.g. given the class fred in the flintstone package, the fully-qualified class name is flintstone.fred).
  • Generally needed when entire static-model won't fit on one sheet.
Classes. Box contains three compartments:
  1. The name compartment (required) contains the class name and other documentation-related information: E.g.:
    Some_class «abstract»
    { author:      George Jetson
      modified:    10/6/2999
      checked_out: y
    •  Guillemets identify stereotypes. E.g.: «utility», «abstract» «JavaBean». Can use graphic instead of word.
    •  Access privileges (see below) can precede name
    •  Inner (nested) classes identify outer class as prefix of class name: (Outer.Inner or Outer::Inner)
  2. The attributes compartment (optional):
    •  During Analysis: identify the attributes (i.e. defining characteristics) of the object.
    •  During Design: identify a relationship to a stock class:
    is a more compact (and less informative) version of this:

    Everything, here, is private. Always. Period.
  3. The operations compartment (optional) contains method definitions:
            message_name( arguments ): return_type
    or use implementation-language syntax. except for access privileges:

     +   public
     #   protected
     ~   package (my extension to UML)1
    •  Abstract operations (C++ virtual, Java non-final) indicated by italics (or underline).
    •  Boldface operation names are easier to read.
If attributes and operations are both omitted, a more-complete definition is assumed to be on another sheet.

1 Java, unfortunately, defaults to "package" access when no modifier is present. In my flavor of UML, a missing access privilege means "public." You could reasonable argue that "private" would be a better default, but most methods that appear in the class box are public.

Associations (relationships between classes).
Implementation Inheritance (Generalize/Specialize)

identifies derivation The derived class is the base class, but with additional (or modified) properties. Derived (sub) class is a specialization of (extends) the base (super) class. Variations include:

Interface Inheritance (Specifies/Refines).

A contract that specifies a set of methods that must be implemented by the derived class. In C++, an interface is a class containing nothing but pure virtual methods. Java supports them directly. (c.f.. "abstract class," which can contain method and field definitions in addition to the abstract declarations.)

Interfaces contain no attributes, so the "attributes" compartment is always empty.

The "inheritance" relationship line is dashed if the base class is an interface.

My extensions to UML:

  • Rounded corners identify interfaces. Since rounded corners are often difficult to draw by hand, I sometimes use the version at right for hand-drawn diagrams.

    Strict UML uses the «interface» stereotype in the name compartment of a standard class box:

  • If the full interface specification is in some other diagram, I use .
UML also permits Microsoft-style "pin" notation, but it's inconsistent with the rest of UML and I see little to recommend it:
Dependency. User uses Resource, but Resource is not a member of the User class. If Resource is modified, some method of User might need to be modified. Resource is typically a local variable or argument of some method in User.
Aggregation (comprises) relationship. Destroying the "whole" does not destroy the parts.
Composition (has) relationship. The parts are destroyed along with the "whole." Doesn't really exist in Java. In C++:
class Container
    Item item1;   // both of these are
    Item *item2;  // "composition"
    Container() { item2 = new Item; }
    ~Container(){ delete item2;     }
Navigability Messages flow in direction of arrow (only). Implicit when no role present: if an object doesn't have a role in some relationship, then there's no way to send messages to it.
Constraint A constrained relationship requires some rule to be applied. (e.g. {ordered})

Often combined with aggregation, composition, etc.

Complex Constraint
  • In the case of the or, only one of the indicated relationships will exist at any given moment (a C++ union).
  • Subset does the obvious.
  • In official UML, put arbitrary constraints that affect more than one relationship in a "comment" box, as shown. I usually leave out the box.
Qualified Association (hash-table, associative array, "dictionary").
class User
{   // A Hashtable is an associative array, indexed
    // by some key and containing some value.

    private Hashtable bag = new HashTable();

    private void add(String key, Item value)
    {   bag.put( key, value );
Association Class
  • Use when a class is required to define a relationship.
  • Somewhere, an additional relationship is required to show ownership. (The one between Person and Ticket in the current example.)

Dynamic-Model Diagrams

New Style (UML):

Old Style (Booch):
Objects and Messages
  • Vertical lines represent objects, not classes.
    • May optionally add a ":class" to the box if it makes the diagram more readable.
  • represents synchronous message. (message handler doesn't return until done).
  • represents return. (Label arrow with name/type of returned object.)
  • Sending object's class must have:
    1. A association of some sort with receiving-object's class.
    2. The receiver-side class's "role" must be the same as the name of the receiving object.

  • Booch style identical to UML in function, but much easier to read. Compare: to

    (Booch-style "return" implied by bottom of box, no need for on methods that don't return values. identifies returned object.)

  • Return arrows are essential in UML style, otherwise control flow is ambiguous. In above diagram, it's unclear whether message2 or message4 returns returned_obj when unlabeled returns are omitted.
  • When drawing by hand, I use a solid line and put the activiation boxes at the side of the line, as is shown at right.
Object Creation
  • Name box appears at point of creation.
  • «creates» form for automatic creation, e.g.. in C++:
        class Creator1
        {   Object1 the_object; // the actual object, not a reference.
    (There is no equivalent operation in Java)
  • If message shown instead of «creates», then the message handler creates the object. Think of new Fred() as Method does not have to be new().
Conditions, Loops, Grouping
  • Message sent only if condition in brackets is true.
  • An asterisk next to the condition signifies iteration.
  • An asterisk without a condition means "every," when receiver is an aggregate.
  • The heavy line used to group together the messages that are affected by some condition is my own extension to UML.
  • The box at the bottom of the diagram is UML's Grouping notation (awkward when you try to group all indirect messages). A * indicates a loop, omit for an "if."
Loops, Alternative (My own extension to UML.)
  • Don't think loops, think what the loop is accomplishing.
  • Typically, you need to send some set of messages to every element in some collection. Do this with every.
  • You can get more elaborate: "every receiver where x<y".
  • The diagram at left comes from this model:
    and maps to the following code:
    class sender_class
    {   receiver_class receiver[n];
        public do_it()
        {   for( int i = 0; i < n; ++i )
Asynchronous Messages
  • Half arrowhead means "asynchronous." (see table, below).
  • Widening of line means "activated" (thread is running). (In diagram to left, sender thread sends message() and then suspends itself waiting for the reply().)
  • Break in box (on "receiver" in diagram to left) means other activity is happening on the thread that isn't relevant in the current scenario. (E.g. Sender could wait() after sending message. reply() message executes notify().)
  • Large X means object deleted (in this case, it's self deleting). An external kill is represented as:
Callbacks, Recursion
  • The callback() message is running on the "receiver" object's thread.
  • Callback() is, however a member of the "sender" object's class, so has access to all the fields of the object.
  • Since the original "sender" thread is also running, any fields accessed by callback must be "synchronized."

Arrow Heads for Asynchronous Messages

Symbol Message
Simple Don't care how it's handled. Usually asynchronous.
Synchronous The sender effectively blocks until the handler completes. This is a normal function call in a single-threaded application.
Asynchronous The handler returns immediately, but the actual work is done in the background and the sender can move on to other tasks while processing goes on.
Balking The receiving object can refuse to accept the message request. This could happen if an "active" object's message queue fills, for example.
Timeout The message handler typically blocks, but will return after a predetermined amount of time, even if the work of the handler is not complete.

Activity Diagrams

Starting and Stopping.
Synchronization. When several activities can go on in parallel, indicates when all activities must be finished in order to continue.
Guards (tests). This path is used only if the text in the brackets is true.
Decision. A decision activity, the guard labels the decision that was made.
Swim Lanes. Activities are arranged into vertical zones delimited with dashed lines. Each zone represents the responsibilities of a particular class or actor.

What's Missing

A Few Examples:

Activity Diagrams

Static-Model Diagram

Sequence Diagram