Activity Diagram tutorial part 3
Download as PPTX, PDF1 like1,485 views
This document discusses the use of activity diagrams to model software use cases, emphasizing the importance of focusing on logical interactions rather than variable details like data options and business rules. It warns against complicating diagrams with alternate paths for different data types, which can reduce clarity and increase maintenance effort. The author strongly advocates for maintaining simplicity in activity diagrams to accurately represent the process without extraneous details.
Activity Diagram tutorial part 3
- 1. Using Activity Diagrams to Model Use Cases Visually Part 3: Ignoring the Variable Details by Declan Chellar
- 2. Our activity diagrams model the Actor/System interactions within a Software Use Case.
- 3. In this example, “Add Address”, we model only the logical interactions between the Actor and the System
- 4. There may be variations in the kind of data that makes up an address, for example, addresses in different countries…
- 5. …but those details are documented as part of the data requirements for the relevant step.
- 6. And they should not distract from the logic of the process itself by appearing in the activity diagram.
- 7. The same is true for any business rules which might affect the flow.
- 8. Or any messages that the System might need to display to the Actor.
- 9. This activity diagram tells us the essential nature of the process without clogging it up with data options, business rules, button clicks and on- screen messages.
- 10. Any of those things can change in the future without the proces s itself changing.
- 11. But analysts who lack experience in drawing activity diagrams often treat every possible data and screen option as if it were an alternate path through the use case.
- 12. Imagine we could capture two types of address in our use case: An Irish address, which does not use post codes, and a UK address, which does.
- 13. Modelling those data differences as alternate paths results in a much more complicated activity diagram, which is harder to follow without really providing any extra information.
- 14. Very inexperienced analysts sometimes even try to model the capture of every item of data as a separate step in the process!
- 15. If we modelled our activity diagram like this, look what would happen if we had to add a third address type…
- 17. By the way, if your activity diagram contains alternate flows hanging off alternate flows, it’s a sign that something may be wrong.
- 18. Another mistake is to try to model each data/business rule/screen variance as a different use case.
- 19. This adds effort to the modelling task without adding clarity. Indeed, it reduces clarity and increases maintenance and development effort.
- 20. When you model it this way, it doesn’t matter how many different address types get added to the data model, or whether the definition of “Valid” changes or whether the on-screen messages change.
- 21. One thing needs to remain absolutely clear…
- 22. This is not an alternative way of modelling a use case… It is plain wrong!
- 23. This is not an alternative way of modelling a use case… It is plain wrong!