activity diagram tutorial part 2
DESCRIPTION
What NOT to put into your activity diagram when modelling a System Use Case.TRANSCRIPT
![Page 1: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/1.jpg)
Using Activity Diagrams toModel Use Cases Visually
Part 2: Model the logical interactions
by Declan Chellar
![Page 2: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/2.jpg)
Our activity diagrams model the Actor/System interactions
within a System Use Case.
![Page 3: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/3.jpg)
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.
![Page 4: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/4.jpg)
The System neither knows nor cares where the Actor gets
the customer details.
![Page 5: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/5.jpg)
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.
![Page 6: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/6.jpg)
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
![Page 7: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/7.jpg)
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
![Page 8: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/8.jpg)
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
![Page 9: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/9.jpg)
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
![Page 10: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/10.jpg)
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
![Page 11: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/11.jpg)
Much better!
Actor elects to Add Customer
System requests customer details
Actor provides customer details
![Page 12: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/12.jpg)
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
![Page 13: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/13.jpg)
Analogy: The waiter does not care what the chef has to do in the kitchen to
produce the order.
![Page 14: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/14.jpg)
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.
![Page 15: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/15.jpg)
Actor elects to Add Customer
Actor provides customer details
System saves customer details to
CRM System database
System confirms customer detals
saved
Much better!
![Page 16: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/16.jpg)
Actor elects to Add Customer
Actor provides customer details
System saves customer details to
CRM System database
System confirms customer detals
saved
But wait!
![Page 17: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/17.jpg)
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
![Page 18: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/18.jpg)
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.
![Page 19: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/19.jpg)
Our activity diagram should only model the logical
interactions between the Actor and the System.
![Page 20: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/20.jpg)
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
![Page 21: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/21.jpg)
The physical layout of how that interaction occurs is not
relevant at this level.
![Page 22: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/22.jpg)
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.
![Page 23: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/23.jpg)
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!
![Page 24: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/24.jpg)
We also don’t care about steps that model the screen
flow and field validations.
![Page 25: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/25.jpg)
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
![Page 26: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/26.jpg)
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
![Page 27: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/27.jpg)
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!
![Page 28: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/28.jpg)
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.
![Page 29: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/29.jpg)
SUMMARY
1. Interactions between the Actor and a third party should be modelled in a low-level business process model.
![Page 30: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/30.jpg)
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.
![Page 31: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/31.jpg)
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.
![Page 32: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/32.jpg)
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.
![Page 33: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/33.jpg)
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.
![Page 34: Activity diagram tutorial part 2](https://reader034.vdocument.in/reader034/viewer/2022042606/5406dab98d7f7288088b4807/html5/thumbnails/34.jpg)
www.chellar.com/blog