chapter 9 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter - 9 PowerPoint Presentation
Download Presentation
Chapter - 9

Loading in 2 Seconds...

play fullscreen
1 / 37

Chapter - 9 - PowerPoint PPT Presentation


  • 326 Views
  • Uploaded on

Chapter - 9 An Object-Oriented Analysis Case Study of Dick’s Dive ‘n’ Thrive 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter - 9' - Audrey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 9

Chapter - 9

An Object-Oriented Analysis Case Study of

Dick’s Dive ‘n’ Thrive

chapter objectives
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
chapter objectives3
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
oo analysis process
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
system definition
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.
further steps in the analysis process
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.
dick s dive n thrive case study
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.
identifying use cases
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
procedure for building the class diagram
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
initial problem domain classes
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
first cut scenarios for the main use case
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
first scenario
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.
rent boat to new customer
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.
refining scenarios and classes
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
refining scenarios and classes18
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
generalization specialization hierarchy customer
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.
generalization specialization
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
boat assembly whole part hierarchies
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
contract whole part hierarchies
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
second cut scenarios
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.
rent boat assembly to new customer
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.
rent boat assembly to new customer29
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.
identifying time dependent behavior
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
review questions
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?
review questions33
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?

discussion questions
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?
discussion questions35
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? 

exercises
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.

exercises37
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.