The document introduces activity diagrams, which are like flow charts for modeling the flow of logic through a system. They define the workflow and how objects share responsibilities. The key elements of activity diagrams are described, and an example is provided to demonstrate how a simple game mechanic could be modeled step-by-step using activity diagrams.

1. +
Activity Diagrams
Systems Analysis and Design
Michael Heron

2. +
Introduction
 Last week we talked about use-case diagrams.
 These let us define the interactions an actor can have with our
systems.
 However, we also need to define how those actions work.
 If we don’t have those, our diagrams are no more effective than
back of the envelope calculations.
 Many of you will be familiar with the idea of a flow chart.
 One of the simplest formal mechanisms by which the flow of logic
through a computer can be modeled.
 Today we talk about activity diagrams.
 These are the UML equivalent of flow charts.

3. +
Activity Diagrams
 Once we have a feel for the static design of a system and the
interactions that actors will have with it, we need to start
mapping out the flow of logic.
 And how different parts of the system are going to handle the
responsibilities.
 That is out activity diagram.
 It’s a diagram of workflow – how individual objects are going to
share out the work between them.
 It outlines the flow of activity associated with a particular
process from start to finish.
 They can get pretty complex.

4. +
Activity Diagram Notation
Element Description
Swim lane A swim lane is used to indicate which actors are responsible for the action in
question. This is represented by a series of lines indicating a partition in the
diagram.
Initial Node The initial node is the starting point for the diagram, and indicates from which
point the diagram should be read. This is represented by a single filled circle.
Activity Final Node This is the ending point for the diagram, and shows the termination point for the
activities. There may be several of these in a diagram. This is indicated by a
filled circle surrounded by a border.
Flow The flow represents the order in which activities are performed. Flows are
represented by arrows.
Fork A fork indicates parallel processing of an activity - when two activities are
undertaken at the same time, a fork is used to represent this. A fork is indicated
by a thick bar into which a single flow enters and multiple flows leave.
Join When parallel processing indicated by a fork is ended, it is merged back into a
single flow. This is indicated by a thick bar into which several flows enter and a
single flow leaves.
Decision A decision indicates a choice that must be decided upon, and takes the form of
a diamond with a single flow entering it and several flows leaving.
Activity An activity is a discreet step of processing within the system, and is indicated
by a rounded oval.

5. +
A Simple Flow Chart

6. +
Activity Diagrams
 Activity diagrams work like flow charts except that they enforce
swim lanes.
 What object is responsible for handling which part of the logic.
 This will be informed by your static design.
 Which object will have the attributes and methods needed to
implement the behaviour.
 In some scenarios, it’s possible for actions to occur in parallel.
 Or as close to parallel is needed for diagramming.
 Consider the following simple example of a company building
physical arcade machines.

7. +
An Activity Diagram

8. +
How Do We Create Them?
 As with all the tools we talk about in this module, an issue is
just where do we begin?
 We begin in pseudocode.
 Luckily this diagram comes in after the use-case and class
diagrams.
 So you should already have a reasonable grasp of what needs to be
done and what’s going to be responsible for doing it.
 We outline the actual process in English, as in a problem
statement.
 We then represent the flow of logic in the process as pseudocode.

9. +
An Example
 One of the things you’re expected to do for the assessment is to
come up with some game mechanics.
 These would be perfect self contained examples of how to do an activity
diagram.
 Let’s come up with a simple mechanic.
 Each player gets a hand of cards. Each card has a class, an action and
a name. Every round, a player can play two cards of different classes
face down. If they only have one card in their hand, they can draw one
from the deck. At the same time, the opponent quietly decides whether
the left or right card will be countered. When this has been done, the
countered card is removed and the action of the remaining card is
performed.
 Our first step is to convert this into pseudocode.
 Have a go at that yourselves.

10. +
Our Next Step
 Our next is to translate that into an activity diagram.
 Breaking it up into separate modules means that we can slot them
neatly into swim-lanes.
 We’ll do this in three discreet stages.
 Fleshing out the flow chart.
 This lets us look to see where the work is going to flow.
 Identifying swim lanes.
 Indicating parallelism.
 The opponent can be doing things at the same time as the player.
 I used an online tool called gliffy for these diagrams.

11. +
Activity Diagram (1)

12. +
Activity Diagram (2)

13. +
Activity Diagram (3)

14. +
An Activity Diagram
 The diagram lets us describe a number of things.
 The relationship between each object
 The methods that will be triggered in each.
 Ownership of particular processes
 It ensures that we know how each part of the mechanic is going
to link to each other part.
 And this will be important when it comes time to code it.
 This ties into our sequence diagram.
 This is where the ‘mystery functionality’ of the sequence diagram
finally gets resolved into outline processes.

15. +
Developing the Steps
 Activity diagrams and pseudocode are two ways of
representing the same basic set of information.
 They both follow the same rules for being developed.
 Identify the process to be documented
 Limit the scope of the process only to the relevant aspects
 Methodically document each step of the process.
 When a decision is called for, precisely enumerate all possible
options.
 When a repetition is called for, precisely enumerate the
termination condition.
 When an activity is called for, analyse and make sure that it
represents one distinct step of the system.

16. +
Activity Diagrams in Context
 The activity diagram we developed during this lecture is an
example only.
 It covers a mechanic rather than an actual section of code.
 They are useful for analysis purposes.
 Which is how they’re used here.
 But they’re also useful for design purposes.
 Remember the difference between the two?
 They represent two separate views of the same system.
 One shows how it works logically.
 The other shows how it works concretely.

17. +
Activity Diagrams in Context
 We’ll return to the subject of activity diagrams for design in a
later lecture.
 For now, it’s just sufficient to know where they fit into the whole
system.
 They’re used to outline code algorithms and object relationships.
 Each diagram in UML has a role to fill.
 They will eventually direct influence the code that is written.
 Activity diagrams in the end will show exactly what methods are
called, in which order, by which objects.
 They will eventually translate directly into your OO code.

18. +
Activity Diagrams in Context
 Activity diagrams for design usually look at a system at the level of
a method in the system.
 Some of these will be simple.
 Some will be complex.
 As a result, they allow for us to effectively abstract.
 ‘I need to make a method call here, although I don’t need to know what
the method does’
 Abstraction is the key tool of an analyst.
 To be able to see things in their general form.
 We can treat whole sections of a program as a black box provided
we can respect the interface that the static model presents.

19. +
Conclusion
 Activity Diagrams form part of the dynamic model of a system.
 How different modules of code mesh together.
 They’re useful for both analysis and design.
 We have focused on the former here, since that’s where we
currently are for the assessment.
 They are a graphical representation of what pseudocode is for.
 They show us the flow of logic through modules of a computer
program.