OO Analysis Example: Online Bookstore

(see 1.4.2 of Object-Oriented Software Development Using Java)

An Informal Description
"The system is an online, web-based bookstore. The bookstore sells books, music CDs, and software. Typically, a customer first logs on to the system, entering a customer ID and password. The customer can then browse for titles or search by keyword. The customer puts some of the titles into a "shopping cart" which keeps track of the desired titles. When the customer is done shopping, he/she confirms the order, shipping address, and billing address. The bookstore system then issues a shipping order, bills the customer, and issues an electronic receipt. At the end of the transaction, the customer logs off."

A Scenario
A scenario is a very specific sequence of actions and responses that detail how the system will interact with a user. It is useful for pinpointing vague or missing requirements, and for verifying that the system does what's expected. A complete system would have several top-level scenarios, each showing a typical interaction with the system.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. User logs on. System displays welcome message and requests customer ID and password. User enters customer ID and password. System validates the ID and password. User searches for a title by browsing or keyword search System displays information about the title. User selects a title to buy System adds title to the customer's shopping cart [Repeat 5-8 until done] User is done with shopping System displays shopping cart, shipping address, and billing address User confirms order and payment method. System processes order, notifies warehouse for shipping, and issues an electronic receipt. User logs off.

In a real world system, the scenarios are the basis for the detailed requirements. You can walk clients through scenarios and see if the system behavior is what's desired. Typically scenarios change and expand over time.

System Diagram
This helps answer very high-level questions: What is part of the system, and what is not? What people interact with the system? What external systems will our system interact with?

people. . Book. OnLineBookstore. For generic relationships. Software. Reflect real world objects where that is useful. Draw relationships as lines between class boxes... places.(I drew the Warehouse System and Billing System with square heads to remind me that they're not actual people. Give them memorable names. A Customer has a name. they're just external systems. aggregation (has-a or owns-a). use an arrowhead to indicate whether . concepts. Annotate the relationships: How many OrderItems for each Order are possible? Use symbols to indicate the kind of relationship: Generic. and postalCode. events. Class Attributes Analyze the requirements to find the attributes of each class. password. country. inheritance (is-a). and billingAddress. etc. organizations.) Candidate Classes Look for important nouns: Objects. Note that some attributes may be references to other objects. city. Customer. Relationships Analyze the requirements to find relationships between classes. customerID. MusicCD. state. shippingAddress. An Address has a street. and create new ones as needed to help support the scenarios.

because most of the system doesn't care what precise kind of item we're talking about. the only behavior we look at is the display() method (below). it's usually a good idea to use inheritance. In this example. It may make sense to factor the common parts into a superclass. but we would also want methods like match() for searching and perhaps preview() for giving users a taste for the item. Class Diagram Draw the entire system on one page (hide details about classes if you run out of room. especially where one class depends on another. Be sure to include all important relationships. and display them on subsequent pages). If you want to let behavior vary between types of items. . Whether you should have actual subclasses for each specific kind of item is a design detail. Clearly preview() varies a lot between the different kinds of items.the relationship is navigable: Does the source object know about the destination object? After identifying candidate classes. and create an inheritance relationship: Item is a useful abstraction. see if there are any commonalities between them that might be an IS-A relationship.

which should remain the same no matter what kind of UI or data storage mechanism you choose.display(). This is actually deliberate. there are two critical pieces not shown on the diagram: UI and data storage (database). when clients call item. they're redundant.display(). (Inside Book. then returns to continue the subclass code.bill().) In thinking about how this system would work in the real world. they'll get the Book version if appropriate. The classes shown here form the "business logic" of the application.display().Note that the method names on the class diagram are very simple. it _has_ to name it the same thing: Book. Verify the design by going back and checking the system against the scenarios. so that each class is cohesive and there is no unnecessary coupling between .display().customerBill(). are all the scenarios supported by the system? Is all data owned by some class? Is it clear which class will be responsible for which actions? Are resonsibilities distributed sensibly among different classes. usually just a verb. This executes the superclass version of the method. customer.display(). There's usually no reason to have methods like item. For Book to override the superclass method. as with Item. You don't have to show everything on one diagram. That's because the class itself usually supplies the noun: item.display(). A special case arises when you want to extend a method of a superclass. you can do this with the special syntax "super.itemDisplay() or customer.display()". That way. it is usually advisable to start the method with a call to Item.

A one-to-many relationship usually needs some kind of collection of references. This can help distinguish member variables from local variables and method parameter names. you will probably need to write a high-level diagram to get a general architecture.classes? Code Now write the code corresponding to the class diagram. A many-to-many relationship is difficult and best avoided if possible. A one-to-one or many-to-one relationship is often most easily expressed with a simple object reference.java Customer. for example _shippingAddress. you may decide later on that you really just need a String to represent an address. so you don't need a separate Address class. In reality. Often it's easiest to let them be implied by the variables shown on the diagram. . for example _itemOrders. I like to name member variables starting with a leading underscore: _item. unless you need to be very precise. Examples: Customer. For example. There are other ways of doing this as well. The accessor methods aren't shown on the class diagram (although they could be). ShoppingCart.java. _address. Often these are just get/set pairs. then write code and refactor individual pieces as needed.java has some examples of methods that provide controlled access to the customer object's data. but not always.

Sign up to vote on this title
UsefulNot useful