1. Chapter 7 A Case Study: Applying the Activity Analysis Approach Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung McGraw-Hill Education (Asia), 2005

2. 2 Objectives After you have read this chapter, you should be able to understand each step of the Activity Analysis Approach apply the Activity Analysis Approach to system development

3. 3 The Case Study This case study describes the development of a mail order system by applying the Activity Analysis Approach (A 3 ). Throughout this case study, we will show the main steps and the artifacts produced in A 3 in one iteration of the development process. Typically, due to the complexity of modern systems, several iterations are necessary in order to elicit and model all the requirements specified.

4. 4 Activity Analysis Approach Activity Analysis Approach has four distinct workflows: business modeling, requirement, analysis and design. In the business modeling workflow, develop activity diagrams to model the operation of the organization. In the requirement workflow, identify the scope of the system and develop the use case models of the target system. In the analysis workflow, analyze the use case descriptions to create domain class diagrams and system-level sequence diagrams. Finally, in the design workflow, we develop low-level collaboration, state and sequence diagrams to model the realization of the use cases.

5. 5 Business Modeling - Domain Analysis (Workflow) The business modeling starts with information gathering about the business processes of an organization. The goal is to identify the candidate activities which are targets for computerization. The developer can collect the information through the following ways: Interviews with users Questionnaires Documents describing the business procedures Domain experts Standards and terminologies in the business domain

6. 6 Business Modeling - Domain Analysis (Workflow) (cont’d) Problem Statement (workflow) The chief executive officer of a mail order company is interested in computerizing its business process. The major business activities of the company can be briefly described as follows: The company aims to provide high quality mail order services to all registered members of the company. An individual or a company can register to become a member by filling the registration form and sending it to the customer service department.

7. 7 Business Modeling - Domain Analysis (Workflow) (cont’d) A member can order items by filling an order form and sending it to the customer service department. The customer service department will verify the membership and forward the order to the sales department. If the order can be processed through existing stock, the sales department will process the order and issue delivery notes to the inventory department. Otherwise, the sales department will issue a purchase order to the supplier. When all items are available, the inventory department delivers the items to the member, and the accounts department issues an invoice to the member. When the accounts department receives an invoice from a supplier, it verifies that the items in the purchase order have been received, and issues payment to the supplier.

8. 8 Business Modeling - Business Process Analysis Apply the elaborator(Problem_Statement[workflow], Swimlane_Activity_Diagram) manipulator to develop an activity diagram.

9. 9 Business Modeling - Business Process Analysis (cont’d)

10. 10 Business Modeling - Determining the System Scope The developer can then discuss with the stakeholders of the system and decide on the business activities that are required to be computerized. Let’s assume that the developer and the stakeholders have agreed to computerize the business activities related to membership, sales, ordering and inventory control of the mail order company. We can now proceed with the requirements workflow (the next workflow of the Activity Analysis Approach).

11. 11 Requirements In this workflow, we start with a set of activities that we wish to computerize and prepare a more detailed (use case level) problem statement. We then conduct a textual analysis on this problem statement to identify the actors and use cases. By elaborating on the use cases, the use case descriptions can be used as the input to the analysis workflow.

12. 12 Requirements - Domain Analysis (Use Case Level) After determining the scope of the system, we can prepare a (use case level) problem statement to describe the required activities. The problem statement should give enough details for identifying the responsibilities of individual users, and describe the procedure for them to perform their tasks.

13. 13 Requirements - Domain Analysis (Use Case Level) (cont’d) Problem Statement (Use Case Level) A customer registers to become a member by filling the membership form and mailing it back to the company. A member who has not been active (i.e. no transactions) for a period of one year will be removed from the membership list and needs to apply for reinstatement of the lapsed membership. A member should inform the company of any change in personal details, such as home address, telephone numbers, etc. A member makes an order by filling out a sales order form and faxing it to the company. Alternatively, the Customer Service Assistant can handle the order over the phone. The Customer Service Assistant always checks the validity of membership before entering the sales order information into the system.

14. 14 Requirements - Domain Analysis (Use Case Level) (cont’d) The Order Processing Clerk checks the availability of the ordered items and holds them for the order. If all the items are available, the Order Processing Clerk will schedule delivery. The Inventory Control Clerk controls and maintains an appropriate level of stock and is also responsible for reordering new items. If there is a problem with an order, members can phone the Customer Service Assistant who will follow up the sales order. Members may return defective goods within 30 days and get their money back. Each task carried out by the system will have the name and ID of the staff member concerned recorded into the system.

15. 15 Requirements - Use Case Analysis: Finding Actor and Use Cases Apply the Transitor(Problem_Statement [use case level], Actor_List) manipulator to identify all the actors. Customer Service Assistant (Membership registration, placement of order) Order Processing Clerk (Process order) Inventory Control Clerk (Inventory control)

16. 16 Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d) Actor Name: Customer Service Assistant Description: The Customer Service Assistant is responsible for the maintenance of membership records, handling of goods returns, creating sales orders, monitoring sales order status and validating membership status.

17. 17 Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d) Actor Name: Order Processing Clerk Description: The Order Processing Clerk is responsible for processing sales orders, submitting reorder requests, requesting necessary deposits from members and scheduling delivery of goods to the members.

18. 18 Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d) Actor Name: Inventory Control Clerk Description: The Inventory Control Clerk is responsible for ordering and reordering of goods. The Inventory Control Clerk uses the system to update the stock level when goods have been received.

19. 19 Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d) Apply the Transitor(Problem_Statement[use case level], Use_Case_List) manipulator to identify all use cases. The following are the use cases of the mail order system: Check order status Place order Handle goods return Update membership record Archive membership

20. 20 Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d) Register new member Process order Schedule delivery Order goods Receive goods Deliver goods

21. 21 Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d)

22. 22 Requirements - Use Case Analysis: Prioritizing Use Cases The use cases are prioritized according to their relative importance in the system. The developer evaluates the risks and the significance of the use cases to the stakeholders of the system. The developer and stakeholders of the system can meet to decide on the priority of the use cases.

23. 23 Requirements - Use Case Analysis: Prioritizing Use Cases (cont’d) Priority RankUse CaseReason HighProcess orderDirectly improves the efficiency of the business process and affects the system architecture HighPlace orderSame as above HighCheck order statusImprove efficiency and quality of customer service MediumOrder goodsOrdering goods is less often than processing order but still is one of the major business processes MediumDeliver goodsImprove the control of stock level

24. 24 Requirements - Use Case Analysis: Prioritizing Use Cases (cont’d) Priority Rank Use CaseReason MediumSchedule deliveryImprove the efficiency of the goods delivery team MediumReceive goodsImprove the control of stock level MediumHandle goods returnSame as above LowUpdate membership record Small impact on the system architecture LowRegister new memberSame as above LowArchive membershipSame as above

25. 25 Requirements - Use Case Analysis: Describing Use Cases Apply the Elaborator(Use_Case, Use_Case_Description) manipulator to develop the use case description. The purpose of this manipulator is to give a detailed description of the use cases which can then be used for constructing other diagrams, such as the interaction diagrams, state diagrams, class diagrams, etc.

26. 26 Requirements - Use Case Analysis: Describing Use Cases (cont’d) Use case nameProcess Order Use case IDUC-200 Primary actor(s)Order Processing Clerk Secondary actor(s) Brief descriptionThe Order Processing Clerk selects a sales order from the system. He/she then checks each line item in the sales order for the availability of stock before finding the stock for each line item. The system records the name of the Order Processing Clerk who handles the sales order. PreconditionsThe sales order is stored in the system.

27. 27 Requirements - Use Case Analysis: Describing Use Cases (cont’d) Flow of events1. The Order Processing Clerk selects a sales order. The system displays the items and quantities of the order. 2. The Order Processing Clerk checks the availability of each item. 3. The Order Processing Clerk holds the stock items for the sales order. The system changes the order status to “filled”. Post-conditionsThe sales order status is changed to “filled” and the stock items are held for the sale.

28. 28 Requirements - Use Case Analysis: Describing Use Cases (cont’d) Alternative flows and exceptions If an item is not available from stock, the sales order status of the item is changed to “hold”. If the number of reorder item exceeds the reorder limit of the member, the clerk will print out a “request deposit” letter to the member, and the sales order is marked as “deposit pending”. When the deposit is received or if the reorder amount does not exceed the reorder limit of the member, the system then forwards a reorder request to the inventory control clerk. The sales order status is changed to “filled” when the stock items have been received, and the system will notify the order processing clerk. Non-behavioral requirements The system should be able to handle 2,000 sales orders per day.

29. 29 Requirements - Use Case Analysis: Describing Use Cases (cont’d) Assumptions IssuesCan the available items be delivered first? SourceUser Interview Memo 21, 8/9/01

30. 30 Requirements - Use Case Analysis: Structuring Use Case Model

31. 31 Analysis The analysis workflow is to develop the domain class model and start the dynamic modeling. First, we develop the domain class model by applying the transitor(problem statement, domain class model) manipulator. Using this manipulator, we can construct the class model for the system (static modeling) and analyze the dynamic behaviors of the use cases (system modeling).

32. 32 Analysis - Domain Analysis (Class Level) We apply the Transitor(Problem_Statement[use case level], Data_Dictionary.Class_List) manipulator to obtain the domain class model.

33. 33 Analysis - Static Modeling Apply the Transitor (Use_Case_Description, Class_Diagram[analysis])

34. 34 Analysis – System Modeling: Elaborating Use Cases Apply Elaborator(Use_Case, Activity_Diagram)

35. 35 Analysis - System Modeling: Elaborating Use Cases (cont’d) Parent use case name Process Order Parent use case IDUC-200 Instance nameA deposit is required before the sales order can be processed. Instance IDUCIS-200-1 Environmental conditions and assumptions All items of the order are available. InputsA sales order of available items Instance flow description  The Order Processing Clerk selects a sales order. The system displays the items and quantities of the order.  The Order Processing Clerk checks the availability of each item. The system confirms all items are available.  The Order Processing Clerk holds all items of the order. The system updates the status of the sales order to “filled”. OutputsThe sales order is filled.

36. 36 Analysis - System Modeling: Elaborating Use Cases (cont’d) Parent use case name Process Order Parent use case IDUC-200 Instance nameThe sales order can be processed and filled. Instance IDUCIS-200-1 Environmental conditions and assumptions All items of the order are available. InputsA sales order of available items Instance flow description  The Order Processing Clerk selects a sales order. The system displays the items and quantities of the order.  The Order Processing Clerk checks the availability of each item. The system confirms all items are available.  The Order Processing Clerk holds all items of the order. The system updates the status of the sales order to “filled”. OutputsThe sales order is filled.

37. 37 Analysis - System Modeling: Elaborating Use Cases (cont’d) Parent use case nameProcess Order Parent use case IDUC-200 Instance nameAn item needs to be reordered. Instance IDUCIS-200-2 Environmental conditions and assumptions Some stock items are not available, and the amount of the items needed to be reordered exceeds the preset reorder limit of the member. InputsA sales order of a stock item costs $1,000, and the preset reordering limit of the member is $2,000. Instance flow description  The Order Processing Clerk selects a sales order. The system displays the items and quantities of the order.  The Order Processing Clerk checks the availability of each item.  An item which costs $1,000 is not available. The Order Processing Clerk submits a reorder request.  The sales order is marked as “deposit pending”. OutputsThe sales order is marked as “hold” and a reorder request is submitted.

38. 38 Analysis - System Modeling: Elaborating Use Cases (cont’d) Parent use case nameProcess Order Parent use case IDUC-200 Instance nameA deposit is required before the sales order can be processed. Instance IDUCIS-200-3 Environmental conditions and assumptions Some stock items are not available, and the amount of items needed to be reordered exceeds the preset reorder limit of the member. InputsA sales order of a stock item costs $5,000, and the preset reordering limit of the member is $2,000. Instance flow description  The Order Processing Clerk selects a sales order. The system displays the items and quantities of the order.  The Order Processing Clerk checks the availability of each item.  An item which costs $5,000 is not available. The system prints a deposit request letter to the member.  The sales order is marked as “deposit pending”. OutputsThe sales order is marked as “deposit pending” and a request deposit letter is sent to the member.

39. 39 Design Design Workflow is to analyze and design how object collaboration is achieved for the performance of use cases. We first elaborate each of the action states in the activity diagram (representing a use case) using a collaboration diagram. We can generate the MVC (Model, View and Control)- level sequence diagram for the scenario by translating the collaboration diagrams corresponding to the action states of the path in the activity diagram.

40. 40 Design (cont’d) For objects with complex dynamic behaviors, especially control objects or subsystems, we model them by using state diagrams. In the process, we apply the view aligners to revise the activity diagram (use case level) and class diagram to maintain consistency among models.

41. 41 Design - Elaborating the Flow of Events For objects with complex dynamic behaviors, especially control objects or subsystems, we model them by using state diagrams.

42. 42 Design - Elaborating the Flow of Events (cont’d)

43. 43 Design - Elaborating the Flow of Events (cont’d)

44. 44 Design - Generating MVC Sequence Diagrams Having created the collaboration diagrams for the action states of the activity diagram, we can generate MVC sequence diagrams by tracing paths in the activity diagram and translating the collaboration diagrams of the action states in the path into an MVC sequence diagram.

45. 45 Design - Generating MVC Sequence Diagrams (cont’d)

46. 46 Design - Generating MVC Sequence Diagrams (cont’d) Normal Scenario

47. 47 Design - Generating MVC Sequence Diagrams (cont’d) An Alternative Scenario

48. 48 Design - Generating MVC Sequence Diagrams (cont’d) Another Alternative Scenario

49. 49 Design - Revising the Class Diagrams After we have drawn the sequence diagram for the process order use case, the class diagram is refined by adding the operations and the attributes identified in the sequence diagrams.

50. 50 Design - Revising the Class Diagrams (cont’d)

51. 51 Design - Performing State Analysis on the Control Object(s) In the MVC sequence diagram, the control object glues all other objects together, handles the control flow and deals with all other transaction-related requirements. Consequently, a control object is usually complex enough to be modeled by a state diagram. For example, the activity diagram of the process order use case together with the collaboration diagrams can be used to construct the state diagram for the control object ProcessOrderControl.

52. 52 Design - Performing State Analysis on the Control Object(s) (cont’d) ProcessOrderControl

53. 53 Design - Revising the Class Diagram(s) After refining the sequence diagrams for the system, we can revise the class diagrams according to the operations and attributes identified in the sequence diagrams. The design class diagram now provides design information for the classes required for the implementation of the process order use case. Hence, the implementation work for the process order use case can be carried out.

54. 54 Design - Revising the Class Diagram(s) (cont’d) For other use cases, the work flows of the activity analysis approach can be repeated to develop the design of the classes required for the implementation of the use cases. The design class diagram will then be incrementally refined by going through the development process iteratively.

55. 55 Design - Revising the Class Diagram(s) (cont’d)