Models in Business Analysis Solution Design

1. Models in Business Analysis & Solution Design IIBA Winnipeg Chapter February 24, 2010 Presented by Kevin Giles

2. & Other Random Thoughts

3. 3 Who Am I Senior Systems Analyst at Investors Group IIBA Winnipeg Chapter: Current VP of Communications Soon-to-be VP of Professional Development Big fan of models and things that can be reused

4. 4 Standard Warning Message

5. 5 My Goals for this Presentation Present modeling tools & techniques Provide you with enough detail so that you can apply what we covered Get you to think about future use when creating your models and deliverables

6. 6 What will not be Covered Event modeling Process analysis Organizing models Black box stuff (in any level of real detail) Lots of other really useful stuff

7. 7 Before we get Too Far In Please feel free to stop me and ask questions Speak up if you know something that would benefit the group Please let me know if I need to speak up If you need to leave for the hockey game, I won�t take offence

8. 8 Your Experience with Models

9. 9 For those Unfamiliar with Models

10. 10 For those who are Occasional Modellers

11. 11 For Those who are Frequent Modellers

12. 12 What is this Presentation All About Cover three modeling techniques: Activity Diagrams Sequence Diagrams Class Diagrams Picked these three because: Excellent ways to communicate to a variety of stakeholders Adaptable and scalable Provide structure to your analysis efforts Can be used in conjunction with (or in place of) other tools such as use cases

13. 13 Kevin�s View of Organization Structure

14. 14 Activity Diagrams Used to model behavior Are a means of describing workflows Can be used in a variety of ways: Capturing Functional Requirements Documenting as-is Processes Defining to-be Processes Very flexible and have a wide range of application

15. 15 Activity Diagrams & Level of Detail Different audiences require different levels of detail Separate requirements from solution design Means different things depending on what level you are looking at

16. 16 Activity Diagram Symbols

17. 17 Initial Activity Defines where the activity diagram starts Only one initial activity is allowed

18. 18 Initial Activity Example

19. 19 Activity

20. 20 Activity Example

21. 21 Activity Tips & Tricks When labeling activities: Use verb-noun to name activities Focus on the result of the activity Keep the name simple Remember that activities encapsulate additional steps

22. 22 Control Flow Bridge the flow between Activity nodes, by directing the flow to the target node once the source node's activity is completed.

23. 23 Control Flow Example

24. 24 Activity Final Indicates an endpoint for an activity diagram An activity diagram can have multiple endpoints

25. 25 Activity Final Example

26. 26 Activity Final Tips & Reminders: If you have multiple endpoints, it is helpful to label them with the end result When decomposing between levels of detail, you should find that subordinate diagrams have the same number of Activity Finals as control flows leaving parent activity

27. 27 Guard A condition that must be satisfied for a flow to take place

28. 28 Guard Example (Exclusive Or)

29. 29 Fork Fork Is a control node that splits a flow into multiple concurrent flows. A fork node has one incoming edge and multiple outgoing edges.

30. 30 Fork Example (Parallel Flows)

31. 31 Fork Example (Inclusive or)

32. 32 Fork Example (Parallel & Inclusive or)

33. 33 Join Join As a control node that synchronizes multiple flows. A join node has multiple incoming edges and one outgoing edge.

34. 34 Join Example

35. 35 Activity Partition (AKA Swim lane) Used to indicate responsibility for completing activities Who/what will be actually doing/controlling the work Can represent roles, systems, external entities, system components, etc.

36. 36 Activity Partition Example

37. 37 Activity Partitions Tips & Reminders Remember that if you are using activity partitions, you are designing a solution Avoid using partitions with different levels of detail on the same diagram

38. 38 Loops Can be used for: Exception handling When multiple repetitive activities need to be performed Requires a guard

39. 39 Loops (Exception Handling)

40. 40 Loops (Repeated Activities)

41. 41 What is missing? Decisions and merges The details

42. 42 Decisions & Merges Decision A point in an activity where the flow may branch according to certain conditions Merge A merge node is a control node that brings together multiple alternate flows Generally, I prefer not to use either

43. 43 Decision & Merge Example

44. 44 No Decisions & Merge Example

45. 45 The Details Can be captured using: A narrative for the activity An additional activity diagram A use case A sequence diagram User guide Etc.

46. 46 Kevin�s Best Practices for Activity Diagrams Main flow should be left to right or top to bottom If you use swim lanes, you are designing a solution KISS with care Do not overwhelm the users of your diagrams but do not leave out important details Remember that there are always opportunities for additional elaboration If designing, I do not usually include storage or schedulers in my activity diagrams (but I do in sequence diagrams)

47. 47 Kevin�s Best Practices for Activity Diagrams When designing solutions: Ensure that your diagrams are logically complete Capture everything that needs to happen for the level of detail of the diagram When documenting as-is: Ensure that what can actually (or could) happen are covered by the diagram Make sure that the diagram can stand on its own

48. 48 Kevin�s Best Practices for Activity Diagrams Don�t have multiple levels of detail in the same diagram

49. 49 Lets Try an Activity Diagram

50. 50 Your Thoughts on Activity Diagrams? Any: Comments Feedback Personal Experiences

51. 51 Sequence Diagrams A Sequence diagram is a structured representation of behaviour as a series of sequential steps over time. It is used to depict: Work flow Message passing How elements in general cooperate over time to achieve a result

52. 52 Sequence Diagrams Provide additional details to support activity diagrams My preference is: To use sequence diagrams as one flow/scenario through an activity diagram Keep the notation simple unless you are working with developers Add-in key components that do not apply to activity diagrams

53. 53 Sequence Diagrams Key point: Remember that sequence diagrams are design diagrams

54. 54 Sequence Diagram Notation

55. 55 Sequence Diagram Example � The Activity

56. 56 Sequence Diagram Example � No Issue

57. 57 Sequence Diagram Example � Issue

58. 58 Sequence Diagrams � Any Questions?

59. 59 Checkpoint Do we continue? Options Stop now Try a sequence diagram Continue on to Class Models

60. 60 Class Diagrams Similar to: Entity-relationship diagrams Logical data models Much more powerful Relationship notation is easier to understand Association Class Methods/Operations Generalization/Specialization Embedding Enumeration

61. 61 Class Models - Relationships

62. 62 Class Models � Association Class

63. 63 Class Models � Methods & Operations

64. 64 Class Models � Generalization/Specialization

65. 65 Class Models � Embedding

66. 66 Class Models � Enumeration

67. 67 Class Models � Questions?

68. 68 Model Use

69. 69 Questions?

70. 70 References & Additional Resources Streamlining Business Requirements Author: Gerrie Caudle UML for the IT Business Analyst Author: Howard Podeswa Workflow Modeling Alec Sharp www.clariteq.com OMG UML Standards http://www.uml.org Agile Modeling www.agilemodeling.com