Once you have a problem summary paragraph, you’re ready to identify the classes and the services they provide. This is really quite easy.
First, activate the transporter. Second, put the problem statement on the transporter pad, slide the lever to the Activate position, and watch as the problem summary paragraph breaks into its component molecules.
Okay, unless you have a transporter, it isn’t quite so simple—but, it’s almost that easy.
Here’s what you do:
1. Underline the action phrases (verb phrases) that appear in the problem summary paragraph.
2. Draw a box around the phrases (noun phrases) that denote actors and objects of action that appear in the problem summary paragraph.
3. Study the actors that you circled in step 2, determining which of them should be represented as classes.
4. Study the actions that you underlined in step 1, deciding which of them are services provided by a class.
5. Record your findings as one or more CRC cards.
To get you started, Figure 3.3 shows the problem summary paragraph for the Kvetch System, with the actions and actors indicated. Next, you learn how to identify the classes.
Figure 3.3: The problem summary paragraph discloses candidate classes and services.
Identifying Classes
To identify the classes, make a list of the problem summary paragraph phrases you circled. Table 3.1 shows such a table for the Kvetch System. Notice how synonyms (entries that mean the same thing, although they’re expressed differently) have been removed. For example, Kvetch System and the system refer to the same thing, so only Kvetch System (the more specific phrase) appears in the table.
TABLE 3.1 CANDIDATE CLASSES OF THE KVETCH SYSTEM
Candidate Class
amount client
client’s requirements
complaint
complaint database
electronic fund transfer
Kvetch System
price
Web browser
Web site
Now, further winnow the list by casting out these entries:
• Entries that do not need to be represented as objects or classes within the system
• Entries that represent attributes or characteristics of other entries
Admittedly, this task is tough. You don’t really know at this point which entries need to be represented as classes. That’s why OOA/OOD is iterative. You probably will make some mistakes at this point, but, as you proceed, your errors will become evident. When that happens, backtrack to this point, add the missing class or delete the unneeded class, and retrace your forward progress.
Perhaps the biggest difference between experienced analysts and inexperienced
analysts is the number of false starts: Experienced analysts experience more false starts than inexperienced analysts, who tend to lock onto their early impressions, refusing to reconsider them even in the light of further information. Don’t hesitate to backtrack:
Backtracking is essential to quality work.
Table 3.2 shows the candidate classes of the Kvetch System after the winnowing cycle.
TABLE 3.2 CANDIDATE CLASSES OF THE KVETCH SYSTEM
Candidate Class
client
client’s requirements
complaint
complaint database
electronic fund transfer
The following candidates were discarded for the reasons given:
• Amount—It’s really an attribute of the electronic fund transfer.
• Kvetch System—The system doesn’t need to represent itself.
• Price—It’s really an attribute of complaint selected by the system.
• Web browser—It’s merely the means used by the client to access the system.
• Web site—It turns out to be roughly synonymous with the system.
Now that you’ve identified the classes, move on to identify the services they provide.
Identifying Services
You saw that the circled actors and objects (noun phrases) in the problem summary paragraph help you identify classes. The underlined actions (verb phrases) help you identify services. You may not be familiar with the term services, even if you know something about objects. Sometimes they’re referred to as behaviors, methods, or responsibilities.
Among these alternatives, the term services is particularly apt because it places the emphasis on actions performed by an object on behalf of other objects. In addition to such public actions, most objects also have private actions, which do not concern us at this point. We prefer services because it emphasizes exactly those behaviors and methods that we seek.
A reason for preferring the term services over the term responsibilities, which also emphasizes public actions, is that services recalls the popular term client-server. The fundamental paradigm of client-server system is client objects requesting services of server objects, exactly the thing we seek to find mentioned in the problem summary paragraph. Table 3.3 shows the candidate services, which are the underlined phrases in the problem summary paragraph.
TABLE 3.3 CANDIDATE SERVICES OF THE KVETCH SYSTEM
Candidate Service
accept accesses authorizes
decline
describe enables matches modified proposes required responds saved selects transmitting
using
Just as the list of candidate classes was winnowed, so now the list of candidate services is winnowed. Table 3.4 shows the winnowed list.
TABLE 3.4 REMAINING CANDIDATE SERVICES OF THE KVETCH SYSTEM
Candidate Service
authorizes
decline describe matches proposes selects transmitting
Here are the reasons entries were deleted:
• Accesses and using—The phrase accesses Kvetch Net’s Web site using a standard Web browser constrains the technology that is used to access the system, rather than specifying a requirement of the system.
• Accept—It can be treated as synonymous with authorizes.
• Enables—It describes a non-specific action of the entire system.
• Modified and saved—They specify actions of the client that do not concern the system.
• Required—It specifies the needs of the client rather than the actions of the client or system.
• Responds—It can be treated as synonymous with transmitting.
In all, about half of the candidate services were eliminated. This is good news because fewer services points to smaller classes that are more quickly and easily implemented.
Let’s move on to a discussion of CRC cards, which helps you pair classes with related services.
Using CRC Cards
Class-Responsibility-Collaboration (CRC) cards are one of the most useful tools during OOA/OOD. A CRC card is nothing more than an index card (for example, a 3⋅5 card) that records information about a class, including
• The name of the class
• A brief description of what the class represents
• The services provided by the class
• A list of class attributes
If you like, you can begin using CRC cards at the outset, rather than building lists of candidate classes and services. However, it’s often easier to identify services and then match them with classes. Making lists first can make things go more smoothly.
Figure 3.4 shows a CRC card for the Kvetch System’s complaint database. Notice that the class name and the names of services have been styled as Java identifiers; this makes it easier to code the class in Java.
Figure 3.4: A CRC card presents key information about a class.
Notice that the back of the CRC card includes a list of attributes. Attributes hold the characteristics of objects. For example, a simple Ball object might have attributes reflecting its color, diameter, weight, and rebound factor.
You may wonder how attributes are identified because you’ve seen no list of candidate attributes for the Kvetch System.
Attributes are seldom disclosed by the problem summary paragraph. Two attributes of the ComplaintDatabase class, price and complaint, appeared there. The remaining attributes, circumstance (is this a complaint about food or a complaint about rent?) and tone (should the complaint be calm or abusive?), are implicit in the phrase matches the client’s requirements in the problem summary paragraph.
Perhaps a more complete problem summary paragraph would have mentioned them, but no problem summary paragraph is likely to mention all the attributes. That’s another reason OOA/OOD is an iterative process. Recall the Lewis and Clark expedition that found a land route across the American territories to the Pacific coast. Despite the help of Indian guide Sacagawea, they merely found a route, not the best route. Don’t expect to do better on your own first trip through a system.
You may also be wondering how the selectComplaint service shown on the CRC card came to be there, rather than on the CRC card of some other class. Determinations such as this involve a combination of problem insight, technical expertise, careful reflection, and luck. The essential function of the ComplaintDatabase class is to provide a complaint that matches the user’s requirements. Therefore, the
selectComplaint service is implicit in the essence of the class.
This is a good time for you to try your hand at making some CRC cards. Select one of the remaining candidate classes and make its CRC card. Do your best to identify the related services and attributes. You may discover a need for services that do not appear in the list of candidates: Feel free to add these. Similarly, feel free to disregard any listed services that don’t seem to actually be needed. The same is true of classes: Add or delete classes as you see fit.