Activity_Diagrams_inClass (1).pptx Activity_Diagrams_inClass (1).pptx

Activity_Diagrams_inClass (1).pptx

1. Week 7: Activity Diagrams

2. Introduction This session will cover: Activity Diagrams Representing Use Cases

3. Activity Diagrams Activity diagrams are typically used for business process modelling , for modelling the logic captured by a single use case or usage scenario, or for modelling the detailed logic of a business rule In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

4. Activity Diagrams Activity Diagrams have five elements Activities Transition Decision Synchronisation Bars Swim Lanes Not all elements need to be included in every diagram

5. Activities Activities represent a task that must be performed Appear as a rounded rectangle Activities are normally given names that begin with a verb followed by the object being acted on Display Screen

6. Activities An activity, also known as an activity state, on a UML activity diagram typically represents the invocation of an operation, a step in a business process, or an entire business process Be wary of “Black Hole” activities A black hole activity is one that has transitions into it but none out, typically indicating that you have either missed one or more transitions Be wary of “Miracle” activities A miracle activity is one that has transitions out of it but none into it, something that should be true only of start points

7. Transitions A transition represents movement from one element in the activity diagram to another Shows flow between elements Transitions may include information about when the transition may occur, e.g. Events and Guard Conditions (more later) Get Screen Information Display Screen

8. Decisions Decisions represent branches in the flow of control Dependent on the outcome of the decision, alternative paths are followed

9. Decisions A decision point is modelled as a diamond on a UML activity diagram Decision points should reflect the previous a ctivity Unlike traditional flowcharts which would include text describing the actual decision being made, you need to imply what decision is being made from the previous activity

10. Decisions Decisions follow on from an activity that relates to the decision The [guards] represent conditions that must be true to traverse a flow Use guard names that define the decision for clarity Process Record Wait for Input [More Records] [Last Record]

11. Specifying Actions (Transitions and Decisions) Actions are connected by transition lines Transitions can branch (diamond) and merge – alternative computation threads May show guard conditions Eg. [Delinquent], [Good] Swipe the card Accept card number Swipes OK? Enter card number manually Yes No 11

12. Guards A guard is a condition that must be true in order to traverse a transition Each transition leaving a decision must have a guard Guards should not overlap For example guards such as x <0, x = 0, and x > 0 are consistent whereas guard such as x <= 0 and x >= 0 are not consistent because they overlap – it isn’t clear what should happen when x is Guards on decision points must form a complete set For example, guards such as x < 0 and x >0 are not complete because it isn’t clear what happens when x is Apply a [Otherwise] guard to catch all logic

13. Synchronisation Bars Tasks in an activity diagram can occur concurrently Concurrent activities are modelled using synchronisation bars Fork Join

14. Synchronisation Bars A fork should have a corresponding join In general, for every start (fork) there is an end (join ) Forks have one entry t ransition Joins have one exit transition Note that in a join, all inputs must be received for the process to continue Be wary of decisions upstream of a join that preclude activities downstream of the join being completed

15. Synchronisation Bars Transitions can fork and re-join (synchronisation bar line) –concurrent (parallel) computation threads Activity diagram without concurrent processes resembles a conventional flowchart Update Stock Accept Payment Print Receipt 15

16. Swim Lanes It is often helpful to show multiple entities that take place in a given workflow or process When modelling use cases, we show how each actor participates through the use of swimlanes Insert Card Customer ATM Insert Pin Validate Identity Present Accounts

17. 17 Swimlanes Swimlanes partition groups of activities based on, for instance, business organizations: Pay bill Bill customer Receive product Customer Billing

18. Initial & Final Nodes In addition to the main elements, an activity diagram needs initial and final nodes identified that dictate the start and end(s) of the workflow Do Something

19. Hierarchical Modelling It should be no surprise that activity diagrams, just like DFDs, can be “nested” to show different levels of complexity The “rake” symbol in an activity indicates that there is a separate activity diagram that is included elsewhere for a single activity Do Something

20. Modelling Use Cases When modelling use cases, it is important to make the activities on the activity diagram distinct tasks that are recognisable Main and alternate flows are modelled

21. Requirements a) b) c) d) Use Case a) Overview PreCondition MainFlow 1. MainFlow 2. AlternateFlow 1. AlternateFlow 2. PostCondition Activity Diagram a) Modelling activity … 21

22. Modelling activity … Activity Diagram a) 22

23. Activity Modeling – Summary Shows the steps of a computation Each step is a state of doing something Execution steps are called actions Control flow – the flow of control from one action to the next Flow of logic Sequential control Concurrent control Diagram depicts which steps are executed in sequence and which can be executed concurrently Can be used at different levels of abstraction At business process level, To define execution of a use case, or To define execution of an operation 23

24. 24 Actions can be discovered from the narrative specifications of use cases The execution proceeds from one action to the next An action completes when its computation is completed A solid filled circle represents the start of an activity. The end of an activity is shown using a bull’s eye symbol. There may be more than one end point. The following items are common to state diagrams and activity diagrams: Activities, actions, transitions, initial/final states, guard conditions Discovering and specifying actions - Summary

25. “Faults” in Activity Diagrams We are going to look at some sample activity diagrams from off the web and see if we can identify “faults” with these diagrams

26. Example 1 Is this a decision? Or should it be a fork?

27. Example 2 Implicit decision in the activity but no explicit decision in the diagram

28. Example 3 Decision with no preceding activity Diagram must start with a single activity!

29. Example 4 Synchronisation Bar… but what type? A “Black Hole”

30. 30 Finding actions in use case flows: Video store example No. Use case statement Action 1 The Employee requests the system to display the rental charge together with basic customer and video details. Display transaction details 2 If the Customer offers cash payment, the Employee handles the cash, confirms to the system that the payment has been received and asks the system to record the payment as made. 3 If the Customer offers debit/credit card payment, the Employee swipes the card and then requests the Customer to type the card’s PIN number, select debit or credit account, and transmit the payment. Once the payment has been confirmed electronically by the card provider, the system records the payment as made.

31. 31 Finding actions in use case flows: Video store example No. Use case statement Action 1 The Employee requests the system to display the rental charge together with basic customer and video details. Display transaction details 2 If the Customer offers cash payment, the Employee handles the cash, confirms to the system that the payment has been received and asks the system to record the payment as made. Key in cash amount; Confirm transaction 3 If the Customer offers debit/credit card payment, the Employee swipes the card and then requests the Customer to type the card’s PIN number, select debit or credit account, and transmit the payment. Once the payment has been confirmed electronically by the card provider, the system records the payment as made. Swipe the card; Accept card number; Select card account; Confirm transaction

32. 32 Finding actions in use case flows No. Use case statement Action 4 The Customer does not have sufficient cash and does not offer card payment. The Employee asks the system to verify the Customer’s rating (which accounts for the customer’s history of payments). The employee decides whether or not to rent out the video with no or partial payment. Depending on the decision, the Employee cancels the transaction (and the use case terminates) or proceeds with partial payment (and the use case continues) 5 The Customer’s card does not swipe properly through the scanner. After three unsuccessful attempts, the Employee enters the card number manually.

33. 33 Finding actions in use case flows No. Use case statement Action 4 The Customer does not have sufficient cash and does not offer card payment. The Employee asks the system to verify the Customer’s rating (which accounts for the customer’s history of payments). The employee decides whether or not to rent out the video with no or partial payment. Depending on the decision, the Employee cancels the transaction (and the use case terminates) or proceeds with partial payment (and the use case continues) Verify customer rating Refuse transaction Allow rent with no payment Allow rent with partial payment 5 The Customer’s card does not swipe properly through the scanner. After three unsuccessful attempts, the Employee enters the card number manually. Enter card number manually

34. 34 Actions The Customer ’s card does not swipe properly through the scanner. After three unsuccessful attempts, the Employee enters the card number manually . Plus more actions ….

35. 35 Activity Diagram (Figure 3.6, p. 132)

36. A customer may ask an employee about video availability (including a reserved video) or may pick a videotape or disk from the shelves. The videotape and the membership card are scanned and any delinquent or overdue details are brought up for the employee to query the customer about. If the customer does not have a delinquent rating, then he or she can hire up to a maximum of eight videotapes. However, if the rating of the customer is “unreliable”, then a deposit of one rental period for each videotape or disk is requested. 36 Create an activity diagram for the following main flow of the “Rent video” use case description for a video store system. The diagram should show the sequence of action executions connected by control flows. (p.212)

37. Main flow for the use case “Rent video” for a video store system … Once the amount payable has been received, the stock is updated and the videotapes and disks are handed to the customer together with the rental receipt. The customer pays by cash, credit card or electronic transfer. Each rental record stores (under the customer’s account) the check-out and due-in dates, together with the identification of the employee. A separate rental record is created for each videotape or disk hired. The use case will generate an overdue notice to the customer if the videotape or disk has not been returned within two days of the due date, and a second notice after another two days (and at that time the customer is noted as “delinquent”). 37

38. 38 Scan Customer Card Scan Video Medium Verify Customer Initiate Rent Transaction Remove Excessive Videos Request Deposit Accept Payment Update Stock Print Receipt Commit Rent Transaction [ is unreliable ] [ is delinquent ] [ more than 8 videos ] Create Rental Record for Each Video [ deposit refused ] [ 8 videos or less ] add deposit Example Video Store – activity diagram solution Figure 4.17 (p. 215)

39. Conclusions Activity diagrams are essentially OO flow charts Illustrate dynamic nature of a system by modelling flow of control from activity to activity Primarily used to model workflows, business processes and to represent use cases Reference: Chapters 3, 4 & Appendix A, Requirements Analysis and System Design: 3 rd edition, Maciaszek , A