UML Diagramming Guide 5.0
UML Diagramming Guide 5.0
A Supplementary Guide to
Pacestar UML Diagrammer 5.0
Pacestar UML Diagrammer
Version 5.0 for Windows
IMPORANT NOTICE:
Copyright © 2005 Pacestar Software. All rights reserved worldwide.
Information in this document is subject to change without notice. No part of this document may be
reproduced in any form or by any means - graphic, electronic, or mechanical - including photocopying,
recording, taping, or storage in any information retrieval system, for any purpose other than to aid a licensed
user directly in the usage of the software, or when authorized in writing by Pacestar Software.
Pacestar Software retains all ownership rights to this computer program and its documentation. The source
code is a confidential trade secret of Pacestar Software. You may not attempt to decipher or decompile the
program or develop source code for it, or knowingly allow others to do so. Making copies of the program
(except for archival purposes or as an essential step in the use of the program) is prohibited. The program and
its documentation may not be sublicensed and may not be transferred without the prior written consent of
Pacestar Software.
Pacestar Software PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. Pacestar Software may revise this publication from time to time without notice.
Every attempt has been made to assure that this manual provides the most current and accurate information
possible.
ACKNOWLEDGEMENTS:
All copyrights and trademarks mentioned herein belong to their respective owners. Pacestar Software is a
trademark of Pacestar Software. Windows is a registered trademark of Microsoft Corporation. Microsoft
Word is a registered trademark of Microsoft Corporation.
Table of Contents 1
TABLE OF CONTENTS
About This Guide ............................................................................................................ 9
Symbols and Conventions.........................................................................................................9
General Techniques ..................................................................................................... 11
General Style Usage Tables ...................................................................................................11
Keywords.................................................................................................................................11
Attachable Nodes ....................................................................................................................12
Attaching Attachable Nodes to Base Nodes .....................................................................13
Repositioning Attachable Nodes.......................................................................................13
Detaching Attachable Nodes from Base Nodes................................................................14
Comments ...............................................................................................................................15
Containers ...............................................................................................................................16
Frames ....................................................................................................................................17
Path Labels .............................................................................................................................18
In-line vs. Lateral Path Labels...........................................................................................18
Flow Labels .............................................................................................................................19
Off Center Path Connections ..................................................................................................19
Path Trees...............................................................................................................................20
Creating Path Trees..........................................................................................................21
Manipulating Path Trees ...................................................................................................21
Node Symbols Containing Internal Icons ................................................................................23
Extensions and Nonstandard Symbols ...................................................................................23
Miscellaneous Drawing ...........................................................................................................24
Activity Diagrams ......................................................................................................... 25
Sample Activity Diagram .........................................................................................................25
Activity Diagram Style Usage Tables ......................................................................................26
Forks and Joins .......................................................................................................................28
Object Flows and Object Flow States .....................................................................................28
Conditional Branches and Decisions.......................................................................................29
Pins .........................................................................................................................................29
Listbox Pins .............................................................................................................................31
Connectors ..............................................................................................................................32
Exception Parameters .............................................................................................................32
Interruptible Activity Regions...................................................................................................33
Class/Object Diagrams ................................................................................................ 35
Sample Class Diagram............................................................................................................35
Class/Object Diagram Style Usage Tables .............................................................................36
Associations ............................................................................................................................40
Association Navigability ....................................................................................................40
This UML Diagramming Guide is a companion to the Pacestar UML Diagrammer software.
Within this guide you will find techniques for developing and maintaining Unified Modeling
Language diagrams using the features, templates, and symbols contained in the software. It will
assume a basic understanding of the product and its diagramming features and terminology
documented in Pacestar UML Diagrammer User Guide. Both this guide and the main user guide
are duplicated in limited detail in online help modules accessible from within the software.
The version of Pacestar UML Diagrammer that accompanies this guide is based on UML 2.0 as
defined by OMG and published in the official specification, and taking into account some of the
more popular industry references. The notation we use for cross referencing the contributing
reference publications is noted below in Symbols and Conventions. Where conflicts,
discrepancies, or voids are apparent, we do our best to combine sources and weigh popular
acceptance and usefulness in determining how to support the notation and terminology. The
dynamic nature of UML and the abundance of tools and publications trying independently to pin
it down, results in constantly changing requirements. Consider this guide to be advisory and
certainly not authoritative in regard to the language notation. If any of the notation described
becomes obsolete or falls in disfavor with the industry, you can use the more generic capabilities
of the software to adapt.
How can I get the tool to something? Refer to the main User Guide
How can I diagram specific UML notation? Refer to this user guide
What is proper UML notation? Refer to OMG specification or leading references
Please note that neither our developers nor our technical writers claim to be experts of UML
usage. The descriptions, examples, and guidelines we provide are meant to be informative with
regard to the software, not necessarily representative of good (or even proper) UML usage.
Style UML
Appearance Description
Name(s) Construct(s)
Style UML
Appearance Description
Name(s) Construct(s)
Keywords
UML keywords are enclosed in guillemets (double angle brackets). These characters are not available
on most keyboards. To add them to text, type two consecutive single angle brackets “<<“or “>>”. The
software will automatically combine these into a single guillemet. To circumvent this behavior, type a
space between the two, then after typing the second one, go back and delete the space - just so long as
the two identical angle brackets are not typed consecutively.
Attachable Nodes
UML notation contains a wide variety of nodes that attach to other nodes in different ways. For
example, qualifiers attach to the outer edges of class nodes, ports attach to components, input and
output pins attach to actions, and so on.
Pacestar UML Diagrammer allows you to attach certain nodes to others so that they can be
manipulated together. In most cases, this relationship involves a base node and an attachable node
that will attach to the base node. A port, for instance is an example of an attachable node that can
be dragged to a component base node where it will snap into place and become attached to the
component. The inverse is not true. A component cannot be dragged to attach it to a port. Most
attachable node relationships have this sort of one-directional relationship with their base node. A
notable exception are lifelines and activations which can be attached to objects bidirectionally.
That is to say that objects can also be attached to activations or lifelines. The process of attaching
nodes to one another is designed to be intuitive for the most part and to reflect the way that you
would construct diagrams on paper.
NOTE: Some attachable nodes, notably the listbox pins and complex ports, have separate
vertical and horizontal configurations (different styles). These can only be attached to
the appropriate side in the way you might expect. The horizontal version of the symbol
can only attach to the top and bottom edges of the base node, and the vertical symbol
can only attach to the left and right sides.
For example, to reposition a port that is attached to a component, simply select only the port and
drag it until it snaps to an alternate location on the edge of the component. You can accomplish
this by dragging the port when nothing is selected as well. If you select the port, but do not select
the component, AND you select any other objects, the port will not move because the component
to which it is attached is not being moved. While this is usually expected, you might be surprised
to find that it also applies to other ports attached to the same component. If you attempt to drag
more than one attached node at a time (with the intent of repositioning both) neither will move.
Simply reposition one at a time instead.
NOTE: When duplicating (via CTRL-drag) an attached node, be sure to release the CTRL key
before dropping the copy. Otherwise, the copy will not snap into place. The CTRL
serves dual purposes, to create a duplicate, and to invoke freeform mode where the
object being manipulated will ignore everything else in the diagram (will not attach
when dropped for example).
Comments
You can add comments anywhere within a type of UML diagram using a Note symbol. There’s
nothing to prevent you from simply adding text annotations throughout your diagram for a similar
purpose, but UML prefers that comments be contained within Note symbols. An added advantage
is that you can use an Anchor path to attach a Note to a particular diagram element or direct it to
any area of a diagram.
Comments can be simple descriptions that annotate your diagrams, or they can be actual
components of diagrams such as constraints on classes or associations, or extension points in use
cases.
When you want to associate a comment with a region of a diagram rather than with a specific
diagram element, you can use an anchor that ends with an anchor point as shown. An anchor point
is a small circle that indicates that the comment is anchored to a position in a diagram rather than
to a node or path. By default, an anchor point appear on an anchor when the terminating end it
unattached to a path or node. You can create such an anchor by entering connect mode, choosing
the anchor style, clicking on the note, then double clicking where the anchor should end.
Containers
UML makes liberal use of containers, large outline shapes that group sections of diagrams.
NOTE: The term container comes from Pacestar UML Diagrammer rather than from UML and
represents a clear and prevalent concept throughout UML and other modeling diagram
notations.
Some containers such as frames and subject boundaries are specifically tasked for sectioning and
organizing a diagram. Others serve as enlarged representations of nodes such as states, classes,
components, and packages that are shown expanded in order to express internal implementation
or structural details. A superstate is typical of many UML containers.
An obvious way to create a container based on an existing node is to simply create a node
symbol, enlarge it, and add the internal diagram elements within. However, using the specialized
container style for the corresponding node offers many advantages:
z Containers are transparent so that you need not be concerned whether the internals are in front
of or behind the container.
z Containers are selectable only by clicking on their outline (or text area if one is present). This
makes it much easier to work on the encompassed diagram details without being concerned
about the container. For example you won’t accidentally select the container when you click
on what seems to be open space at the more detailed level.
z Most containers are configured to be created by a lasso method. Instead of stamping out a
fixed size initial shape, you click where you want the upper left hand corner of the container
and drag the mouse to establish its bounds, ideal for sectioning off a portion of a diagram.
z Containers have other minor properties that are designed for the convenience of their intended
purpose such as how they resize, snap to the grid, and support attachments and path
connections.
Containers are available from the Containers drop menu which is located within the Nodes drop
menu on the style bar on the left hand side of the screen.
Frames
Frames are a new type of container introduced in UML 2.0 that are used in UML diagrams to
show groupings and constructs that apply to portions of a diagram. You can draw a frame around
a portion of a diagram that includes any number of objects or even other frames.
Frames have specific uses within diagrams such as combined fragments in sequence diagrams but
they are available in all UML diagrams. One common use is to bound any diagram or diagram
fragment to identify the type of diagram, such as class, component, communication, sequence and
so on.
% Creating Frames
Create a frame by choosing its icon from the Containers submenu located within the Node Styles
drop-down menu in the style bar. Position it by clicking where you want the upper right corner
and dragging to define the size of the frame. Then switch to text mode and edit the description
text.
% Selecting Frames
To select a frame, click on the outline or in the description area. Drag the frame from the same
areas. Like other containers, the frame is transparent so that you can see diagram element it
surrounds even if the frame is on top of them. Therefore, you cannot select it or drag it by clicking
on its interior as you would with ordinary nodes.
% Resizing Frames
When you add text to a frame, the description area will expand as needed to contain the text. You
can also reshape this area by selecting the frame and dragging the yellow reshape handle.
Path Labels
Path labels occur frequently in UML diagrams. They are used to add guard conditions, name
associations, identify constraints, express relationships, and so on. Pacestar UML Diagrammer
supports several different path label types which remain properly positioned when the path or
attached nodes move around.
UML allows for either style when a path requires a label. You are free to choose the method that
is most clear and fits the constraints of your diagram.
When in text mode the presence of a dotted rectangle indicates what type of label will be created
when you click at the current cursor position. If no rectangle appears, the label will not be
attached to a path or other object. If the rectangle appears directly over the path, the label will be
an in-line path label. And if it appears alongside the path, it will be a lateral label.
Flow Labels
Flow labels provide a way to label the intersection of a path with a node. Unlike in-line and lateral
path labels, flow labels are concerned with both the path and the attached node and are
automatically positioned in the “corner” where the two meet regardless of angle or direction.
Common uses for flow labels include multiplicities and role names on associations. Note that a
single path can have up to four flow labels, one on each side of the connection of each end of the
path.
When in text mode the presence of a dotted rectangle indicates what type of label will be created
when you click at the current cursor position. If the rectangle appears in the corner of the
intersection of a path and a node, the label will be a flow label. You can tell it will be a flow label
rather than a lateral label both because it is fixed at the very end of the path and by the presence of
a small dotted line that appears between the rectangle and the point where the path meets the
node.
There are two ways to control which of these connection models are used to configure new path
connections. You will find this information under Attach Modes in the main user guide, but we’ll
summarize it here as well for convenience.
If most of your connections will be centered with an occasional off center connection, you can
switch back and forth simply by holding down the SHIFT key as you make the connection. For
example, if you are attaching a path between two nodes and wish it to originate from the point on
the first node where you click (as opposed to the center of the node), you simply hold the SHIFT
key as you click to position the start of the path on the first node. This method of connecting a
path is called Click Point. Note that while in connect mode, the status bar will remind you that
holding SHIFT will result in Click Point attachments. Also note that you can route the path from
the origin point on the first node to the terminating point on the second node by clicking at any
number of intermediate points on the diagram in between.
You can also switch attach modes so that holding down the SHIFT key is no longer necessary. If
your diagram contains many off center attachments, this is the more practical way to proceed. In
fact, switching the attach mode to Click Point is often the first step in beginning a non-trivial
class diagram. The attach mode can be changed by selecting one of the modes listed under Attach
which is available in the Paths menu. Once in Click Point attach mode, SHIFT switches back to
centers on a case-by-case basis.
Path Trees
Some UML diagrams require more than simple node-to-node paths. You can create any
conceivable circuit of paths by connecting portions of paths to one another. The most common
arrangement is a “tree”. A tree minimizes the number of paths that connect to a common node. A
good example is an inheritance relationship which consists of a large number of classes that
derive from a base class, each depicted by a generalization path to the base class node.
1. Choose your connector style and enter connect mode. In this example we use a generalization
path. Create the first leg of the tree by clicking at point A (anywhere on the lower class node)
and then at point B (anywhere on the upper class node).
2. Create the left branch of the tree by clicking at point C (anywhere on the left class node), then
at a point D of your choosing directly above the class, and terminate the branch by clicking on
point E directly to the right of D and on the path you created in the last step. You can tell that
the cursor is over the vertical path when the arrowhead of the cursor changes from white to
black.
3. Repeat the last step from points F and G, and back to E. If any of the connections did not turn
out straight, go back to select mode (ESC) and drag the junctions that are now located at points
D, E, and G until they appear correctly.
You can see that a simple tree like the one shown is just one example of a limitless arrangement of
paths that you can design.
1. In this example, we enlarge the tree vertically by selecting the bottom portion and dragging it
downward in a single step.
2. In this example, we move the right branch to the right as if making room for a new class.
3. In this example, we move the connecting paths upward. When dragging paths like this, we
have to make sure to grab the selected path either by the horizontal portion of one of the
selected paths, or by the small red outline around the selected junctions - NOT by the red
handle on the junctions which will cause the movement only of the one junction.
The icons are defined as part of the node styles. The line width and color they are drawn with
matches the line width of the border of the style and cannot be modified independently. The
spacing between the icon and the edges of the shape matches the text border and can be controlled
(currently only per-diagram) by adjusting the text margin spacing located in the Diagram
Properties dialog box.
Also note that in most cases the internal icon overlaps the text area of the symbol. This means that
your text may collide with the symbol. You can avoid this manually by adjusting the size of the
symbol, the text justification, or padding the text with extra spaces.
emphasis. To insert a graphic from a file, use the Insert Graphic feature from the Nodes menu
(also available by default as a toolbar button).
Miscellaneous Drawing
You may find the need to draw diagram elements that are not included in the UML diagram
templates. There are several reasons why this could happen:
z You require a symbol or construct that is not supported by the tool.
z You need to add a simple dividing line, arrow, box, etc. that is not a standard part of UML
such as to annotate or adorn your diagram.
z You decide to implement your own extensions.
We have included some generic shapes and line just for this purpose.
Do not use diagram elements for general drawing purposes
We recommend that you resist the temptation to use a UML diagram element for a purpose for
which it is not intended just because it is the proper shape or line type. If you need a generic box
for example to add the author’s name at the bottom of a page, do NOT use a Class/Object symbol.
If you need a simple line to divide your diagram into two parts, do NOT use an Association path,
and so on. The UML diagram elements have defined purposes and it’s best to use them only for
these purposes. Adding extraneous diagram elements could hinder consistency checking, confuse
third party tools that attempt to interpret your files, and interfere with conversions when
upgrading to new releases of the tool or new versions of the UML specification.
Instead, we have included some basic generic symbols and lines especially for this reason. In the
previous section we discussed how to add nonstandard shapes both from the Nonstandard Node
Style drop menu, and from the Symbol Galleries via the Insert Node/Icon feature. We have also
included a category of path styles for generic drawing. You will find these in the Nonstandard
drop menu category by clicking on the Paths button in the style bar at the left of the screen. If you
need to add a line to your diagram, pick one of these styles and draw with it. (Remember that a
line does not need to start or end on a node, you can start it anywhere and end anywhere else by
double-clicking.) Once you’ve created the line, you can select it and use the toolbar controls or
the Path Properties to change its color, thickness, line pattern and so on however you like.
For creating compound symbols or for adding new lines to existing symbols, you can try using
the Group feature. A group has limited functionality but it can be a helpful way to create a quasi-
custom symbol that you will subsequently copy within your diagram. Note that the group feature
is not intended for this purpose so the grouped elements will not behave like a new shape or style
- for example you cannot use a group to define the shape of a node style and you cannot add a
group to a style bar button for easy replication. One example where grouping could be useful is in
creating an unusual-shaped partition buy grouping lines, bookstand even labels into a single
structure that can then be copied, moved, duplicated, and resized as a whole.
Style UML
Appearance Description
Name(s) Construct(s)
Object Flow object flow An input or output to or from an Object Flow State symbol.
Flow or Object Flow path styles are used for this purpose
seemingly interchangeably. Object Flow paths provide addi-
tional clarity.
Style UML
Appearance Description
Name(s) Construct(s)
Action action (activity) An action state consisting of a single activity that runs to
completion.
Object Flow object flow state A key data object state shown being affected by actions.
State
Send Event send event A signal that is sent asynchronously to a target. Use this
symbol when the target is not shown, or when a compli-
mentary receive event is shown to the right.
Receive Event receive event A signal that is received from a target. Use this symbol
when the source is not shown, or when a complimentary
send event is shown to the right.
Send Event2 send event A signal that is sent asynchronously to a target. Use this
(opposite direc- symbol when a complimentary receive event is shown to
tion) the left.
Receive Event2 receive event A signal that is received from a target. Use this symbol
(opposite direc- when a complimentary send event is shown to the left.
tion)
Style UML
Appearance Description
Name(s) Construct(s)
Branch/Merge branch, Decision branch point where the guard conditions ade-
merge quately describe flow alternatives. Use the same symbol
as a merge point.
Decision decision This larger decision symbol is like a branch symbol but it
can also contain text to help describe the branch condi-
tions, reducing the complexity of the guard conditions on
the outgoing flows.
Initial State initial state Initial state. This is the starting point of the activity.
Final State final state Final state. This is the ending point of the activity.
Expansion expansion region A container for defining an action state expansion region.
Region The interior contains the expansion of the action state.
Listbox Pin Vert listbox pin Also known as an expansion node, a listbox pin repre-
sents a list of input or output data parameters for an activ-
ity/action. A listbox pin can be attached to an action or
expansion region.
Listbox Pin Horz listbox pin A horizontal version of the listbox pin for attaching to the
top and bottom sides of actions or expansion regions.
Exception exception param- This small symbol is placed near an output pin to repre-
Parameter eter marker sent an exception parameter output that flows to the next
action immediately
Time Signal time signal A time signal (or accept) triggered by passage of time (or
triggered to wait.)
Flow Final flow final An end to a flow that does not terminate the activity.
Forks and joins always occur in pairs. A fork usually has a single flow entering one side and
multiple flows exiting the other. The complimentary join usually has the same number of flows
entering one side and a single flow exiting the other side.
To create a fork or join, add a “Fork/Join Vert” or “Fork/Join Horz” node to your diagram. Then
connect flows to and from the incoming and outgoing actions. Once a connector is attached, you
can select the connector and slide its connecting end to any point on the fork/join to achieve the
spacing you prefer. You can also resize the fork/join by selecting it and dragging the bright red
handles on either edge. Note that you can only lengthen or shorten the fork/join in this manner. If
you need a thinner or thicker fork/join, select the symbol, right click and choose properties, the
edit the height and/or width to change the size.
UML references vary as to whether normal flows should be used to connect actions and object
flow states, or whether a special dashed Object Flow path should be used. We included the Object
Flow path style for this use, but you are free to use ordinary flows.
Branch node
Use a simple branch node to show that the flow branches in different paths based on conditions
that can be easily described in the guard conditions of the outgoing flows. For example, a branch
could have two outgoing flows with the guard conditions “[daytime]” and “[nighttime]”.
Decision node
When the guard conditions alone are insufficient for describing the condition, use the large
Decision symbol so that you can use text to describe the condition more clearly. A decision node
is analogous to those found in flow charts. For example, rather than using a simple branch node
with elaborate guard conditions such as “[date of last internal audit more than a year ago]” and
“[date of last internal audit less than a year ago]”, you could instead use a Decision with the text
“date of last internal audit” and guard conditions “[more than a year]” and “[less than a year]”.
Action node
An action node can be used in place of a decision node when the branch of flows is the result of
some action described in the action node. For example, an action node might contain the text
“Calculate the rate of return.” and the guard conditions could be “[ROI > 5%]” and “[ROI <=
5%]”.
Pins
Pins represent data flows such as input and output parameters. Pins typically attach to the sides of
actions to show data inputs and outputs, but the can also occur outside actions as if they were
miniature versions of object flow nodes. They can also appear on the edges of expansion regions
and decomposed actions to show how the action or expansion region interacts with data. In the
latter case, the pins appear directly overlapping the outline of the node.
Pins are attachable nodes that attach to the edges of actions, or overlapping the edges of
expansion regions. Like all attachable nodes, you create the base node first (in this case the action
or expansion region), then create the attachable node (in this case the pin) and snap it into place
on the base node where it attaches for the purposes or moving, copying, and so on (see
Attachable Nodes on page 12).
% To create a pin
1. Select the Pin node style. The cursor will take the shape of the pin.
2. If creating a free pin (not attached to a node), simply click on the diagram. If creating a pin on
an action, move the cursor until it is aside the outer edge of the action and it snaps into place. If
creating a pin on an expansion region or other action container, move the cursor until it is
directly over one of the edges and it snaps into place.
3. Click to create the pin. The pin will automatically cling to the action or expansion region if you
clicked near a node of the proper type.
% Labeling a pin
The best way to label a pin is to attach a node label to it. In the above example, you could right
click on the pin and choose Add Node Label, Above Left. Use text mode to change the text of the
label to the name you want. You may also want to reposition the label relative to the pin by
dragging it. The label will remain attached to the pin in the same way the pin is attached to the
action. You can un attach it later if you like by right clicking on the label and choosing Detach
Label.
% Detaching a Pin
To detach a pin from an action, simply drag it away from the action node. Alternately, right click
on the pin and select the Detach command.
% Repositioning a pin
You can drag a pin to reposition it on the action or detach it. Dragging to reposition the pin works
similar to creating the pin. You can choose to move it free of the action, attach it to a side of an
action, or attach it to an expansion region.
Listbox Pins
Listbox pins are synonymously called expansion nodes. We’ve chosen the term listbox pin
because it is more easily remembered and associated with pins. A listbox pin is similar to a
standard pin except that it typically identifies a range of data for which the expansion region will
act upon. For example, a listbox pin could represent a customer database or list of names and the
expansion region could represent a complex activity that is applied to the data set (or manipulates
it). The key representation made by having a listbox pin as opposed to a standard pin is that the
action, subactivity, or expansion region applies iteratively.
Creating, manipulating, labeling, and repositioning listbox pins work similar to with standard pins
(see previous section). The only difference is that listbox pins can be vertical or horizontal and
therefore should be attached to the corresponding sides of node.
Listbox pins are attachable nodes that attach to the edges of actions, or overlapping the edges of
expansion regions. Like all attachable nodes, you create the base node first (in this case the action
or expansion region), then create the attachable node (in this case the listbox pin) and snap it into
place on the base node where it attaches for the purposes or moving, copying, and so on (see
Attachable Nodes on page 12).
Connectors
Connectors are small circles used to replace sections of paths. Use connectors anytime they
increase the readability of a diagram or simplify the maintenance of a complex routing of paths.
Connectors are also important for continuing a path from one page to another or one diagram to
another.
UML allows the use of connectors to replace just about any path. Therefore you will find the
connector symbol available is all UML diagram templates located in the General symbols under
Nodes. Simply add connectors to your diagram, one where the path breaks, and the other where
the path continues. Label each connector with an identical letter or number. Then connect up the
paths.
Exception Parameters
Exception parameters are a special case of an output pin which is marked by a small triangle. The
The jagged flow is not a special flow style, but rather a flow that is created in three segments. For
example, select the Path path style, click at A, click at B, click at C, then double click at D to
create the above jagged flow symbol.
Style UML
Appearance Description
Name(s) Construct(s)
Style UML
Appearance Description
Name(s) Construct(s)
Active Class active class A class or object that actively directs other objects. In
active object earlier versions of UML an active class was shown with
a thick border instead.
Active Class R2 active class A class or object that actively directs other objects, with
active object a second compartment. The top compartment is gener-
ally used for the class name, and the lower compart-
ment for attributes.
Active Class R3 active class A class or object that actively directs other objects, with
active object three compartments. The compartments are generally
used for class name (top), attributes (middle), and oper-
ations (bottom).
Class Actor actor An actor class, same as a class with the “<<actor>>”
stereotype.
Class Boundary actor A boundary class, same as a class with the “<<bound-
ary>>” stereotype.
Style UML
Appearance Description
Name(s) Construct(s)
Class Control actor A control class, same as a class with the “<<control>>”
stereotype.
Class Entity actor An entity class, same as a class with the “<<entity>>”
stereotype.
N’ary Associator n’ary associator Joins multiple associations when more than two classes
are involved.
Style UML
Appearance Description
Name(s) Construct(s)
Associations
Associations are the most common type of paths found in Class and Object diagrams. They show
relationships between classes and objects such as generalization, aggregation, composition,
navigability, and so on.
At its simplest, an association is a solid line connecting two classes or objects. However the
association can be adorned by different types of terminators (arrowheads) and labels that
represent attributes of the association like its name, direction, roles, multiplicities, and
constraints.
We’ve provided styles that represent the most common types of associations “Association”,
“Directional Association”, “Bidirectional Association”, “Generalization”, “Aggregation”, and
“Composition”. However you can use any association style to define an association between
classes and alter it by changing terminators or adding labels to arrive at any possible association.
Association Navigability
In addition to the normal “Association” path style, we include the two common variations
“Directional Association” and “Bidirectional Association”. We don’t provide styles for all the
possible permutations such as those that involve the less frequently used unidirectional terminator
shown. To get a unidirectional indicator, create a directional indicator, then right click on the
endpoint without a terminator and chose the terminator for the “X”.
Association Multiplicities
Multiplicities show how many of one class are associated with another, or how many are
permitted to be. Multiplicities can be added to associations just like end labels described in the
previous section.
However, because multiplicities are usually one of a very few varieties, we’ve added shortcut
styles with predefined text so that you can add a multiplicity without even having to do any
typing. The pre-defined common multiplicities are “*” (meaning any number, zero or more), “1”
(obviously meaning just one), “0..1” (meaning one if any), or “1..*” (meaning at least 1). To add
one of these multiplicities, simple click on the corresponding style bar button, and then click it
into place, being sure to let it snap into a flow label slot as described for end labels in the previous
section. You can of course, edit the text after creating the label if you require a different
multiplicity expression.
Association Names
Associations can also have an optional name. An association name is usually a verb or verb
phrase such as “hosts” or “is hosted by”. The association name can be implemented as an inline
path label in which the association breaks around the label, or more commonly as a lateral path
label as shown in which the name appears alongside the association (above or below).
Lateral path labels are discussed elsewhere and are described in detail in the main product user
guide. In short, you can name an association by selecting a label style. Then move the text caret
cursor over the association path until you see a dotted rectangle appear and click. The name label
will appear with the default text “name” which you will then edit with the proper name. Once
created in this way, the name will remain with the association if the nodes or the path moves.
a small solid arrowhead beside the association name. Often a name is implied to mean left to right
or top to bottom and a direction indicator is only used when this convention is contradicted.
Others prefer to always include a direction indicator.
To add a direction indicator to an association name, right click on the name and choose “Direction
Indicator” from the right click menu, then select “None”, “Forward”, or “Backward”. Notice that
directions such as right and left are not used because the association can be oriented in any
direction - though typically the name direction indicator is clearest if the association is vertical or
horizontal. Forward means from the point where the path was started to where it was terminated
when it was first created, so a forward direction could easily be right to left or left to right.
Note that Pacestar UML Diagrammer places direction indicators on vertical associations
following the name text. This is different than in most UML references where the arrow appears
before the text. The meaning however remains clear and the name remains predictably near the
path.
Association Constraints
Association constraints are simply documented relationships between two associations, usually
Association Classes
An association class is another common construct in class diagrams in which a class is used to
further define an association. It’s easy to create by creating the association class (no special style
is required class/object will do). Then connect the association class to the association using an
Anchor path.
N’ary Associations
Most associations tend to be binary (between two classes or objects). UML also supports
associations between more than two and calls it an “n’ary association”. To represent an n’ary
association, create an N’ary Associator node near the center of the nodes, then connect each node
to the N’ary Associator and add the appropriate end labels and multiplicities as needed. You can
name any or all of the association links (and add direction indicators if you like), or you can add a
node label to the n’ary associator instead to add a single name to the association if you prefer.
Qualifiers
Qualifiers attach to class symbols to add information to association paths.
A qualifier can attach to any side of a class as show. And a single class can have any number of
qualifiers.
An association that is attached to a qualifier can be annotated in all the usual ways. You can add
an association name, direction indicator, multiplicities, rolenames, constraints and so on. Labels
that generally attach to the ends of the association as flow symbols where the association meets
the class, should instead can be placed where the association meets the qualifier.
Qualifiers are attachable nodes that attach to the edges of classes. Like all attachable nodes, you
create the base node first (in this case the class), then create the attachable node (in this case the
qualifier) and snap it into place on the base node where it attaches for the purposes or moving,
copying, and so on (see Attachable Nodes on page 12).
Templates
Templates are constructed by attaching a parameter list box to the upper right hand corner of a
class node or collaboration node as shown.
Parameter lists are attachable nodes that attach to the upper right hand corners of classes and
collaborations. Like all attachable nodes, you create the base node first (in this case the class or
collaboration), then create the attachable node (in this case the parameter list) and snap it into
place on the base node where it attaches for the purposes or moving, copying, and so on (see
Attachable Nodes on page 12).
Once a parameter list is attached to a class or collaboration, it will remain with it if you move the
class or collaboration, copy it, duplicate it, and so on. If you delete the class or collaboration, the
parameter list will be deleted automatically as well. If you prefer to delete the class or
collaboration but not the parameter list, simply detach it first.
To detach a parameter list from a class or collaboration, right click on the parameter list and select
Detach from the right click menu.
A parameter list cannot be repositioned while attached to a class or collaboration. To reposition it,
detach it and re-attach it at a new location.
Style UML
Appearance Description
Name(s) Construct(s)
Message FOUND found message A message received from a sender unknown or outside
of scope.
Message DATA data flow Although not exactly messages, data flows are concep-
tually similar to messages and their behavior and
implementation are identical to other message types.
The above message path styles are point-to-point which means they are defined so that you create
a message by clicking on the source, then clicking on the destination. All of the above also have
stamp styles which you simply choose and then stamp onto your diagram where you want them.
The stamp styles are defined with the same style names as above plus a prefix indicating the
orientation of the message. For example, the stamp styles for the synchronous message are:
Messages
Messages are common in several types of UML diagrams, most prominently in Communication
Diagrams and Sequence Diagrams. Messages are represented as directed arrows (paths) often
with a text label that describes the message.
Messages can be attached at both ends to a source and destination as with most messages in
Sequence Diagrams. They can also be free floating as with most messages in Communications
diagrams. For convenience, Pacestar UML Diagrammer offers two ways to add messages to
diagrams corresponding to these two common usages. Messages can be created point-to-point or
they can be stamped onto a diagram.
Each message type has two pre-defined path styles. One path style is defined for creating point-
to-point messages and is available in the style bar. Stamp messages are available only in
Messages drop menu (in the main Paths drop menu on the style bar). Stamp message styles are
defined in a variety or orientations for quick access. You can use point-to-point and stamp
messages interchangeably discriminating only based on how you prefer to add them to your
diagram. Both methods result in identical messages that can late be edited in the same ways.
Labeling Messages
Message labels are simply lateral path labels. You can manipulate them like any other lateral path
labels, adding, deleting, sliding, and editing in all the usual ways. As with all lateral path labels,
they self-adjust to remain near the path as the path changes. While UML seems to prefer you to
use lateral path labels to label messages, you can just as properly use inline path labels instead.
The pre-defined path styles (point-to-point and stamp) automatically add lateral path labels to
message paths as you create them, but you may also substitute inline path labels on a case-by-
case basis. After you create a message with a label, you can simply slide the label over the path to
make it inline.
Looping Messages
Communication diagrams often require looping messages as shown.
Style UML
Appearance Description
Name(s) Construct(s)
To Interface None A path that connects from a component (or other classifier)
to an interface symbol (a Provided Interface or a Required
Interface node).
Style UML
Appearance Description
Name(s) Construct(s)
Complex Port complex port A complex port (port with multiple interfaces) that is oriented
Vert vertically and attached to the top or bottom of a component
or other classifier.
Complex Port complex port A complex port (port with multiple interfaces) that is oriented
Horz horizontally and attached to the left or right of a component
or other classifier.
Style UML
Appearance Description
Name(s) Construct(s)
Interfaces
Interfaces depict defined points of interaction to classifiers such as classes, packages, and
components. UML 2.0 defines two type of interfaces, required interfaces and provided interfaces.
Each is diagrammed identically with different interface symbols. In the case of a required
interface, the interface symbol is a small circle which has been referred to as a lollipop for its
appearance. The required interface is represented by a half circle large enough to interlock with
the provided interface symbol. The combination of these two notations is also referred to as ball
and socket notation.
classifier closest to where you place the interface has a Port, the interface will automatically
connect up to the closest port.
In either case the interface created in this manner is attached to the classifier and can be
conveniently manipulated along with the classifier. If you move the classifier, copy it, delete it,
and so on, all of the attached interfaces will act as if they were a part of the classifier.
For added convenience, when you add an interface to a classifier it receives a default text label.
You can manipulate the text label in the usual ways. However, if you type the text for the label
immediately, before moving the mouse from over the interface symbol and without leaving the
current mode, the text you type will replace the default label text for the interface you just created.
Hitting ESC to terminate text editing then returns you to create mode to create additional ports if
you choose.
Interfaces can be constructed in two different ways. The first way involves creating a “Provided
Interface” or a “Required Interface” node near an eligible symbol (class, package, or component).
This method is convenient for defining the interfaces for the class, package or component, and for
manipulating them later.
The second method is to use Provided Interface Assembly and Required Interface Assembly path
styles. Rather than using a node for the interface symbol, these path styles include terminators
that are indentical in appearance to the interface symbol nodes described above.
Both of the above configurations can be used interchangeably and interlock properly together. We
recommend that you use the node symbols for establishing the interfaces that are essentially part
of a class, package, or component. And us the path styles for connecting these interfaces to other
interfaces or remote classifiers.
Labeling Interfaces
Interfaces defined on classifiers often have a name. Add a name using the node label. Simply
right click on the interface symbol and select Add Node Symbol and choose a label position. You
can then use text mode to change the label text and use select mode to drag the position of the
label relative to the interface symbol.
Moving Interfaces
When you establish interfaces on a classifier using interface nodes (the recommended method
described in the previous section), you can adjust the interface symbol by simply dragging them.
The connection to the classifier will automatically adjust to the new position.
Assembly Connectors
Often you will see a complete interface assembly connector like the one show drawn on a
diagram but neither side (the ball or socket) is in the immediate vicinity of a classifier (class,
package, or component). In this case, both ‘sides’ of the assembly connector can be created by
Interface Assembly path styles that meet at a common point.
3. Double click on the place in your diagram where the interface connector will appear. In the
example, double-click on (c).
4. Select the opposing Interface Assembly path style (in the example this is the Required Interface
Assembly which will form the complementary side of the assembly connector) by clicking on
its button in the style bar.
5. Route the second path to the same location created by the loose end above and click on the end
of the other path. In the example, click on (d), (e), then double-click back on (c).
Ports
Ports in UML2 appear as small squares that overlap the edges of component symbols (though
they can also be used on packages and classes). A port is a higher level concept than an interface
and represents a collection of related interfaces. Therefore, you can attach interfaces to ports
instead of attaching them directly to classifiers.
Ports are attachable nodes that attach to the edges of components (and classes and packages). Like
all attachable nodes, you create the base node first (in this case the component, class, or package),
then create the attachable node (in this case the port) and snap it into place on the base node
where it attaches for the purposes or moving, copying, and so on (see Attachable Nodes on page
12).
Creating Ports
Ports automatically cling to the edge of any component symbol (or other classifier symbol such as
a class or package symbol). Most ports are public and externally visible, however a port can also
be attached just inside the classifier boundary to represent a private (hidden) port.
Labeling Ports
The best way to label a port is to attach a node label to it. In the above example, you could right
click on the port and choose Add Node Label, Above Left. Use text mode to change the text of
the label to the name you want. You may also want to reposition the label relative to the port by
dragging it. The label will remain attached to the port in the same way the port is attached to the
component. You can unattach it later if you like by right clicking on the label and choosing
Detach Label.
Repositioning Ports
You can drag a port to reposition it on the component or detach it. Dragging to reposition the port
works similar to creating the port. You can choose to move it free of the component or attach to a
different component or a different position on the same component.
Style UML
Appearance Description
Name(s) Construct(s)
Style UML
Appearance Description
Name(s) Construct(s)
Package C2R2a package A package symbol with two columns, one having two
rows.
Containments
Containment is simply the collection of a number of packages within a broader package. UML
provides a special symbol for expressing containment that saves diagram space and is easier to
manage and extend. Use the containment path style as shown similar to how generalization is
expressed. See the Trees section for tips on working with tree path configurations.
Style UML
Appearance Description
Name(s) Construct(s)
Message LOST lost message A message sent to a receiver unknown or outside of scope.
Style UML
Appearance Description
Name(s) Construct(s)
Lifeline lifeline An object lifeline. Note that the Lifeline style is a node style
rather than a path style despite that it appears as a vertical
dashed line.
Style UML
Appearance Description
Name(s) Construct(s)
Active Object active object An object that actively directs other objects. In earlier ver-
sions of UML an active class was shown with a thick border
instead.
Terminate destruction event Marks the destruction of a lifeline or activation. The termi-
nate node is used for different purposes with different
names in different diagram types. In a state diagram the
same symbol denotes a terminate node. For simplicity, we
use this term for both cases, noting that the terminate node
is used to represent a destruction event in sequence dia-
grams.
Lifelines
Lifelines form the foundation of a Sequence Diagram. They appear as vertical dashed lines
attached to objects.
NOTE: There is some discrepancy in terminology among reputable sources. [SPEC] describes
the rectangle as the lifeline, whereas [REF2] describes the rectangle as a role and the
dashed line itself as the lifeline of the role. We have chosen to stick with the previously
popularized terminology which seems to remain clear and accepted, and also better
suits our implementation. With regard to roles vs. objects, we have also chosen to stick
with object for the time being, as it is clearly an object symbol representing the broader
concept of a role. For the purposes of our implementation, this convention also permits
you to use any variation of a class/object node as the object or role.
Activations and messages attach to lifelines to show sequences of messages and system events.
Lifelines are attachable nodes that attach to the bottom of objects (roles). Unlike other attachable
nodes, you can create either the object or the lifeline first, then create the other and snap it into
place on the base node where it attaches for the purposes or moving, copying, and so on (see
Attachable Nodes on page 12).
Activations
This tool uses the term activation to refer to what UML 2 officially terms an execution
specification (also a focus of control [BIB]), a vertical rectangle attached to a lifeline to identify
defined portions of the life cycle. The UML 2.0 specification actually defines the term activation
specifically as the start (top) of a execution specification, but this broader usage is common and
well understood.
Activations typically attach to a lifeline, but they can also attach directly to an object or to another
activation, overlapping to represent nesting and recursion.
Activations are attachable nodes that attach to the bottom of objects. Unlike other attachable
nodes, you can create either the object or the activation first, then create the other and snap it into
place on the base node where it attaches for the purposes or moving, copying, and so on (see
Attachable Nodes on page 12).
Terminate Nodes
A terminate node (sometimes called a stop or a destruction event) marks the end of an object’s
lifeline. It appears as a small ‘X’ located at the bottom edge of a lifeline or an activation.
Terminate nodes are attachable nodes that attach to the bottom edges of lifelines and activations.
Like all attachable nodes, you create the base node first (in this case the lifeline or activation),
then create the attachable node (in this case the terminate symbol) and snap it into place on the
base node where it attaches for the purposes or moving, copying, and so on (see Attachable
Nodes on page 12).
Messages
Messages in sequence diagrams flow from a source object’s lifeline (or activation), to a
destination object’s lifeline (or activation). The messages used in activations are rarely free
floating, and therefore you should generally create them using the point-to-point message path
styles. See the section on messages for further descriptions of point-to-point message path styles.
3. Click on the destination of the message to terminate it. The destination is most often a lifeline
or activation as well, though you can terminate a message anywhere (double click to terminate
when not over a node).
4. When you create a message, it will have a default text label attached as a lateral path label to
the center and above the message. Enter text mode to edit the label text appropriately.
5. If you prefer the message label located further left or right, or below the message simply drag it
where you like.
lifelines beneath the location of the arrow. Before we do, we’ll need to shift a portion of the
diagram down to free up the needed space.
1. The first step is making room in this diagram is to extend the lifelines, lengthening them
downwards. Select each lifeline (individually) in turn, and drag it downward as shown. The
messages and activations attached to the lifeline will not be disturbed.
2. Next use lasso selection to select all of the messages below the arrow, and shift them
downward by grabbing and dragging any of the selected messages. Grab by the line, not by the
red select handles.
Creating the overlapping subactivation is straight-forward. Simply snap a new activation symbol
into place over an existing activation.
In the case of direct recursion, you may need to create messages that connect from the activation
to the subactivation and back without interacting with any other objects. Obviously the usual
straight horizontal message path is inadequate for this purpose. Most depictions of such messages
show looped messages as in the example here.Creating messages of this sort requires a few extra
steps.
3. Create the message by clicking at points A, B, C, and D as shown in the example above.
Create a looped message on a lifeline in the same way.
You can add a guard condition to an activation or a lifeline by selecting the guard condition label
style (or any other label style). Move it over the activation or lifeline until the outline box is
visible then click to create the label. The guard condition label style should have a white
background so it is visible atop the activation. If not, select the label and use the Fill toolbar
button to change the fill color to white.
Like all attachable nodes, you create the base node first (in this case the lifeline or activation),
then create the attachable node (in this case the state) and snap it into place on the base node
where it attaches for the purposes or moving, copying, and so on (see Attachable Nodes on page
12).
Style UML
Appearance Description
Name(s) Construct(s)
Transition transition A transition from one state to another or the same state. A
guard condition on the transition, usually represented by an
attached path label, indicates the event that caused the
transition.
Style UML
Appearance Description
Name(s) Construct(s)
State R3 state A state with a name compartment and two body com-
partments.
Name Tab name tab A name tab is affixed to the left side of the top edge of a
state symbol as an alternate method of naming a state.
Junction State junction state Chains transition segments into single run-to-comple-
tion transition.
Decision decision This larger decision symbol is like a branch symbol but
it can also contain text to help describe the branch con-
ditions, reducing the complexity of the guard conditions
on the outgoing flows.
Style UML
Appearance Description
Name(s) Construct(s)
Initial State initial state Initial state. This is the starting point of the state
machine.
Final State final state Final state. This is the ending point of the state
machine.
History State history state Restores the previous condition of the composite state.
Deep History State deep history state Restores any past condition of the composite state.
Entry Point entry point An externally visible entry point that identifies an inter-
nal state as a target.
Exit Point exit point An externally visible entry point that identifies an inter-
nal state as a source.
Entry/Exit Point alternate entry/ An alternate notation for entry or exit points. The node
exit point symbol contains the name of the entry or exit point, and a tran-
sition arrow connects to or from the state.
Container State state with concur- A container that encompasses the internals of a state,
CB2,.. rency bound- such as a superstate, containing two compartments
ary(s) separated by a concurrency boundary. Available in mul-
tiple numbers of compartments.
Superstates
A superstate is a state that has internal substates and contains a diagram of its inner workings. An
obvious way to create a superstate is to create a normal state, enlarge it, and add the substate
diagram within. However, we strongly recommend that you instead create the superstate using a
State Container. A State Container (like any container) is more that a large state. For one thing it
is transparent so that you need not be concerned whether the internals are in front of it or behind
it. It is transparent so that it is selectable only by its outline or its text area (if any), making it
easier to work on the internals without accidentally selecting the container. Containers also have a
number of other minor behavioral differences designed for exactly this purpose.
The substate diagram within a superstate is simply a normal state diagram and requires no special
techniques.
Concurrency Boundaries
A concurrency boundary is a divider drawn within a superstate that separates two or more
portions of the state that operate concurrently. It is represented as a simple dashed line dividing
the superstate symbol. Although the tool does not explicitly support this notation as part of the
state symbol, you can easily add your own concurrency boundary anywhere within a superstate
symbol. To create the concurrency boundary, use a path of style Dashed Divider (obtain this by
clicking on the Paths button in the style bar and locating it in the Nonstandard category drop
menu).
Entry and exit point nodes are attachable nodes that attach to the edges of states. Like all
attachable nodes, you create the base node first (in this case the state), then create the attachable
node (in this case the entry or exit point) and snap it into place on the base node where it attaches
for the purposes or moving, copying, and so on (see Attachable Nodes on page 12).
label relative to the entry or exit point by dragging it. The label will remain attached to the entry
or exit point in the same manner the entry or exit point is attached to the state. You can unattach it
later if you like by right clicking on the label and choosing Detach Label.
Self-transitions
Self-transitions are common in state diagrams in which an event results in a transition to the same
state.
4. Click on intermediate points to route the path away from the state and back.
5. While still holding the SHIFT key, click on the endpoint of the state where the self-transition
will terminate.
Note that self-transitions created manually may need to be manually re-adjusted if the size of the
state changes. Self-transitions created using the Add Self-Transition command will self-adjust
when the state resizes. Either type will move automatically with the state.
Name tabs are attachable nodes that attach to the top edges of states. Like all attachable nodes,
you create the base node first (in this case the state), then create the attachable node (in this case
the name tab) and snap it into place on the base node where it attaches for the purposes or
moving, copying, and so on (see Attachable Nodes on page 12).
Style UML
Appearance Description
Name(s) Construct(s)
Style UML
Appearance Description
Name(s) Construct(s)
Actor System system actor A more generalized representation of an actor. Used to dis-
tinguish non-user actors (such as systems) from the stan-
dard actor symbol. Graphics and other symbols are
acceptable as well.
Subject subject boundary A rectangular container that shows the boundaries of the
Boundary subject (system). Any container can be used for this pur-
pose.
Relationships
Relationships between use cases are expressed as dashed paths of the style Relationship plus an
inline path label with a keyword (<<includes>> or <<extends>>).
Timing Diagrams
Timing diagrams are included as part of the UML 2.0 specification but are not directly supported by
this release of the software. While there is no timing diagram template or symbols and features to
conveniently support constructing timing diagrams, you can use the standard templates and the
generic symbols (lines and basic shapes) to create simple timing diagrams without too much difficulty.
Parameter Sets
Parameter set notation is not supported directly. Parameter set notation consists of rectangles that
encompass a set of pins. As a work-around you can add a generic rectangle for this purpose. It will just
lack the automatic attachment capabilities and will require greater effort to maintain.
F J
final state 27, 83 jagged flow 33
flow 26 join 26, 27, 28, 83
flow final 27 junction state 82
flow label 19, 41
flow symbol 44 K
focus of control 72, 74 keys 9
fork 26, 27, 28, 83 keywords 11
found message 48, 72
frames 17 L
free floating messages 49 labeling interfaces 58
free pin 30 labeling messages 51
labeling ports 60, 85
G lateral path label 18, 42, 43, 51
general ordering path 93 lifeline 72, 73, 75
general techniques 11 listbox pin 27, 31
generalization 36, 68 lollipop interface 56
N R
n’ary association 43 realization 36, 68
n’ary associator 38 receive event 26
n’ary associator node 43 recursion 79
name tab 82, 87 reply 48, 72
navigability 40 required interface 55, 56
node 55 required interface assembly 55, 57
nonstandard symbols 23 role 41, 72, 73
note 15 rolename 41, 44
O S
object 72 self-transition 86
object diagram 35 send event 26
object flow 26, 28 stamped messages 49, 50
object flow node 29 state 73, 82
object flow state 26, 28 state container 84
state diagram 81
P stop 76
package 60, 68 subactivation 79
package diagram 67 subactivity 26
parameter list 45 subsystem 68
parameter sets 93 superstate 84
part 72 symbols (used in this guide) 9
synchronization state 82
synchronous message 48, 72
T
template 39, 45
terminate 73
terminate node 73, 76, 83
terminate psuedostate 83
time signal 27
timing diagram 93
to interface path 56
transition 82
trees 69
U
unidirectional association 40
unnavigable association 36
unsupported UML 93
use case diagram 89