Introduction to using activity diagrams to model use cases visually.

1. UsingActivityDiagrams toModel Use Cases VisuallyPart 1: TheBasics by Declan Chellar

3. START POINT

4. TheStart Point representstheEVENT that triggersthe use case.

5. LabeltheStart Point to makethe INTENT and TRIGGER of the use case explicit.

6. Actor elects to AddCustomer

7. Actor elects to AddCustomer END POINT

8. Actor elects to AddCustomer LabeltheEnd Point to EXPLICITLY confirm that theintent of the use case has beenachieved.

9. Actor elects to AddCustomer Customeradded

10. Actor elects to AddCustomer This makesitclear to thereader that the use case is complete and that nothingfurther is needed in order to fulfiltheintent. Customeradded

11. Actor elects to AddCustomer NOT a goodlabelforanEnd Point End of process

12. To reachtheEnd Point…

13. … you need to model STEPS.

14. Link thestepswith TRANSITIONS.

16. Transitions use arrowheads to show thedirection of processflow.

17. I like to put a note againstanystep that achievesthegoal of the use case. Goal X achieved

18. Goal X achieved … becauseitmightnotbethelaststep.

19. Themostcommonroutefromthestartpoint to theendpoint has manynames.

20. Buttheyeffectively mean thesamething.

21. Combine anywordontheleftwithanyphraseontheright. PRIMARY… …PATH BASIC… …FLOW TYPICAL… …COURSE OF EVENTS …SCENARIO

22. Often in a use case theSystem has to make a decisionbasedonbusiness rules...

23. The actual decisiontakes place within a STEP

24. System determines whether X or Y The actual decisiontakes place within a STEP

25. System determines whether X or Y A DECISION POINT is then used to helpthereadernavigatethediagram.

26. DECISION POINT

27. DecisionPointscontaintextwhich describes thenature of thedecision to bemade.

28. So wasit X or Y?

29. Decisionpointsallowtheflow to branchawayfromthePrimaryPath.

30. Transitionscomingout of DecisionPointsmust have a GUARD. [Condition 2] [Condition 1]

31. [IT WAS “Y”] [IT WAS “X”] A Guardneeds to explicitly describe a conditionwhichmustbe true in order to proceeddown that path.

32. IftheflowrejoinsthePrimaryPath, it is known as anAlternatePath. [Condition 2] [Condition 1]

33. [Condition 2] [Condition 1] WithAlternatePaths, thegoal of the Use Case is stillachieved.

34. There are othernamesforAlternatePaths. [Condition 2] [Condition 1]

35. Combine anywordontheleftwithanyphraseontheright. ALTERNATE… …PATH ALTERNATIVE… …FLOW SECONDARY… …COURSE OF EVENTS …SCENARIO [Condition 2] [Condition 1]

36. [Condition 2] [Condition 1] You can show howpathsrejoinbyusing a MERGE POINT.

37. [Condition 2] [Condition 1] You can show howpathsrejoinbyusing a MERGE POINT.

38. I don’tlikeMergePointsbecausetheytake up spacewithoutaddingclarity. [Condition 2] [Condition 1]

39. I prefer to modelmergingpathslikethis. [Condition 2] [Condition 1]

40. MergePoints can sometimesbeparticularlysuperfluous. [Condition 2] [Condition 1]

41. [Condition 2] [Condition 1] I thinkit is neater to show themergethisway.

42. Iftheflowdoes NOT rejointhePrimaryPath, it is known as anExceptionPath. [Condition 2] [Condition3] [Condition 1]

43. WithExceptionPaths, thegoal of the Use Case is NOT achieved. [Condition 2] [Condition3] [Condition 1] Goal X achieved

44. WithExceptionPaths, thegoal of the Use Case is NOT achieved. [Condition 2] [Condition3] [Condition 1] Uh, oh! Goal X achieved

45. I like to use colour to highlightthedifferentpaths. [Condition 2] [Condition3] [Condition 1]

46. [Condition 2] [Condition3] [Condition 1]

47. [Condition 2] [Condition3] [Condition 1]

48. This makesiteasy to identify test scenarios at a glance. [Condition3] [Condition 2] [Condition 1]

49. I alsolike to labeltheGuards in order to easilyidentifythepaths. A1: [Condition 2] E1: [Condition 3] P: [Condition 1]

50. And I like to labeltheStepsforeasybackwardreferencefrom Business Rules and a Logical Data Model. P1: A1: [Condition 2] E1: [Condition 3] P: [Condition 1] P2: A1.1: E1.1:

51. PrimaryPath: P1, P2. P1: A1: [Condition 2] E1: [Condition 3] P: [Condition 1] P2: A1.1: E1.1:

52. PrimaryPath: P1, P2. AlternatePath 1: P1, A1.1, P2. P1: A1: [Condition 2] E1: [Condition 3] P: [Condition 1] P2: A1.1: E1.1:

53. PrimaryPath: P1, P2. AlternatePath 1: P1, A1.1, P2. ExceptionPath 1: P1, E1.1. P1: A1: [Condition 2] E1: [Condition 3] P: [Condition 1] P2: A1.1: E1.1:

54. In some Use Cases, you willneed to modelparallelsteps [Condition 2] [Condition3] [Condition 1]

55. [Condition 2] [Condition3] [Condition 1] X A B In thisexample, steps A and B mustbothstartafterstep X finishes and mustbothfinishbeforethe Use Case ends.

56. [Condition 2] [Condition3] [Condition 1] X A B Butwe do notcareabouttheorder in which A and B happen.

57. A and B couldevenhappen at thesame time. [Condition 2] [Condition3] [Condition 1] X A B

58. In thisexample, B mustfollow A, butwe do notcarewhen C happens in relation to (A + B). [Condition 2] [Condition3] [Condition 1] A C B

59. In some Use Cases, you willneed to modelrepeatedsteps. [Condition 2] [Condition3] [Condition 1] A B

60. [Condition 2] [Condition3] [Condition 1] Foreach X: A In thisexample, you repeat (A + B) untilthere is no more X. B

61. [Condition 2] [Condition3] [Condition 1] Foreach X: A Forexample, you might do thiswhenaddingpassengers to a holidaybooking. B

62. Let’sreviewtheshapes

63. START POINT DECISION POINT [Condition] END POINT GUARD STEP PARALLEL STEPS Foreach X: TRANSITION REPEATED STEPS

64. www.chellar.com/blog