Using Activity Diagrams toModel Use Cases Visually

Part 1: The Basics

by Declan Chellar

START POINT

The Start Point represents the

EVENT that triggers the use case.

Label the Start Point to make the INTENT and

TRIGGER of the use case explicit.

Actor elects to Add Customer

END POINT

Actor elects to Add Customer

Actor elects to Add Customer

Label the End Point to EXPLICITLY confirm that the intent of the use case has

been achieved.

Actor elects to Add Customer

Customer added

Actor elects to Add Customer

Customer added

This makes it clear to the reader that the use case is complete and that nothing further is needed in order

to fulfil the intent.

Actor elects to Add Customer

End of processNOT a good label for an End Point

To reach the End Point…

… you need to model STEPS.

Link the steps with TRANSITIONS.

Transitions use arrow heads to show the

direction of process flow.

I like to put a note against any step that achieves

the goal of the use case.

Goal X achieved

… because it might not be the last step.

Goal X achieved

The most common route from the start

point to the end point has many names.

But they effectively mean the same thing.

PRIMARY…

BASIC…

TYPICAL…

…PATH

…FLOW

…COURSE OF EVENTS

Combine any word on the left with any phrase on the

right.

…SCENARIO

Often in a use case the System has to make a

decision based on business rules...

The actual decision takes place within a

STEP

System determines

whether X or Y The actual decision takes place within a

STEP

System determines

whether X or Y A DECISION POINT is then used to help the reader navigate the

diagram.

DECISION POINT

Decision Points contain text which describes

the nature of the decision to be made.

So was it X or Y?

Decision points allow the flow to branch

away from the Primary Path.

[Condition 2]

[Condition 1]

Transitions coming out of Decision

Points must have a GUARD.

[IT WAS “Y”]

[IT WAS “X”]

A Guard needs to explicitly describe a

condition which must be true in order to proceed

down that path.

[Condition 2]

[Condition 1]

If the flow rejoins the Primary Path, it is known as an Alternate Path.

[Condition 2]

[Condition 1]

With Alternate Paths, the goal of

the Use Case is still achieved.

[Condition 2]

[Condition 1]

There are other names for

Alternate Paths.

[Condition 2]

[Condition 1]

ALTERNATE…

ALTERNATIVE…

SECONDARY…

…PATH

…FLOW

…COURSE OF EVENTS

Combine any word on the left with any phrase on the

right.

…SCENARIO

[Condition 2][Condition 1]

You can show how paths rejoin by using

a MERGE POINT.

[Condition 2][Condition 1]

You can show how paths rejoin by using

a MERGE POINT.

[Condition 2][Condition 1]

I don’t like Merge Points because they take up space

without adding clarity.

[Condition 2][Condition 1]

I prefer to model merging paths like this.

[Condition 2]

[Condition 1]

Merge Points can sometimes be

particularly superfluous.

[Condition 2]

[Condition 1]

I think it is neater to show the merge

this way.

[Condition 2]

[Condition 1]

[Condition 3]

If the flow does NOT rejoin the Primary Path, it is known as an Exception Path.

[Condition 2]

[Condition 1]

[Condition 3]

With Exception Paths, the goal of

the Use Case is NOT achieved.

Goal X achieved

[Condition 2]

[Condition 1]

[Condition 3]

With Exception Paths, the goal of

the Use Case is NOT achieved.

Goal X achievedUh, oh!

[Condition 2][Condition 3]

[Condition 1]

I like to use colour to highlight the different

paths.

[Condition 1]

[Condition 2][Condition 3]

[Condition 2]

[Condition 1]

[Condition 3]

[Condition 3]

This makes it easy to identify test scenarios at a

glance.

[Condition 1]

[Condition 2]

A1: [Condition 2]

P: [Condition 1]

E1: [Condition 3]

I also like to label the Guards in order to easily

identify the paths.

P1:

P2: A1.1:E1.1:

A1: [Condition 2]

P: [Condition 1]

E1: [Condition 3]

And I like to label the Steps for easy backward

reference from Business Rules and a Logical Data

Model.

P1:

P2: A1.1:E1.1:

A1: [Condition 2]

P: [Condition 1]

E1: [Condition 3]

Primary Path: P1, P2.

P1:

P2: A1.1:E1.1:

A1: [Condition 2]

P: [Condition 1]

E1: [Condition 3]

Primary Path: P1, P2.

Alternate Path 1: P1, A1.1, P2.

P1:

P2: A1.1:E1.1:

A1: [Condition 2]

P: [Condition 1]

E1: [Condition 3]

Primary Path: P1, P2.

Alternate Path 1: P1, A1.1, P2.

Exception Path 1: P1, E1.1.

[Condition 2]

[Condition 1]

[Condition 3]

In some Use Cases, you will need to

model parallel steps

X

[Condition 2]

[Condition 1]

[Condition 3]

A B

In this example, steps A and B must both start after step

X finishes and must both finish before the Use Case

ends.

X

[Condition 2]

[Condition 1]

[Condition 3]

A B

But we do not care about the order in

which A and B happen.

X

[Condition 2]

[Condition 1]

[Condition 3]

A B

A and B could even happen at the

same time.

[Condition 2]

[Condition 1]

[Condition 3]

A C

B

In this example, B must follow A, but we do not care when C happens in

relation to (A + B).

[Condition 2]

[Condition 1]

[Condition 3]

A

B

In some Use Cases, you will need to model

repeated steps.

[Condition 2]

[Condition 1]

[Condition 3]

A

B

For each X:

In this example, you repeat (A + B) until there is no more X.

[Condition 2]

[Condition 1]

[Condition 3]

A

B

For each X:

For example, you might do this when

adding passengers to a holiday booking.

Let’s review the shapes

[Condition]

For each X:

START POINT

END POINT

STEP

TRANSITION

DECISION POINT

GUARD

REPEATED STEPS

PARALLEL STEPS

www.chellar.com/blog