Using Activity Diagrams to Model Use Cases Visually Part 2: Model the logical interactions by Declan Chellar
Activity diagram tutorial part 2
Sep 03, 2014
What NOT to put into your activity diagram when modelling a System Use Case.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Using Activity Diagrams toModel Use Cases Visually
Part 2: Model the logical interactions
by Declan Chellar
Our activity diagrams model the Actor/System interactions
within a System Use Case.
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.
The System neither knows nor cares where the Actor gets
the customer details.
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.
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
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
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
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
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
Much better!
Actor elects to Add Customer
System requests customer details
Actor provides customer details
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
Analogy: The waiter does not care what the chef has to do in the kitchen to
produce the order.
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.
Actor elects to Add Customer
Actor provides customer details
System saves customer details to
CRM System database
System confirms customer detals
saved
Much better!
Actor elects to Add Customer
Actor provides customer details
System saves customer details to
CRM System database
System confirms customer detals
saved
But wait!
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
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.
Our activity diagram should only model the logical
interactions between the Actor and the System.
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
The physical layout of how that interaction occurs is not
relevant at this level.
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.
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!
We also don’t care about steps that model the screen
flow and field validations.
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
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
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!
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.
SUMMARY
1. Interactions between the Actor and a third party should be modelled in a low-level business process model.
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.
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.
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.
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.
www.chellar.com/blog
Related Documents
