Activity diagram tutorial part 2
Download as PPTX, PDF2 likes2,296 views
1. The document discusses modeling logical interactions between an Actor and System using activity diagrams for use cases. It provides guidance on what interactions should be included and excluded from activity diagrams. 2. Interactions between the Actor and third parties, and technical details of what the System does internally, should be modeled elsewhere rather than in activity diagrams which focus only on the logical flow between Actor and System. 3. References to user interface elements and screen flows should also be avoided in activity diagrams, which should remain technology agnostic and focus only on logical steps.
Activity diagram tutorial part 2
- 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.