A consistent, unambiguous and complete notation for modeling with use cases.

1. 2009 copyright Leslie Munday University
Use Case Modeling With Activity
And Use Case Diagrams
Requirements Discipline Activity
5 November 2019

2. Leslie Munday 2008
Precursor
 In order to understand the material in this
course, you should have equivalent
knowledge of a UML modeling tool and of
the following:
 An Introduction To Business Use Cases.
 Working with AUC documents.
11/5/2019 2

3. Leslie Munday 2008
Use Case And Activity Diagrams
 In this presentation we will learn:
 what are the components of a use case diagram.
 how the use case diagram components are related.
 what is the difference between an application use case
diagram and a business use case diagram.
 what are the different components of an activity
diagram.
 what are the relationships between the different
components.
 how to represent a business use case with an activity
diagram.
 how to represent an application use case with an
activity diagram.
11/5/2019 3

4. Leslie Munday 2008
 Activity - The specification of an executable statement that includes 1 or more actions
and may result in a change in the state of the system.
 Application – the software part of the system under discussion.
 Artifact – Any complete piece of a model.
 Business Actor – Someone who gets benefit from the business use case.
 Component – Anything that can be placed on a diagram.
 Diagram – A graphical depiction of all or part of a model.
 Model – A complete description of a system from a particular perspective.
 Object - An entity with a well-defined boundary and identity that encapsulates state
and behavior.
 Postcondition – the state of the system after a use case has executed.
 Precondition – the state of the system prior to a use case executing.
 Relationship – shows communication between an actor and a use case.
 State - A condition or situation during the life of an object during which it satisfies
some condition, performs some activity, or waits for some event.
 Package – A container for grouping artifacts.
 System – the item under discussion, it may comprise hardware, software or both.
 System Actor - Someone or something, outside the system that interacts with the
system.
 Use Case – A set of actions a that yields an observable result of value to a particular
actor.
Terms Used In This Presentation
11/5/2019 4

5. Leslie Munday 2008
Use Case History
 1986 - Ivar Jacobson introduces the
concept of use cases to Ericsson.
 1987 – Objectory AB, founded by Jacobson.
 1995 – Rational buys Objectory.
 1995 – Use cases are introduced into the
Unified Modeling Language 0.9 proposal.
 1997 – UML 1.0 adopted by OMG.
 1998 – Rational Unified Process is evolved
from the Objectory process.
11/5/2019 5

6. Leslie Munday 2008
Activity Diagram History
 The activity diagram is a derivation of the state
transition diagram. (State transition diagrams, (STD)
as their name suggests contain states connected by
transitions.)
 A transition is triggered by an event.
 A state is the result of the execution of an event.
 With the emergence of use cases a diagram was
required that also shows events and actions.
 Actions were added to the STD to create the activity
diagram.
 Think of it as a hybrid of a state transition diagram
and a flowchart.
 In UML 2.x the activity diagram has evolved into an
automated token executing machine, which allows for
modeling of complex operations.
11/5/2019 6

7. Leslie Munday 2008
Overview
 The notation used in this presentation is based upon
that specified in the UML 1.x specifications, not UML
2.x.
 The notation is specific to modeling use cases.
Where the definition of a component is not relevant
to this goal, I either ignore it or redefine it
appropriately.
 The objective is to define a notation that is
consistent, easy to use and does not allow
ambiguous modeling rules (one way and one way
only to represent a concept) yet will not restrain you
from expressing everything that is required in your
use case model.
11/5/2019 7

8. Leslie Munday 2008
Why Do We Need Notation?
 Don’t the UML specifications specify how to draw these
diagrams? No, they define the semantics of the symbols used in
the diagrams, but do not commit to a consist use on diagrams.
 UML tries to be all things to all people. It is impossible to use in
consistent and unambiguous manner unless guidelines are built
around the semantics in order to constrain their rules.
 For example, Rational recommends that the primary actor in a
use case is identified with a directed association. UML contains
no such rules or guidelines.
 I was taught that when two threads are created, from a fork,
(which run concurrently) that neither thread could continue
(return to the main path) until both threads reached a join.
 According to the UML specifications, concerning forks and joins,
either can be used without the other. In my understanding this
does not make sense because the threads will never complete,
hence the use case will never end.
11/5/2019 8

9. Leslie Munday 2008
The Use Case Diagram
 There are two types of use case diagram:
 business use case (BUC) diagram.
 application use case (AUC) diagram.
 The business use case diagram describes the
activities performed by any number of
business workers (people) in order to achieve
a business goal (whether they are manual or
automated is not specified in the BUC).
 The application use case describes the
activities performed by the software in order to
achieve a system goal.
11/5/2019 9

10. Leslie Munday 2008
Use Case Diagram Overview
 A use case diagram
contains actors, use cases
and relationships between
them.
 If a use case diagram
becomes difficult to read
on a single page, then
break it into 2 diagrams.
 I recommend, especially for
systems with a large
number of use cases,
showing actors connecting
to a single use case, by
duplicating the actor. In
this manner restructuring
the use case diagram is
much simpler.
11/5/2019 10

11. Leslie Munday 2008
Common To Use Case Diagrams
 Indicate the primary actor using
an arrowhead on the
relationship entering the use
case.
 Indicate secondary actors by
using no arrowheads on the
relationship line.
 Included use cases have an
arrowhead entering the use
case and the relationship
contains the stereotype
<<include>>.
 Extending use cases have an
arrowhead entering the use
case being extended and the
relationship contains the
stereotype <<extend>>.
11/5/2019 11

12. Leslie Munday 2008
Business Use Case Diagrams
 The primary actor is the stakeholder that is getting benefit from the BUC.
 The secondary actors are people outside the business, that interact with the
activity of the BUC.
 Some modeling tools will distinguish a BUC from an AUC by placing a line
through the use case shape; alternatively give the BUC a stereotype named
‘Business’.
 Some guidelines distinguish between business actors and system actors; rarely
do I find this necessary. (If a role of the same name appears in both
organizations; business and system, but they perform different roles, then
distinguishing between business and system actors may be necessary.)
11/5/2019 12

13. Leslie Munday 2008
Application Use Case Diagrams
 The primary actor is the role that initiates the
execution of the AUC.
 The secondary actors are applications or people
outside of the AUC that interact with the use case.
11/5/2019 13

14. Leslie Munday 2008
Using Inheritance In Use Cases
 When two or more roles are the
primary actor of a use case,
create a common role and use
the ‘generalization’ relationship
to inherit that role’s capabilities.
 The systems and business
process analysts both inherit
everything the analyst role
does.
 I have rarely found a need to
use the ‘generalization’
relationship between use cases.
If anything I have found that it
adds ambiguity to the use
cases.
11/5/2019 14

15. Leslie Munday 2008
The Activity Diagram Components
 Initial Node
 Control Flow
 Action or Activity
 Object Flow
 Branch
 Merge
 Fork
 Join
 Final Node
11/5/2019 15

16. Leslie Munday 2008
Initial Node
 This represents the
start of the flow of
an activity diagram.
 An activity diagram
contains a single
start node.
 The name of the
initial node is
entered on the
node. It takes the
form of an adjective.
11/5/2019 16

17. Leslie Munday 2008
Control Flow
 A control flow connects any combination of:
 activities
 branches
 merges
 forks
 joins
 A control flow has direction, which is indicated by the arrow
head – you may only traverse the control flow in the
direction of the arrow.
 A control flow may not enter an initial state.
 A control flow may not exit a final node.
 A control flow is the representation of an occurrence of an
event.
 The name of the event is entered on the control flow. It
takes the form of something has been done, noun-
verb(past-tense)
11/5/2019 17

18. Leslie Munday 2008
Activity And Action
 The activity represents
the actions that occur as
a result of an incoming
event from a control flow.
 The name of the activity
is entered on the activity
and takes the form of
something being done,
present tense verb-noun
11/5/2019 18

19. Leslie Munday 2008
Branch
 The branch is used to show alternative paths in the
activity diagram.
 Label the decision node with a question(?).
 Do not label the merge, (unless you have a good
reason to).
 One control flow enters the decision node and two or
more alternative control flows exit the decision node.
 Only one of the paths may be transitioned as the
result of an event occurring.
 Each exiting control flow contains the condition under
which it is taken (called a guard), dependent upon the
answer to the question. These guards must be
mutually exclusive.
 The guards on exiting control flows must cover all
possible outcomes of the question being asked by the
branch.
 The simplest way to ensure all possible outcomes are
covered is to phrase the branch question such that the
only possible answers are ‘Yes’ or ‘No’. Note, this can
add extra branches to the diagram.
 Two or more control flows enter the merge node
and one control flow exits.
11/5/2019 19

20. Leslie Munday 2008
Fork
 The fork may be represented by vertical or
horizontal bars.
 The fork represents that the flow through the
diagram has split into 2 paths that are running
in parallel (multitasking).
 The fork has a single control flow on entry and
several control flows exiting.
 Use a fork when there is no requirement on
the order of activities in a flow.
 For example, the Dematerializer receives an
event that the door is shut. It now suspends the
cargo and creates a vacuum, but these actions
may be performed in parallel, so we model them
with a fork.
11/5/2019 20

21. Leslie Munday 2008
Join
 For every fork there should be a join (if not
your activity diagram is broken).
 The join may be represented by vertical or
horizontal bars.
 A join simply shows that when the parallel
activities have finished that they then
come back to join a single flow again.
 The join has several control flows entering
and a single control flow on exit.
 The exiting control flow cannot be
executed until every incoming control flow
has completed.
 There is no need to label the fork or join.
11/5/2019 21

22. Leslie Munday 2008
Final Node
 The final node represents the termination of
the activity diagram.
 There may be several termination states in
a single diagram.
 Label the final node with an adjective.
11/5/2019 22

23. Leslie Munday 2008
The Use Case Details
 How does the activity diagram relate to the
use case template?
 Each component of the activity diagram
represents a detail in the use case, as follows:
 Precondition – Initial state.
 User step – Event.
 System action – Activity.
 Alternate flow – Decision.
 Alternate flow returning to the basic flow – Merge.
 System activities running in parallel – Fork.
 Parallel activities joining the basic flow – Join.
 Postcondition – Final node.
11/5/2019 23

24. Leslie Munday 2008
Mapping To The Use Case?
 Precondition
 Actor input
 System Step
 Alternative or extension
flow
 Basic Flow
 Returning alternate flow
 Parallel activities
 Postcondition
11/5/2019 24

25. Leslie Munday 2008
Dematerialize Cargo Example 1
 Precondition
 The system is ready to transport
cargo.
 Basic Flow
1. The system receives a command
to open the door to the
Dematerializer.
2. The system opens the door to
the Dematerializer.
3. The system receives a command
to transport the cargo.
4. The Transmitter is ready to
transmit and the system closes
the door to the Dematerializer.
 Alternate Flow
1. At step 4, the Transmitter is not
ready to transmit, and the
system waits for the transmitter
to be ready to transmit.
2. The Transmitter is ready to
transmit and the use case
continues from step 4.
11/5/2019 25

26. Leslie Munday 2008
Dematerialize Cargo Example 2
 Basic Flow (continued)
6. The system sends the
deconstructed cargo to the
Transmitter and sends the
cargo blueprint to the
Blueprint Manager.
7. The system removes the
vacuum from the
Dematerializer.
8. The vacuum is removed and
the use case ends.
 Postcondition
 The system is ready to
transmit cargo.
 Extension Flow
1. At step 8, the system is set to
shutdown when the cargo is
transmitted, and the systems
performs a shutdown.
2. The system shutsdown and
the use case ends.
 Postcondition
 The system is shutdown
11/5/2019 26

27. Leslie Munday 2008
Advanced Notation
 In addition to the basic activity diagram
components there are:
 Objects and object flows.
 Swimlanes.
 Objects are used to identify potential
analysis classes.
 Swimlanes can be used on BUC activity
diagrams to group activities or indicate roles
that perform an activity.
11/5/2019 27

28. Leslie Munday 2008
Swimlanes
 Consider the following activity diagram which
describes the ‘Exploring Automation Requirements’
workflow from the business modeling discipline.
 ‘Set And Adjust Goals’ activity is performed by the
business process analyst.
 ‘Define Automation Requirements’ activity is
performed by the business designer.
 The activities performed by the same role (or
department) are positioned such that they all fall
into the same vertical column.
 Beware: swimlanes can become very expensive to
maintain, you might want to consider using
stereotypes to identify the role.
11/5/2019 28

29. Leslie Munday 2008
Swimlane Example Diagram
11/5/2019 29

30. Leslie Munday 2008
Another Swimlane Example
 This example
demonstrates
how swimlanes
can be used to
define the steps
of a business
use case that
are to be
automated.
11/5/2019 30

31. Leslie Munday 2008
Object
 Objects represent external
information that is being
manipulated by the use case.
 Every use case activity should be
reading from or writing to at least
one object, (otherwise how can
you test that the activity executed).
 Any data manipulated by an
activity, should be shown as being
input from an object.
 The results are output to an object.
 The object takes the name of an
instance of its class.
11/5/2019 31

32. Leslie Munday 2008
AUC With Objects
 The ‘Opening Door’
activity sends an
‘open’ command to
the ‘door’ object.
 The ‘Waiting For
Transmitter’ activity
reads the status of
the ‘transmitter’
object.
 The objects are
instances of the
‘Door’ and
‘Transmitter’
classes.
11/5/2019 32

33. Leslie Munday 2008
Why Model Use Cases?
 Gives an overview of your use case steps without having
to read the details.
 Performing a simulated execution, aids identifying missing
or misplaced steps in the use case.
 Shows the alternative paths through the use case with the
basic flow.
 Allows for a consistent and unambiguous method for
specifying the steps in the use case.
 It’s a faster way to get the basic flow from the
stakeholders (they will thank you in the long term).
11/5/2019 33

34. Leslie Munday 2008
Naming Conventions
 Name events in the past tense with text that describes what happened in order to
trigger the event. Text of the form of ‘Verb Noun’ is appropriate, (or ‘Noun Verb’ if
preferred, but be consistent).
 Activities should be named in the present tense with text that describes what is
currently happening. Text of the form ‘Doing Something With Noun’ is appropriate.
 The control flows exiting a fork synchronization bar are effectively the same as the
control flow entering the fork and do not need to be named.
 The control flow exiting a join synchronization bar is effectively a combination of all
entering control flows. It is not necessary to label the exiting control flow.
 Use ‘Capitalized Words’ for names of activities, events and guards.
 The start state should be labeled such that it describes a precondition of the activity
diagram (i.e. the state of the system or business prior to the occurrence of the event
that control flows out of this state).
 Label the end state with text that describes the postcondition of the system/business
when the end state is reached.
 Label a decision with text representing the question being asked, followed by a ‘?’.
 It is not necessary to label a merge, fork or join.
11/5/2019 34

35. Leslie Munday 2008
Activity Diagram Semantics
 Every activity diagram should have exactly one start state.
 Every activity diagram should contain one or more end states.
 Every activity should have at least one entering control flow and one exiting control
flow. (An activity with no entering control flow will never be executed. An activity with
no exiting control flow will never terminate.)
 Ensure that the labels on the control flows exiting a decision cover every possible
outcome to the question being asked by the decision node.
 Ensure that no two exiting control flows from a decision can take the same answer to
the question.
 Use the [guard] field to label the outgoing control flows from a decision; because the
text does not represent an event, it represents a guard on the incoming event.
 Avoid placing activities (or any other activity diagram component) within activities. If
you feel the need to break your activity into smaller sub-activities (the general semantic
meaning of placing activities within activities) it suggests that the activities are too
complex and their scope should be re-visited.
 For every fork synchronization bar there should be a corresponding join synchronization
bar. The join synchronization bar allows every activity on a parallel path in the fork, to
complete. The omission of a join synchronization bar indicates that the activity diagram
can end with an activity not completed.
11/5/2019 35

36. Leslie Munday 2008
Exercise
 Create a use case diagram that shows a
customer making a withdrawal and a deposit
with an ATM.
 Model The ATM example use case With An
Activity Diagram.
 There are no ‘right’ answers.
 There is no industry standard for modeling
use cases.
11/5/2019 36