Downloaded 205 times
Uploaded byDeclan Chellar
Activity diagram tutorial part 2
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.
More Related Content
Similar to Activity diagram tutorial part 2
Activity diagram tutorial part 2
- 1. Using Activity Diagramsto Model Use Cases Visually Part 2: Model the logical interactions by Declan Chellar
- 2. Our activity diagramsmodel the Actor/System interactions within a System Use Case.
- 3. Actor needs todo 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 neitherknows nor cares where the Actor gets the customer details.
- 5. Analogy: A chefdoes 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 chefdoes 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 chefdoes 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 toAdd 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/Systemrelationship 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 stepsbelong 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 electsto Add Customer System requests customer details Actor provides customer details
- 12. Actor elects toAdd 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 waiterdoes not care what the chef has to do in the kitchen to produce the order.
- 14. Actor elects toAdd 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 toAdd Customer Actor provides customer details System saves customer details to CRM System database System confirms customer detals saved Much better!
- 16. Actor elects toAdd Customer Actor provides customer details System saves customer details to CRM System database System confirms customer detals saved But wait!
- 17. Actor elects toAdd 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 toAdd 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 diagramshould only model the logical interactions between the Actor and the System.
- 20. Our activity diagramshould 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 layoutof how that interaction occurs is not relevant at this level.
- 22. Actor clicks onthe “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 onthe “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’tcare about steps that model the screen flow and field validations.
- 25. Actor clicks onthe “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 onthe “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 onthe “Do something” button System responds by asking for some information Actor provides information System does something with the information Much better!
- 28. Actor clicks onthe “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 betweenthe Actor and a third party should be modelled in a low-level business process model.
- 30. SUMMARY 1. Interactions betweenthe 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 betweenthe 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 betweenthe 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 betweenthe 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.