Allen Holub's UML Reference Card
Allen Holub's UML Reference Card
Allen Holub's UML Reference Card
1 of 15
http://www.holub.com/goodies/uml/
UML
Java com
Java To
Java 1.5
Miscellany
Comments. Any kind of information that isn't easily representable in UML, including comments,
implementation-level code, etc. Also used for a long constraint. This symbol is used in all of the UML
diagrams.
Organizational Diagrams
8/14/2013 4:46 PM
2 of 15
http://www.holub.com/goodies/uml/
Packages
Group together functionally-similar classes.
Same as C++ namespace.
identifies derivation. Classes/interfaces in "base" package are extended/implemented
in "derived" package, etc. Derived classes need not be in the same package as base class,
however.
represents a dependency, typically stereotyped (import, access, etc.).
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.
Packages can nest. Outermost packages called domains if they contain only subpackages
(no classes). (The tools package at left is an outer package; the
com.holub package is a domain.) Nested packages can also be
shown using a tree structure and static-model nested-class
symbol (shown at right).
Subsystems. A subsystem is a cooperating set of runtime objects that form a cohesive group.
(Packages are made up of classes, not objects. They are not the same as subsystems.) A
subsystem presents a standard set of interfaces to the outside world, and all access to the
objects that comprise the subsystem should be through these interfaces. If you access the
subsystem via a single object whose primary responsibility is to implement an access
interface(s), that object is called a port.
Packages are compile-time things, subsystems are run-time things. Don't confuse them the
similar notation is unfortunate. The classes that comprise the subsystem are often contained in a
single package, but need not be. (The classes that define objects in the JDBC subsystem are
defined in the java.sql package. I've shown relationship at left, but that's not standard UML.)
symbol, which can be placed in the tab or body of the
Subsystems are identified as such by a
box.
The diagram at left shows both the standard and ball-and-socket-style interface notations. UML
also lets you put into the box a static-model diagram showing the classes that comprise the
subsystem. I've found that level of detail to be unnecessary in practice, so have not shown it.
Use-Case Diagram
Specifies participants in a use case and the relationships between use cases.
The stick-figure represents a role taken on by some actor (sometimes called
simply "actor," but it's really a role).
A line connects the actor/role to the use case in which it participates. You may
use cardinality. (A Salesperson places many orders.)
An is-specialization-of/generalizes relationship between actor/roles (denoted by
) indicates additional responsibilities. (A Supervisor has all the
responsibilities of a Salesperson, but can also establish credit. A Supervisor can
create an account, for example.)
Dotted lines denote use-case dependencies. Common dependencies are:
equivalent Equivalent use cases have identical activities and identical flow,
but end users think of them as different. ("Deposit" and
"Withdrawal" might have identical activities, though the objects
involved might be different.)
extends
When extension extends base, all the activities of the base use
case are also performed in the extension use case, but the
extension use case adds additional activities to or slightly
modifies existing activities ofthe base use case. (To place a
recurring order, you must perform all the activities of placing an
order plus set up the recurrence.)
If a set of activities occur in several use cases, it's reasonable to
"normalize" these common activities out into a base use case, and
then extend it as necessary.
Holub Extension: This relationship is really a form of derivation, so
I use the derivation arrow (
) instead of a dashed line. As in a
class diagram, the arrow points from the extension to the base use
case.
8/14/2013 4:46 PM
3 of 15
http://www.holub.com/goodies/uml/
includes
requires
follows
resembles
Two use cases are very similar, but do have different activities.
Guards (tests). This path is used only if the text in the brackets is true.
8/14/2013 4:46 PM
4 of 15
http://www.holub.com/goodies/uml/
Decision (Branch/Merge). A decision activity, the guard labels the decision that was
made. The diamond with outgoing arrows (the branch) specifies an OR operation, with a
condition imposed by the guard. The diamond with incoming arrows (a merge) simply
provides an end to the OR operation. A merge can occur without an associated branch if
the diagram has multiple start states.
Signals (Events).
Generating signals: sent to outside process (Request Payment at left).
Accepting signals: received from outside process (Payment Received at left).
Timer signals: received when time elapses or a set time arrives (30 days... at left).
Exceptions. Extraordinary errors that you typically don't detect with explicit tests are
indicated with a "lightning bolt."
Object Flow. Identifies objects that are created by activities (box with outgoing arrow)
or used by activities (box with incoming arrow).
In the example at left, The invoice object is created during the receive-invoice activity
and used by the process-invoice activity. The check object is created in the cut-check
activity and is used by the send-payment activity. In this second case, you can also put
boxes at both ends of the line.
You can indicate exactly how the object is used with a constraint. (e.g. {create},
{store}, etc.)
Swim Lanes. Activities are arranged into vertical or horizontal zones delimited with
lines. Each zone represents a broad area of responsibility, typically implemented by a
set of classes or objects. For example, the swim lane labeled accounting could represent
objects of several classes (Bookkeeper, Clerk, MailRoom, Accountant) working in
concert to perform the single "cut paycheck" activity.
UML 2.x (bottom diagram at left) uses solid rather than dashed lines, and permits both
horizontal and vertical (or both) delimitation. The upper left quadrant in the diagram at
left represents accounting activities that happen in Paris.
8/14/2013 4:46 PM
5 of 15
http://www.holub.com/goodies/uml/
8/14/2013 4:46 PM
6 of 15
http://www.holub.com/goodies/uml/
public
protected
package2
--
private
8/14/2013 4:46 PM
7 of 15
http://www.holub.com/goodies/uml/
Example:
class Company
{ private Person[] employee=new Person[n];
public void give_me_a_raise(
Person employee)
{ /*...*/
}
public void hire_me( Person prospect )
{ /*...*/
}
}
class Person
{
private String
private Company
private Person
private Vector
public void
}
name;
employer;
boss;
flunkies=new Vector();
you_re_fired(){...}
(A Java Vector is a variable-length array. In this case it will hold Person objects.)
Implementation Inheritance (Generalize/Specialize)
identifies implementation inheritance (extends in Java) The base class is a
concrete class, with data or methods defined in it, as compared to an interface, which
is purely abstract (in C++, a class made of nothing but pure virtual methods). The
derived class is the base class, but with additional or modified properties. The derived
(sub) class is a specialization of the base (super) class. Variations include:
8/14/2013 4:46 PM
8 of 15
http://www.holub.com/goodies/uml/
Dependency. User uses Resource, but Resource is not a member of (field in) 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. The line is
typically stereotyped (e.g. creates modifies)
Aggregation (comprises) relationship relationship.1 Destroying the "whole" does not
destroy the parts.
Composition (has) relationship.1 The parts are destroyed along with the "whole."
Doesn't really exist in Java. In C++:
class Container
{
Item item1;
Item *item2;
public:
Container() {
~Container(){
}
8/14/2013 4:46 PM
9 of 15
http://www.holub.com/goodies/uml/
8/14/2013 4:46 PM
10 of 15
http://www.holub.com/goodies/uml/
Sequence Diagram
Without Activations:
With Activations:
8/14/2013 4:46 PM
11 of 15
http://www.holub.com/goodies/uml/
to
Data "Tadpoles"
Data "tadpoles" are often more readable than return arrows or message arguments. At
left, the entryClerk object sends the shippingDock an object called order. The
shippingDock returns the shippingReceipt object.
Object Creation
Name box appears at point of creation.
creates form for automatic creation. In C++: An object (not a reference to one) is
declared as a field in a class. The closest Java equivalent is an object created by
instance-variable initialization:
class X
{ private Cls o = new Cls();
//...
}
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().
Conditions, Branches, Loops, Grouping
1. message1() is sent only if the condition specified in the guard (in brackets) is true.
2. A branch. Sender sends either message2() or message3(). Guards should be
exclusive. I use else instead of a guard when appropriate.
3. Iteration. Sender sends message4() as long as the condition is true.
4. "For each." If the receiver is a collection of objects (indicated by the cardinality of
the associated role in the static model), send the message to all of them.
5. UML 2.0 Interaction Frame. As shown, condition specifies a loop. Can also use:
loop
A loop, executes multiple times
opt
Optional. An "if" statement.
region A named region.
ref
A reference to a named region (elsewhere in diagram or on another
diagram):
8/14/2013 4:46 PM
12 of 15
http://www.holub.com/goodies/uml/
8/14/2013 4:46 PM
13 of 15
http://www.holub.com/goodies/uml/
Message Arrowheads
Symbol Message
Description
Type
Asynchronous The handler returns immediately, but the actual work is done in the background. The sender can move on
to other tasks while processing goes on.
Synchronous The sender waits until the handler completes (blocks). This is a normal method call in a single-threaded
application.
Asynchronous Obsolete (UML version 1.3 or earlier.)
Balking
The receiving object can refuse to accept the message request. This could happen if an "active" object's
message queue fills, for example. Not part of "core" UML.
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. Not part of "core" UML.
8/14/2013 4:46 PM
14 of 15
http://www.holub.com/goodies/uml/
Method parameter.
local name
Local variable.
name {new}
name {destroyed}
name {transient}
Usually, the instance name (or reference through which the instance is accessed) is
the same as the role the instance plays in the collaboration. When the name and role
aren't identical, use instance/role:Class. E.g.: given tutor/teacher:Person and
lecturer/teacher:Person, an object of class Person, used in the role of teacher,
is called tutor in some portion of the code and lecturer elsewhere in the code.
Messages that flow from one object to another are drawn next to the line, with an
arrow indicating direction. Arrowhead types have the same meaning as in sequence
diagrams. The message sequence is shown via a numbering scheme. Message 1 is
sent first. Messages 1.1, 1.2, etc., are sent by whatever method handles message 1.
Messages 1.1.1, 1.1.2, etc., are set by the method that handles message 1.1, and so
forth. Message sequence in the current example is:
1.
1.1
1.1.1
1.1.2
1.1.2.1
1.1.2.2
1.1.3
2.
2.1
2.2
2.2.1
2.2.2
3.
Guards are specified using the "Object Constraint Language," a pseudo-code that's
part of the UML specification. Syntactically, it's more like Pascal and Ada than Java
and C++, but it's readable enough. (The operators that will trip you up are
assignment [:=] equality [=] and not-equals [<>]). As in a sequence diagram, an
asterisk indicates iteration.
Nomeclature
There are three broad categories of diagrams.
Structure Diagrams
include class diagrams, deployment diagrams, etc.
Behavior Diagrams
include activity, use-case, and state diagrams.
Interaction Diagrams (are a subclass of Behavior Diagrams)
8/14/2013 4:46 PM
15 of 15
http://www.holub.com/goodies/uml/
What's Missing
A few parts of UML aren't shown here. (Some of these are useful, I just haven't gotten around to adding them yet.)
State-Diagram Symbols. There are a few symbols used in state diagrams that aren't shown in the earlier
Activity/State-Diagram section.
Deployment diagrams. Show how large modules in the system hook up. Useful primarily for marketing
presentations, executive summaries, and pointy-haired bosses.
Parameterized Classes. C++ templates/Java generics.
N-ary Associations. are better done with classes. Don't use them.
Component Diagrams. The only difference between a component and a subsystem is size. Component
diagrams are almost identical to subsystem diagrams.
Activity Realization Diagram. is an activity diagram redrawn to look more like a collaboration-diagram.
Refer to the UML Superstructure document for more details.
Footnotes
(1) Composition vs. Aggregation:
Neither "aggregation" nor "composition" really have direct analogs in many languages (Java, for example).
An "aggregate" represents a whole that comprises various parts; so, a Committee is an aggregate of its Members. A
Meeting is an aggregate of an Agenda, a Room, and the Attendees. At implementation time, this relationship is not
containment. (A meeting does not contain a room.) Similarly, the parts of the aggregate might be doing other things
elsewhere in the program, so they might be referenced by several objects. In other words, There's no
implementation-level difference between aggregation and a simple "uses" relationship (an "association" line with no
diamonds on it at all). In both cases an object has references to other objects. Though there's no implementation
difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the
domain model better, and because there are subtle implementation issues. I might allow tighter coupling
relationships in an aggregation than I would with a simple "uses," for example.
Composition involves even tighter coupling than aggregation, and definitely involves containment. The basic
requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the
"elements"), then the elements will come into existence and also be destroyed as a side effect of creating or
destroying the container. It would be rare for a element not to be declared as private. An example might be an
Customer's name and address. A Customer without a name or address is a worthless thing. By the same token, when
the Customer is destroyed, there's no point in keeping the name and address around. (Compare this situation with
aggregation, where destroying the Committee should not cause the members to be destroyed---they may be
members of other Committees).
In terms of implementation, the elements in a composition relationship are typically created by the constructor or an
initializer in a field declaration, but Java doesn't have a destructor, so there's no way to guarantee that the elements
are destroyed along with the container. In C++, the element would be an object (not a reference or pointer) that's
declared as a field in another object, so creation and destruction of the element would be automatic. Java has no
such mechanism. It's nonetheless important to specify a containment relationship in the UML, because this
relationship tells the implementation/testing folks that your intent is for the element to become garbage collectible
(i.e. there should be no references to it) when the container is destroyed).
Allen I. Holub & Associates
Berkeley, California
510.528.3620
2011 Allen I. Holub ( www.holub.com ). All Rights Reserved.
8/14/2013 4:46 PM