What NOT to put into your activity diagram when modelling a System Use Case.

1. Using Activity Diagrams to
Model Use Cases Visually
Part 2: Model the logical interactions
by Declan Chellar

2. Our activity diagrams model
the Actor/System interactions
within a System Use Case.

3. Actor needs to do
something
System responds
by asking for some
information
Actor provides
information
System does
something with
the information
Our activity diagrams model
the Actor/System interactions
within a System Use Case.

4. The System neither knows nor
cares where the Actor gets
the customer details.

5. Analogy: A chef does not care what the waiter
says to the diner. The chef only cares about
what the waiter writes on the order slip.

6. Analogy: A chef does not care what the waiter
says to the diner. The chef only cares about
what the waiter writes on the order slip.
The Actor

7. Analogy: A chef does not care what the waiter
says to the diner. The chef only cares about
what the waiter writes on the order slip.
The System The Actor

8. Actor elects to Add Customer
System requests
customer details
Actor asks
customer for
details
Customer provides
details to Actor
Actor provides
customer details to
System
The System neither knows nor
cares where the Actor gets
the customer details

9. Interactions outside the
Actor/System relationship
belong in other models.
Actor elects to Add Customer
System requests
customer details
Actor asks
customer for
details
Customer provides
details to Actor
Actor provides
customer details to
System

10. The highlighted steps belong
in a low-level business
process diagram, not an
activity diagram.
Actor elects to Add Customer
System requests
customer details
Actor asks
customer for
details
Customer provides
details to Actor
Actor provides
customer details to
System

11. Much better!
Actor elects to Add Customer
System requests
customer details
Actor provides
customer details

12. Actor elects to Add Customer
Actor provides
customer details
System connects
to CRM System
database
System saves
customer details to
CRM System
database
CRM System
confirms customer
detals saved
Similarly, the Actor neither
knows nor cares what the
System has to do to produce
the result the Actor needs.
System confirms
customer detals
saved

13. Analogy: The waiter does not care what
the chef has to do in the kitchen to
produce the order.

14. Actor elects to Add Customer
Actor provides
customer details
System connects
to CRM System
database
System saves
customer details to
CRM System
database
CRM System
confirms customer
detals saved
System confirms
customer detals
saved
The highlighted steps belong
in a Technical Use Case, not
an activity diagram.

15. Actor elects to Add Customer
Actor provides
customer details
System saves
customer details to
CRM System
database
System confirms
customer detals
saved
Much better!

16. Actor elects to Add Customer
Actor provides
customer details
System saves
customer details to
CRM System
database
System confirms
customer detals
saved
But wait!

17. Actor elects to Add Customer
Actor provides
customer details
System saves
customer details to
CRM System
database
System confirms
customer detals
saved
Our diagram should be
technology-agnostic

18. Actor elects to Add Customer
Actor provides
customer details
System saves
customer details to
CRM System
database
System confirms
customer detals
saved
The steps and text of our
diagram should remain valid
even if the technology
changes, so we remove any
reference to technology.

19. Our activity diagram should
only model the logical
interactions between the
Actor and the System.

20. Our activity diagram should
only model the logical
interactions between the
Actor and the System.
Actor needs to do
something
System responds
by asking for some
information
Actor provides
information
System does
something with
the information

21. The physical layout of how
that interaction occurs is not
relevant at this level.

22. Actor clicks on the
“Do something”
button
System responds
by asking for some
information
Actor provides
information
System does
something with
the information
Screen design in an activity
diagram draws focus away
from the logic of the System
Use Case and must be
avoided.

23. Actor clicks on the
“Do Something”
button
System responds
by asking for some
information
Actor provides
information
System does
something with
the information
We simply don’t care at this
point whether it’s a button or
a hyperlink or an item in a
drop-down list!

24. We also don’t care about
steps that model the screen
flow and field validations.

25. Actor clicks on the
“Do something”
button
System responds
by asking for some
information
Actor provides
information
System checks whether
Actor provided
mandatory information
System does
something with
the information
System displays
error message

26. Actor clicks on the
“Do something”
button
System responds
by asking for some
information
Actor provides
information
System checks whether
Actor provided
mandatory information
System does
something with
the information
System displays
error message

27. Actor clicks on the
“Do something”
button
System responds
by asking for some
information
Actor provides
information
System does
something with
the information
Much better!

28. Actor clicks on the
“Do something”
button
System responds
by asking for some
information
Actor provides
information
System checks whether
Actor provided
mandatory information
System does
something with
the information
System displays
error message
Of course we don’t lose these
screen flow details. We
capture them in a screen flow
diagram, not an activity
diagram.

29. SUMMARY
1. Interactions between the Actor and a third
party should be modelled in a low-level
business process model.

30. SUMMARY
1. Interactions between the Actor and a third
party should be modelled in a low-level
business process model.
2. What the System has to do in the “kitchen”
to produce a result for the Actor should be
modelled within a Technical Use Case.

31. SUMMARY
1. Interactions between the Actor and a third
party should be modelled in a low-level
business process model.
2. What the System has to do in the “kitchen”
to produce a result for the Actor should be
modelled within a Technical Use Case.
3. Avoid references to widgets on screens.

32. SUMMARY
1. Interactions between the Actor and a third
party should be modelled in a low-level
business process model.
2. What the System has to do in the “kitchen”
to produce a result for the Actor should be
modelled within a Technical Use Case.
3. Avoid references to widgets on screens.
4. Screen flow should be modelled in a screen
flow diagram.

33. SUMMARY
1. Interactions between the Actor and a third
party should be modelled in a low-level
business process model.
2. What the System has to do in the “kitchen”
to produce a result for the Actor should be
modelled within a Technical Use Case.
3. Avoid references to widgets on screens.
4. Screen flow should be modelled in a screen
flow diagram.

34. www.chellar.com/blog