1. Activity Diagrams in UML

2. Definition Activity diagrams represent the dynamics of the system. They are flow charts that are used to show the workflow of a system. They show. –The flow of control from activity to activity in the system, –What activities can be done in parallel. –Alternate paths through the flow. They can show the flow across use cases or within a use case.

3. Activity Diagram Core symbol is an activity. An activity is some task which needs to be done. Each activity can be followed by another activity (sequencing). Triggers from the activity may be guarded as in state diagrams.

4. Decision Activities Diamond. Each trigger coming from it has a guard. Synchronisation bar. All triggers from this attach to activities that can occur in parallel, with no specific sequence, or concurrently. The next synchronisation bar closes the concurrency. Iteration is represented by a * on the trigger. or

5. Activity Diagrams for Use Cases They can be used for describing either –Use cases or –Complicated methods

6. Find Beverage Put coffee in filter Add water to reservoir Drink Beverage Pour coffee Brew coffee Turn on machine Put filter in machine Get can of cola Get cups [found coffee] [no coffee] [no cola]

7. Use Case for Order Processing (Generic system) “When we receive an order, we check each line item on the order to see if we have the goods in stock. If we do, we assign the goods to the order. If this assignment sends the quantity of those goods inn stock below the reorder level, we reorder the goods. While we are doing this, we check to see if the payment is OK. If the payment is OK and we have the goods in stock, we dispatch the order. If the payment is OK but we don’t have the goods, we leave the order waiting. If the payment isn’t OK, we cancel the order.”

8. Combining Use Cases The end point of an activity diagram is the point at which all triggered activites have been run and there are no more left to do. Dead ends (e.g. Reorder item) can occur. Sometimes dead ends meet up with other use cases (e.g. Check line item).

9. Receiving Supply “When a supply delivery comes in, we look at the outstanding orders and decide which ones we can fill from this incoming supply. We then assign each of these to its appropriate orders. Doing this may release those orders for dispatching. We put the remaining goods into stock.”

10. Drawback Activity diagrams tell you what is happening, but not who does what. In domain modeling, this diagram type does not convey which people or departments are responsible for each activity. In programming, it does not convey which class is responsible for each activity.

11. Swimlanes Arrange activity diagrams into vertical zones separated by dashed lines. Each zone represents the responsibilities of a particular class or department.

12. When to Use Activity Diagrams Do use them for –Analysing Use Cases. –Understanding workflow across many Use Cases. –Dealing with multi-threaded applications. Don’t use them –to see how objects collaborate. –to see how an object behaves over its lifetime.

13. Assign to Order Check line item Cancel Order Authorise Payment Reorder item Dispatch Order Receive order * for each line item on order [failed] [succeeded] [in stock] [need to reorder] [stock assigned to all line items and payment authorised] Activity Diagram for Receiving an Order

14. Activity Diagram for receiving Supply Choose outstanding order items Assign goods to order Add remainder to stock Receive Supply * for each chosen order item [all outstanding order items filled] Dispatch Order

15. Assign to Order Check line item Cancel Order Authorise Payment Choose outstanding order items Assign goods to order Reorder item Add remainder to stock Dispatch Order Receive Supply Receive order * for each line item on order [failed] [succeeded] * for each chosen order item [in stock] [need to reorder] [stock assigned to all line items and payment authorised] [all outstanding order items filled] Combined Activity Diagram

16. Assign to Order Check line item Cancel Order Authorise Payment Choose outstanding order items Assign goods to order Reorder item Add remainder to stock Dispatch Order Receive Supply Receive order Finance Order Processing Stock Manager * for each line item on order [failed] [succeeded] * for each chosen order item [in stock] [need to reorder] [stock assigned to all line items and payment authorised] [all outstanding order items filled] With Swimlanes

17. Understanding Workflows –Each activity represents the performance of a group of actions in a workflow. –Once the activity is complete, the flow of control moves to the next activity or state through a transition. –If an outgoing transition is not clearly triggered by an event, then it is triggered by the completion of the contained actions inside the activity. –A unique activity diagram feature is a swimlane that defines who or what is responsible for carrying out the activity or state. –It is also possible to place objects on activity diagrams. –The workflow stops when a transition reaches an end state.

18. Activity Diagram Tools You can use the following tools on the activity diagram toolbox to model activity diagrams: –Activities –Decisions –Object –Object Flow –States Start State End State –Swimlanes –Synchronizations –Transitions

19. Placing an Activity diagram Where? –You can attach activity diagrams to most model elements in the use case or logical views. –Activity diagrams cannot reside within the component view. Why? –Very effective in illustrating the workflow of various events in a use-case diagram. –You can use activity diagrams to specify and define each event in a use-case diagram.

20. Creating an activity diagram Modelling a workflow in an activity diagram –Identify a workflow objective. –Decide the pre and post-conditions of the workflow. – Define all activities and states. –Define any objects that are created or modified. –Decide on responsibility for performing the activities. –Connect all elements on the diagram with transitions. –Place decisions on the diagram. –Evaluate your diagram for concurrent workflows. –Set all actions, triggers and guard conditions in the specifications of each model element.

21. Identify a workflow objective. –"What needs to take place or happen by the end of the workflow? What needs to be accomplished?“ –For example, if your activity diagram models the workflow of ordering a book from an online bookstore, the goal of the entire workflow could be getting the book to the customer. –What is the goal in the claims system? –What are the goals in the tennis club?

22. 2.Workflow pre and post- conditions – Define pre and post conditions of the workflow through a start state and an end state. – In most cases, activity diagrams have a flowchart structure so start and end states are used to designate the beginning and ending of the workflow. –Start and end states clarify the perimeter of the workflow. –What is the pre-condition of the main workflow in The claims system? The tennis club?

23. Define activities and states Define and recognize all activities and states that must take place to meet your objective. Place and name them on the activity diagram in a logical order. Are there intermediate states in the claims / tennis club systems?

24. Identify persistent object operations Define and diagram any objects that are created or modified within your activity diagram. Connect the objects and activities with object flows.

25. Add swimlanes Decide who or what is responsible for performing the activities and states through swimlanes. Name each swimlane and place the appropriate activities and states within each swimlane. Identify swimlanes for –The tennis club workflow –The claims workflow

26. Finish diagram Connect all elements on the diagram with transitions. Place decisions on the diagram where the workflow may split into an alternate flow. –E.g. based on a Boolean expression, the workflow could branch to a different workflow. Evaluate your diagram and see if you have any concurrent workflows. If so, use synchronizations to represent forking and joining. Set all actions, triggers and guard conditions in the specifications of each model element.