1

UM L Tut or ia l
The Unified Modeling Language has quickly becom e t he de- fact o st andard for building Obj ect - Orient ed soft ware.

The OM G specificat ion st at es: " The Unified Modeling Language ( UML) is a graphical language for visualizing, specifying,
const ruct ing, and docum ent ing t he art ifact s of a soft ware- int ensive syst em . The UML offers a st andard way t o writ e a syst em 's
blueprint s, including concept ual t hings such as business processes and syst em funct ions as well as concret e t hings such as
program m ing language st at em ent s, dat abase schem as, and reusable soft ware com ponent s."

The im port ant point t o not e here is t hat UML is a 'language' for specifying and not a m et hod or procedure. The UML is used t o
define a soft ware syst em ; t o det ail t he art ifact s in t he syst em , t o docum ent and const ruct - it is t he language t hat t he blueprint is
writ t en in. The UML m ay be used in a variet y of ways t o support a soft ware developm ent m et hodology' but in it self it does not
specify t hat m et hodology or process.

UML defines t he not at ion and sem ant ics for t he following dom ains:

- The User I nt eract ion or Use Case Model - describes t he boundary and int eract ion bet ween t he syst em and users. Corresponds
in som e respect s t o a requirem ent s m odel.
- The I nt eract ion or Com m unicat ion Model - describes how obj ect s in t he syst em will int eract wit h each ot her t o get work done.
- The St at e or Dynam ic Model - St at e chart s describe t he st at es or condit ions t hat classes assum e over t im e. Act ivit y graphs
describe t he workflow's t he syst em will im plem ent .
- The Logical or Class Model - describes t he classes and obj ect s t hat will m ake up t he syst em .
- The Physical Com ponent Model - describes t he soft ware ( and som et im es hardware com ponent s) t hat m ake up t he syst em .
- The Physical Deploym ent Model - describes t he physical archit ect ure and t he deploym ent of com ponent s on t hat hardware
archit ect ure.

UM L 2 .0
UML 2 builds on t he already highly successfull UML 1.x st andard, which has becom e an indust ry st andard for m odeling, design and
const ruct ion of soft ware syst em s as well as m ore generalized business and scient ific processes. UML 2 defines 13 basic diagram
t ypes, divided int o t wo general set s:

1 . St r uct ur a l M ode ling D ia gr a m s

St ruct ure diagram s define t he st at ic archit ect ure of a m odel. They are used t o m odel t he 't hings' t hat m ake up a m odel - t he
classes, obj ect s, int erfaces and physical com ponent s. I n addit ion t hey are used t o m odel t he relat ionships and dependencies
bet ween elem ent s.

- Package diagram s are used t o divide t he m odel int o logical cont ainers or 'packages' and describe t he int eract ions bet ween
t hem at a high level
- Class or St ruct ural diagram s define t he basic building blocks of a m odel: t he t ypes, classes and general m at erials t hat are
used t o const ruct a full m odel
- Obj ect diagram s show how inst ances of st ruct ural elem ent s are relat ed and used at run- t im e.
- Com posit e St ruct ure diagram s provide a m eans of layering an elem ent 's st ruct ure and focusing on inner det ail, const ruct ion
and relat ionships
- Com ponent diagram s are used t o m odel higher level or m ore com plex st ruct ures, usually built up from one or m ore classes,
and providing a well defined int erface
- Deploym ent diagram s show t he physical disposit ion of significant art efact s wit hin a real- world set t ing.

2 . Be ha vior a l M ode ling D ia gr a m s

Behavior diagram s capt ure t he variet ies of int eract ion and inst ant aneous st at e wit hin a m odel as it 'execut es' over t im e.

- Use Case diagram s are used t o m odel user/ syst em int eract ions. They define behavior, requirem ent s and const raint s in t he
form of script s or scenarios
- Act ivit y diagram s have a wide num ber of uses, from defining basic program flow, t o capt uring t he decision point s and act ions
wit hin any generalized process
- St at e Machine diagram s are essent ial t o underst anding t he inst ant t o inst ant condit ion or " run st at e" of a m odel when it
execut es
- Com m unicat ion diagram s show t he net work and sequence of m essages or com m unicat ions bet ween obj ect s at run- t im e during
a collaborat ion inst ance
- Sequence diagram s are closely relat ed t o Com m unicat ion diagram s and show t he sequence of m essages passed bet ween
obj ect s using a vert ical t im eline
- Tim ing diagram s fuse Sequence and St at e diagram s t o provide a view of an obj ect 's st at e over t im e and m essages which
m odify t hat st at e
- I nt eract ion Overview diagram s fuse Act ivit y and Sequence diagram s t o provide allow int eract ion fragm ent s t o be easily
com bined wit h decision point s and flows
 2
UM L 2 Act ivit y D ia gr a m
Act ivit y D ia gr a m s
I n UML an act ivit y diagram is used t o display t he sequence of act ivit ies. Act ivit y Diagram s show t he workflow from a st art point t o
t he finish point det ailing t he m any decision pat hs t hat exist in t he progression of event s cont ained in t he act ivit y. They m ay be used
t o det ail sit uat ions where parallel processing m ay occur in t he execut ion of som e act ivit ies. Act ivit y Diagram s are useful for
Business Modelling where t hey are used for det ailing t he processes involved in business act ivit ies.

An Exam ple of an Act ivit y Diagram is shown here

The following sect ions describe t he elem ent s t hat const it ut e an Act ivit y diagram .

Act ivit ie s
An act ivit y is t he specificat ion of a param et erized sequence of behaviour. An act ivit y is shown as a round- cornered rect angle
enclosing all t he act ions, cont rol flows and ot her elem ent s t hat m ake up t he act ivit y.

Act ion s
An act ion represent s a single st ep wit hin an act ivit y. Act ions are denot ed by round- cornered rect angles.

Act ion Con st r a in t s

Const raint s can be at t ached t o an act ion. The following diagram shows an act ion wit h local pre- and post - condit ions.
 3
Con t r ol Flow
A cont rol flow shows t he flow of cont rol from one act ion t o t he next . I t s not at ion is a line wit h an arrowhead.

I n it ia l N ode
An init ial or st art node is depict ed by a large black spot , as depict ed below.

Fin a l N ode
There are t wo t ypes of final node: act ivit y and flow final nodes. The act ivit y final node is depict ed as a circle wit h a dot inside.

The flow final node is depict ed as a circle wit h a cross inside.

The difference bet ween t he t wo node t ypes is t hat t he flow final node denot es t he end of a single cont rol flow; t he act ivit y final
node denot es t he end of all cont rol flows wit hin t he act ivit y.

Obj e ct s a n d Obj e ct Flow s

An obj ect flow is a pat h along which obj ect s or dat a can pass. An obj ect is shown as a rect angle.

An obj ect flow is shown as a connect or wit h an arrowhead denot ing t he direct ion t he obj ect is being passed.
 4
An obj ect flow m ust have an obj ect on at least one of it s ends. A short hand not at ion for t he above diagram would be t o use input
and out put pins.

A dat a st ore is shown as an obj ect wit h t he «dat ast ore» keyword.

D e cision a nd M e r ge N ode s
Decision nodes and m erge nodes have t he sam e not at ion: a diam ond shape. They can bot h be nam ed. The cont rol flows com ing
away from a decision node will have guard condit ions which will allow cont rol t o flow if t he guard condit ion is m et . The following
diagram shows use of a decision node and a m erge node.

For k a n d Join N ode s

Forks and j oins have t he sam e not at ion: eit her a horizont al or vert ical bar ( t he orient at ion is dependent on whet her t he cont rol flow
is running left t o right or t op t o bot t om ) . They indicat e t he st art and end of concurrent t hreads of cont rol. The following diagram
shows an exam ple of t heir use.

A j oin is different from a m erge in t hat t he j oin synchronises t wo inflows and produces a single out flow. The out flow from a j oin
cannot execut e unt il all inflows have been received. A m erge passes any cont rol flows st raight t hrough it . I f t wo or m ore inflows are
received by a m erge sym bol, t he act ion point ed t o by it s out flow is execut ed t wo or m ore t im es.

Ex pa n sion Re gion
An expansion region is a st ruct ured act ivit y region t hat execut es m ult iple t im es. I nput and out put expansion nodes are drawn as a
group of t hree boxes represent ing a m ult iple select ion of it em s. The keyword it erat ive, parallel or st ream is shown in t he t op left
corner of t he region.
 5
Ex ce pt ion H a ndle r s
Except ion Handlers can be m odelled on act ivit y diagram s as in t he exam ple below.

I n t e r r u pt ible Act ivit y Re gion

An int errupt ible act ivit y region surrounds a group of act ions t hat can be int errupt ed. I n t he very sim ple exam ple below, t he Process
Order act ion will execut e unt il com plet ion, when it will pass cont rol t o t he Close Order act ion, unless a Cancel Request int errupt is
received which will pass cont rol t o t he Cancel Order act ion.

Pa r t it ion
An act ivit y part it ion is shown as eit her horizont al or vert ical swim lanes. I n t he following diagram , t he part it ions are used t o
separat e act ions wit hin an act ivit y int o t hose perform ed by t he account ing depart m ent and t hose perform ed by t he cust om er.
 6

UM L 2 Cla ss D ia gr a m
Cla ss D ia gr a m s
The Class diagram shows t he building blocks of any obj ect - orient at ed syst em . Class diagram s depict t he st at ic view of t he m odel
or part of t he m odel, describing what at t ribut es and behaviour it has rat her t hat det ailing t he m et hods for achieving operat ions.
Class diagram s are m ost useful t o illust rat e relat ionships bet ween classes and int erfaces. Generalizat ions, aggregat ions, and
associat ions are all valuable in reflect ing inherit ance, com posit ion or usage, and connect ions, respect ively.

The diagram below illust rat es aggregat ion relat ionships bet ween classes. The light er aggregat ion indicat es t hat t he class Account
uses AddressBook, but does not necessarily cont ain an inst ance of it . The st rong, com posit e aggregat ions by t he ot her connect ors
indicat e ownership or cont ainm ent of t he source classes by t he t arget classes, for exam ple Cont act and Cont act Group values will
be cont ained in AddressBook.

Cla sse s
A class is an elem ent t hat defines t he at t ribut es and behaviours t hat an obj ect is able t o generat e. The behaviour is t he described
by t he possible m essages t he class is able t o underst and along wit h operat ions t hat are appropriat e for each m essage. Classes
m ay also cont ain definit ions of const raint s t agged values and st ereot ypes.

Cla ss N ot a t ion
Classes are represent ed by rect angles which show t he nam e of t he class and opt ionally t he nam e of t he operat ions and at t ribut es.
Com part m ent s are used t o divide t he class nam e, at t ribut es and operat ions. Addit ionally const raint s, init ial values and param et ers
m ay be assigned t o classes.

I n t he diagram below t he class cont ains t he class nam e in t he t opm ost com part m ent , t he next com part m ent det ails t he at t ribut es,
wit h t he " cent er" at t ribut e showing init ial values. The final com part m ent shows t he operat ions, t he set Widt h, set Lengt h and
set Posit ion operat ions showing t heir param et ers. The not at ion t hat precedes t he at t ribut e or operat ion nam e indicat es t he visibilit y
of t he elem ent , if t he + sym bol is used t he at t ribut e or operat ion has a public level of visibilit y, if a - sym bol is used t he at t ribut e
or operat ion is privat e. I n addit ion t he # sym bol allows an operat ion or at t ribut e t o be defined as prot ect ed and t he ~ sym bol
indicat es package visibilit y.
 7
I n t e r fa ce s
An int erface is a specificat ion of behaviour t hat im plem ent ers agree t o m eet . I t is a cont ract . By realizing an int erface, classes are
guarant eed t o support a required behaviour, which allows t he syst em t o t reat non- relat ed elem ent s in t he sam e way – i.e. t hrough
t he com m on int erface.

I nt erfaces m ay be drawn in a sim ilar st yle t o a class, wit h operat ions specified, as shown below. They m ay also be drawn as a
circle wit h no explicit operat ions det ailed. When drawn as a circle, realizat ion links t o t he circle form of not at ion are drawn wit hout
t arget arrows.

Ta ble s
A t able is a st ereot yped class. I t is drawn wit h a sm all t able icon in t he upper right corner. Table at t ribut es are st ereot yped
«colum n». Most t ables will have a prim ary key, being one or m ore fields t hat form a unique com binat ion used t o access t he t able,
plus a prim ary key operat ion which is st ereot yped «PK». Som e t ables will have one or m ore foreign keys, being one or m ore fields
t hat t oget her m ap ont o a prim ary key in a relat ed t able, plus a foreign key operat ion which is st ereot yped «FK».

Associa t ion s
An associat ion im plies t wo m odel elem ent s have a relat ionship - usually im plem ent ed as an inst ance variable in one class. This
connect or m ay include nam ed roles at each end, cardinalit y, direct ion and const raint s. Associat ion is t he general relat ionship t ype
bet ween elem ent s. For m ore t han t wo elem ent s, a diagonal represent at ion t oolbox elem ent can be used as well. When code is
generat ed for class diagram s, associat ions becom e inst ance variables in t he t arget class.
 8
Ge n e r a liza t ion s
A generalizat ion is used t o indicat e inherit ance. Drawn from t he specific classifier t o a general classifier, t he generalize im plicat ion
is t hat t he source inherit s t he t arget 's charact erist ics. The following diagram shows a parent class generalizing a child class.
I m plicit ly, an inst ant iat ed obj ect of t he Circle class will have at t ribut es x_posit ion, y_posit ion and radius and a m et hod display( ) .
Not e t hat t he class Shape is abst ract , shown by t he nam e being it alicized.

The following diagram shows an equivalent view of t he sam e inform at ion.

Aggr e ga t ion s
Aggregat ions are used t o depict elem ent s which are m ade up of sm aller com ponent s. Aggregat ion relat ionships are shown by a
whit e diam ond- shaped arrowhead point ing t owards t he t arget or parent class.

A st ronger form of aggregat ion - a com posit e aggregat ion - is shown by a black diam ond- shaped arrowhead and is used where
com ponent s can be included in a m axim um of one com posit ion at a t im e. I f t he parent of a com posit e aggregat ion is delet ed,
usually all of it s part s are delet ed wit h it ; however a part can be individually rem oved from a com posit ion wit hout having t o delet e
t he ent ire com posit ion. Com posit ions are t ransit ive, asym m et ric relat ionships and can be recursive.

The following diagram illust rat es t he difference bet ween weak and st rong aggregat ions. An address book is m ade up of a
m ult iplicit y of cont act s and cont act groups. A cont act group is a virt ual grouping of cont act s; a cont act m ay be included in m ore
t han one cont act group. I f you delet e an address book, all t he cont act s and cont act groups will be delet ed t oo; if you delet e a
cont act group, no cont act s will be delet ed.

Associa t ion Cla sse s

An associat ion class is a const ruct t hat allows an associat ion connect ion t o have operat ions and at t ribut es. The following exam ple
shows t hat t here is m ore t o allocat ing an em ployee t o a proj ect t han m aking a sim ple associat ion link bet ween t he t wo classes:
t he role t hat t he em ployee t akes up on t he proj ect is a com plex ent it y in it s own right and cont ains det ail t hat does not belong in
t he em ployee or proj ect class. For exam ple, an em ployee m ay be working on several proj ect s at t he sam e t im e and have different
j ob t it les and securit y levels on each.
 9

D e pe n de n cie s
A dependency is used t o m odel a wide range of dependent relat ionships bet ween m odel elem ent s. I t would norm ally be used early
in t he design process where it is known t hat t here is som e kind of link bet ween t wo elem ent s but it is t oo early t o know exact ly
what t he relat ionship is. Lat er in t he design process, dependencies will be st ereot yped ( st ereot ypes available include «inst ant iat e»,
«t race», «im port » and ot hers) or replaced wit h a m ore specific t ype of connect or.

Tr a ce s
The t race relat ionship is a specializat ion of a dependency, linking m odel elem ent s or set s of elem ent s t hat represent t he sam e idea
across m odels. Traces are oft en used t o t rack requirem ent s and m odel changes. As changes can occur in bot h direct ions, t he order
of t his dependency is usually ignored. The relat ionship's propert ies can specify t he t race m apping, but t he t race is usually bi-
direct ional, inform al and rarely com put able.

Re a liza t ion s
The source obj ect im plem ent s or realizes t he dest inat ion. Realize is used t o express t raceabilit y and com plet eness in t he m odel - a
business process or requirem ent is realized by one or m ore use cases which are in t urn realized by som e classes, which in t urn are
realized by a com ponent , et c. Mapping requirem ent s, classes, et c. across t he design of your syst em , up t hrough t he levels of
m odelling abst ract ion, ensures t he big pict ure of your syst em rem em bers and reflect s all t he lit t le pict ures and det ails t hat
const rain and define it . A realizat ion is shown as a dashed line wit h a solid arrowhead and t he «realize» st ereot ype.

N e st in gs
A nest ing is connect or t hat shows t hat t he source elem ent is nest ed wit hin t he t arget elem ent . The following diagram shows t he
definit ion of an inner class alt hough in EA it is m ore usual t o show t hem by t heir posit ion in t he Proj ect View hierarchy.
 10

UM L 2 Com m unica t ion D ia gr a m

Com m u n ica t ion D ia gr a m s
A com m unicat ion diagram , form erly called a collaborat ion diagram , is an int eract ion diagram t hat shows sim ilar inform at ion t o
sequence diagram s but it s prim ary focus in on obj ect relat ionships.

On com m unicat ion diagram s, obj ect s are shown wit h associat ion connect ors bet ween t hem . Messages are added t o t he
associat ions and show as short arrows point ing in t he direct ion of t he m essage flow. The sequence of m essages is shown t hrough
a num bering schem e.

The following t wo diagram s show a com m unicat ion diagram and t he sequence diagram t hat shows t he sam e inform at ion.
Alt hough it is possible t o derive t he sequencing of m essages in t he com m unicat ion diagram from t he num bering schem e, it isn’t
im m ediat ely visible. What t he com m unicat ion diagram does show quit e clearly t hough is t he full set of m essages passed bet ween
adj acent obj ect s.
 11

UM L 2 Com pone nt D ia gr a m
Com pone nt D ia gr a m s
Com ponent Diagram s illust rat e t he pieces of soft ware, em bedded cont rollers, et c. t hat will m ake up a syst em . A Com ponent
diagram has a higher level of abst ract ion t han a Class diagram - usually a com ponent is im plem ent ed by one or m ore classes ( or
obj ect s) at runt im e. They are building blocks, such t hat event ually a com ponent can encom pass a large port ion of a syst em .

The diagram below dem onst rat es som e com ponent s and t heir int er- relat ionships. Assem bly connect ors 'link' t he provided
int erfaces supplied by Product and Cust om er t o t he required int erfaces specified by Order. A dependency relat ionship m aps a
cust om er's associat ed account det ails t o t he required int erface, 'Paym ent ', indicat ed by Order.

Com ponent s are sim ilar in pract ice t o package diagram s as t he define boundaries and are used t o group elem ent s int o logical
st ruct ures. The difference bet ween Package Diagram s and Com ponent diagram s is t hat Com ponent Diagram s offer a m ore
sem ant ically rich grouping m echanism . Wit h Com ponent Diagram s all of t he m odel elem ent s are privat e whereas Package
diagram s only display public it em s.

Re pr e se nt ing Com pone nt s

Com ponent s are represent ed as a rect angular classifier wit h t he keyword «com ponent », opt ionally t he com ponent m ay be
displayed as a rect angle wit h a com ponent icon in t he right - hand upper corner.

Re qu ir e d I n t e r fa ce s
The Assem bly connect or bridges a com ponent ’s required int erface ( Com ponent 1) wit h t he provided int erface of anot her
com ponent ( Com ponent 2) ; t his allows one com ponent t o provide t he services t hat anot her com ponent requires. I nt erfaces are
collect ions of one or m ore m et hods which m ay or m ay not cont ain at t ribut es.
 12
Com pon e n t s w it h Por t s
Using Port s wit h Com ponent Diagram s allows for a service or behavior t o be specified t o it s environm ent as well as a service or
behavior t hat a Com ponent requires. Port s m ay specify input s, out put s as well as operat ing bi- direct ionally. The following
diagram det ails a com ponent wit h a port for Online services along wit h t wo provided int erfaces Order Ent ry and Tracking as well
as a required int erface Paym ent .
 13

UM L 2 Com posit e St r uct ur e D ia gr a m

Com posit e D ia gr a m s
A com posit e st ruct ure diagram is a diagram t hat shows t he int ernal st ruct ure of a classifier, including it s int eract ion point s t o
ot her part s of t he syst em . I t shows t he configurat ion and relat ionship of part s t hat t oget her perform t he behaviour of t he
cont aining classifier.

Class elem ent s have been described in great det ail in t he sect ion on class diagram s. This sect ion describes t he way t hat classes
can be displayed as com posit e elem ent s exposing int erfaces and cont aining port s and part s.

Pa r t
A part is an elem ent t hat represent s a set of one or m ore inst ances which are owned by a cont aining classifier inst ance. So for
exam ple, if a diagram inst ance owned a set of graphical elem ent s, t hen t he graphical elem ent s could be represent ed as part s, if it
were useful t o do so t o m odel som e kind of relat ionship bet ween t hem . Not e t hat a part can be rem oved from it s parent before
t he parent is delet ed, so t hat t he part isn't delet ed at t he sam e t im e.

A part is shown as an unadorned rect angle cont ained wit hin t he body of a class or com ponent elem ent .

Por t

A port is a t yped elem ent t hat represent s an ext ernally visible part of a cont aining classifier inst ance. Port s define t he int eract ion
bet ween a classifier and it s environm ent . A port can appear on t he boundary of a cont ained part , a class or a com posit e
st ruct ure. A port m ay specify t he services a classifier provides as well as t he services t hat it requires of it s environm ent .

A port is shown as a nam ed rect angle on t he boundary edge of it s owning classifier.

I n t e r fa ce s
An int erface is sim ilar t o a class but wit h a num ber of rest rict ions. All int erface operat ions are public and abst ract , and do not
provide any default im plem ent at ion. All int erface at t ribut es m ust be const ant s. However, while a class m ay only inherit from a
single super- class, it m ay im plem ent m ult iple int erfaces.
 14
An int erface, when st anding alone in a diagram , is eit her shown as a class elem ent rect angle wit h t he «int erface» keyword and
wit h it s nam e it alicised t o denot e it is abst ract , or it is shown as a circle.

Not e t hat t he circle not at ion does not show t he int erface operat ions. When int erfaces are shown as being owned by classes, t hey
are referred t o as exposed int erfaces. An exposed int erface can be defined as eit her provided or required. A provided int erface is
an affirm at ion t hat t he cont aining classifier supplies t he operat ions defined by t he nam ed int erface elem ent and is defined by
drawing a realisat ion link bet ween t he class and t he int erface. A required int erface is a st at em ent t hat t he classifier is able t o
com m unicat e wit h som e ot her classifier which provides operat ions defined by t he nam ed int erface elem ent and is defined by
drawing a dependency link bet ween t he class and t he int erface.

A provided int erface is shown as a " ball on a st ick" at t ached t o t he edge of a classifier elem ent . A required int erface is shown as a
" cup on a st ick" at t ached t o t he edge of a classifier elem ent .

D e le ga t e
A delegat e connect or is used for defining t he int ernal workings of a com ponent 's ext ernal port s and int erfaces. A delegat e
connect or is shown as an arrow wit h a «delegat e» st ereot ype. I t connect s an ext ernal cont ract of a com ponent as shown by it s
port s t o t he int ernal realisat ion of t he behaviour of t he com ponent 's part .

Colla bor a t ion

A collaborat ion defines a set of co- operat ing roles used collect ively t o illust rat e a specific funct ionalit y. A collaborat ion should only
show t he roles and at t ribut es required t o accom plish it s defined t ask or funct ion. I solat ing t he prim ary roles is an exercise in
sim plifying t he st ruct ure and clarifying t he behaviour, and also provides for re- use. A collaborat ion oft en im plem ent s a pat t ern.

A collaborat ion elem ent is shown as an ellipse.

 15
Role Bin din g
A role binding connect or is drawn from a collaborat ion t o t he classifier t hat fulfils t he role. I t is shown as a dashed line wit h
arrowhead and t he st ereot ype «role binding».

Re pr e se n t s
A represent s connect or m ay be drawn from a collaborat ion t o a classifier t o show t hat a collaborat ion is used in t he classifier. I t is
shown as a dashed line wit h arrowhead and t he st ereot ype «represent s».

Occu r r e n ce
An occurrence connect or m ay be drawn from a collaborat ion t o a classifier t o show t hat a collaborat ion represent s( sic) t he
classifier. I t is shown as a dashed line wit h arrowhead and t he st ereot ype «occurrence».
 16

UM L 2 D e ploym e nt D ia gr a m
D e ploym e nt D ia gr a m s
A Deploym ent Diagram m odels t he run- t im e archit ect ure of a syst em . I t shows t he configurat ion of t he hardware elem ent s
( nodes) and shows how soft ware elem ent s and art ifact s are m apped ont o t hose nodes.

N ode
A Node is eit her a hardware or soft ware elem ent . I t is shown as a 3- dim ensional box shape, as below

N ode I n st a n ce
A node inst ance can be shown on a diagram . An inst ance can be dist inguished from a node by t he fact t hat it s nam e is underlined
and has a colon before it s base node t ype. An inst ance m ay or m ay not have a nam e before t he colon. The following diagram
shows a nam ed inst ance of a com put er.

N ode St e r e ot ype s
A num ber of st andard st ereot ypes are provided for nodes, nam ely «cdrom », «cd- rom », «com put er», «disk array», «pc», «pc
client », «pc server», «secure», «server», «st orage», «unix server», «user pc». These will display an appropriat e icon in t he t op
right corner of t he node sym bol

Ar t ifa ct
An Art ifact is a product of t he soft ware developm ent process. That m ay include process m odels ( e.g. Use Case m odels, Design
m odels et c) , source files, execut ables, design docum ent s, t est report s, prot ot ypes, user m anuals and so on.

An art ifact is denot ed by a rect angle showing t he art ifact nam e, t he «art ifact » st ereot ype and a docum ent icon, as follows.
 17
Associa t ion
I n t he cont ext of a deploym ent diagram , an associat ion represent s a com m unicat ion pat h bet ween nodes. The following diagram
shows a deploym ent diagram for a net work, showing net work prot ocols as st ereot ypes and also showing m ult iplicit ies at t he
associat ion ends.

N ode a s Con t a in e r
A node can cont ain ot her elem ent s, such as com ponent s or art ifact s. The following diagram shows a deploym ent diagram for part
of an em bedded syst em and showing an execut able art ifact as being cont ained by t he m ot herboard node.
 18

UM L 2 I nt e r a ct ion Ove r vie w D ia gr a m

I nt e r a ct ion Ove r vie w D ia gr a m s
An I nt eract ion Overview Diagram is a form of act ivit y diagram in which t he nodes represent int eract ion diagram s. I nt eract ion
diagram s can include sequence, com m unicat ion, int eract ion overview and t im ing diagram s. Most of t he not at ion for int eract ion
overview diagram s is t he sam e as for act ivit y diagram s, for exam ple init ial, final, decision, m erge, fork and j oin nodes are all t he
sam e. However, int eract ion overview diagram s int roduce t wo new elem ent s, int eract ion occurrences and int eract ion elem ent s.

I n t e r a ct ion Occu r r e n ce
I nt eract ion Occurrences are references t o exist ing int eract ion diagram s. An int eract ion occurrence is shown as a reference fram e,
i.e. a fram e wit h “ ref” in t he t op- left corner. The nam e of t he diagram being referenced is shown in t he cent er of t he fram e.

I n t e r a ct ion Ele m e n t
I nt eract ion Elem ent s are sim ilar t o int eract ion occurrences in t hat t hey display a represent at ion of exist ing int eract ion diagram s
wit hin a rect angular fram e. They differ in t hat t hey display t he cont ent s of t he references diagram inline.

Put t ing it a ll t oge t h e r

All t he sam e cont rols from act ivit y diagram s ( fork, j oin, m erge et c) can be used on I nt eract ion Overview diagram s t o put t he
cont rol logic around t he lower level diagram s. The following exam ple depict s a sam ple sale process wit h sub- processes abst ract ed
wit hin int eract ion occurrences.
 19

UM L 2 Obj e ct D ia gr a m s
Obj e ct D ia gr a m s
An obj ect diagram m ay be considered a special case of a class diagram . Obj ect diagram s use a subset of t he elem ent s of a class
diagram in order t o em phasize t he relat ionship bet ween inst ances of classes at som e point in t im e. They are useful in
underst anding class diagram s. They don’t show anyt hing archit ect urally different t o class diagram s, but reflect m ult iplicit y and
roles.

Cla ss a nd Obj e ct Ele m e nt s

The following diagram shows t he differences in appearance bet ween a class elem ent and an obj ect elem ent . Not e t hat t he class
elem ent consist s of t hree part s, being divided int o nam e, at t ribut e and operat ion com part m ent s; by default , obj ect elem ent s
don’t have com part m ent s. The display of nam es is also different : obj ect nam es are underlined and m ay show t he nam e of t he
classifier from which t he obj ect is inst ant iat ed.

Run Tim e St a t e
A classifier elem ent can have any num ber of at t ribut es and operat ions. These aren’t shown in an obj ect inst ance. I t is possible,
however, t o define an obj ect ’s run t im e st at e, showing t he set values of at t ribut es in t he part icular inst ance.

Ex a m ple Cla ss a n d Obj e ct D ia gr a m s

The following diagram shows an obj ect diagram wit h it s defining class diagram inset , and it illust rat es t he way in which an obj ect
diagram m ay be used t o t est t he m ult iplicit ies of assignm ent s in class diagram s. The car class has a 1- t o- m any m ult iplicit y t o t he
wheel class, but if a 1- t o- 4 m ult iplicit y had been chosen inst ead, t hat wouldn’t have allowed for t he t hree- wheeled car shown in
t he obj ect diagram .
 20

UM L 2 Pa ck a ge D ia gr a m
Pa ck a ge D ia gr a m s
Package Diagram s are used t o reflect t he organizat ion of packages and t heir elem ent s. When used t o represent class elem ent s
package diagram s are used t o provide a visualizat ion of t he nam espaces. The m ost com m on uses for Package diagram s is t o use
t hem t o organize Use- Case Diagram s and Class diagram s, alt hough t he use of Package Diagram s is not lim it ed t o t hese UML
elem ent s.

The following is an exam ple of a package diagram .

Elem ent s cont ained in a Package share t he sam e nam espace, t his sharing of nam espace requires t he elem ent s cont ained in a
specific nam espace t o have unique nam es.

Packages can be built t o represent eit her physical or logical relat ionships. When choosing t o include classes t o specific packages,
it is useful t o assign t he classes wit h t he sam e inherit ance hierarchy t o packages, classes t hat are relat ed via com posit ion and
classes t hat collaborat e wit h also have a st rong argum ent for being included int o t he sam e package..

Packages are represent ed in UML 2.0 as folders and cont ain t he elem ent s t hat share a nam espace; all elem ent s wit hin a package
m ust have a unique ident ifier. The Package m ust show t he Package nam e and can opt ionally show t he elem ent s wit hin t he Package
in ext ra com part m ent s.

Pa ck a ge M e r ge
When a «m erge» connect or is used on a package, t he source of t he m erge im port s t he t arget ’s nest ed and im port ed cont ent s. I f an
elem ent exist s wit hin t he source and in t he t arget t he sources elem ent ’s definit ions will be expanded t o will be expanded t o include
t he elem ent definit ions cont ained in t he t arget . All of t he elem ent s added or updat ed by a m erge are not ed by a generalizat ion
relat ionship from t he source t o t he t arget .

Pa ck a ge I m por t
The «im port » connect or indicat es t hat t he elem ent s wit hin t he t arget package, which in t his exam ple is a single class, t he t arget
package, will be im port ed int o t he source package. The Source Package’s nam espace will gain access t o t he Target ’s class/ s; t he
Target ’s nam espace is not affect ed.

N e st in g Con n e ct or s
The nest ing connect or bet ween t he t arget package and source packages reflect what t he package cont ent s reveal.
 21
UM L 2 Se que nce D ia gr a m
Se qu e n ce D ia gr a m s
A sequence diagram is a form of int eract ion diagram which shows obj ect s as lifelines running down t he page and wit h t heir
int eract ions over t im e represent ed as m essages drawn as arrows from t he source lifeline t o t he t arget lifeline. Sequence diagram s
are good at showing which obj ect s com m unicat e wit h which ot her obj ect s and what m essages t rigger t hose com m unicat ions.
Sequence diagram s are not int ended for showing com plex procedural logic..

Life line s
A lifeline represent s an individual part icipant in a sequence diagram . A lifeline will usually have a rect angle cont aining it s obj ect
nam e. I f it s nam e is self t hen t hat indicat es t hat t he lifeline represent s t he classifier which owns t he sequence diagram ..

Som et im es a sequence diagram will have a lifeline wit h an act or elem ent sym bol at it s head. This will usually be t he case if t he
sequence diagram is owned by a use case. Boundary, cont rol and ent it y elem ent s from robust ness diagram s can also own lifelines.

M e ssa ge s
Messages are displayed as arrows. Messages can be com plet e, lost or found; synchronous or asynchronous; call or signal. I n t he
following diagram , t he first m essage is a synchronous m essage ( denot ed by t he solid arrowhead) com plet e wit h an im plicit ret urn
m essage; t he second m essage is asynchronous ( denot ed by line arrowhead) and t he t hird is t he asynchronous ret urn m essage
( denot ed by t he dashed line) .

Ex e cu t ion Occu r r e n ce
A t hin rect angle running down t he lifeline denot es t he execut ion occurrence or act ivat ion of a focus of cont rol. I n t he previous
diagram , t here are t hree execut ion occurrences. The first is t he source obj ect sending t wo m essages and receiving t wo replies; t he
second is t he t arget obj ect receiving a synchronous m essage and ret urning a reply; and t he t hird is t he t arget obj ect receiving an
asynchronous m essage and ret urning a reply.
 22
Se lf M e ssa ge
A self m essage can represent a recursive call of an operat ion, or one m et hod calling anot her m et hod belonging t o t he sam e obj ect .
I t is shown as creat ing a nest ed focus of cont rol in t he lifeline’s execut ion occurrence.

Lost a n d Fou n d M e ssa ge s

Lost m essages are t hose t hat are eit her sent but do not arrive at t he int ended recipient , or which go t o a recipient not shown on
t he current diagram . Found m essages are t hose t hat arrive from an unknown sender, or from a sender not shown on t he current
diagram . They are denot ed going t o or com ing from an endpoint elem ent .

Life lin e St a r t a n d En d
A lifeline m ay be creat ed or dest royed during t he t im escale represent ed by a sequence diagram . I n t he lat t er case, t he lifeline is
t erm inat ed by a st op sym bol, represent ed as a cross. I n t he form er case, t he sym bol at t he head of t he lifeline is shown at a lower
level down t he page t han t he sym bol of t he obj ect t hat caused t he creat ion. The following diagram shows an obj ect being creat ed
and dest royed.
 23
D ur a t ion a nd Tim e Const r a int s
By default , a m essage is shown as a horizont al line. Since t he lifeline represent s t he passage of t im e down t he screen, when
m odelling a real- t im e syst em , or even a t im e- bound business process, it can be im port ant t o consider t he lengt h of t im e it t akes t o
perform act ions. By set t ing a durat ion const raint for a m essage, t he m essage will be shown as a sloping line.

Com bine d Fr a gm e nt s

I t was st at ed earlier t hat Sequence diagram s are not int ended for showing com plex procedural logic. While t his is t he case, t here
are a num ber of m echanism s t hat do allow for adding a degree of procedural logic t o diagram s and which com e under t he heading
of com bined fragm ent s. A com bined fragm ent is one or m ore processing sequence enclosed in a fram e and execut ed under specific
nam ed circum st ances. The fragm ent s available are:

• Alt ernat ive fragm ent ( denot ed “ alt ” ) m odels if…t hen…else const ruct s.
• Opt ion fragm ent ( denot ed “ opt ” ) m odels swit ch const ruct s.
• Break fragm ent m odels an alt ernat ive sequence of event s t hat is processed inst ead of t he whole of t he rest of t he diagram .
• Parallel fragm ent ( denot ed “ par” ) m odels concurrent processing.
• Weak sequencing fragm ent ( denot ed “ seq” ) encloses a num ber of sequences for which all t he m essages m ust be processed
in a preceding segm ent before t he following segm ent can st art , but which does not im pose any sequencing wit hin a
segm ent on m essages t hat don’t share a lifeline.
• St rict sequencing fragm ent ( denot ed “ st rict ” ) encloses a series of m essages which m ust be processed in t he given order.
• Negat ive fragm ent ( denot ed “ neg” ) encloses an invalid series of m essages.
• Crit ical fragm ent encloses a crit ical sect ion.
• I gnore fragm ent declares a m essage or m essage t o be of no int erest if it appears in t he current cont ext .
• Consider fragm ent is in effect t he opposit e of t he ignore fragm ent : any m essage not included in t he consider fragm ent
should be ignored.
• Assert ion fragm ent ( denot ed “ assert ” ) designat es t hat any sequence not shown as an operand of t he assert ion is invalid.
• Loop fragm ent encloses a series of m essages which are repeat ed.

The following diagram shows a loop fragm ent .

 24
There is also an int eract ion occurrence, which is sim ilar t o a com bined fragm ent . An int eract ion occurrence is a reference t o anot her
diagram which has t he word " ref" in t he t op left corner of t he fram e, and has t he nam e of t he referenced diagram shown in t he
m iddle of t he fram e.

Ga t e
A gat e is a connect ion point for connect ing a m essage inside a fragm ent wit h a m essage out side a fragm ent . EA shows a gat e as a
sm all square on a fragm ent fram e.

Pa r t D e com posit ion

An obj ect can have m ore t han one lifeline com ing from it . This allows for int er- and int ra- obj ect m essages t o be displayed on t he
sam e diagram .

St a t e I nva r ia nt / Cont in u a t ion s

A st at e invariant is a const raint placed on a lifeline t hat m ust be t rue at run- t im e. I t is shown as a rect angle wit h sem i- circular
ends.

A Cont inuat ion has t he sam e not at ion as a st at e invariant but is used in com bined fragm ent s and can st ret ch across m ore t han one
lifeline.
 25

UM L 2 St a t e M a chine D ia gr a m
St a t e M a chine D ia gr a m s
A St at e Machine Diagram m odels t he behaviour of a single obj ect , specifying t he sequence of event s t hat an obj ect goes t hrough
during it s lifet im e in response t o event s.

As an exam ple, t he following St at e Machine Diagram shows t he st at es t hat a door goes t hrough during it s lifet im e.

The door can be in one of t hree st at es: Opened, Closed or Locked. I t can respond t o t he event s Open, Close, Lock and Unlock.
Not ice t hat not all event s are valid in all st at es: for exam ple, if a door is Opened, you cannot lock it unt il you close it . Also not ice
t hat a st at e t ransit ion can have a guard condit ion at t ached: if t he door is Opened, it can only respond t o t he Close event if t he
condit ion doorWay- > isEm pt y is fulfilled. The synt ax and convent ions used in St at e Machine Diagram s will be discussed in full in t he
following sect ions.

St a t e s

A St at e is denot ed by a round- cornered rect angle wit h t he nam e of t he st at e writ t en inside it .

I nit ia l a nd Fina l St a t e s
The I nit ial St at e is denot ed by a filled black circle and m ay be labelled wit h a nam e. The Final St at e is denot ed by a circle wit h a dot
inside and m ay also be labelled wit h a nam e.

Tr a n sit ion s
Transit ions from one st at e t o t he next are denot ed by lines wit h arrowheads. A t ransit ion m ay have a t rigger, a guard and an
effect , as below.
 26
" Trigger" is t he cause of t he t ransit ion, which could be a signal, an event , a change in som e condit ion, or t he passage of t im e.
" Guard" is a condit ion which m ust be t rue in order for t he t rigger t o cause t he t ransit ion. " Effect " is an act ion which will be invoked
direct ly on t he obj ect t hat owns t he st at e m achine as a result of t he t ransit ion.

St a t e Act ion s
I n t he t ransit ion exam ple above, an Effect was associat ed wit h t he t ransit ion. I f t he t arget st at e had m any t ransit ions arriving at it ,
and each t ransit ion had t he sam e effect associat ed wit h it , it would be bet t er t o associat e t he effect wit h t he t arget st at e rat her
t han t he t ransit ions. This can be done by defining an ent ry act ion for t he st at e. The diagram below shows a st at e wit h an ent ry
act ion and an exit act ion.

I t is also possible t o define act ions t hat occur on event s, or act ions t hat always occur. I t is possible t o define any num ber of act ions
of each t ype.

Se lf- Tr a n sit ion s

A st at e can have a t ransit ion t hat ret urns t o it self, as in t he following diagram . This is m ost useful when an effect is associat ed wit h
t he t ransit ion.

Com pound St a t e s
A st at e m achine diagram m ay include sub- m achine diagram s, as in t he exam ple below.
 27
The alt ernat ive way t o show t he sam e inform at ion is as follows.

The not at ion in t he above version indicat es t hat t he det ails of t he Check PI N sub- m achine are shown in a separat e diagram .

En t r y Poin t
Som et im es you won’t want t o ent er a sub- m achine at t he norm al I nit ial St at e. For exam ple, in t he following sub- m achine it would
be norm al t o begin in t he I nit ializing st at e, but if for som e reason it wasn’t necessary t o perform t he init ializat ion, it would be
possible t o begin in t he Ready st at e by t ransit ioning t o t he nam ed Ent ry Point .

The following diagram shows t he st at e m achine one level up:

 28
Ex it Poin t
I n a sim ilar m anner t o Ent ry Point s, it is possible t o have nam ed alt ernat ive Exit Point s. The following diagram gives an exam ple
where t he st at e execut ed aft er t he m ain processing st at e depends on which rout e is used t o t ransit ion out of t he st at e.

Ch oice Pse u do- St a t e

A choice pseudo- st at e is shown as a diam ond wit h one t ransit ion arriving and t wo or m ore t ransit ions leaving. The following
diagram shows t hat whichever st at e is arrived at aft er t he choice pseudo- st at e is dependent on t he m essage form at select ed during
execut ion of t he previous st at e.

Junct ion Pse udo- St a t e

Junct ion pseudo- st at es are used t o chain t oget her m ult iple t ransit ions. A single j unct ion can have one or m ore incom ing and one or
m ore out going t ransit ions and a guard can be applied t o each t ransit ion. Junct ions are sem ant ic- free; a j unct ion which split s an
incom ing t ransit ion int o m ult iple out going t ransit ions realizes a st at ic condit ional branch as opposed t o a choice pseudo- st at e which
realizes a dynam ic condit ional branch.
 29
Te r m in a t e Pse u do- St a t e
Ent ering a t erm inat e pseudo- st at e indicat es t hat t he lifeline of t he st at e m achine has ended. A t erm inat e pseudo- st at e is not at ed as
a cross.

H ist or y St a t e s
A Hist ory St at e is used t o rem em ber t he previous st at e of a st at e m achine when it was int errupt ed. The following diagram
illust rat es t he use of hist ory st at es. The exam ple is a st at e m achine belonging t o a washing m achine.

I n t his st at e m achine, when a washing m achine is running it will progress from Washing t hrough Rinsing t o Spinning. I f t here is a
power cut , t he washing m achine will st op running and will go t o t he Power Off st at e. Then when t he power is rest ored, t he Running
st at e is ent ered at t he Hist ory St at e sym bol m eaning t hat it should resum e where it last left - off.

Con cu r r e n t Re gion s
A st at e m ay be divided int o regions cont aining sub- st at es t hat exist and execut e concurrent ly. The exam ple below shows t hat
wit hin t he st at e " Applying Brakes" , t he front and rear brakes will be operat ing sim ult aneously and independent ly. Not ice t he use of
fork and j oin pseudo- st at es rat her t han choice and m erge pseudo- st at es. These sym bols are used t o synchronize t he concurrent
t hreads.
 30

UM L 2 Tim ing D ia gr a m
Tim ing D ia gr a m s
UML t im ing diagram s are used t o display t he change in st at e or value of one or m ore elem ent s over t im e. I t can also show t he
int eract ion bet ween t im ed event s and t he t im e and durat ion const raint s t hat govern t hem .

St a t e Life line
A st at e lifeline shows t he change of st at e of an it em over t im e. The X- axis displays elapsed t im e in what ever unit s are chosen while
t he Y- axis is labelled wit h a given list of st at es. A st at e lifeline is shown below.

Va lu e Life lin e
A value lifeline shows t he change of value of an it em over t im e. The X- axis displays elapsed t im e in what ever unit s are chosen, t he
sam e as for t he st at e lifeline. The value is shown bet ween t he pair of horizont al lines which crosses over at each change in value. A
value lifeline is shown below.

Put t ing it a ll t oge t he r

St at e and Value Lifelines can be st acked one on t op of anot her in any com binat ion. They m ust have t he sam e X- axis. Messages can
be passed from one lifeline t o anot her. Each st at e or value t ransit ion can have a defined event , a t im e const raint which indicat es
when an event m ust occur, and a durat ion const raint which indicat es how long a st at e or value m ust be in effect for. Once t hese
have all been applied, a t im ing diagram m ay look like t he following.
 31

UM L 2 Use Ca se D ia gr a m
Use Ca se M ode l
The Use Case Model capt ures t he requirem ent s of a syst em . Use cases are a m eans of com m unicat ing wit h users and ot her
st akeholders about what t he syst em is int ended t o do.

Act or s
A Use Case Diagram shows t he int eract ion bet ween t he syst em and ent it ies ext ernal t o t he syst em . These ext ernal ent it ies are
referred t o as Act ors. Act ors represent roles which m ay include hum an users, ext ernal hardware or ot her syst em s. An act ors is
usually drawn as a nam ed st ick figure, or alt ernat ively as a class rect angle wit h t he «act or» keyword.

Act ors can generalize ot her act ors as det ailed in t he following diagram :

Use Ca se s
A use case is a single unit of m eaningful work. I t provides a high- level view of behavior observable t o som eone or som et hing
out side t he syst em . The not at ion for a use case is an ellipse.

The not at ion for using a use case is a connect ing line wit h an opt ional arrowhead showing t he direct ion of cont rol. The following
diagram indicat es t hat t he act or Cust om er uses t he Wit hdraw use case.

The uses connect or can opt ionally have m ult iplicit y values at each end, as in t he following diagram which shows t hat a cust om er
m ay only have one wit hdrawal session at a t im e, but a bank m ay have any num ber of cust om ers m aking wit hdrawals concurrent ly.
 32
Use Ca se D e fin it ion
A Use Case Typically I ncludes:

• Nam e and Descript ion

• Requirem ent s
• Const raint s
• Scenarios
• Scenario Diagram s
• Addit ional inform at ion.

N a m e a n d D e scr ipt ion

A use case is norm ally nam ed as a verb- phrase and given a brief inform al t ext ual descript ion.

Re qu ir e m e n t s
The requirem ent s define t he form al funct ional requirem ent s t hat a use case m ust supply t o t he end user. They correspond t o t he
funct ional specificat ions found in st ruct ured m et hodologies. A requirem ent is a cont ract or prom ise t hat t he Use Case will perform
an act ion or provide som e value t o t he syst em .

Const r a int s
A const raint is a condit ion or rest rict ion t hat a Use Case operat es under and includes pre, post and invariant condit ions. A
precondit ion specifies t he condit ions t hat need t o be m et before t he Use Case can proceed. A post condit ion is used t o docum ent
t he change in condit ions t hat m ust be t rue aft er t he execut ion of t he Use Case. An invariant condit ion specifies t he condit ions t hat
are t rue t hroughout t he execut ion of t he Use Case

Sce na r ios
A Scenario is a form al descript ion of t he flow of event s t hat occur during t he execut ion of a Use Case inst ance. I t defines t he
specific sequence of event s bet ween t he syst em and t he ext ernal Act ors. I t is norm ally described in t ext and corresponds t o t he
t ext ual represent at ion of t he Sequence Diagram .

I n clu din g Use Ca se s

Uses Cases m ay cont ain t he funct ionalit y of anot her Use Case as part of t heir norm al processing. I n general it is assum ed t hat any
included use case will be called every t im e t he basic pat h is run. An exam ple of t his is t o have t he execut ion of t he Use Case < Card
I dent ificat ion> t o be run as part of a Use Case < Wit hdraw> .

Use Cases m ay be included by one or m ore Use Case, helping t o reduce t he level of duplicat ion of funct ionalit y by fact oring out
com m on behavior int o Use Cases t hat are re- used m any t im es.

Ex t e nding Use Ca se s
One Use Case m ay be used t o ext end t he behavior of anot her; t his is t ypically used in except ional circum st ances. For exam ple, if
before m odifying a part icular t ype of cust om er order, a user m ust get approval from som e higher aut horit y, t hen t he < Get
Approval> Use Case m ay opt ionally ext end t he regular < Modify Order> Use Case.
 33
Ex t e n sion Poin t s
The point at which an ext ending use case is added can be defined by m eans of an ext ension point .

Syst e m Bou n da r y
I t is usual t o display use cases as being inside t he syst em and act ors as being out side t he syst em .