UML Notation

1
Overview
This overview is meant to provide a coherent guide to the Unified Notation, as developed by
Grady Booch and Jim Rumbaugh, representing a unification of the Booch and OMT methods.
This document is not meant to take the place of a book or a full reference, which must include full
explanations and lots of examples (and which takes a long time to write). Further documentation
will come (as the Read Me document explains), but our purpose here is to provide a status report
on the Unified Notation so that we may get feedback quickly. This document should be read in
conjunction with the metamodel guide, which provides more complete information on the
underlying semantic concepts that the notation represents.
The bulk of this document contains a discussion of the Unified Notation, organized by
diagram kind. The syntax of the notation and its associated text are described together with some
suggestions for useful conventions for diagramming. The final part of the document contains a list
of the Unified Notation notation elements compared against the equivalent elements (if any) in the
Booch-93 and OMT-2 notations.
Unifed Method V0.8
RATIONAL SOFTWARE CORPORATION

Thi d
t d ith F
M k
404
Diagrams
1. Diagrams
A diagram is a projection upon the elements of a model; the same elements may appear in
multiple diagrams. A given diagram may present somebut not necessarily allof the details of
any particular element.
Diagrams are the primary artifacts that developers use when manipulating models. However,
some modeling information is more conveniently manipulated using tables or text, therefore a
model editing tool would need to support both pictures and a kind of semantic backplane, which
provides forms and textual annotation to supplement the pictures. Maintenance of both diagrams
and backplanes is best performed using on-line interactive tools that permit searching and
hyperlinks. When the backplane information is presented in printed diagrams, it will usually be
expressed textually, but we have not chosen to freeze the external format of this information, as
we do not regard it as the normal means of communication.*
We have defined the external format of diagrams. In the Unified Method, there are a number
of diagrams that are central:
Class diagram
Use case diagram
Message trace diagram
Object message diagram
State diagram
Module diagram
Platform diagram
In the remainder of this document, we examine each of these kinds of diagrams.
*This is identical to the approach in Booch of providing a specification for each modeling element. In this
document, we illuminate one such specification (for operations) although in principle, every modeling element has an associated specification.
Unifed Method V0.8
Class Diagram
2. Class Diagram
The class diagram is the core of a Unified Model. This view shows the logical static structure of a
system: its contents and their relationships to each other. In its most fundamental form, it shows
the elements composing the state of a system, i.e., those elements that must be remembered from
moment to moment.
Class diagrams show generic descriptions of possible systems and object diagrams show
particular instantiations of systems and their behavior. Class diagrams contain classes and object
diagrams contain objects, but it is possible to mix classes and objects for various purposes, so the
separation is not rigid.
Classes
A class is drawn as a solid-outline rectangular box with 3 compartments, with the class name in
the top compartment, a list of attributes (with optional types and initial values) in the middle
compartment, and a list of operations (with optional argument lists and return types) in the bottom
compartment (Fig. 1).*
The name of a class has scope within its enclosing category. (However, one is wise to avoid
reusing names in different scopes even when the scoping rules can resolve ambiguities.) The full
path name of a class imported from another category may be given by specifying the enclosing
category in the form CategoryName::ClassName. Multiple levels of category can be specified if
necessary. Tools may provide alternate formats for navigating diagrams.
The attribute and operation compartments of the class box can be suppressed to reduce detail
in an overview.** Suppression of compartments is a view effect and can differ for different icons
representing the same class. Omitting a compartment makes no statement about the absence of
attributes or operations, but drawing an empty compartment explicitly states that there are no
elements in that part. Various stylistic conventions are possible regarding when to show the
compartments and when to show just the class name.
The name compartment contains the name of the class, preferably in boldface font.***
Additional language-dependent and user-defined information can be included in each
compartment in a textual format. The class stereotype can be shown as a normal-font text string in
parentheses centered above the class name. A stereotype tells what kind of class it is; several
authors supply suggested lists of stereotypes (such as controller, actor, interface, etc.) but we do
not restrict the list so the user is free to make up new stereotypes as necessary. Languagedependent, code generator, and user-defined arbitrary properties can be shown as a list of
keyword strings, indented in italic font below the class name; the strings can include parameters
as well as arbitrary keywords defined by a tool or by the user. Example: abstract, readonly,
designer=Joe Smith.
*This follows the style in OMT, which is space-efficient and easy to draw.
**In fact, there are lots of opportunities for tool builders to provide creative ways of presenting and manipulating these elements. In practice, one typically displays only a few interesting attributes and operations in a given diagram; the backplane, of course, holds all such attributes and operations.
***This is merely a stylistic convention; the typeface used has only visual, not semantic, impact.
Unifed Method V0.8
Class Diagram
There is no special notation for a metaclass. It may be indicated using the stereotype
(metaclass). The same approach may be applied to other kinds of special classes, such as
exceptions, events, or other kinds of entities that may be implemented as classes subject to certain
semantic or implementation conventions.
Attributes and Operations
The attribute compartment contains a list of attributes.* Their order is meaningful and can be used
by the code generator, but tools may provide filters that display full or partial lists of attributes
(and operations) in other orders, such as alphabetical, sorted by visibility or properties, etc. An
attribute has a name and type specified in the format name: type=initialValue. The name and type
are strings that are ultimately language-dependent. The initial value is a string representing an
expression in the target language; it is optional and represents a hint to the code generator for
initializing class-scope attributes and for building constructors for instance-scope attributes. The
context and evaluation time of the expression depends on the target language.
The operation compartment contains a list of operations with the same ordering
considerations as attributes. An operation has the format
name (parameter:type=defaultValue, ...): resultType. The operation components are strings that
are language-dependent. If the target language supports multiple return types, a list of types can
be supplied. The legality of default value specifications is dependent on the target language. If
there are no parameters, show an empty pair of parentheses. If an operation does not return a
value, omit the colon and result type (equivalent to C++ void).
Tools may provide alternate formats for displaying attributes and operations, such as C++ or
Smalltalk formats. Tools may also provide filters for suppressing various constituents of each
element; for example, a user might want to see simply a list of attributes without types. Similarly,
a user might wish to visualize the responsibilities associated with a particular class.
Various language-dependent refinements are useful when class diagrams are used for detailed
design and coding (Fig. 2). Initial values for attribute values can be specified: name: type =
expression. Attributes and operations can have class scope (C++ static, Smalltalk class variables
or methods) by prepending a $ symbol: $name. The absence of a symbol indicates that the
element is instance-scope (i.e., the information may not be suppressed by a tool on the diagram,
although it could be shown in some other way, such as color, font, or different ordering). The
external visibility of an element can be specified by prepending a symbol: public (+), protected
(#), or private (-). The absence of a symbol indicates that the visibility is not being shown. To
accommodate other features needed by programming languages, properties in braces can follow
the affected element: {constraint}. These can be used in a language-dependent way, such as
{const}. In particular, {abstract} indicates an operation whose implementation is deferred to a
subclass (an abstract operation). User-defined properties also appear in this format:
{status=incomplete}.
*This compartment most often is used to show pure elements, but in practice may also be used to show
references to other objects when the relationship is subordinate and uninteresting at a higher level.
Unifed Method V0.8
Class Diagram
Templates
Parameterized (also called template or generic) classes can be specified by impacting the class
box with a small dashed box in the upper right corner. The template name is placed in the class
box. The dashed box contains a list of formal template parameters and their types in attribute
form: arg:type (Fig. 3). A type of Type can be omitted and is assumed by default if only a name is
given. The parameters may be used lexically within the template as formal parameters subject to
the rules of the target language.
Classes instantiated from templates are drawn as ordinary class boxes but the instantiation is
indicated lexically in the class name string in the format: templateName<value, value>. The
classname is the name of the template. The values are language-dependent expressions whose
types must match the corresponding parameters. Usually the actual parameters are class names
but they could be of other types, such as integer expressions. The entire expression with angle
brackets is the name of the instantiated class (i.e., instantiation of a template does not require
giving it a new name) and can be used in any context in which a simple class name is usable
(similar to C++ rules).
Instantiated template classes can be connected to their templates by dashed arrows (which can
also be used to show instantiation of ordinary classes as objects), but this is usually unnecessary,
since the match-up can be matched lexically. Usually it is unnecessary to drawn instantiated
classes on class diagrams, since they usually appear only as variable and parameters types, but
they can be drawn if they must be subclassed. Instantiated classes may not have additional
contents (attributes or operations) since these are derived from the template itself.
Utilities
A utility is shown as a class box with a shadow to the right and bottom sides. A utility is a
grouping of global attributes and operations. Utilities may also be templates which are shown by
impacting them with the same dashed box symbol. A template utility has the effect of declaring
global template procedures. Code generator options can determine whether a utility generates
global names or whether they are encapsulated in a dummy class declaration.
Objects
An object is drawn as a hexagon with straight sides and a slight peak at the top and bottom.* It
may be divided into two compartments (Fig. 5).
The top compartment contains a string in the format: objectName: className. The object
name can be omitted for anonymous objects. If there is no colon, then the string designates the
class of an anonymous object. As with classes, it is possible to render an objects stereotype and
properties, preferably under dynamic control of an editing tool.
The bottom compartment contains a list of attribute values in the format: attributeName: type
= value. The type is usually omitted since it can be determined from the class itself as well as the
form of the value but it may be included for clarity if needed. The attribute name must match one
from the class. The value is a language-dependent expression. The bottom compartment can be
suppressed; it is usually suppressed on scenario diagrams.
No operations are needed since they are the same for all instances of a class (although a third
section would make sense for a delegation-based language such as self that lack a clear distinction
*This shape may be thought of as a structured cloud.
Unifed Method V0.8
Class Diagram
between class and object). The class name can be omitted during early analysis when it is yet
unknown.
You may show instantiation with a dashed arrow from the object to the class, but the class
name in the object is sufficient and it is rarely necessary to show instantiation visually. The
instantiation arrow may be thought of as a special case of the dependency relationship, and may
be labeled with the keyword instance.
An object can have a multiplicity within an enclosing composite class (Fig. 24). The
multiplicity indicator is drawn as a small integer-range expression in the peak (Fig. 6), such as: 3,
5, 7..13, 19..*. This indicates how many instances of the class can exist at a time within the
containing composite class. The symbol * indicates no upper bound; alone it indicates zero or
more unbounded elements. The default is exactly one object. A set of nondistinguished objects
can also be indicated by a stack icon: a second object symbol outline is placed behind the main
icon, obscured by the main icon and shifted slightly to the upper right (Fig. 6). This format is
more intuitive on scenario or object diagrams.
It is possible to combine a class definition with the specification of a singleton (or multiple)
object by superimposing the class and object symbols (Fig. 25). There is a default composite class
surrounding the entire model representing the system or world, so that an object at the outer
level of a diagram represents a global-level object in the system.
Associations
Associations (Fig. 7) represent structural relationships between objects of different classes,
information that must be preserved for some duration and not simply procedural dependency
relationships. The individual instances of an association are called links; each is a tuple of object
references. Most associations are binary, drawn as solid lines between pairs of classes. Lines may
be orthogonal or oblique; they may be drawn as one or more connected line segments or even
curved segments if desired.*
An association may have a name with an optional small direction arrow (solid triangle with
no tail) showing which way it is read: Foo. An association could have different names in each
direction, but this would be unnecessary and tedious in practice and we do not recommend that
tools support it. The name may be placed on or adjacent to the association line. The name of an
association can be omitted, particularly if rolenames are used.
Each end of an association is a role. Each role may have a name (rolename), showing how its
class is viewed by the other class. The rolenames opposite a class must be unique. The rolename
is placed next to the end of the line. Each role indicates the multiplicity of its class, i.e., how many
instances of the class can be associated with one instance of the other class. Multiplicity is
indicated by a text expression on the role. The expression is a comma-separated list of integer
ranges. A range is indicated by an integer (the lower value), two dots, and an integer (the upper
value); a single integer is a valid range, and the symbol * indicates many, i.e., an unlimited
number of objects. The symbol * by itself is equivalent to 0..*, i.e., any number including
none. An optional scalar role has the multiplicity 0..1. If multiplicity is more than one, the
keyword {ordered} may be placed on the role, indicating that the elements have an explicit order;
otherwise they are an unordered set. The model does not specify how the ordering is maintained;
*This is true of all relationships; whether or not a line has multiple segments or is linear or oblique is a stylistic convention that is matter of personal taste, and as such as no semantic impact. However, as with program language formatting, users are advised to choose a consistent style and stick with it.
Unifed Method V0.8
Class Diagram
the operations that update an ordered association must specify where the updated elements are
inserted. Note that sorting the elements on internal values does not add any semantic information;
it makes sense to indicate {sorted} as a design optimization but it does not change the logical
information, unlike {ordered}.
Self-associations and multiple associations (including multiple self-associations) between a
pair of classes are possible and common. It is important to use association names or role names to
tell them apart; role names are essential on self-associations. Note that drawing two associations
between class A and class B does not mean that the same A and B objects are related twice; a
given A object may be linked to different B objects through each association. Each association is
independent.
Occasionally one class can participate in two associations, but each object can only participate
in one of the associations at a time. This can be shown by placing an or constraint between the
pair of associations (Fig. 8). In this case both associations can be given the same role name since
they both cannot hold simultaneously.
An association class is an association whose elements have attribute values (and possibly
operations and associations too). It is shown by drawing a dashed line from the association line to
a class box that holds the attributes, operations, and associations for the association. The class box
can contain multiple attributes and operations, and associations to it apply to the original
association itself. Each link in the association has the indicated attributes and relationships. The
most common use of association classes is to show associations between classes and associations
(Fig. 9). In principle, the name of the association and class should be the same, but we permit a
tool to use separate names if necessary. A degenerate association class just contains attributes for
the association; in this case omit the association class name to deemphasize its separateness (Fig.
10).
A qualified association is a variant form of association attribute (Fig. 11). A qualifier is an
association attribute value(s) that is unique within the set of links associated with an object in the
association. In other words, an object and a qualifier value identify a unique object across the
association; they form a composite key. The qualifier is part of one role of the association;
qualification is not symmetric. Qualification usually reduces the multiplicity of the opposite role;
the net multiplicity shows the number of instances of the related class associated with the first
class and a given qualifier value. Often the new multiplicity is 0..1, i.e., any qualifier value selects
a unique associate but not all qualifier values are used. A multiplicity of 1 would indicate a
mapping from all values of a finite qualifier domain to unique objects. During design it is useful to
allow qualified associations to have multiplicity many to indicate an index that selects sets of
objects by the qualifier value, i.e., a dictionary or look-up table. Qualifiers are drawn as small
boxes on the end of the association attached to a class. They are part of the association, not the
class. A qualifier box may contain multiple qualifier values; the qualification is based on the entire
list of values.
Aggregation is a special form of association with the connotation of whole-part
relationship. It indicates that the lifetimes of the parts are dependent on the lifetime of the whole.
It does not indicate a particular kind of implementation or navigation direction. It is indicated by
placing a diamond on the role attached to the whole object. Mathematically it indicates that the
association is transitive and antisymmetric. If you are not sure when to use it, ignore it and stick to
plain associations. Note that recursion is a use of aggregation that requires the transitiveantisymmetric property. (Fig. 12)
Unifed Method V0.8
Class Diagram
The multiplicity of an aggregate can be one (or optional-one) or many. A multiplicity of one
indicates a physical aggregation; a part cannot be part of more than one whole. A multiplicity of
many indicates a catalog aggregation; a part model in a catalog can be used in many different
assembly models. Additional notation is not needed to distinguish these two cases; the
multiplicity is sufficient.
An optional style to show aggregation is to combine all of the parts of a given aggregate into a
tree with one root segment with a diamond and many tails. Each tail can have its own multiplicity.
(Fig. 13) This is simply a stylistic convenience which may be applied to groups of relationships,
such as among a superclass and its subclasses; it has no new semantic consequences and may be
avoided entirely if desired.
Ternary (or higher order) associations are drawn as diamonds with one line path to each
participating class (Fig. 14). This is the traditional entity-relationship model symbol for an
association. The binary form is drawn without the diamond for greater compactness, since they
are the bulk of associations in a real model. Ternary associations are fairly rare and can also be
modeled by promoting them to classes. Ternary associations can have link attributes (attach the
arc to the diamond). Roles may have rolenames but multiplicity is more complicated and best
specified by listing candidate keys. If given, the multiplicity represents the number of instances
corresponding to a given tuple of the other N-1 objects. Most uses of ternary associations can be
eliminated using qualified associations or association classes. They can also be replaced by
ordinary classes, although this loses the constraint that only one link can occur for a given tuple of
participating objects.
The navigability property on a target role indicates that the implementation should make it
straightforward to navigate from a class to the target class across an association.* This is normally
implemented using a pointer from one class to another, although a hash table implementation is
also reasonable. It is inherently a design and implementation property. It is indicated by the
physical implementation adornment, which is a small square placed on the target end of the
association line next to the target class (the one being navigated to). If the square is hollow, it
indicates a by-reference implementation (i.e., a pointer or other reference); if the square is filled, it
indicates a by-value implementation, i.e., a class that is embedded within another class (Fig. 15).
When in doubt, use by-reference semantics, since they are more general.
Navigation expressions
We provide a simple expression language for describing class diagram paths within pseudocode
expressions. A dot . shows accessing an attribute value or traversing an association:
person.employer. The expression denotes a scalar or a set of values depending on the multiplicity
of the association. An expression in brackets shows selection of values from a set:
todaysFlights:= flights[flight.date=today]. For a qualifier, it indicates selecting the associated
object with the given qualifier: aFile:= directory.files[filename]. Note that an array can be
modeled as a qualified association with integer qualifiers. A tilde indicates inverse traversal of an
association from a class with the given rolename: pilotFlights:= aPilot.~pilot. This usage
requires that the incoming role names attached to a class be unique.
*In the absence of any such adornment, the association is regarded as bidirectional. The placement of a single navigability property limits the association to being unidirectional An editing tool can easily make the
adornments totally explicit on demand.
Unifed Method V0.8
Class Diagram
Inheritance
Inheritance is the taxonomic relationship between a superclass and its subclasses. It is often
called generalization or specialization depending on whether one is going from the subclasses to
the superclass or from the superclass to the subclasses. It is drawn as a solid line from subclass to
superclass with a large filled triangular arrowhead on the superclass end (Fig. 16). For stylistic
conventions the subclass lines may be drawn as a tree sharing a single line to the triangular
arrowhead. All attributes, operations, and associations are inherited by all subclasses.
Normally the subclasses represent different alternatives; generalization is often called the orrelationship. This is in fact the dominant use of inheritance. However, sometimes a class can be
specialized on several different dimensions simultaneously; a concrete object must participate in
all the dimensions and so represents a Cartesian product of the different dimensions. This is called
an and-generalization and is shown by connecting the inheritance arrows with a dashed line
labeled with the keyword and (Fig. 17). Each subclass represents a different mandatory aspect of
the superclass. Each and-subclass can be specialized into its own subtree; a concrete descendent
class must be chosen by multiple inheritance from each of the subtrees. However, even if the
combinations are not explicitly shown, they are implicit. It is sometimes useful to give a name to
the implicit enumeration-type value that goes across the subclasses of a class; we call this implicit
attribute a discriminator. It is particularly useful in generating database schemas. To indicate a
discriminator, draw a dashed line across all the inheritance lines and label it with the name of the
discriminator.
Generally subclasses are disjoint but sometimes they can overlap. The use of overlapping
subclasses implies that they can be combined using multiple inheritance (Fig. 18). To show
multiple inheritance, simply draw multiple inheritance relationships from a given subclass. Note
that a common ancestor is inherited once even though it may appear on several paths (a virtual
base class, in C++ terms). Various language-dependent options (such as virtual vs. repeated
inheritance, public vs. private inheritance, etc.) can be shown as text annotations on the
inheritance line. We do not provide notation to distinguish overlapping subclasses; they are
implicit if they are used in multiple inheritance and irrelevant otherwise.
Multiple inheritance can also occur when a subclass has two superclasses that share no
common ancestor. The use of mixins is a form of multiple inheritance.
An abstract class is one that may not have direct instances (because it has deferred operations,
for example). An abstract class can be specified with the property abstract as shown in Fig. 16.
As a matter of style, many developers prefer to treat all non-leaf classes as abstract. Any concrete
intermediate-level class can be easily converted to an abstract class by adding a new concrete
subclass equivalent to none of the other subclasses
Constraints
The symbols previously described together with annotations for particular programming language
constructs are sufficient for generating class declarations in most languages. Sometimes you also
want to restrict the values that objects or links can assume. A constraint is a restriction on values
expressed as an arbitrary expression attached (implicitly on paper) to a class or association. A
constraint may be written as text within braces, either free standing or embedded in a note
attached to the affected elements. For binary constraints, a dashed dependency line may be drawn
between the affected elements; the line is labeled with the constraint string enclosed in braces.
Navigation expressions are handy for writing constraints (Fig. 19). Notes can also be used for
placing arbitrary comments on diagrams and for showing implementation code for operations.
Unifed Method V0.8
10
Class Diagram
Generally it is best to avoid redundancy in object models, but sometimes it is useful to show a
redundant value or association that can be derived from other elements. To indicate a derived
entity, place a slash (/) in front of the name of the derived entity and write a constraint defining
its value. (Fig. 20)
Categories
Large models require internal organization. A category is a subset of the model itself (Fig. 21).
Each category owns some of the classes, associations, and generalizations of the model, as well as
portions of the other model views and the actual code. Categories are purely organizational; they
have no logical semantics, although they may be organized along semantic lines.Categories do
have a scoping impact, for they define a name space. Categories can be nested, so the a category
for the entire system is the root of the model tree. Each class has a home category where its
internal details are defined; this category owns the class. A class can also appear in the context
of another category as an imported occurrence. The annotation CategoryName::ClassName can
be used to signify a class owned by a different category. Ownership of model elements would be
used for configuration control, versioning, and division of work among parallel workers.*
A category is drawn as a rectangular box with a double outline.** Dependencies between
categories are shown by dashed arrows between them, with the tail on the client (dependent)
category and the arrowhead on the supplier (independent) category (Fig. 21). Dependencies may
be shown between classes and categories but this is usually too fussy and verbose in practice.
A category diagram is a kind of class diagram showing only categories (the classes are
suppressed). Decomposition of a category into smaller categories can be shown in two ways: by
nesting categories inside larger categories (Fig. 21) or by using the aggregation syntax to
externalize the nesting (Fig. 22). The inheritance symbol is used to show variant versions of a
category; normally only one version at a time would be linked into an executable program,
although this is not mandatory.
A category interface diagram is a kind of class diagram showing categories and their public
classes and public relationships (Fig. 23). The public operations can be shown in the class boxes,
but usually it is better to simply list them in a table to avoid clutter. Several categories can be
shown on one diagram, but often one diagram will be used for each subsystem.
The full details of a category can be shown on a class diagram showing all the contents.
Generally it is best to work with one category at a time at the detailed level, but several can be
shown at once if necessary.
As an organizational element, categories provide the home for other modeling elements, such
as use cases.Thus, the root category of a system may have associated use cases (which specify the
behavior of the system as a whole), and lower-level categories may have associated use cases as
well (denoting the behavior of segments of the logical architecture).
*The location of the home of a class has no inherent semantic significance, but it may impose restrictions
on the kinds of visibility it can have. A category should have some meaning to the modeler, of course.
**This is similar to the style in Booch, but with a slight modification to distinguish categories from classes.
Unifed Method V0.8
Class Diagram
11
Composites
A class defines a context within which instances of other types can be instantiated and used. The
attributes of a class are defined within this context. More generally, a class may define a pattern of
objects and links that are part of it and that exist whenever the class is instantiated. Such a class is
called a composite. It is a class that contains an object diagram. It may be thought of as an
extended form of aggregation where the relationships among the parts are valid only within the
composite. A composite is a kind of pattern or macro that represents a conceptual clustering for a
given purpose. Composition is shown by drawing a class box around its embedded components
(Fig. 24), which are prototypical objects and links. That is, a composite defines a context in a
which references to classes and associations defined elsewhere can be used. A composite is a class
that has identity. All the objects and links contained within a composite box take identity from the
composite; they must all be part of the same instantiated object. (Under some circumstances an
object might be regarded as part of two parallel, independent object composition hierarchies, but
this kind of modeling is tricky and best suited to conceptual views.) However, a link that crosses
the composite boundary connects objects from two different composites. Multiple objects of the
same class may appear within a single composite; they may have different names and may
participate in different relationships.
The multiplicity indicator in an object icon shows the number of instances of the object within
one instance of the composite object. The default is one. You can assume an implicit system
composite object encloses the entire model.* In an abstract (high-level) view, the classes and
internal associations of composites may be suppressed and associations between classes of
different composites may be elided to the composites themselves (Fig. 24)
A class can also encapsulate embedded class definitions. Simply embed a class box inside the
encapsulating class box. If an instance of the embedded class occurs as a fixed part of the
encapsulating class, the class and object icons can be combined into a single symbol (Fig. 25).
Recall that a many objects of the same class may occur in a single composite, and that objects
of the same class can be used in different composites. In such cases keep the definition of the class
distinct from the reference to the class by each object. However, sometimes there is only one
reference to a given class definition; in that case, the class icon and object icon may be combined
into a single icon for convenience (Fig. 25). This is the way to represent singleton classes of
Embley.
Although the examples here do not address this, composites are also applicable in
distinguishing threads and processes, as well as clusters of objects that are physically distributed
together.
*This is in fact the style taken in the use case diagram.
Unifed Method V0.8
12
Class Diagram
Figure 1. Class
Polygon
center: Point
vertices: List of Point
borderColor: Color
fillColor: Color
Polygon
display (on: Surface)

rotate (angle: Integer)
erase ()
destroy ()
select (p: Point): Boolean
ZWindows::Window
Figure 2. Visibility and scope of attributes and operations

(user interface)
Window
abstract
+size: Area = (100,100)
#visibility: Boolean = invisible
+$default-size: Rectangle
#$maximum-size: Rectangle
-xptr: XWindow*
+display () {abstract}
+hide () {abstract}
+$create () {abstract}
-attachXWindow(xwin:Xwindow*)
Figure 3. Parameterized classes

T,n:Integer
FArray
FArray<Point,3>
FArray<Address,24>
FArray<Name,100>
Unifed Method V0.8
Class Diagram
13
Figure 4. Utility
MathPack
randomSeed: long = 0
pi:long = 3.14159265358979
sin (angle: double): double
cos (angle:double): double
random (): double
return sin (angle + pi/2.0);
Figure 5. Object
triangle1: Polygon
center = (0,0)
vertices = ((0,0),(4,0),(4,3))
borderColor = black
fillColor = white
Polygon
Figure 6. Multiobject
Controller
Window
Unifed Method V0.8
Controller
14
Class Diagram
Figure 7. Association notation

husband 0..1
Company
name
address
Works-for
0..1
wife
Person
employer employee
name
Employs
social security number
address
worker
Married-to
boss
0..1
Manages
3..
Contains
Polygon
Point
{ordered}
Figure 8. Or-association.
or
Account
Person
holder
1
Company
Figure 9. Association class
User
Authorized on
Workstation
Authorization
priority
privileges
start session
1 home directory
Directory
Unifed Method V0.8
Class Diagram
15
Figure 10. Association attribute

Company
name
address
Owns-stock
Person
name
birthdate
address
quantity
Figure 11. Qualified association

Airline
Chessboard
frequent flyer #
rank:Rank
file:FIle
1
1
0..1
Person
Square
Catalog
part number
1
0..1
Part
Figure 12. Aggregation in recursive structure

1..
Block
Compound
0..1 statement
Unifed Method V0.8
Simple
statement
16
Class Diagram
Figure 13. Aggregation tree notation

Window
1
1
TitleBar
0..2
Pane
ScrollBar
Border
1
Close button
Title
Arrow
1
Indicator
Figure 14. Ternary association

Reservation
Flight
seat
flight
Seat
passenger
date
number
location
Person
name
Figure 15. Navigability/implementation adornment

1
Contains
3..
Polygon
Point
{ordered}
1
1
GraphicsBundle
color
texture
density
Unifed Method V0.8
Class Diagram
17
Figure 16. Inheritance

Figure1dim
Figure1dim
abstract
abstract
color
display {abstract}
Line
endpoints
display
Arc
radius
start angle
arc angle
display
color
display {abstract}
Spline
control pts
endpoints
display
display
Line
Arc
radius
start angle
arc angle
display
Spline
control pts
display
Figure 17. Parallel inheritance
Vehicle
venue
propulsion
and
Vehicle
Propulsion
Muscle
Powered
Wind
Powered
Motor
Powered
Muscle
Water
Vehicle
...
Canoe
Unifed Method V0.8
Vehicle
Venue
Kayak
Water
Vehicle
Land
Vehicle
Air
Vehicle
...
Rowboat
RacingShell
18
Class Diagram
Figure 18. Overlapping subclasses

Vehicle
LandVehicle
Car
WaterVehicle
AmphibiousVehicle
Boat
Figure 19. Constraints
Person
Member-of
worker
Chair-of
employee
Person
0..1
boss
Committee
subset
1
employer
0..1
Company
{Person.employer =
Person.boss.employer}
Figure 20. Derived values

Person
birthdate
/age
{age = currentDate - birthdate}
1
Company
Department
1
Employs
Person
/Employs
{Person. company =Person.department.company}
Unifed Method V0.8
Class Diagram
19
Figure 21. Categories (nested form)

Editor
Controller
Diagram
Elements
Domain
Elements
Graphics
Core
Windowing
System
Motif
Microsoft
Windows
Figure 22. Categories (tree form)
Editor
Controller
Domain
Elements
Diagram
Elements
Graphics
Core
Windowing
System
Motif
Unifed Method V0.8
Microsoft
Windows
20
Class Diagram
Figure 23. Category interface
Graphics Core (Public Interface)
Window: imported
1
part of
Canvas
Rectangle
Graphic
Unifed Method V0.8
displayed in
Line
Graphic
Graphic
Element
Ellipse
Graphic
Text
Graphic
Class Diagram
21
Figure 24. Composites

connected-to
Detailed View
Traffic Light
Lamp
Central Control
1
1
Controller
1
coordinated-by
Weight
Sensor
Console
Traffic Light
Visual
Sensor
1
Computer
Abstract View
Central Control
coordinated-by
connected-to
Figure 25. Category composite
Printer
1
1
PrinterController
Queued
print(File):Job
Unifed Method V0.8
Job
status():Status
kill()
22
Use Case Model
3. Use Case Model

A use case is a generic description of an entire transaction involving several objects. A use case
can also describe the behavior of a set of objects, such as an organization. A use case model thus
presents a collection of use cases and is typically used to specify or characterize the behavior of a
whole application system* together with one or more external actors that interact with that
system.
An individual use case may have a name (although it is typically not a simple name). Its
meaning is often written as an informal text description of the external actors and the sequences of
events between objects that make up the transaction. Instances of this behavior may be formally
specified using scenarios, but iteration and conditionality within scenarios is usually best
expressed as informal text.
A scenario is an instance of a use case. Each scenario provides a prototypical thread through
its associated use case; a given use case is typically characterized by multiple scenarios.** Both
use cases and their associated scenarios can be regarded as models for viewing purposes that can
be derived from or built upon more fundamental models. As such, they represent the emergent
behavior of the system.
A top level use case diagram is helpful in visualizing the context of a system (or a part of a
system) and the boundaries of the systems behavior.*** A use case diagram shows the set of
external actors and the system use cases that the actors participate in, as in Fig. 26. A use case
diagram contains a composite representing the system containing the use cases that it supports;
each use case is connected to the external actors (which are objects) that use it. The use cases are
drawn as ellipses within the icon for the system object. The actors are drawn as object icons
outside the system icon; solid lines connect the actors to the use cases that they participate in. For
further detail, each participation relationship can be labeled with message flows (messages
attached to arrows) showing the messages or events exchanged between each actor and each use
case.
Use cases can include other use cases as part of their behavior. A dashed arrow from one use
case to another indicates that the first use case includes the behavior of the second use case as part
of its behavior; the arrow can be labeled if more detail is needed.****
*Or a part of an application system, as in the situation whereby we attach use cases to non-root categories.
**These scenarios may themselves be classified under a given use case. For example, it is common to distinguish between primary and secondary use cases, representing main line functions versus the systems
behavior in the presence of exceptional conditions. These categories of scenarios may be denoted by a
property (much as how one may use this classification property to distinguish kinds of attributes and
operations in a class, e.g. design attributes)
***Such a diagram in effect provides a context for the system as a whole. This top-level context diagram
also provides a common and simply entry point to all of the other models that characterize a systems
requirements, architecture, and implementation.
****Jacobsons distinction between uses and extends can be indicated. Inheritance and aggregation relationships among uses cases seem theoretically interesting, but it is not yet clear whether these relationships are
useful in practice. We expect to explore this issue further with Jacobson.
Unifed Method V0.8
Use Case Model
23
Figure 26. Use Cases for Bank

Bank
Clear
checks
Prepare
statements
Counter
transaction
Clerk
Customer
Identify
Loan
application
Auditor
Audit
Print
report
Unifed Method V0.8
Loan officer
Manager
24
Message Trace Diagram
4. Message Trace Diagram

A scenario shows a particular series of interactions among objects in a single execution of a
system; it describes a single history without conditionality.* Scenarios illustrate interactions that
are inherent in the underlying behavior of the associated objects but whose overall form is not
apparent in their isolated behavior. State diagrams may be used for specifying the behavior of a
class of objects, whereas, scenarios are for understanding how such objects collaborate.
Scenarios can be shown in two different ways containing the same information but organized
around different dimensions. A message trace diagram** shows the interactions among a set of
objects in temporal order, which is good for understanding timing issues. A text dialog can
accompany or replace such a diagram. An object message diagram*** shows the interactions
among a set of objects as nodes in a graph, which is good for understanding software structure,
since the interactions that affect an object are localized around it. Ultimately, both forms build
upon the same underlying semantics, and so it is possible to transform one view to the other
without loss of information.
A message trace diagram (Fig. 27) is drawn as follows: Objects (not classes) in a transaction
are drawn as solid vertical lines; their names are shown at the top. The line begins when the object
is created and ends when the object is destroyed. An event or a message dispatch is drawn as a
labeled horizontal arrow from the sending objects line to the receiving objects line.**** Time
proceeds vertically, so event timing sequences can be easily seen. An object can send
simultaneous events to other objects; simultaneous reception of events is not meaningful and
should be avoided. To indicate events that require time to deliver, the event line can be slanted
downward so that the sending and receiving times are distinct (Fig. 28). A string label can be
placed even with the end of a message arrow; this is a timing mark that, a formal parameter that
designates the time at which the message is sent or received (Fig. 28). Timing marks can be used
in timing constraints, which are Boolean expressions that may be placed in braces and attached to
the diagram.
A special form of message trace diagram (a focus-of-control diagram) shows the period of
time when an object has a thread of control as a double (fat) line; a single line indicates an
object that is blocked waiting for an event (Fig. 29). Focus-of-control diagrams are good for
showing procedure calling sequences in which there is a single locus of control at one time; they
are not so useful to fully concurrent systems because all objects are always active.
Normally on a procedural scenario, only calls are shown, the returns being implicit. However,
both calls and returns can be shown, which may be helpful if there is a lot of recursion (Fig. 30).
A distinction can also be made between in scope and in control. As with object message
diagrams, data flows may be represented as well.
*In a fully implemented system the scenarios are implicitly derivable from the underlying state machines
and procedure code; they represent emergent behavior. In practice the scenarios are often written before the
low-level design is completed, so they serve a very real independent purpose in the design process.
**Jacobson calls these interaction diagrams.
***Originally called an object diagram in Booch.
****Other forms of synchronization symbols are permitted, as in object message diagrams.
Unifed Method V0.8
25
Figure 27. Event trace diagram
Caller
Phone Line
Callee
caller lifts receiver

dial tone begins
dial (9)
dial tone ends
dial (1)
time
dial (1)
ringing tone
phone rings
answer phone
tone stops
ringing stops
Figure 28. Timing marks and events that take time

Phone
a
{b - a < 1 sec.}
b
Exchange
lift receiver
dial tone
< 10 sec.
{c - b < 10 sec.}
c
dial digit
...
route
{e - d< 5 sec.}
e
Unifed Method V0.8
26
Figure 29. Event trace with focus-of-control regions

A
f()
create
time
g()
h()
destroy
Figure 30. Event trace with explicit returns and in-control regions
A
f()
create
time
g()
return
h()
return
return
Unifed Method V0.8
destroy
Object Message Diagram
27
5. Object Message Diagram

An object message diagram is a scenario diagram that shows the sequence of messages that
implement an operation or a transaction. Whereas message trace diagrams emphasize the
temporal flow of behavior, object message diagrams emphasize relationships.An object message
diagram is thus a time lapse photograph of this behavior: the object message diagram shows the
objects and links that exist just before the operation begins and also the objects and links created
(and possibly destroyed) during the operation. It may be useful to distinguish the old and new
elements by some graphic mark, such as color; on monochrome diagrams newly-created elements
can be distinguished with the keyword new. Fig. 31 shows a sample object message diagram.
An object message diagram can include both permanent links, i.e., those that correspond to
associations, as well as temporary links, i.e., those that correspond to procedure arguments or
local variables. If necessary, the nature of the link can be distinguished by placing an
implementation adornment within a small square on the end of the link line attached to the target
class. The adornments can have the following values:
A - association link
F - object field (the target object is part of the source object)
G - global variable
L - local variable
P - procedure parameter
S - self reference
Rolenames can also be used to distinguish links. An ordinary rolename indicates an association
navigable toward the rolename. A rolename in parentheses indicates a temporary link, i.e., one
that is not an association. The absence of a rolename indicates a link that is not navigable in the
given direction. A tool can use a variety of notations together with more dynamic means to show
implementation properties.
A message from one object to another is indicated by a label consisting of a text string with an
arrow showing the message flow direction; the label is drawn next to the link that is used to send
the message. Multiple messages can be attached to the same link, in the same or opposite
directions. Normally a link should be sent to a single object. However, if a message selects from
or scans over a set of objects, then the link should be sent to a multiobject icon, drawn as a stack
of object icons (Fig. 6). The label on a message may contain the following elements (some
optional):
1. A comma-separated list of sequence numbers in brackets: [seqno, seqno]. The sequences
numbers indicate messages from other threads of control that must occur before the current
message can occur. This element is only needed with concurrent flow of control.
2. A sequence number containing a list of sequence elements separated by dots. These represent
the nested procedural calling sequence of the message in the overall transaction. Each element
section has the following parts:
a. A letter (or name) indicating a concurrent thread. All letters at the same level of nesting
represent threads that execute concurrently, e.g., 1.2a and 1.2b are concurrent. Omitting the
letter entirely is equivalent to another dummy letter and usually indicates the main
sequence. With procedural flow of control concurrent threads can be executed in any
relative order.
b. An integer number. The numbers show the sequential position of the current message
Unifed Method V0.8
28
within its thread. The overall nested calling sequence is in Dewey Decimal notation. For
example, message 2.1.4 is part of the procedure invoked by message 2.1 and follows
message 2.1.3 within that procedure.
c. An iteration indicator. This is a star (*), optionally followed by an iteration expression in
parentheses. Iteration indicates that several messages of the same form are sent either
sequentially (to a single target) or concurrently (to the elements of a set). If there is an
iteration expression, it shows the values that the iterator or iterators assume, such as
(i=1..n); otherwise the details of the iteration must be specified in text or simply deferred
to the code.
d. A conditional indicator. This is a question mark (?), optionally followed by a Boolean
expression in parentheses. The iteration and conditional indicators are mutually exclusive.
(This option is still under evaluation.)
3. A return value name (or values, if you like multi-valued expressions) followed by an
assignment sign (:=) If present, this indicates that the procedure returns a value designated by
the given name. The use of the same name elsewhere in the diagram designates the exact same
value. If no return value is specified, then the procedure operates by side effects.
4. The name of the message. This is an event name or an operation name. It is unnecessary to
specify the class of an operation, since this is implicit in the target object.
5. The argument list of the message. The arguments are expressions defined in terms of input
values of the nesting procedure, local return values of other procedures, and attribute values of
the object sending the message.
Note that you can also use these labels on a message trace diagram, but the physical nesting
may make sequence numbers unnecessary.
Argument values and return values for messages may optionally be shown graphically using
small data flow tokens near a message (Fig. 32). Each token is a small circle labeled with the
name of the argument or result bearing an arrow showing the direction of data flow (arguments:
same direction as message, results: opposite direction as message). This is more verbose than text
arguments and returns and best reserved for special situations.
Concurrent Object Message Diagram
A concurrent object message diagram shows the flow of control in the presence of concurrency
(Fig. 33). In such a diagram more than one locus of control can exist at a given time, each in an
active object. An active object is an object that maintains its own state and exchanges
asynchronous events with other active objects. We may indicate an active object by setting an
appropriate property. (We are still considering the proper graphical notation.) An active object is
essentially a composite that can contain other objects (including other active objects). Any
passive objects in it are under the control of the active object; they are accessed with procedure
calls, not true asynchronous events between independent objects.
Messages between active objects follow links just like messages between passive objects. For
clarity, such asynchronous messages are drawn with a half-arrowhead to indicate a one-way
asynchronous flow of control. The sender of an asynchronous message does not wait for a return
but proceeds to the next message (if any) or possibly waits for some future message. A full
arrowhead indicates a procedural flow of control. Other control regimes, such as balking and
timeout calls, can be indicated using traditional Booch symbols.
The flow of control in a concurrent object message diagram can branch and merge. It has the
form of a partially-ordered graph. The number of loci of control varies at different times. A
Unifed Method V0.8
29
simple sequential numbering system is not sufficient to represent a partial order, but several other
schemes will work. Here is one possible scheme:
There can be multiple control threads. Each is indicated by an initial letter (or name) followed
by a sequence number (such as B3). Each letter defines a separate thread (there is also a main
thread for labels without initial letters). Within a thread, messages occur in sequential order, for
example, B3 follows B4. Different threads are potentially concurrent, subject to explicit
dependencies. Dependencies between different threads are specified explicitly: [B2]C4
indicates that message C4 follows messages B2 (explicitly) and C3 (implicitly).
Within a concurrent object message diagram, procedural messages to passive objects can be
shown in the usual way using nested numbers and full arrowheads. Nested procedural flow of
control is part of a single locus of control that eventually terminates at a top level active
subsequence.
Fig. 33 shows a sample concurrent object message diagram for a factory control system with 3
active threads. The active threads contain passive parts, both hardware parts (such as oven doors
and robot arms) and data parts (such as transfer jobs), as well as controllers (such as the manager
object in each active object).
Figure 31. Object message diagram
redisplay()
window
Window
Controller
1: displayPositions(window)
wire
1.1.3.1: add(self)
new contents
temp (line)
1.1*(i=1..n): drawSegment(i)
Wire
1.1.2: create(r0,r1)
1.1.3: display(window)
(self)
i-1
(window)
new Line
i
1.1.1b: r1:=position()
1.1.1a: r0 := position()
A
Bead
Bead
Figure 32. Data flow tokens on message

window
Controller
Unifed Method V0.8
Window
1: findLines
region
lines
30
Figure 33. Concurrent object message diagram
temp (job)
Transfer
temp (job) Job
temp (job)
job
(active)
(active)
Factory Manager
Factory
Scheduler
1 start(job)
[A7,B6] 2 completed(job)
(active)
Factory
JobMgr
A2.1 self:=copy()
B2.1 self:=copy()
[1]A1 start(job)
[1]B1 start(job)
A7 completed(job)
B6 completed(job)
new
Robot
Transfer
Job
new rjob
A2 rjob:=
copy(iob)
A3.1 location:=
get_location()
RobotMgr
A3.2 moveTo(location)
[B4]A4 takeMaterial
A5 removeArm()
B4 ready
B2 ojob:=copy(job)
OvenMgr
A6 done
B3 openDoor()
[A6]B5 closeDoor()
(active)
Robot
Unifed Method V0.8
new ojob
new
Oven
Transfer
Job
(active)
Robot
Arm
Oven
Door
Oven
State Diagram
31
6. State Diagram
The state diagram describes the temporal evolution of an object of a given class in response to
interactions with other objects inside or outside the system. Each class may have a state diagram
to describe its dynamic behavior, although not all classes have interesting dynamic behavior
(most have exactly one state with the same response always). Each state diagram is associated
with one class or with a higher-level state diagram. In practice most of the objects in a system do
not undergo significant state changes, so only a minority of classes require state diagrams. (This
may not be true for problems that are heavily control-based, in which the dynamic model is
dominant.) The state diagram notation that we use was adopted from David Harel with some
minor modifications.
State diagrams are formal specifications of the behavior of a class. Scenarios are examples of
execution of a system. They may involve several objects playing various roles. Since they are
instances of behavior, they illustrate but cannot ultimately define behavior; they can ultimately be
derived from the entire set of state diagrams. A scenario is an instance of a use case, which may
be thought of as a slice of system behavior across state diagrams from multiple classes.
State Diagrams
A state diagram (Fig. 34) is a directed graph of states (nodes) connected by transitions (directed
arcs). A state diagram describes the life history of objects of a given class. It describes all possible
ways in which the objects respond to events from other objects. Normally state diagrams would
also be used for objects that receive external events from actors outside of a system. Such objects
are usually controllers, i.e., objects whose business is to maintain the system and control other
objects.
State diagrams can also be used to show the life history of objects that undergo sequences of
operations that take the objects into several fundamentally different states.* They can even be
used to show the internal flows of control in the implementation of an application, in which case
the events correspond to procedure calls (messages). During analysis this level of detail should be
avoided.
If an object always responds the same way to external stimuli, then it is modeless and can be
simply described by a table of events and corresponding operations. Since there are no states, the
different rows in the table are independent of each other, which makes the behavior much simpler.
Of course, any graph can be expressed as a table.
Events
Events are the most fundamental concept in the dynamic model; states can be considered a
derived concept. An event is an occurrence at a point in time; a state is a period of time during
which an object is waiting for an event to occur. The granularity of time depends on the degree of
abstraction and can vary at different levels of the same application, but basically an event is
something that is atomic, i.e., non-interruptible, at the given level of abstraction. A event is a oneway asynchronous transmission of information from one object to another and can have
parameters with names and types. The general format of an event is:
*This follows the approach used in Shlaer/Mellor and in SSADM.
Unifed Method V0.8
32
State Diagram
eventName (parameter:type, ...)

Many events have no associated parameters. If there are no parameters, the parameter list may be
omitted.
A two-way information flow (i.e., call-and-return) can always be modeled as two one-way
information flows, so there is no need to provide notation for them, as they are not fundamental.
Synchronous transmission is a special case of asynchronous transmission and should be modeled
as such; in distributed systems you cannot count on synchronous behavior anyway.
The full specification of an event could optionally include: name, list of parameters, sender
and receiver objects, description of event meaning, implementation mechanism, and timing of
event delivery.
Events can be arranged into a taxonomy and modeled by a class diagram (Fig. 35). Although
events are shown as classes in such a diagram, they have special semantics and should be labeled
with the event stereotype. The attributes in the class diagram are the event parameters.
However, it is best to think of classes as the implementation of events and to treat events as a
distinct semantic entity. A subevent inherits the parameters of its ancestors and adds its own
parameters. A subevent triggers any transitions that depend on any of its ancestor events.
An event name that is a time period (such as 10 sec.) is a convention for an elapsed time event
(Fig. 34). This indicates an event that occurs at a given elapsed time after the current state is
entered. The mechanism of implementing such an event would involve setting and resetting
timers, but there is no need to bother with this internal complexity in the specification, since timeout events are common in practice. The sender of a timer event is the environment rather than
any individual object.
States
Each state represents a period of time during which an object is waiting for an event to occur. A
state is drawn as a rounded box containing the (optional) name of the state. A state box can
contain two additional sections, one section containing a list of state variables and the other
section containing a list of triggered operations (Fig. 36). The sections can be separated by lines
for clarity as in a class box [change].
A state variable is an attribute that is valid while the object is in the state (or any nested
substates) and that is meaningless elsewhere. It can have a name, type, and initial value, like any
attribute:
name: type = value
State variables can be accessed and modified by operations within the state, including entry and
exit operations.
State variables are attributes of the object described by the state diagram. We single out as
state variables those attributes that affect the flow of control, since state diagrams are concerned
with control. They are a convenience to highlight the attributes affecting the flow of control.
Substates
States can be refined into disjoint substates exactly as classes can be refined into disjoint
subclasses. The meaning is the same or-relationship in both cases: an object in superstate A is
either in substate A1 or A2 or A3 or so on. Although the relationships are similar, we draw
Unifed Method V0.8
State Diagram
33
substates by nesting them inside the superstate box to avoid confusion between substate lines and
transition lines (Fig. 34). An alternative notation using the generalization tree symbol is possible
but generally less clear.
A substate inherits the properties of its superstate: state variables and transitions (internal and
external). More precisely, outgoing transitions are inherited. If an event is received by an object in
a given substate, all transitions on all enclosing states are potentially applicable, provided they
have not been overridden by transitions on inner states. Incoming transitions are not inherited,
since they point to a specific state.
Composite States
A composite state is like a composite object: a high-level view on a model that can be expanded
into lower-level detail (Fig. 37). At a high level, a composite state is a single state, with one or
more transitions entering and leaving it. At an expanded level of detail, a composite state contains
several lower-level states responding to lower-level transitions. The lower-level events are not
visible at the higher-level of abstraction.
A composite state has a default starting substate. Any transition to the composite state itself
(at the higher level of abstraction) represents a transition to the default starting substate. A starting
substate is drawn as a circle. A termination substate is drawn as a bulls-eye.
A composite state can return an event on a terminal state, using the send event notation
(Fig. 37), since the object is sending an event to its higher-level self. This means that the
execution of the sequence leading to the termination state is a detailed equivalent of receiving the
higher-level event in the higher-level state diagram.
Although the concepts of state generalization and state aggregation are distinct from the
concept of composite states, it is rarely useful to separate them, so nesting in a state diagram for
generalization or aggregation also implies a composite state.
Concurrency
Most concurrency arises by aggregation: a composite object contains several parts, each of which
has its own state. The state of the overall composite object is the Cartesian product of the
individual states. No additional notation is needed in this case.
We also provide an explicit notation for concurrency within a state without using object
aggregation. A state can have multiple explicit loci of activity, i.e., multiple threads of control.
The number of threads can vary among the states of the same object, i.e., the amount of
concurrent activity can vary from moment to moment. Concurrent substates are shown by
partitioning a state into regions with dashed lines (Fig. 38). Each region is a concurrent substate.
When the enclosing state is entered, there is one thread for each substate.
Splitting or merging of concurrent threads can be shown by a synchronization bar, which is
a short heavy line which can have one or more incoming and outgoing transitions attached to it
(Fig. 39). It is unnecessary to show explicit transitions into a subregion that starts in its default
starting state, a usual occurrence (Fig. 38).
A transition from a concurrent substate to a state outside the enclosing superstate terminates
any parallel substates by a forced exit (Fig. 38). Arrows from several parallel states can merge to
indicate that all of the indicated states must hold to enable the transition (Fig. 39). An unlabeled
transition from the enclosing superstate indicates that all the substates must have reached their
terminal substates for the transition to occur (Fig. 38).
Unifed Method V0.8
34
State Diagram
Concurrent objects can interact explicitly by sending events. They can interact implicitly if
one object has a guard condition that depends on the state of another object, such as being in a
given state: object.in (state).
A satisfactory model of concurrency is as follows: An atomic object can be thought of as a
finite-state machine with a queue for incoming events. New events go on the queue until the
object is free to deal with them. Composite concurrent objects contain several atomic objects as
parts, each of which maintains its own queue and thread of control.
Transitions
A transition is a response to an external event received by an object which is in a certain state. A
transition may invoke an operation and may cause the object to change to another state. An
external transition leads to a new state and may invoke an operation. A internal transition
invokes an operation without causing a change of state.
Transitions leading from the current state of an object are eligible to be triggered by an event
received by the object. The trigger for an event includes an event name and an optional guard
condition. The event may have parameters, which must be the same for all occurrences of the
same event name. The values of the event parameters are available to operations triggered by the
event.
A guard condition is a Boolean expression in terms of trigger event parameters, state
variables, and functions of the controlling object. If the event occurs and the value of the
expression is true, then the transition occurs, otherwise the transition does not occur. The same
event name can be used for more than one transition from the same state, but they must have
different guard conditions. In principle no more than one guard condition should evaluate to true,
but in practice any conflicts can be resolved by specifying the order for evaluating transitions
from a given state.
As we have noted, events can be arranged into a class hierarchy (Fig. 35). An event triggers
any transitions that depend on any of its ancestors in the hierarchy. Events that do not trigger any
transitions in a state are simply ignored.
In principle, operations triggered by transitions are instantaneous. In practice they take some
time to evaluate in an actual program, so this really means that they are atomic and
noninterruptible at some level of abstraction.
A useful convention is to permit transitions without event names. If an unlabeled transition
has a guard condition, then it is triggered whenever the condition becomes true; in practice, it
need be tested only after an event occurs since something must initiate a change. A state can have
a single unlabeled transition without a guard condition; this transition is automatically taken when
the internal activity of the state is completed. These so-called lambda transitions are not needed
in theory, but they permit state diagrams to be factored into simpler pieces that are easier to
understand.
The overall syntax for a transition permits all the following elements, each of which is
optional:
event(arguments)
[condition]
^target.sendEvent(arguments)
/operation(arguments)
Unifed Method V0.8
State Diagram
35
During design additional information might be specified, such as the protocol (procedure call,
I/O event, interprocess message, hardware signal), the transport channel, the timing of event
delivery and response, etc. This kind of information is probably best kept in tables maintained by
a tool so that diagrams do not become too cluttered, although it might be exposed for certain kinds
of applications.
Stubbed Transitions
When viewing a state diagram at a higher level of detail, low level states may be suppressed. If
there are transitions into a composite state to internal states that are not visible, the transitions can
be shown as ending inside the composite state with stubs to indicate that they go to an internal but
invisible state (Fig. 40). A similar notation can be used for transitions from an invisible internal
state to an outside state.
History State
Sometimes it is desirable for a state to remember its substate when it is exited and to be able to
resume the same substate on a subsequent reentry to the state. This can be indicated with a history
marker, a small circle containing an H, which indicates that the containing composite state
preserves its substate (Fig. 41). Transitions that come to this icon trigger the history mechanism.
When a transition invokes the history marker, then the enclosing state region goes to the same
substate that was in effect the last time the enclosing region was active. If a default entry to the
region is meant to trigger the history mechanism, then a transition should be drawn from the
initial state icon to the history icon.
Operations
Operations on the controlling object are invoked by transitions. We call these operations actions;
they must be instantaneous, i.e., noninterruptible. They can be implemented as methods on the
controlling object. As methods, they have access to the parameters of the trigger event as well as
the state variables and other attributes of the controlling object; they can invoke other operations
reachable from the controlling object.
To permit modularization of states, we allow entry and exit operations. An entry operation is
an operation that is automatically performed whenever the state is entered by any transition. An
exit operation is an operation that is automatically performed whenever the state is exited by any
transition. The same effect could be obtained by attaching the operation to all transitions entering
or exiting the state, but this notation permits a separation between the inside and outside of the
state. In effect, it makes the state a self-contained module. Entry and exit transitions are shown as
internal transitions with the pseudo-event names entry and exit (Fig. 36).
If a transition enters a nested state, then all the entry operations are performed starting with
the outermost state; the reverse is true when leaving a nested state. On an internal transition the
entry and exit operations are not performed since control remains within the state. On a selftransition, the exit and entry operations are performed, since control exits and reenters the state,
so there is a subtle difference between an internal transition and a self-transition.
Unifed Method V0.8
36
State Diagram
Activities
An activity is an ongoing operation within a state that takes time to complete. Since it has
duration, it cannot be attached to a transition (internal or external) but it can be interrupted by an
event that causes a state transition. An activity is indicated as a pseudo-transition with the
pseudoevent name do (to perform the activity continuously while in the state) (Fig. 37). The same
effect is obtained by starting the activity on an entry event and stopping the activity on an exit
event in the state. Some activities continue forever and some terminate of their own accord. If an
activity terminates by itself, then an unlabeled (lambda) transition for the state is taken. Whether
or not an activity terminates by itself, it is forcibly terminated if the reception of an event causes
an exit from the state. In principle, one activity per state is sufficient; in practice you could specify
a list of operations to be performed in order.
Sending Events
Objects can send events to other objects. In general, an event can be directed to any set of objects
known to the sending object. Sending an event to a single fixed object (the most usual case) and
broadcasting to the whole system can be considered as special cases of sending an event to a set.
Sending an event is an action that can be performed by an object, but we provide special syntax
for it because it affects the flow of control so much (Fig. 42). Sending an event can be specified as
part of a transition as follows:
^target.event(arglist)
where target is an expression designating a set of objects, event is the name of an event, and
arglist is a list of expressions for parameter values. Expressions must be written in terms of
parameters of the trigger event, state variables, and functions of the sending object, as well as
literal values, such as the target object name. In normal loose practice, the target object may be
omitted if it is fixed and well known. Normally it is sufficient to simply notate sending an event
using the text syntax on a transition. Sending an event can also be indicated graphically in a
scenario diagram. (It is unnecessary to use both the text and graphical syntax simultaneously as
shown in the diagram.
A summary of events exchanged among actors and the system (a context diagram or event
flow diagram) can be shown on a use case diagram or an object message diagram. No additional
notation is required.
Creating Objects
Creating a new object of a given class can be thought of as a special case of sending an event to
the class itself. The event arguments are used to instantiate the object. When the new object is
created, it begins in an initial state in which it receives the creation event as its first birth event.
This is the way that creator objects pass information to their creations (Fig. 43).
A class could have multiple possible birth events, although this makes things more
complicated. The initial state would have multiple transitions with different event labels. The
creator would specify which event to use.
Unifed Method V0.8
State Diagram
37
Destroying Objects
When an object reaches a top-level terminal state, it ceases to exist. (If it reaches a terminal state
in a nested state, then the nested state ceases to hold.) As part of the transition to the terminal
state, it can send an event to another object (Fig. 43). For convenience, an action and event
sending expression can be attached directly to a terminal state.
Timing Mark
A timing mark can be associated with a transition. A timing mark is a name designating the time
at which the transition occurs (Fig. 28). The timing mark can be used to write constraints on the
timing of transitions, usually maximum limits on the elapsed time between events. To show the
effects of a time-out, use more than one event trace: one to show the normal case and another to
show the time-out case. Real-time constraints can be specified using timing marks.
Timing marks can also be used on state diagrams but the control path that they represent in the
diagram must be clearly specified.
Figure 34. State diagram of telephone
Active
phone #
Timeout
do/ play message
dial digit(n)
[incomplete]
15 sec.
15 sec.
DialTone
lift
receiver
/get dial tone
dial digit(n)
do/ play dial tone
Invalid
do/ play message
Idle
Pinned
caller
hangs up
/disconnect
callee
answers
callee
hangs up
dial digit(n)[valid]
/connect
Connecting
busy
Busy
connected
do/ play busy

tone
Ringing
Talking
Unifed Method V0.8
Dialing
dial digit(n)[invalid]
callee answers
/enable speech
do/ play ringing

tone
38
State Diagram
Figure 35. Event taxonomy for keyboard events

event
time
user input
device
mouse
button
location
mouse
button
down
keyboard
character
character
mouse
button
up
control
space
graphic
alphanumeric
punctuation
Figure 36. State Box with Regions

Typing Password
password: String =
fails: Integer = 0
help / display help
entry / set echo invisible
exit / set echo normal
Unifed Method V0.8
State Diagram
39
Figure 37. Composite State

lift receiver
dialedNumber(num)
Dialing
Idle
Connecting
Dialing
number: String =
digit(n)
Start
do / play dial tone
[number.isValid()]
Partial Dial
entry/number.append(n)
^ dialedNumber(number)
digit(n)
Figure 38. Concurrent substates

Taking Class
Incomplete
Lab1
lab done
Lab2
lab
done
Passed
Term
Project
Final
Test
project done
pass
fail
Failed
Unifed Method V0.8
40
State Diagram
Figure 39. Explicit branching and merging threads
A1
A2
Setup
Cleanup
B1
B2
Figure 40. Stubbed transitions
Figure 41. History indicator
interrupt
A1
resume
H
A2
Unifed Method V0.8
State Diagram
41
Figure 42. Sending events

VCR
toggle Power
On
Off
toggle Power
toggle Power
Remote Control
power button
^VCR.togglePower
VCR
Controlling
VCR
Controlling
TV
power button
^television.togglePower
TV
togglePower
Television
toggle Power
Off
On
toggle Power
Unifed Method V0.8
42
State Diagram
Figure 43. Creating and destroying objects

Pawn
Alive
double move
En passant
opponent moves
Unmoved
create(file,rank=2)
capture
single move
Moved
[on 8th rank] ^piece.create(file,rank)

{where piece =
Queen, Rook, Bishop, or Knight}
captured
Unifed Method V0.8
Module Diagrams
43
7. Module Diagrams
All of the previously-discussed diagrams address the elements of a systems logical model. The
development view of a system may be specified and visualized in module diagrams,which
represent the physical modules that provide the defining occurrence of these logical elements.
Each such module thus denotes a file in which the realization of a class (or any other element in
the logical model) may be defined. Modules may be distinguished as either specifications or
implementations. We indicate compilation dependencies among modules via a dashed arrow
(identical to the dependency relationship found in class diagrams).
Similar to the issues of scale addressed by categories in the logical model, we may show
clusters of modules via subsystems. In many (but not all) system designs the categories and the
subsystems correspond; however, they represent fundamentally different packaging decisions,
and so we render them differently. As for interfaces in categorizes, we may illustrate the interface
of a subsystem.
In (Fig. 44) we provide an example of a simple module diagram.
Figure 44. A module diagram
client
storeM
view
components
queU
Unifed Method V0.8
44
Platform Diagrams
8. Platform Diagrams
The physical topology upon which a software system executes may be specified and visualized in
a platform diagram. Such a diagram (of which there is most often one for the system) includes
processors (which have computational power) and devices (which do not) all united by
connections along which information may pass.
Threads may be associated with a given processor, and represent active objects that live in a
common address space; processes may also be associated with a given processor, and represent
active objects that live in separate address spaces.
In (Fig. 45) we provide an example of a simple module diagram.
Figure 45. A platform diagram
PC
Fax
Order entry
ProcessCustomerOrder
TrackCustomerOrder
Server
PC
Printer
Receiving
PC
Purchasing
Unifed Method V0.8
Operation Specification
45
9. Operation Specification
Every element in the notation has an associated specification, which denotes all of the semantics
of that element. One such specification is worth mentioning here because of its importance in
capturing behavior (the functional model). This specification is essentially of the same form as all
other kinds of specifications and so also provides a useful model.
An operation can be specified by giving before and after conditions on its execution,
expressed as properties. A before condition states assumptions on the state of the system at the
beginning of the operation. An after condition is a description of the state of a system at the
completion of operation execution in terms of the state of the system at the beginning of operation
execution. Before-and-after conditions are a good formal way to specify operations; however, in
most cases it is satisfactory to express the conditions in ordinary words, provided the meaning is
clear. Fig. 46 shows a specification of the sort operation.
One way to specify before-and-after conditions is to show two object diagrams, one showing
the state before the operation and the other showing the state after. This might be useful for
complicated data structures, for example. It is possible to fold the two object diagrams together
into a data flow diagram, but experience has shown that in practice a textual specification works
just as well and is much more compact than a data flow diagram.
The design of an operation can be shown by one or more scenario diagrams (Fig. 29, Fig. 30,
Fig. 31) or possibly a state diagram. The actual code associated with a method can be specified by
a note attached to the operation within a class diagram (Fig. 4).
Figure 46. Operation Specification
Operation: sort (elements: Array of T)
Responsibilities: organizes the elements of the array (in place) so that they are in increasing
order
Inputs: elements an array of objects of type T
Returns: none
Modified objects elements
Preconditions:
All of the elements must be of type T or a subtype.
Type T has an operation compare(t1:T) returning {LT, EQ, GT} which compares two
elements and returns whether the first is less than, equal to, or greater than the second. The
operation must define a total order on the values of T.
Duplicate values of T are allowed.
Postconditions:
The elements are ordered according to the comparison function.
The array contains exactly the same number of occurrences of each value of T as before.
If two elements compare as equal, then they have the same relative order before and after
the operation.
Unifed Method V0.8
46
Summary Diagrams
10. Summary Diagrams

Various kinds of diagrams can be constructed that summarize information derived from more
fundamental diagrams and models. These can be extremely useful in a large model, especially if
they are automatically generated by an on-line model editor. We have not chosen to specify the
format for these diagrams because they are less important for constructing models and because
our suggestions would be just recommendations which might be given more weight than they
deserve. Tool builders should have some freedom in the presentation of derived information and
we do not want to restrict it excessively.
Some possible kinds of summary diagrams include context diagrams (show on use case
diagram), event flow diagrams (show on use case or object message diagrams), module
dependency diagrams (derive from the code), call trees (derive from the code or from object
message diagrams), classes affected by changes to a method (derive from the code, class
diagrams, and object message diagrams), and many others.
There are also many different ways in which an on-line tool can present and highlight
information, including color, brightness, texture, underlining, fonts, ordering, flashing, animation,
and many other ways, some of which are only applicable to on-line editors and not to printed
documents. We have presented a canonical format for static monochromatic diagrams, similar to a
presentation format for programs in books, but on-line tools might render these diagrams in
various ways better suited to the needs of the medium, so this document should not be regarded as
inhibiting such mappings.
Unifed Method V0.8
Comparison Chart of Notation
47
11. Comparison Chart of Notation

Table 1: Class and Object Properties
Feature
Unified
Booch
OMT
1 Class
solid rectangle
dashed cloud
solid rectangle
2 Compartments
name
attributes
operations
all compartments
except name can be
suppressed
name
all members
name
attributes
operations
3 Stereotype
above name in parentheses (centered)
inside cloud
N/A
4 Properties
below name in braces

or italics (indented)
N/A
name in braces
5 Attributes
name
type
initial value
n:t=v
types are languagedependent expressions, nominally
pure values, but may
be arbitrary implementation types
initial values are
optional (usually
part of a constructor
or class-scope
attribute)
other syntax (e.g.
C++) optional
name
type
initial value
often only the name
is shown
name
type
initial value
usually pure values,
but in practice may
be more complex
types
6 Operations
full signature using

Ada-like syntax
n(a:t, a:t = e) : t
other syntax (e.g.
C++) optional
full signature
often only the name
is shown
full signature
7 Type syntax
language-dependent
string
Ada-like, C++ optional
Ada-like, C++ optional
Unifed Method V0.8
48

Feature
8 Visibility
Unified
Booch
OMT
leading character
+
public
#
protected
private
null unspecified
marks
null
|
||
|||
9 Class members
leading $
static (C++ keyword)
leading $
10 Member
properties
after or below name in

braces (indent)
N/A
N/A
11 Code body
note attached to opera- note attached to operation, for inline add key- tion
word inline as
member property
inline code shown after

equal sign
12 Abstract class
keyword abstract as
class property
A adornment in triangle
Multiplicity 0 in upper
right of class
13 Parameterized class
class rectangle
impacted by small
dashed rectangle containing list of template
arguments in attribute
format
class cloud impacted

C++-like syntax with a
by small dashed rectan- list of parameters and
gle containing list of
their types
template arguments
14 Instantiated
class
C++-like syntax with

list of actual expressions
name<e, e>
class cloud impacted

by small solid rectangle containing actual
names
C++-like syntax with

list of actual expressions
name<e, e>
15 Object
hexagon with vertical

sides and slightly
peaked top and bottom;
contains
name : type
list of object attributes
where type is a class
name or a type name
if no colon appears,
the name is the class
of an anonymous
object
solid cloud
solid rectangle
name : class
Unifed Method V0.8
public
protected
private
implementation
leading character
+
public
#
protected
private
49

Feature
Unified
Booch
OMT
16 Object
attributes
list of:
name = value
where value is a language-dependent
expression
only need to show
attributes that are
interesting
may include attributes

with values in object
icon
may include attributes

with values in object
icon
17 Object multiplicitiy
number or * (many) in
upper peak of object
applies only inside
composites
default is many
number inside cloud

default is many
number or * (many) in
upper right of class
default is many
18 Multiobject
stacked objects, indicating an anonymous

set of objects
stacked to upper right
or use a multiplicity
indicator
stacked objects, indicating an anonymous

set of objects
N/A
19 Link
solid line with name of

association
name optional if
unambiguous

association

association
20 Messages
shown as labeled arrow

next to link line with
arrowhead pointing
toward target object
multiple messages in
either direction may
be attached to a link
line
initiation is shown as
a dangling link line

attached to link
multiple messages
may be attached

attached to link
multiple messages
may be attached
21 Message synchronization
symbols for procedural (full arrowhead)

asynchronous (half
arrowhead) are basic
advanced includes
balking, timeout, etc.
same
symbol for procedural

call (full arrowhead)
and asynchronous
(half arrowhead)
Unifed Method V0.8
50

Feature
Unified
Booch
OMT
22 Data flow
small labeled circle

with arrow for flow
direction near message
compact alternate is to
show arguments and
return values in operation syntax:
result := op (arg, arg)
optional data flow

token (option is to
show arguments)
show arguments
23 Message
ordering
modified Dewey decimal numbering

letter denotes a concurrent thread
number denotes a
sequential step within
a thread
iteration is shown
with * with optional
iteration condition in
parentheses (i =
1..10)
condition is shown
with ? and optional
Boolean expression
in parentheses (i > 0)
monotonically increasing number
dewey decimal numbering
24 Timing
marks
name attached to end

of a message
N/A
N/A
25 Timing budget
shown as constraint,
e.g. {b - a < 10 sec.}
shown as constraint
shown as constraint
26 Multilink
no special notation;
link line to multiobject
implies multilink
no special notation;
link line to multiobject
implies multilink
N/A
Unifed Method V0.8
51

Feature
Unified
27 Implementation adornment
on link
optional small box on

target end containing
key letter:
A association (default)
F object field (member)
G global variable
L local variable
P parameter
S self
small box on far end

N/A
with key letter
F object field (member)
P parameter
L local variable
G global variable
28 Instantiation
Dashed arrow (special

case of a dependency
relationship) from
object to class (for
object instances) or
from class to class (for
instantiation)
Dashed arrow from

object instances) or
from class to class (for
instantiation)
Dashed arrow from

object instances)
29 Metaclass
use metaclass stereotype, no special icon
grey-filled class
same as class
30 Metaclass
instantiation
same as instantiation
(implied by instantiating a metaclass)
usually unnecessary
thick grey arrow from

class to metaclass
same as instantiation
31 Constraint
text in braces near target or labeling a dashed

line connecting two or
more elements, or
show as a note
text in braces near target
text in braces near target
32 Note
dog-eared rectangle
attached to one or more
elements by a dashed
line
diagrams may be
marked with freefloating text in braces
for simple comments
dog-eared rectangle
attached to one or more
elements by a dashed
line
text in braces near the

target
Unifed Method V0.8
Booch
OMT
52

Feature
Unified
Booch
33 Language
adornments
Show most as member

property: keyword in
braces after member,
e.g. {deferred},
{const}
if C++ syntax is used,
just do it
use $ for C++ static
members
letter within an
inverted triangle in
class or on association
line
use S for C++ static
members
comment in braces
use $ for C++ static
members
34 Friend
dashed arrow (dependency) labeled friend

from the friend to the
supplier
letter (F) within an

inverted triangle
leading % in front of
the name of the friend
class or operation
within the supplier
class
35 Nested class
Nest class box within

other class box or Special icon within name
compartment of class
box; click to expand
the class to see contents (implicit category). The icon
indicates the presence
of one or more nested
classes, not individual
classes, and is not
labeled or repeated.
nested cloud
none, actively discouraged
36 Utilities
class box with shadow

on the right and bottom
class cloud with

shadow on the right
and bottom
dummy class box with

type global
37 Derived
entity (any kind)
slash (/) in front of

name, comment can
give details of derivation
N/A
slash (/.) in front of

name
38 Composite
embed objects and

links within a class box
rectangle
internal details may
be elided
N/A
Heavy rectangular
frame with contained
classes and associations
may be elided
Unifed Method V0.8
OMT
53

Feature
Unified
Booch
OMT
39 Category
(logical grouping)
rectangular frame with

double line border and
name (inside double
lines)
rectangular frame with

single line border and
name
rectangular doted
frame with name (same
as for physical grouping)
40 Category
contents
show as nested class

diagram
may be elided

diagram
may be elided

diagram
may be elided
41 Public/private contents of
categories
show public contents

as a separate diagram
or use tool markup
(color, fonts, grouping,
etc.) to show things
dynamically.
access markup
show on separate diagrams
42 Category
nesting
allowed; may be shown

graphically or elided
into a zoomed diagram
yes, but not shown

graphically
yes, and may be shown

graphically
43 Dependencies
dashed arrow from client (knower) to supplier (known)

Optionally label by
kind of dependency
hollow ball on line near

clients end
dashed arrow from client to supplier
44 Global visibility of a category
stereotype global
keyword global in
left bottom of category
N/A
45 Association
oblique or orthogonal
line
oblique or orthogonal
line
traditionally orthogonal line
46 Association
name
string on or next to
line; optional directed
small filled triangle in
name shows direction
to read the name, e.g.,
Foo
on line
next to line; optional

arrow shows direction
to read the name
47 Role
name next to end of

line attached to target
class playing the role;
represents a reference
from the client class
to the target class
name next to end of

line near class, far end
name next to end of

line near class, far end
Unifed Method V0.8
54

Feature
Unified
Booch
OMT
48 Multiplicity
text expression near

end of line attached to
target class (the one
whose multiplicity is
specified)
text expression, far end
multiplicity balls or
text expression, far end
49 Many multiplicity
*
means unbounded
multiplicity
by itself means zero
or more unbounded
50 Multiplicity
expression
1
0 .. 1
*
1 .. *
3 .. 5, 7, 15
3 .. *
1
0 .. 1
N
1 .. N
3 .. 5, 7, 15
3 .. N
1 default
0 .. 1 hollow circle
0 .. * filled circle
51 Ordered set
keyword {ordered}
near multiplicity symbol
keyword {ordered}
keyword {ordered}
52 Aggregation
diamond at aggregate
filled circle at aggre(whole) end of link line gate (whole) end
binds to line more
tightly than implementation adornment
diamond at aggregate
(whole) end
53 Physical
implementation
adornment
square on target end

indicates navigability
from the other class to
the target class:
by-value: filled square
by-reference: hollow
square (default)
Arrowhead on target
end shows navigability,
by-reference/by-value
distinction relegated to
backplane specification
Unifed Method V0.8
square on far end

by value: filled
by reference: open
55

Feature
Unified
54 Relationship
tree
can combine individual

relationships for visual
combination (adds no
semantics)
typically for inheritance and aggregation
No
can combine individual

relationships for visual
combination
adds no semantics for
association or aggregation
Strong semantics for
generalization indicating a distinct parallel dimension of
generalization
55 Dependency
Dashed line from client

to supplier
may be labeled with
the specific kind of
using dependency,
e.g., calls, instantiates, etc.)
(uses) hollow circle at

client end
deemded unnecessary
56 Qualifier
medium-size rectangle
on end of link line near
qualified class; rectangle contains a list of
qualifiers and types in
attribute format
part of the association, not the class
the qualified class is
the one that combines
with the qualifier
value to select a
unique object from
the opposite target
class
name in brackets near

qualified class
medium-size rectangle
neat qualified class on
association line containing list of qualifier
and types (part of the
association, not the
class)
Unifed Method V0.8
Booch
OMT
56

Feature
Unified
Booch
OMT
57 Association
class
class attached to association line by dashed

line (think of as a special kind of dependency)
link class is a reification of the association itself and they
share a single implementation
the names really
ought to be the same
degenerate form (link
attribute) has only
attributes in anonymous class, no real
difference
class attached to association by dashed line
class attached to association by horse collar

degenerate form (link
attribute) has only
attributes in class
58 N-ary association
diamond with lines to

each participating class
ternary rare, try to
avoid
qualifiers and attributed associations
avoid most uses
may have role names
may have multiplicity but their meaning
is less useful than
binary case; relative
to all N-1 other
classes
promote to a class
diamond with lines to

each class
discouraged
59 Or-association
dashed (dependency/
constraint) line across
all associations with
constraint or
constraint or
constant or
Unifed Method V0.8
57

Feature
Unified
Booch
OMT
60 Inheritance
line from subclass to

superclass with large
filled triangle arrowhead on superclass end
(larger than association adornments for
visual contrast)
grouping subclasses
as a tree is permitted
but not required
solid arrow from subclass to superclass
tree from triangle, fanning out to subclasses
61 Inheritance
grouping
dashed line across all

associations with discriminator name
N/A
dashed line across all

associations with discriminator
62 Parallel
inheritance
(independent
dimensions)
grouping with and

constraint
N/A
Explicit with multiple

generalization symbols
63 Superclass
ordering
number superclasses
(but usually only in
specification backplane)
N/A
N/A
64 Subclass
ordering
Seems unnecessary
N/A
N/A
65 Disjoint/
overlapping subclasses
N/A
N/A
hollow triangle vs.

solid triangle
distinction is little
used
Table 2: State Machine Properties

Unified
66 Use basic Harel diagrams with states, transitions, conditions, timeouts, etc. as in Booch and
OMT
67 State is rounded box with state name; may have stubbed nested states or explicit nested
states
68 Transition is a solid arrow from state to state labeled with a transition rule. Arrowhead is a
stick figure, not a filled triangle, to distinguish visually from inheritance.
Unifed Method V0.8
58
Table 2: State Machine Properties

Unified
69 Transition rule is of the form:
[condition] eventname (arguments) ^ targetobject.sendevent(arguments) / action
(all elements are optional)
70 Nested states (embed state boxes inside larger state boxes) show inheritance of transitions
71 Concurrent states (subdivide state by dashed lines) show concurrent activity
72 Fork and join of control shown by heavy vertical bar with multiple input and/or output transition arrows
73 History symbol (small H in a circle) shows preservation of previous state on reentry
74 Stubbed entry to and exit from leveled substate shows elided detail
75 Events may have parameters (on transitions) and arguments (on sends)
76 Use ^ notation for sending events
Optionally may show target object with a dashed line from the sending transition line to the
target object, labeled with the sent event and its arguments)
77 Use send notation to a class for creating new objects (new object receives the event as its
initial event)
78 Use send notation (without a target object) to return an event from a final state on a leveled
subdiagram to its higher-level subdiagram
79 Internal events are indicated by text within the transition section of the state box
Same transition syntax as transition except no target state
entry, exit, do are pseudo events shown as reserved event names on an internal transition
80 States may have state variables, as attributes of the controlling class, in attribute section of
state box
Table 3: Use Case and Scenario Properties
Unified
81 Message trace diagrams as in both Booch and OMT: time proceeds downward vertically,
objects shown by vertical lines, events by arrows between lines
82 Lifetime of an object is shown by the vertical line (nonlife is shown by no line)
83 Time sequence shown by option numbers on labels
84 Focus of control (fat regions) is permitted
Optionally include notation to distinguish in-control from in-scope but usually not
needed
Unifed Method V0.8
59
Table 3: Use Case and Scenario Properties

Unified
85 Slanted lines show time delay in messaging, default is horizontal line meaning atomic transition
86 Constraints may be attached to elements or to the entire diagram
87 Use cases shown in a diagram as ellipse, containing name of use case
88 System is a hexagon (object icon) containing use case ellipses
89 Actors are object icons with name, identifying an outside agent in a particular role
90 Actors and use cases are attached by lines
Optionally label lines with possible events exchanged (show direction by arrows)
91 Use case inclusion (uses or extends) shown as a dependency relationship (dashed arrow)
from a use case to another use case that is embedded within its activity
Table 4: Module Properties
Feature
Unified
Booch
OMT
92 Subsystem
(physical grouping)
rounded box with

shadow on right and
bottom with name
rounded box with

shadow on right and
bottom with name
rectangular dashed
frame with name (same
as for logical grouping)
93 Subsystem
contents
show as nested module

diagram
may be elided
show as nested module

diagram
may be elided
N/A
94 Subsystem
variations
use generalization
symbol
N/A
use generalization
symbol
95 Module
funny symbols with

things sticking out
funny symbols with

things sticking out
no distinction from category
Table 5: Other Properties

Unified
96 Module diagrams are as in Booch
97 Process diagrams are as in Booch, but need further integration with processes and threads
Unifed Method V0.8
60
Unifed Method V0.8

UML Notation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UML Notation

Uploaded by

Copyright:

Available Formats

1

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

RATIONAL SOFTWARE CORPORATION

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

*This is in fact the style taken in the use case diagram.

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

display (on: Surface)

Figure 2. Visibility and scope of attributes and operations

Figure 3. Parameterized classes

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

return sin (angle + pi/2.0);

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 7. Association notation

Figure 9. Association class

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 10. Association attribute

Figure 11. Qualified association

Figure 12. Aggregation in recursive structure

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 13. Aggregation tree notation

Figure 14. Ternary association

Figure 15. Navigability/implementation adornment

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 16. Inheritance

Figure 17. Parallel inheritance

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 18. Overlapping subclasses

Figure 19. Constraints

Figure 20. Derived values

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 21. Categories (nested form)

Figure 22. Categories (tree form)

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 23. Category interface

Graphics Core (Public Interface)

Unifed Method V0.8

RATIONAL SOFTWARE CORPORATION

Figure 24. Composites

Figure 25. Category composite