Activity diagram tutorial part 2

3,365 views

Published on

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

Published in: Business, Travel
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,365
On SlideShare
0
From Embeds
0
Number of Embeds
117
Actions
Shares
0
Downloads
159
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Activity diagram tutorial part 2

  1. 1. Using Activity Diagrams to Model Use Cases Visually Part 2: Model the logical interactions by Declan Chellar
  2. 2. Our activity diagrams model the Actor/System interactions within a System Use Case.
  3. 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. 4. The System neither knows nor cares where the Actor gets the customer details.
  5. 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. 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. 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. 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. 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. 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. 11. Much better! Actor elects to Add Customer System requests customer details Actor provides customer details
  12. 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. 13. Analogy: The waiter does not care what the chef has to do in the kitchen to produce the order.
  14. 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. 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. 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. 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. 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. 19. Our activity diagram should only model the logical interactions between the Actor and the System.
  20. 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. 21. The physical layout of how that interaction occurs is not relevant at this level.
  22. 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. 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. 24. We also don’t care about steps that model the screen flow and field validations.
  25. 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. 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. 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. 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. 29. SUMMARY 1. Interactions between the Actor and a third party should be modelled in a low-level business process model.
  30. 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. 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. 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. 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. 34. www.chellar.com/blog

×