Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
UsingActivityDiagrams toModel Use Cases Visually<br />by Declan Chellar<br />
START POINT<br />
TheStart Point representstheevent that triggersthe use case.<br />
I like to labelStartPoints.<br />
Actor elects to AddCustomer<br />
Actor elects to AddCustomer<br />Althoughthis is notstandardpractise.<br />
END POINT<br />
To reachtheEnd Point…<br />
… you need to model STEPS.<br />
Link thestepswith TRANSITIONS.<br />
Link thestepswith TRANSITIONS.<br />
Transitions use arrowheads to show thedirection of  processflow.<br />
I like to put a note againstanystep that achievesthegoal of the use case.<br />Goal  X achieved<br />
Themostcommonroutefromthestartpoint to theendpoint has manynames.<br />
Buttheyeffectively mean thesamething.<br />
Combine anywordontheleftwithanyphraseontheright.<br />PRIMARY<br />PATH<br />BASIC<br />FLOW<br />TYPICAL<br />COURSE OF E...
Often in a use case theSystem has to make a decisionbasedonbusiness rules...<br />
DECISION POINT<br />
DecisionPointscontaintextwhich describes thenature of thedecision to bemade.<br />
Decisionpointsallowtheflow to branchawayfromthePrimaryPath.<br />
Transitionscomingout of DecisionPointsmust have a GUARD.<br />[Condition 2]<br />[Condition 1]<br />
[Condition 2]<br />[Condition 1]<br />A Guardneeds to explicitly describe a conditionwhichmustbe true in order to proceedd...
IftheflowrejoinsthePrimaryPath, it is known as anAlternatePath.<br />[Condition 2]<br />[Condition 1]<br />
[Condition 2]<br />[Condition 1]<br />WithAlternatePaths, thegoal of the Use Case is stillachieved.<br />
There are othernamesforAlternatePaths.<br />[Condition 2]<br />[Condition 1]<br />
Combine anywordontheleftwithanyphraseontheright.<br />ALTERNATE<br />PATH<br />ALTERNATIVE<br />FLOW<br />SECONDARY<br />C...
[Condition 2]<br />[Condition 1]<br />You can show howpathsrejoinbyusing a MERGE POINT.<br />
[Condition 2]<br />[Condition 1]<br />You can show howpathsrejoinbyusing a MERGE POINT.<br />
I don’tlikeMergePointsbecausetheytake up spacewithoutaddingclarity.<br />[Condition 2]<br />[Condition 1]<br />
I prefer to modelmergingpathslikethis.<br />[Condition 2]<br />[Condition 1]<br />
MergePoints can sometimesbeparticularlysuperfluous.<br />[Condition 2]<br />[Condition 1]<br />
[Condition 2]<br />[Condition 1]<br />I thinkit is neater to show themergethisway.<br />
Iftheflowdoes NOT rejointhePrimaryPath, it is known as anExceptionPath.<br />[Condition 2]<br />[Condition3]<br />[Conditi...
WithExceptionPaths, thegoal of the Use Case is NOT achieved.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
I like to use colour to highlightthedifferentpaths.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
This makesiteasy to identify test scenarios at a glance.<br />[Condition3]<br />[Condition 2]<br />[Condition 1]<br />
I alsolike to labeltheGuards in order to easilyidentifythepaths.<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Co...
And I like to labeltheStepsforeasybackwardreferencefrom Business Rules and a Logical Data Model.<br />P1:<br />A1: [Condit...
PrimaryPath: 	P1, P2.<br />P1:<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Condition 1]<br />P2:<br />A1.1:<br ...
PrimaryPath: 	P1, P2.<br />AlternatePath 1: 	P1, A1.1, P2.<br />P1:<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: ...
PrimaryPath: 	P1, P2.<br />AlternatePath 1: 	P1, A1.1, P2.<br />ExceptionPath 1: 	P1, E1.1.<br />P1:<br />A1: [Condition 2...
In some Use Cases, you willneed to modelparallelsteps<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
[Condition 2]<br />[Condition3]<br />[Condition 1]<br />X<br />A<br />B<br />In thisexample, steps A and B mustbothstartaf...
[Condition 2]<br />[Condition3]<br />[Condition 1]<br />X<br />A<br />B<br />Butwe do notcareabouttheorder in which A and ...
A and B couldevenhappen at thesame time.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />X<br />A<br />B<br />
In thisexample, B mustfollow A, butwe do notcarewhen C happens in relation to (A + B).<br />[Condition 2]<br />[Condition3...
In some Use Cases, you willneed to modelrepeatedsteps.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />A<br /...
[Condition 2]<br />[Condition3]<br />[Condition 1]<br />Foreach X:<br />A<br />In thisexample, you repeat (A + B) untilthe...
[Condition 2]<br />[Condition3]<br />[Condition 1]<br />Foreach X:<br />A<br />Forexample, you might do thiswhenaddingpass...
Let’sreviewtheshapes<br />
START POINT<br />DECISION POINT<br />[Condition]<br />END POINT<br />GUARD<br />STEP<br />PARALLEL STEPS<br />Foreach X:<b...
www.chellar.com/blog<br />
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Activity diagram tutorial
Upcoming SlideShare
Loading in …5
×

Activity diagram tutorial

30,567 views

Published on

Introduction to using activity diagrams to model use cases visually.

Activity diagram tutorial

  1. 1. UsingActivityDiagrams toModel Use Cases Visually<br />by Declan Chellar<br />
  2. 2.
  3. 3. START POINT<br />
  4. 4. TheStart Point representstheevent that triggersthe use case.<br />
  5. 5. I like to labelStartPoints.<br />
  6. 6. Actor elects to AddCustomer<br />
  7. 7. Actor elects to AddCustomer<br />Althoughthis is notstandardpractise.<br />
  8. 8. END POINT<br />
  9. 9. To reachtheEnd Point…<br />
  10. 10. … you need to model STEPS.<br />
  11. 11. Link thestepswith TRANSITIONS.<br />
  12. 12. Link thestepswith TRANSITIONS.<br />
  13. 13. Transitions use arrowheads to show thedirection of processflow.<br />
  14. 14. I like to put a note againstanystep that achievesthegoal of the use case.<br />Goal X achieved<br />
  15. 15. Themostcommonroutefromthestartpoint to theendpoint has manynames.<br />
  16. 16. Buttheyeffectively mean thesamething.<br />
  17. 17. Combine anywordontheleftwithanyphraseontheright.<br />PRIMARY<br />PATH<br />BASIC<br />FLOW<br />TYPICAL<br />COURSE OF EVENTS<br />SCENARIO<br />
  18. 18. Often in a use case theSystem has to make a decisionbasedonbusiness rules...<br />
  19. 19. DECISION POINT<br />
  20. 20. DecisionPointscontaintextwhich describes thenature of thedecision to bemade.<br />
  21. 21. Decisionpointsallowtheflow to branchawayfromthePrimaryPath.<br />
  22. 22. Transitionscomingout of DecisionPointsmust have a GUARD.<br />[Condition 2]<br />[Condition 1]<br />
  23. 23. [Condition 2]<br />[Condition 1]<br />A Guardneeds to explicitly describe a conditionwhichmustbe true in order to proceeddown that path. <br />
  24. 24. IftheflowrejoinsthePrimaryPath, it is known as anAlternatePath.<br />[Condition 2]<br />[Condition 1]<br />
  25. 25. [Condition 2]<br />[Condition 1]<br />WithAlternatePaths, thegoal of the Use Case is stillachieved.<br />
  26. 26. There are othernamesforAlternatePaths.<br />[Condition 2]<br />[Condition 1]<br />
  27. 27. Combine anywordontheleftwithanyphraseontheright.<br />ALTERNATE<br />PATH<br />ALTERNATIVE<br />FLOW<br />SECONDARY<br />COURSE OF EVENTS<br />SCENARIO<br />[Condition 2]<br />[Condition 1]<br />
  28. 28. [Condition 2]<br />[Condition 1]<br />You can show howpathsrejoinbyusing a MERGE POINT.<br />
  29. 29. [Condition 2]<br />[Condition 1]<br />You can show howpathsrejoinbyusing a MERGE POINT.<br />
  30. 30. I don’tlikeMergePointsbecausetheytake up spacewithoutaddingclarity.<br />[Condition 2]<br />[Condition 1]<br />
  31. 31. I prefer to modelmergingpathslikethis.<br />[Condition 2]<br />[Condition 1]<br />
  32. 32. MergePoints can sometimesbeparticularlysuperfluous.<br />[Condition 2]<br />[Condition 1]<br />
  33. 33. [Condition 2]<br />[Condition 1]<br />I thinkit is neater to show themergethisway.<br />
  34. 34. Iftheflowdoes NOT rejointhePrimaryPath, it is known as anExceptionPath.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
  35. 35. WithExceptionPaths, thegoal of the Use Case is NOT achieved.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
  36. 36. I like to use colour to highlightthedifferentpaths.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
  37. 37. [Condition 2]<br />[Condition3]<br />[Condition 1]<br />
  38. 38. [Condition 2]<br />[Condition3]<br />[Condition 1]<br />
  39. 39. This makesiteasy to identify test scenarios at a glance.<br />[Condition3]<br />[Condition 2]<br />[Condition 1]<br />
  40. 40. I alsolike to labeltheGuards in order to easilyidentifythepaths.<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Condition 1]<br />
  41. 41. And I like to labeltheStepsforeasybackwardreferencefrom Business Rules and a Logical Data Model.<br />P1:<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Condition 1]<br />P2:<br />A1.1:<br />E1.1:<br />
  42. 42. PrimaryPath: P1, P2.<br />P1:<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Condition 1]<br />P2:<br />A1.1:<br />E1.1:<br />
  43. 43. PrimaryPath: P1, P2.<br />AlternatePath 1: P1, A1.1, P2.<br />P1:<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Condition 1]<br />P2:<br />A1.1:<br />E1.1:<br />
  44. 44. PrimaryPath: P1, P2.<br />AlternatePath 1: P1, A1.1, P2.<br />ExceptionPath 1: P1, E1.1.<br />P1:<br />A1: [Condition 2]<br />E1: [Condition 3]<br />P: [Condition 1]<br />P2:<br />A1.1:<br />E1.1:<br />
  45. 45. In some Use Cases, you willneed to modelparallelsteps<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />
  46. 46. [Condition 2]<br />[Condition3]<br />[Condition 1]<br />X<br />A<br />B<br />In thisexample, steps A and B mustbothstartafterstep X finishes and mustbothfinishbeforethe Use Case ends.<br />
  47. 47. [Condition 2]<br />[Condition3]<br />[Condition 1]<br />X<br />A<br />B<br />Butwe do notcareabouttheorder in which A and B happen.<br />
  48. 48. A and B couldevenhappen at thesame time.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />X<br />A<br />B<br />
  49. 49. In thisexample, B mustfollow A, butwe do notcarewhen C happens in relation to (A + B).<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />A<br />C<br />B<br />
  50. 50. In some Use Cases, you willneed to modelrepeatedsteps.<br />[Condition 2]<br />[Condition3]<br />[Condition 1]<br />A<br />B<br />
  51. 51. [Condition 2]<br />[Condition3]<br />[Condition 1]<br />Foreach X:<br />A<br />In thisexample, you repeat (A + B) untilthere is no more X.<br />B<br />
  52. 52. [Condition 2]<br />[Condition3]<br />[Condition 1]<br />Foreach X:<br />A<br />Forexample, you might do thiswhenaddingpassengers to a holidaybooking.<br />B<br />
  53. 53. Let’sreviewtheshapes<br />
  54. 54. START POINT<br />DECISION POINT<br />[Condition]<br />END POINT<br />GUARD<br />STEP<br />PARALLEL STEPS<br />Foreach X:<br />TRANSITION<br />REPEATED STEPS<br />
  55. 55. www.chellar.com/blog<br />

×