Chapter - 9

1. Chapter - 9 An Object-Oriented Analysis Case Study of Dick’s Dive ‘n’ Thrive

2. Chapter Objectives • An overview of the OO Analysis Process • Dick’s Dive ‘n’ Thrive • Identifying Use Cases and Building the Use Case Diagram • Developing initial Scenarios and Initial Classes • Procedure for Building the Class Diagram • Finding Initial Problem Domain Classes • First Cut Scenarios of the Main Use Case • Refining Scenarios and Classes • Identifying Generalization/ Specialization Hierarchy

3. Chapter Objectives • Identifying Whole-Part Hierarchies • Identifying and Specifying Attributes • Identifying Additional Relationships • Second-Cut Scenarios • Identifying Methods • Identifying Time-Dependent Behavior • Moving on with the Development Process • Finalizing the Analysis Documentation

4. OO Analysis Process • OO analysis process involves four main activities: • Create the system definition • Decide the system main functionality through use cases • Build the class diagram, develop scenarios and corresponding sequence diagrams • Finalize the analysis documentation

5. System Definition • First create system definition • When system definition is agreed to, most important Use Cases are identified • Use cases provide a natural way of dividing the system into manageable units • The object is to identify what the system must do for the user to complete the required work tasks.

6. Further Steps in the Analysis Process • With several iterations two major activities are usually carried out parallel • Build a class diagram with the capability to satisfy the requirements • Develop scenarios through sequence diagrams • Final analysis documentation is then assembled and thoroughly reviewed with the end users of the system.

7. Dick’s Dive ‘n’ Thrive Case Study • DDT is a small business that rents diving equipment and boats • sells equipment and organizes diving trips • Hires a consulting firm to develop a system • Consultants suggests focusing initially on the rental operations only because that’s where the problems and opportunities are.

8. Identifying Use Cases • After the brainstorming session with Dick the consultants decided to determine the important or typical events. • The events translate into a list of use cases: • Rent equipment • Return equipment • Add new equipment • Discard equipment • Suspend equipment

9. Initial Use Case DiagramFig 9.1

10. Procedure for Building the Class Diagram • The steps for developing the class diagram are: • Identify problem domain classes • Identify generalization/specialization hierarchies and whole-part hierarchies to refine problem domain classes • Identify the important attributes • Identify additional association relationships • Identify custom methods of classes • Specify time-dependent behavior of objects

11. Initial problem domain classes • Customer can rent diving equipment and boats from DDT. When the customer has seen what is available and made a decision about what to rent, a rental agreement, or contract is produced and signed. Fig.9.2

12. First cut scenarios for the Main Use Case • At least 4 scenarios and 4 sequence diagrams are required to model the interactions involved: • Rent boat to existing customer • Rent boat to new customer • Rent diving equipment to existing customer • Rent diving equipment to new customer

13. First Scenario Event: Customer rents something • Use Case: Rent equipment • Scenario: Rent boat to existing customer • The user asks Contract to create a new Contract object. • Contract connects to the correct Customer object • Contract connects to the Boat object, and gets some information about the amount to charge for the rental. • Contract provides the contract details in whatever form the user might require.

14. Rent Boat to Existing CustomerFig 9.3

15. Rent Boat to New Customer • Scenario: Rent boat to new customer • The user asks Contract to create a new Contract object. • Contract knows it needs to create a new Customer object, so it asks Customer to create a new Customer object. • Customer needs information to create itself, so the new Customer object asks the user for name, address, and other information. • The user supplies the requested information, and then Customer supplies the information to Contract. • Contract connects to the Boat object, and gets some information about the amount to charge for the rental. • Contract provides the contract details in whatever form the user might require.

16. Rent Boat to New CustomerFig 9.4

17. Refining Scenarios and Classes • Diving Equipment and Boat, are both types of equipment that are rented. So consultants created a general class Rental Equipment. • Producing a generalization/specialization hierarchy. This is an example of the bottom-up approach

18. Refining Scenarios and Classes • Although specific attributes are not specified at this point, it is still necessary to think about needed attributes. • By thinking about the attributes that are relevant for only some of the objects, the developers recognized a need for a subclass named Diving suite. • This is an example of top-down approach. Fig 9.6

19. Generalization/Specialization Hierarchy:Customer • After a careful look the structure looked unstable to the consultants. • They realized diving related information could be contained in a class they called a Diving License. Similarly, boat related information could be related to Boat License. • The customer object would then be associated with Diving License object or Boat License Object or both. • These association are strong relationships in the sense that neither objects can exist without a corresponding customer object.

20. Multiple Inheritance HierarchyFig. 9.7

21. Generalization/Specialization • In the new approach acquiring a new customer would mean adding two objects (customer & Dive License or a customer and boat license) or adding three objects: a Customer, a Dive License, and a Boat License. Fig 9.8

22. Boat Assembly Whole-Part Hierarchies • At DDT some boats are rented with trailer, some without a motor, and some with one or two motors. • Trailer motors always stay with the same boat; they never rented by themselves. Fig 9.9

23. Contract Whole-Part Hierarchies • They focused on contract class and decided that a contract contains or includes many items for equipment. • Each contract is part of one contract, so they defined a whole-part hierarchy that contains a Contract and its Contract Items. Fig 9.10

24. Class Diagram Showing Initial Attributes Fig 9.11

25. Class diagram showing association relationships and customer methods

26. Second-Cut Scenarios • Event: Customer rents something • Use Case: Rent Equipment • Scenario: Rent boat assembly to existing customer • The user asks contract to create a new contract object for an existing customer, based on a customer ID. • Contract connects to the correct Customer object. • The Customer object asks its Boat License object for license details and returns all customer information to the Contract object. • Contract asks Contract Item to create a new object and to connect to the Contract. • Contract Item asks the user for the boar ID since it is a boat rental contract, which the user supplies. • Contract Item connects to the correct Boat Assembly and gets boat details, including the amount to charge for the rental ,which it returns to Contract. • Contract provides contract details to the user in whatever form the user might require.

27. Refined Sequence Diagram: Rent Boat Assembly to Existing Customer Fig 9.13

28. Rent boat assembly to new customer • Scenario: Rent boat assembly to new customer • The user asks Contract to create a new Contract object for a new customer. • Contract knows it needs to create a new Customer, so it asks Customer to create a new Customer object. • Customer needs information to create itself, so the new Customer object asks the user for name, address, and information about the boat license. • The user supplies the requested information ,the Customer object creates a new Boat License object, and then supplies all customer details to Contract.

29. Rent boat assembly to new customer • Contract asks Contract Item to create a new object and to create a new object and to connect to the Contract. • Contract Item asks the user for the boat ID since it is a boat rental contract, which the user supplies. • Contract Item connects to the correct Boat Assembly and gets boat details, including the amount to charge for the rental, which it returns to Contract. • Contract provides contract details to the user in whatever form the user might require.

30. Rent Boat Assembly to New Customer Fig 9.14

31. Identifying Time-Dependent Behavior • The object can be thought of as having a life cycle, a sequence of states the objects can go through in its lifetime. • At some time the object is created, it then goes through various stages, and finally it is deleted. Fig 9.15

32. Review Questions • What are the four activities of object-oriented analysis? • Which of the activities are done in parallel? • What are some ways to initially identify classes? • What is the role of use cases and scenarios when building the requirement model? • What is the relationship between a written scenario and a sequence diagram? • What is the difference between the top-down approach and the bottom up approach for identifying generalization/specialization hierarchies and whole-part hierarchies?

33. Review Questions 7. Explain why identifying a generalization/ specialization hierarchy requires identifying some attributes of the classes. • Explain how scenarios and sequence diagrams are used to find messages and methods that are required. • What graphical model documents time-dependent behavior? 10. What are the reasons for clustering classes and defining packages?

34. Discussion Questions • In the DDT case, the consultants knew very little about the equipment rental business when they began. At the end of the case, Dick mentioned that they seemed to understand very well what the system needed to do. To what extent, then, is the analysis process a learning process for the analyst? Is the object-oriented approach a more natural approach for the analyst to use to learn something?

35. Discussion Questions 2. An iterative, incremental approach to development is assumed in the DDT case. An important use case might be implemented as a prototype before addressing the requirements of additional use cases. To what extent is the class diagram relatively complete after developing just one use case in the DDT case? Why would an important use case involve most or even all of the problem domain classes of the system? 3. After completing the Rent equipment use case, what is the next use case you would choose to work on if you were running this project? Why? 

36. Exercises 1. Write descriptions for the two scenarios of the Rent equipment use case that were not shown in the text: “rent diving equipment to an existing dive customer” and “rent diving equipment to a new customer.” Create sequence diagrams to document the scenarios. 2. Consider whether a separate scenario should be written for the situation in which an existing boat customer wants to rent dive equipment for the first time. Write a description for the scenario and create a sequence diagram. 3. All objects go through a life cycle. Create a statechart for Customer encompassing each of following: the customer is added, is in good standing, has equipment, is in default, and is deleted, Create a statechart for Contract.

37. Exercises • What if Dick rented different types of boats, such as trailerable boats, motor boats, and row boats, each with different parts? Revise the class diagram to show this. • What if Dick had two different types of contracts, long-term rentals(leases)and short –term rentals. Revise the class diagram to show this. • Write a description of the scenario “add new diving equipment.” Create a sequence diagram to document the scenario. • What are some additional scenarios that might be included for the Add new equipment use case to handle all of the special situations? For ant one of the special situations, write a description of the scenario and create a sequence diagram.