Activity Diagrams Expl

Analysis Through Pictures Version 3.0

© 2011 Leslie Munday Page 91

Chapter 4 Use Case Activity Diagrams

This chapter is specific to modeling use case details with activity

diagrams. Previously we discussed how to detail a use case with text, but

this is often not sufficient for ensuring the completeness of the use case.

The activity diagram allows us to perform a cross-check between the

textual details and a formal notation in diagrammatic form.

UML activity diagrams are intended for much more than simply modeling

steps in a use case (detailing class operations, for example). Some of the

activity diagram capabilities go beyond those that are needed for modeling

use cases.

The notation for UML 2.x activity diagrams includes symbols for;

Partition, Initial Node, Final Node, Action, Accept Event, Send Signal,

Structured Activity, Decision, Merge, Fork, Join, Control Node, Object

Node, Central Buffer, Data Store, Activity Parameter, Input Pin, Output

Pin, Value Pin, Object Flow, Control Flow and just a plain Flow.

It is unlikely that you will find a use for all (or even most) of these

symbols when diagramming use cases. [Not only that, but your audience

will not be happy if they need to understand the difference between a

Central Buffer and a Data Store, for example.] Applying the rule of only

using the minimum language necessary that delivers the details of what it

is to say, many of the above elements may be eliminated when modeling

use case details.

The following modeling notation uses the minimum set of elements that

are needed to model the details of a use case and define consistent

meanings for them, when used for use case modeling. The following

subsections define the symbol used54

to represent the element, a

description of its purpose on an activity diagram, its label, the rules of its

use and how it is related to the text of a use case.

54 These symbols were imported to Visio from a template of UML 2.2 icons that I downloaded from

softwarestencils.com. BTW, I highly recommend this stencil over the one that comes with Visio. As well as

having additional symbols that support UML 2, all of the symbols display their „Name‟ field on the Visio

diagram. Many of the default Visio symbols do not (why, I have no idea .. what is the point in naming a

drawing element and not being able to see its name?)

http://www.softwarestencils.com/tips/index.html



Contents

4.1 Activity Diagram Elements

4.1.1 Event Flow

4.1.2 Initial Node State

4.1.3 Action

4.1.4 Decision

4.1.5 Merge

4.1.6 Fork

4.1.7 Join

4.1.8 Activity Final State

4.1.9 Object Flow

4.1.10 Object Node

4.1.11 Activity

4.2 Rules For Modeling Activity Diagrams

4.3 Examples of Using the Rules for Activity Diagrams

4.3.1 Two Events Exiting from an Action

4.3.2 Several Events from the Initial state

4.3.3 Merging

4.3.4 Action Looping Back To Itself

4.3.5 Forks and Joins

4.3.6 Objects

4.3.7 Use Case Fragments

4.4 Summary of Activity Diagram Rules

4.5 Addendum 1

4.6 Addendum 2



4.1 Activity Diagram Elements

The notation in both BUC and SUC activity diagrams is identical. The

necessary elements and their symbols is described in this section.

4.1.1 Event Flow

- Otherwise known as a control flow in UML (or a

transition in Visio). The event flow represents something that has

occurred. For example, the triggering event of the use case. An event flow

is directed and the direction is represented by an arrowhead at one end of

the flow. The event flow may only be traversed along the direction

indicated by the arrowhead. An event flow connects any two other

symbols, where the rules for those elements allow them to be connected.

The event flow represents one or more externally visible event(s) between

the AUC and one of its actors or between actors or workers in a BUC.

The event flow always connects exactly 2 distinct elements, i.e. it may not

connect to the same element at both ends.

Label an event in past tense, i.e. <something happened> or you may leave

it blank, when:

There was no action between it and the previous event, and the

previous event has a label, The event takes the name of the previous

event.

There is no action between it and subsequent events that all have

labels. All of the subsequent events are captured by this flow.

(Generally the event flow will represent one or more input events to the

use case from an actor or worker, but output events may be represented by

event flows also.) The event flow represents a step in the workflow text of

the use case.

4.1.2 Initial Node State

Preconditions - This is the starting point when executing the use case.

The initial node represents the preconditions of the use case.



Label the initial node with the name(s) of the precondition(s) of the use

case.

There is exactly 1 initial node on a use case activity diagram. There is

exactly 1 use case triggering event exiting from this node. There are no

events entering this node.

4.1.3 Action

Action

- The action describes activity that is performed by the system

in response to an event occurring. The action represents a step in the

workflow textual description of the use case.

Label the action with text that describes an activity in the present tense.

I.e. <doing something>.

An action has exactly one event entering, and one event exiting it.

4.1.4 Decision

Question?

- The decision acts very much like the decision in a

flowchart.

It has a single event entering, and several events exiting it. The decision is

a representation of a branch from the current flow to an alternate or

extension flow in the text of the use case.

Its label always asks a question („Is balance>50?, for example).

The labels55

on the events (or responses to the question) exiting the

decision must equal all possible valid answers to the question being asked

by the decision.

In addition, the answers to the question may not overlap (only one path

may be taken upon exiting the decision). For this reason, it may be easier

to model decisions responses with simple 'Yes' or 'No' answers. In this

55 This section used to describe the labels as guards, but I have revised it to remove reference to guards on

control flows. I do not see any need to have both on a single event flow. One or the other suffices for my needs.



manner it is not necessary to be concerned whether there is overlap or

missing values in the answers.

For every decision leading to an alternate flow there must be an

equivalent subsequent merge when it re-enters the flow from which it

branched.

4.1.5 Merge

- The merge is the opposite of a decision. It has several events

entering, and only a single event exiting. The merge represents an

alternate flow re-entering the basic flow (or a different alternate flow) of

the use vase. It also represents the last line of an alternate flow, which

contains the text 'the use case continues from step „x‟.

The merge does not require a label.

For every merge in the diagram there must be an equivalent decision.

4.1.6 Fork

- A fork allows the current flow to be split into several flows

running in parallel. The fork represents steps in the use case workflow

description that are shown as executing in parallel.

A fork is used when the sequence of steps is indeterminate (i.e. there are

no requirements around ordering).

Forks do not require labels.

A fork has a single event entering, and several events exiting it.

For every fork in the diagram there must be an equivalent following join.

4.1.7 Join

- A join is the opposite of a fork. It represents the end of an

indeterminate set of use case steps. It allows several parallel paths to

merge into a single flow. It has several events entering and a single event

exiting it.

For every join in the diagram there must be an equivalent preceding fork.



Joins do not require labels.

4.1.8 Activity Final State

Postcondition - The activity final state terminates a use case flow (also

known as the end state). This could be the end of the main flow or an

extending flow. The final state represents a postcondition of the use case,

and the event entering it represents the text 'the use case ends'.

Label the final state with the name of the postcondition that it represents.

It has exactly one event entering it.

Every postcondition has at least one equivalent final state.

4.1.9 Object Flow

- The object flow connects a single action to a single

object node. The arrowhead indicates whether the object is an input to the

action or being manipulated by the action. There is no exact equivalent in

the textual workflow of the use case.

Object flows are not labeled.

4.1.10 Object Node

Object : Class

[state]

- The object node represents a thing (artifact) that is being

manipulated or used by the action. If the object flow that is connecting the

object to the action is in the direction of the object the artifact is being

manipulated (produced), otherwise it is being used (consumed). The object

node represents the artifacts in the text of the use case.

The object node takes the name of the object, (and an optional state that

the object is in; after it has been manipulated, or when it is used, by the

action it connects to).

Every action should either consume or produce at least 1 object.



4.1.11 Activity act Name

- The activity element does not come with Visio 2007,56

but it is a part of UML 2.

This is used to represent a sequence of actions. For example, if you have a

use case fragment included in the steps of your use case, then this symbol

may be used to represent those included steps and the use case fragment is

referenced from within the activity.

Label the activity with the name of the use case fragment that it represents.

4.2 Rules For Modeling Activity Diagrams

The following rules can be deduced from the descriptions of each element.

[It seems only fair to give a justification for each rule and what the

consequences might be of not following the rule.]

1. There is exactly 1 initial node on a use case activity diagram.

2. There is exactly 1 use case triggering event exiting from this node.

Rule 1 follows from rule 2: There needs be only a single entry point into

the use case. This is via the triggering event, which starts the execution of

the use case. The initial node (representing the use case preconditions), is

effectively a guard ensuring that the triggering event is only recognized

under the right conditions.

If the use case starts with 2 initial paths that later converge (if they don‟t

converge, you probably should have 2 use cases), then show the triggering

event entering a decision or a fork, depending upon whether the 2 paths

can run in parallel or they are discrete.

This is much simpler to understand for the reader than having 2 initial

entry points. And it also raises the question, can the 2 paths execute in

parallel, or does the use case only execute the first triggering event? See

Chapter 4

56In fact I only just discovered this element while writing this chapter.



3. An action has exactly one event entering, and one event exiting it.

The question arises; what does it mean to have 2 events entering or exiting

an action; can they enter and exit in parallel or are they discrete events and

only the first is recognized?

By ensuring that the discrete or parallel flows are always indicated by a

fork or a decision ensures that this rule is not broken.

4. The decision has a single event entering, and several events exiting

it.

This is actually enforced by the rules governing UML. A decision always

indicates an alternate (or exception) path being taken in the flow of the use

case. If there are two flows that use the decision, then precede it with a

merge or a join, whichever is appropriate.

Again the rule clarifies whether the input flows are executing in parallel or

if they are discrete.

5. The labels on the events (which are responses to the question)

exiting a decision must equal all possible valid answers to the

question being asked by the decision.

This and rule 6 are normal UML rules for decisions, but unenforceable,

since the exit event labels are often written in English.

If a valid answer is not shown, then functionality of the use case is being

missed by the use case details, and it will eventually fail to execute.

6. The answers to the question exiting the decision may not overlap.

If a response may take more than a single exit from the decision then

which path should the use case take? If it is possible for the same response

to take 2 parallels paths, then this may be modeled with a separate exiting

event that enters a fork. Model this way to maintain consistency.

7. For every decision leading to an alternate flow there must be an

equivalent following merge, and for every merge in the diagram

there must be an equivalent decision.

This rule is mostly used for validating clarity and correctness of the use

case steps. It allows a direct connection to the textual details of the use

case steps. It also clarifies that either of the two paths entering the merge

will cause the use case to continue, without the reader having to retrace the


© 2011 Leslie Munday 9

use case steps in order to determine whether the paths were the result of a

decision or a fork57

.

8. A fork has a single event entering, and several events exiting it.

Again, this is a UML rule that may be enforced by your modeling tool. If

you need several flows to enter the fork, then it may be preceded by a

merge or a join, as appropriate.

9. For every fork in the diagram there must be an equivalent

following join. For every join in the diagram there must be an

equivalent preceding fork.

The reasons for this rule are similar to those for the decision/merge rules,

with the added complication that the diagram is easily misunderstood and

can easily become incorrect if this rule is not followed. If 2 paths running

in parallel do not eventually merge does the use case ever finish

executing? (There is an example of this rule in action in Figure 30:)

10. A postcondition has a single event exiting it.

This rule is a consequence of the above rules concerning action,

decision/merge and fork/join rules. If 2 event flows may enter a

postcondition, the diagram should clarify whether they are the result of a

merge or a join.

11. Every postcondition has at least one equivalent final state.

Each final state represents a resulting state of the system after the use case

has completed execution. Each should be distinct in order to clarify which

postcondition was the result of the use case execution. For clarity of

drawing it is sometimes useful to show a single postcondition as several

different final states, all representing the same postcondition.58

12. An event flow may not connect at both ends to the same element.

57 If a path does not re-enter a flow from which it branched, such as an exception flow, then no equivalent

merge is necessary.

58 Unless using Enterprise Architect – which prevents you from showing duplicate symbols on the same

diagram.


© 2011 Leslie Munday 0

This rule is a consequence of the preceding rules. If this occurs, then one

of these rules has been broken.

13. Every action should either consume or produce an object.

This is not a rule as such, but a guideline that you may wish to check the

activity diagram against. If an action is not connected to observable data, it

may be prudent to ask; “what could this action be doing such that no

observable data is being consumed or produced?”.

4.3 Examples of Using the Rules for Activity Diagrams

As you may have noticed, these rules are very restrictive. If you find them

too restrictive for your purposes, take what you want and ignore the

others, but make sure that you have an appropriate notation in place to

replace the removed rule. Using such a restrictive set of rules helps to

verify that the use case is correct and complete, and gives the reviewers a

checklist to work against.

Using these rules ensures that both the textual use case description and the

activity diagram should have the same number of triggers, alternate paths,

extensions and postconditions. For every decision in the activity diagram

there should be an equivalent alternate or extension flow. Every action and

event should map to 1 or more steps in the use case59

.

If you cannot model every path through your use case on a single activity

diagram within your guidelines, then either your guidelines are too

restrictive or your use case is incorrect. Within these guidelines you

should be able to model any valid textual use case that is not overly

complicated, on a single diagram.

The following sections contain graphical examples of activity diagrams

that do not satisfy these rules.

4.3.1 Two Events Exiting from an Action

59 I stop short of insisting that the number of steps are equal, but if you really want accuracy there is no reason

why you could not go back and update the text in the steps of the use case to reflect the events and actions in the

activity diagram.



Why do we not show two events exiting an action? As shown in Figure

18::

Doing Previous Action

Taking Action Taking Other Action

Figure 18: Action With 2 exiting events

The question is; do the events represent a decision being made, or are they

parallel flows as the result of a fork?

Instead of being open to interpretation, the diagram can explicitly state

what action is occurring (without having to look at the details of the

action). If the result of the action is a decision, it is indicated in the

diagram, Figure 19:.



Question?

No Yes

Question Received

Figure 19: Representation of a Decision

Or the action is followed by two parallel flows as shown in Figure 20:.



Doing Action A1 Doing Action A2


Figure 20: Representation of a Fork With 2 Parallel Flows

But what if the flow exiting the action represents several unrelated

asynchronous events? Then it is not necessary to label the flow exiting the

action. The flows exiting the decision represent the different events that

cause the action to exit. See Figure 21: below for an example:

Waiting For Customer Input

What Was The Event?

Customer Made A Change User Interface Was Reset

Figure 21: Unrelated Events Exiting From An Action

In Figure 21: while waiting for the customer to make an entry to the

system, it is possible for an event to occur elsewhere, that causes the

system to reset the user interface. (This might be because the customer

took too long to make a change.) Both events are shown as exiting the

action by the unlabeled flow, but then the decision will determine which

of the 2 events occurred.



4.3.2 Several Events from the Initial state

Similarly, the same rules apply to the initial state.

Consider that the use case describes two initial paths depending upon

which command is entered. You might want to represent a basic flow and

alternate flow as follows:


B Pressed A Pressed

Precondition

Figure 22: Initial State With Two Events

If the two flows represent alternative paths exiting the initial state:

Taking Action

Taking Other Action

Precondition

Figure 23: Merge From The Initial State

Then we have just broken the rule that every merge must follow a

previous decision.

Similarly, if the two flows represent parallel actions being initiated from

the trigger of the initial state:



Taking ActionAlso Taking Action

Precondition

Figure 24: Initial State With Parallel Events

Again, it may appear obvious that these are parallel activities, but the rule

that every join must have a preceding fork is broken.

Figure 25: shows how to represent Figure 23: and Figure 24: respectively.


Question?

Doing Action A1 Doing Action A2

Precondition

Precondition

Figure 25: Correct Representation of Two Events from the Initial State

Another reason to impose guidelines that may seem unnecessary and

require the author to add extra elements to the diagram, is to encourage the

rule, „that if there are two ways of doing something, pick one and stick

with it‟. The representation in Figure 25: will prove necessary. The

notation in Figure 23: and Figure 24: is not.



4.3.3 Merging

We could represent a merge by simply having the two event flows enter

the same action, as shown below:

BF AF

MF

Figure 26: Merging Flows into an Action

But what about the case where the two flows meet at a fork? A fork only

allows one event to enter. We need to represent this scenario with the

diagram below:



BF AF

Figure 27: Correct Representation of a Merge

Again we have two ways to represent the same thing, but only Figure 27:

works in every instance. So choosing the notation in Figure 27: everytime

disallows any alternative notations for the same thing.

4.3.4 Action Looping Back To Itself

How does one model an action that transitions back to itself? As in Figure

28:.



Action

entry

loop

Figure 28: Looping Transition

In this instance there must be at least 2 transitions exiting the action

(otherwise the activity diagram will never end), so draw a single transition

exiting the action that enters a decision. The decision allows one path to

continue. the other path loops back to the action. But the path looping

back to the action cannot be shown entering the action directly, so a merge

is drawn preceding the action into which both the looping transition and

the initial entering transition connect. Figure 28: is now redrawn as in

Figure 29:.

merge

Action

entry

loop

exit

loop or exit?

Figure 29: Loop With Entry And Exit



The „entry‟ transition ignores the merge and continues through to trigger

the action. The „loop‟ and „exit‟ transitions are both represented by the

unlabeled transition exiting the action. The decision determines which

path is taken (one or the other). The „loop‟ returns to merge into the

action. The „exit‟ transition continues the activity diagram.

Figure 29: may at first appear to be more complicated than Figure 28:, but

what happens if the „loop„ and „exit‟ occur at the same time. The logic for

resolving the correct path to take may be placed in the decision box, and

not in the action.

4.3.5 Forks and Joins

All forks must have a following join that merges all paths back into a

single flow of events. This is perhaps the toughest rule to justify. There are

rules concerning joins that state that the join can be exited when all paths

entering the join have completed. This statement would make Figure 30:

correct.

Figure 30: A Fork flow without a Join

But the structure in Figure 31: would also be correct:



Figure 31: Forks without a Join

Does this make sense? In Figure 31: the forked flow to the left has joined

back to the basic flow (as indicated by the single transition entering a join

and a single transition exiting the same join). The flow to the right never

joins back to the basic flow, but is still running in parallel to the basic

flow. If this is not the basic flow and it‟s not an alternate flow (because an

alternate flow branches from a decision) then what is it? Even if you could

come up with an elaborate description of what is happening, imagine the

complicated scenarios that one could create using forks whose flows do

not subsequently join. Use cases are supposed to be simple.

Again, invoking the rule that if there is two ways to do something pick one

and stick with it. For consistency, every forked flow merges back to the

flow that it forked from via a join. Figure 30: now looks like the flow in

Figure 32:.



Figure 32: Paired Fork and Join

Terminating a flow with a forked execution might on the face of it appear

to be a way to allow the basic flow to continue while a parallel flow is

executing. If we put a join at the end of both flows, as shown in Figure 30:

neither flow can continue past the join until the other flow has finished

(this also leads to potential deadlock). If we wish the basic flow to

continue through to termination without the parallel flow holding up

execution, simply add the join just prior to the final state. See Figure 33::



Figure 33: Nested Parallel Flows

Now the flow to the left may continue through to completion without

having to wait for the parallel flow on the right. [Completion is the join;

remember the flow entering the final node simply states, „the use case



ends‟.] Similarly the right hand flow does not need to wait for the left flow

to complete.

4.3.6 Objects

Attaching objects to actions is a good method for checking that every step

in your use case is performing value. Ensure that each action manipulates

some data and that the data is used by an actor or worker of the use case.

Connect at least one object to each action using an outgoing (arrowhead

connected to the object) object flow to indicate what artifacts are being

manipulated by the action. Then add objects to represent artifacts that are

being consumed by the action. Connect these to the action with an

incoming (arrowhead connected to the action) object flow. If you cannot

discover an artifact that the action outputs to, then you might want to

consider revising the steps related to that action in the use case. 60

Figure 34: shows activity with objects attached.

Sending Results To User

Waiting For Customer Response

Results Sent

Search Results

Response

Response Received

Figure 34: Objects On An Activity Diagram

60 Consider that there are valid actions that do not necessarily produce or consume data. A timer is an action that

comes to mind, but it could be argued that a timer is consuming „time‟ although it is not explicitly shown on the

activity diagram.



Figure 35: shows an action where it may not be appropriate to add objects.

Sending Results To User

Waiting 30 Seconds

Results Sent

Search Results

Response

Response Received

Waiting For Customer Response

Times Up

Figure 35: Action Without Objects

4.3.7 Use Case Fragments

This section contains examples of modeling extending and included use

case fragments with activity diagrams. Use case fragments are used to

share parts of a use case between use cases, or simply for organizing the

use cases details into smaller chunks.61

Consider the use case example in Figure 36:.

61 I have witnessed use case modeling examples where use case fragments have been used to breakdown a use

case into some sort of functional decomposition. Use cases are not intended to be decomposed. The fragments

should only be used for organization and removal of duplication issues.



Serve Customer Bill Customer

Customer

«includes»

Credit Processor

Figure 36: Included Use Case Fragment

The Serve Customer use case includes a use case fragment that deals with

billing customers. The Bill Customer fragment interfaces with a secondary

actor that deals with credit card processing.

The Serve Customer activity diagram is shown in Figure 37:.



Serve Food To Customer

Bill Customer

Meal Finished

Clean Table

Customer Billed

Figure 37: Simple Serve Customer Activity Diagram.

The activity diagram has been simplified to show that the customer is

served a meal, when the customer has finished their meal, they are billed

for the meal and then the table is cleaned, in preparation for the next

customer.

The Bill Customer activity is shown as a use case fragment. The Bill

Customer fragment activity diagram is shown in Figure 38:.



Customer Exists

Meal Finished

Handing Bill To Customer

Customer Reviewing Bill

Bill Given To Customer

Verifying Payment

Customer Pays Bill

Payment Accepted?

Payment Verified

Requesting Alternate Payment

[No]

Customer Pays Bill

Handing Receipt To Customer

[Yes]

Customer Billing Complete

Bill Paid

Figure 38: Bill Customer Activity Diagram



The activity diagram shows that the customer is billed after the meal is

complete. The customer pays the bill and the restaurant verifies that the

payment method is acceptable.62

The payment is accepted, the customer is

handed a receipt for their payment and the use case ends.

The use case contains (secondary actors), preconditions, postconditions,

alternate and exception flows, just like a normal use case. (The primary

actor can be considered to be the „including‟ use case.)

4.4 Summary of Activity Diagram Rules

Sticking to these guidelines (or whatever equivalent guidelines you use),

greatly helps to check the use case for, consistency (have we captured all

of the alternate paths?), correctness (are the steps in the right order?) and

completeness (are we missing any steps?).

If you do deviate from the guidelines (and you probably will) it is

recommend adding a note explaining why the deviation. In general, if you

find that there is more than 1 way of modeling activity, add notes

explaining why you choose one way over the others. Eliminating all but 1

a single notation makes the diagram consistent, easier to review, (and

saves on diagram notes).

4.5 Addendum 1

It is possible for the decision and merge to be the same symbol on the

diagram. Consider the following example in Figure 39::

62 Payment method may also be a use case fragment, but only if the details are required by another use case.



Executing Command

Command Enterd

Exit?Yes

Waiting For Command

Command Enterd

No

Figure 39: Combined Decision and Merge

A command is entered by the primary actor. The system executes the

command and waits for the primary actor to enter another command. If the

primary actor enters the „Exit‟ command at any time the use case ends.

We could have drawn the merge symbol above or below the decision, but

in this example it is unnecessary and the 2 symbols are combined63

.

4.6 Addendum 2

Note that swimlanes have not been discussed in conjunction with activity

diagrams. Swimlanes are often used to allocate actions to workers, by

lining the actions performed by a worker either vertically or horizontally

on the page. Swimlanes are avoided for several reasons:

They add whitespace to the diagram.

They restrict the flexibility of the layout of the diagram.

On a diagram that has many workers, the analysts will find themselves

editing the diagram for format rather than content. (In particular, when

re-organizing action allocations to swimlanes, it often proves more

efficient to delete the swimlanes layout the diagram and add the

swimlanes back to the diagram.64

)

63 If your modeling tool allows such a notation.

64 In fact, I have yet to discover a modeling tool that does not totally destroy the layout of the diagram when

swimlanes are edited.



There are many ways to portray the same information that one gets from

swimlanes on an activity diagram, using much simpler concepts.

Alternatives to swimlanes are shown in the examples in this book.

Activity Diagrams Expl

Documents

Transcript of Activity Diagrams Expl