Workflow and Business Process Modeling with UML Activity Diagrams. April 17, 2008

Transcription

1 Workflow and Business Process Modeling with UML Activity Diagrams April 17,

2 About Today s Seminar Your input Polls Questions This session will be recorded 2

3 Introductions ti Boston University Corporate Education Center Today s speaker: Dr. Martin Schedlbauer 3

4 Agenda This webinar will show: How UML Activity Diagrams are used to effectively visualize workflows 4

5 Definition: iti Workflow Model A workflow model is a visual representation of the flow of work in a business area. Workflow models are used to document how work processes are carried out, and to find opportunities for process improvement. BABOK, v1.6, Section

6 Workflow Model: Components A workflow model typically has the following components: Activities (Tasks) Sequential Flows Decision Points Concurrent Flows Swimlanes (Partitions) Annotations Terminals Structural Elements Data and Information Flows 6

7 Recording with Diagrams Diagrams are a good way to record information and communicate insights visually Unified Modeling Language: a standard, industry-accepted notation maintained by the Object Management Group ISO and ANSI standard Workflow modeling: Activity Diagram Alternative notations for process modeling: ANSI/ISO flow charts BPMN 7

8 Why Build Models? Models, particularly visual ones, are developed in order to: document a business process identify weaknesses in the process evaluate improvements to the process communicate business logic to stakeholders aid in reviews of requirements gain consensus among stakeholders guide interviews of stakeholders 8

9 Model Elements Even though our focus is on visual modeling, a workflow model consists of: one or more diagrams supporting text narrative of process definitions detailed business rules matrices e.g., CRUD matrices, decision tables 9

10 Model Perspective Process and workflows are modeled either as: current state ( as-is ) future state ( to-be ) They describe either a: business process reaction to an event external to organization or business system process interaction with a system Diagrams must contain this information to be useful and readable 10

11 Getting Startedt Describe the main flow (normal scenario) and its pre- and post-conditions Identify alternate and exception flows (variations) and their post-conditions Determine start and end of the workflow, but don t focus on sequencing immediately Use text initially, then turn narrative into a diagram (process visualization) apply use case analysis for this part 11

12 Activities iti and UML Symbols print loan request form Simple Activity «automated» print loan request form Activity with Stereotype «manual» prepare loan agreement Interest Rate Due Date Parameterized Activity Each step in the process is described as an activity (action) Activities are described with a verbphrase e.g., print loan request form Sequencing of activities is indicated with control flows (edges): ideally, only one input and output flow per activity «manual» fill out loan request form «manual» meet with student 12

13 Showing Workflow Start t & End initial activity fill out loan request form final activity meet with student Success there can only be one start for each workflow, but multiple ends (success and failure) the control flow points from the initial activity icon to the first activity 13

14 Best Practices Stakeholders often don t know their processes Asking for the first step may confuse them Better approach: ask what happens during this process what tasks do have to be accomplished to achieve the process goal Don t focus on the order of steps Afterwards, for each step ask them: what other step must be completed before this one can be done 14

15 Showing Pre-Conditions stereotype pre-conditions [student asks for loan] «manual» fill out loan request form «Pre-condition» {student is matriculated} trigger pre-conditions summarize the assumptions that the process designer makes pre-conditions indicate constraints that must be true in order for the workflow to be successfully completable a trigger is the external event that starts the process stereotypes are a UML mechanism for classifying constructs 15

16 Showing Post-Conditions «manual» issue funds «Post-condition» {funds i ssued; promi ssory note signed} post-conditions summarize the outcome of the process primarily concerned about changes to data or output critical for testing 16

17 Showing Decisions/Branches i Guard conditions are placed fill out tloan request tf form into brackets, e.g., [not approved] Decision does not contain a YES/NO question as would meet w ith student be done in a flow chart Guard conditions are simple narratives [not approved] Guard conditions must be Failure mutually exclusive [loan approved] disburse funds guard conditions route the flow Guard conditions can be compound, e.g.,[approved AND not critical] 17

18 Multi-Branches [tran sfer] [check] [cash] write check issue cash from petty cash transfer credit to account Ab branch may have more than two outgoing control flows There is no restriction, but if the conditions get too complex, consider using chains of decisions 18

19 Learning Checkpoint: Poll Which of the following can NOT be shown in an activity diagram? A. decisions B. multiple l actions C. actors D. notes E. none of the above 19

20 Learning Checkpoint: Poll What is an advantage of UML-style guard conditions compared to flow chart decisions with Yes/No outflows? A. much easier to read B. more than two outflows C. compound conditions D. more compact syntax E. B and C F. B, C, and D 20

21 Merging Subflows branch [cash] issue cash from petty cash [check] write check Decision i and merge symbols are the same Decisions have multiple outgoing flows Merges have multiple incoming flows UML 2 requires merges, but UML 1 did not merge sign loan agreement 21

22 Alternate t Style [ca sh] issue cash from petty cash [check] write check In UML 1.x the merge is optional Since the icon for merge is the same as for branch, it can be visually confusing Color can be used to disambiguate sign loan agreement 22

23 Best Practices Build the workflows collaboratively with your stakeholders Each activity likely will lead to functional requirements and possibly rules or constraints Document these insights in the requirements log or business rule catalog Augment activities with text narratives and other analysis work products, such as decision tables 23

24 Partitioning i Responsibilities Partitions can be horizontal, vertical, or both Partitions are labeled with the actor or workflow participant i t who is responsible for carrying out the activities (tasks) If an actor has to make a decision, the branch icon must be shown in that actor s partition Swimlanes are an alternative mechanism 24

25 Hiding Complexity [check] issue funds [cash] write check issue cash from petty cash Subflows have their own start and end nodes. sign loan agreement 25

26 Unordered d Steps fork optional step join sign loan agreement write check [loan request] sign receipt A set of steps that can be done: in any order at the same time All steps must complete before the activity after the join can start Optional steps within the fork/join can be indicated with guard conditions 26

27 Iterationti «iterativ e» sign loan agreement create student record Iterations are indicated for each disbursement with expansion regions Disbursement The loop condition is generally indicated d with write check a note Stereotypes are used to indicate iteration semantics: [loan request] sign receipt iterative concurrent parallel 27

28 Concurrent vs. Iterativeti Iterative example: Subway: one sandwich at a time; goes through a preparation pipeline Concurrent example: McDonalds: several sandwiches at a time In concurrent processing, the repeated tasks can be carried out simultaneously Parallel means that the tasks are done in lockstep: unusual in business processes 28 28

29 Learning Checkpoint: Poll In an activity diagram you would combine flows that were previously separated by a decision using a: A. merge B. fork C. join D. connector E. none of the above 29

30 Object Flows write check sign receipt Chec k Object flows show data that is generated and consumed by activities Provides activity diagrams with capabilities similar to DFDs 30

31 Object: Direct Consumption Approach I print loan agreement Loan Agreement sign loan agreement The first activity produces the object that the second activity requires as input Color can be used to clarify the diagram, but color has no semantics Approach II print loan agreement Loan Agreement Loan Agreement sign loan agreement 31

32 Indicating State t Changes state State changed by previous activity print loan agreement Loan Agreement [new] sign loan agreement Loan Agreement [signed] The outcome of an activity may be a change in state (status) of an object, rather than the creation of a new object 32

33 Best Practices Any object flowing into an activity it must be generated somewhere. Any object generated by an activity must be used somewhere. If an object is not used, then one could argue why would be important and would have to be shown. The structure of the objects (attributes, relationships, rules) are documented in a UML Class Diagram. 33

34 Signals & Events Signals indicate that another process should start and run while the current processes continues The name of the signal and the event must be the same send signal wait for event ie r r Cashi Prepare record order process take payment order process order fetch ingredients assemble sandwich 34

35 Interruptible tibl Regions An interruptible region contains a group of activities that can be interrupted. Issue Loan cancel application print loan agreement sign loan agreement issue funds 35

36 Other Important t UML Diagrams Use Case Diagram User requirements State Diagram Complex rules Class Diagram Data requirements Sequence Diagram Complex algorithms and procedures Diagrams are developed concurrently Iterative refinement is critical We have studied: Activity Diagram 36 36

37 UML Modeling Tools Enterprise Architect Poseidon Sparx Systems, Ltd./$ Gentleware, Inc./$$ Visual Paradigm Visible Analyst Visual Paradigm/$$ Visible Systems/$$$ Rational Architect ArgoUML IBM/Rational/$$$$ Tigris/FREE Altova Umodel 2008 Vision Altova/$$ Microsoft/$$ MagicDraw BOUML No Magic, Inc./$$ Open Source Software/FREE Together Architect StarUML Borland/$$$ Open Source Software/FREE 37

38 Best Practices Don t use tools during collaborative sessions with stakeholders unless you know the tool really well and the stakeholders can see you work Use whiteboards to think; use tools to record 38

39 Upcoming classes and Q&A Thank you for attending today s webinar! Upcoming classes: BA114 - Model and Document Your Project Requirements May 14 Univ of Houston, Houston TX May 21 Waltham MA June 11 Univ of Houston at Cinco Ranch, Katy TX June 18 Teachers College/Columbia Univ, NY For more information please call us at BUtrain ( ) or visit us at: 39