Chapter 7 A Case Study: Applying the Activity Analysis Approach

1. Chapter 7A 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 Dr. Hussein Al-Zoubi

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. The Case Study • This case study describes the development of a mail order system by applying the Activity Analysis Approach (A3). • Throughout this case study, we will show the main steps and the artifacts produced in A3 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. 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. 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 Designer 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. 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. 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. Business Modeling - Business Process Analysis • Apply the elaborator(Problem_Statement[workflow], Swimlane_Activity_Diagram) manipulator to develop an activity diagram.

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

10. Business Modeling - Determining the System Scope • The Designer 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 Designer 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. 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. 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. 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. 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. 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. Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d)

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

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

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. 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. Requirements - Use Case Analysis: Finding Actor and Use Cases (cont’d)

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. Requirements - Use Case Analysis: Prioritizing Use Cases (cont’d)

24. Requirements - Use Case Analysis: Prioritizing Use Cases (cont’d)

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. Requirements - Use Case Analysis: Describing Use Cases (cont’d)

27. Requirements - Use Case Analysis: Describing Use Cases (cont’d)

28. Requirements - Use Case Analysis: Describing Use Cases (cont’d)

29. Requirements - Use Case Analysis: Describing Use Cases (cont’d)

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

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. Analysis - Domain Analysis-Problem_Statement(Class Level)

33. Analysis - Static Modeling (Use_Case_Description)

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

35. Analysis - System Modeling: Elaborating Use Cases (cont’d)

36. Analysis - System Modeling: Elaborating Use Cases (cont’d)

37. Analysis - System Modeling: Elaborating Use Cases (cont’d)

38. Analysis - System Modeling: Elaborating Use Cases (cont’d)

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. 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. 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. Design - Elaborating the Flow of Events (cont’d)

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

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. Design - Generating MVC Sequence Diagrams (cont’d)

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

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

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

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. Design - Revising the Class Diagrams (cont’d)