• 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.

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: This: 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
   –	private
   ~	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.

¹ 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.

• Associated classes are connected by lines.
• The relationship is identified, if necessary, with a < or > to indicate direction (or use solid arrowheads).
• The role that a class plays in the relationship is identified on that class's side of the line.
• Stereotypes (like «friend») are appropriate.
• Unidirectional message flow can be indicated by an arrow (but is implicit in situations where there is only one role):
• Cardinality:

  1	(usually omitted if 1:1)
  n	(unknown at compile time, but bound)
  0..1	(1..2   1..n)
  1..*	(1 or more)
  *	(0 or more)

• Example:

  class Company
  {   private Person[] employee = new Person[n];
      public void give_me_a_raise( Person employee )
      {   /*...*/
      }
      public void please_hire_me( Person prospect )
      {   /*...*/
      }
  }
  
  class Person
  {   private String  name;
      private Company employer;
      private Person  boss;
      private Vector  flunkies = new Vector();
      public  void    you_re_fired(){/*...*/}
  }
  

  (A Java Vector is a variable-length array. In this case it will hold Person objects.)

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:

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 .

class Container
{
    Item item1;   // both of these are
    Item *item2;  // "composition"
public:
    Container() { item2 = new Item; }
    ~Container(){ delete item2;     }
}

Often combined with aggregation, composition, etc.

• 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.

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 );
    }
}
    

• 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.)

• 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.

• 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 Fred.new(). Method does not have to be new().

• 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."

• 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 )
              receiver[i].message();
      }
  }
  

• 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:

• 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."