4.3. The Initial Design

 <  Day Day Up  >  

Everyone has their own way of coming up with an initial set of classes. You can start with the basic abstractions that were described during analysis. Some people examine the requirements or use cases for nouns, and turn those nouns into either classes or attributes of classes. Verbs that occur can be turned into responsibilities or methods of the classes. One ambiguity that exists in using grammatical syntax to discover objects is that an operation might be expressed as either a noun or a verb. The requirements might talk about a customer renting a CD or starting a CD rental.

Tim and I use a variation of CRC cards (see Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock and Alan McKean [Addison-Wesley Professional, 2002]) to formulate a starting set of classes. [*] CRC stands for Class-Responsibility-Collaboration . On an index card, you list the class name , the responsibilities assigned to the class, and the other classes that it collaborates with to fulfill those responsibilities. Tim and I also jot a one-line description of each class on the card. Often we also capture potential attributes or other information that might have been referred to in the use cases or client discussions. Figure 4-2 depicts the CRC cards for Sam's CD rental system.

[*] See also http://c2.com/doc/oopsla89/paper.html.

Figure 4-2. CRC cards for Sam's CD rental system

Tim and I often code class interfaces directly from the CRC cards. But since our handwriting can be unreadable to others, this book contains machine-written UML diagrams of our classes. UML diagrams are more formal than CRC cards and usually contain more precise declarations of the names of the methods and their parameters. Figure 4-3 shows the corresponding UML diagram for the class structure for Sam's system.

Figure 4-3. Class structure for Sam's CD rental system

Once Tim and I have agreed on the classes and their responsibilities, we create more detail regarding each class. The details show more specific information than the CRC cards. The following code shows the specifics for the classes illustrated in Figure 4-3. Note that the abstract data types (ADTs) specify meaningful types without addressing a specific design or implementation.

 CDRelease /* A CD identified by its UPC*/         CommonString title         UPCCode upc_code          CDDisc /* Physical copy of a CDRelease */         PhysicalID physical_id         CDRelease cd_release         static CDDisc find_cd_disc_by_id(PhysicalID physical_id)         rent(Customer customer)         return_a_rental()           Customer         CustomerID id         Name name         Address address         PhoneNumber day_phone_number         static Customer find_customer_by_id(CustomerID id) 


Note: static is a keyword that denotes a classwide method. A classwide method does not operate on an object. It is typically used to return objects of a class.

Along with the class diagram, we write sequence diagrams or pseudocode listings to demonstrate that the proposed classes have sufficient behavior to implement the use cases. We could create these documents for all the use cases. However, Sam is anxious to get a working system (the MFS). So we write down the complete details for only the first two use cases:



Checkout_a_CDDisc

Enter customer_id and cd_disc_id from keyboard or barcode scan:

CDDisc cddisc_rented = CDDisc.find_cd_disc_by_id(cd_disc_id);

Customer renting_customer = Customer.find_customer_by_id(customer_id)

cddisc_rented.rent(renting_customer); // Prints contract



Checkin_a_CDDisc

Enter cd_disc_id :

CDDisc cddisc_rented = CDDisc.find_cd_disc_by_id(cd_disc_id);

cd_disc_rented.return_a_rental() // If overdue, print message

Before we move on, we need to get a little more information from Sam. I noticed that we never discussed "overdue." Since that concept is mentioned at this high-level description, it seems like an important detail.

I gave him a call.

"Sam, how do I know if a CDDisc is overdue?" I asked.

"Well, we allow the customer a base period. If the CD comes back after that period, we charge him a late fee," he replied.

This is an example of the feedback that occurs between the design and analysis phases. Often the complete understanding of a concept does not occur until someone tries to use the concept.

 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net