E N D
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