Activity diagram tutorial
-
Upload
declan-chellar -
Category
Self Improvement
-
view
25.482 -
download
3
description
Transcript of Activity diagram tutorial
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