Designing Object-Oriented Software Rebecca Wirfs-Brock rian Wilkerson Lauren Wienerlasses Where do objects come from? The first task in an object-oriented design is to {ind the classes that will compose it. This chapter provides a process you can use to start finding those classes. We provide a number of guidelines, tools, and examples to help you decompose your application into classes. We can also help you get started. inding Classes ‘How, then, do you start? You start with the requirements specification, of course, as itis the only input you have. If you don't have a specification of ‘what you are to design, write down a description of the goals of your design. Discuss the things your system should do: its expected inputs and desired responses. If you do have a specification, read and understand it before you begin. Your goal is to create classes of objects that will model the domain of your application. Items mentioned in the specification are likely to be part of that model38_DESIGNING OsjECT-OriENTED SOFTWARE Read through the requirements specification carefully again, this time looking for noun phrases. Change al plurals to singulars, and make a preliminary list, Ttis likely, looking over that list, that you will mentally divide the items onit into three categories: obvious classes, obvious nonsense, and phrases you are not sure about. It is usually safe to discard the obvious nonsense. From the other two categories, you can selectively glean candidate classes. Notall of these candidates will be classes in your final design, of course. Some will certainly be spurious. Other classes that will ultimately appear in your design will be overlooked by this process. Aer al language is « supple and flexible tool, and concepts can usually be stated in dozens of ways, 60 you will certainly need to apply judgment to the restilts of this procedure. Nevertheless, its a good way to get started, Choosing the classes in your system is the first step in defining the essence of your problem. If you can name an abstraction, or better yet, find one already appropriately named in the specification, you have found a candidate class. If you can formulate a statement of purpose for that candidate class, the chances are even higher it willbe included in your design. Emphasize the ‘important, and eliminate the irrelevant. Aside from this piece of common sense, what other criteria can you use to help decide which noun phrases are meaningful candidates for classes? Here are some guidelines for choosing candidate classes. ‘+ Model physical objects, such as disks or printers on the network. * Model conceptual entities that form a cohesive abstraction, stich as a window on a display, or a file. + l-more than one word is used for the same concept, choose the one that is ‘most meaningful in terms of the rest of the system. ‘This is part of building a common vocabulary for the team as a whole. Choose carefully; the word ‘you choose will color your view, and have a subtle impact on your evolving model. * Be wary of the use of adjectives. ives can be used in many ways. An adjective can suggest a different kind of object, a different use of the same object, or it could be utterly irrelevant. Does the object represented by the noun behave differently when the adjective is applied toit? If the use of the adjective signals that the behavior of the object is different, then make a new class. * Be wary of sentences in the passive voice, or those whose subjects are not Part of the system. Specifications are seldom as carefully written as this use of them warrants. Sentences written in the passive voice have implied subjects, although no noun phrase appears on the page. Recast theClasses 39 sentence in the active voice. Is it masking a subject that might be a class required by your application, or is it masking nothing of importance? Similarly, many sentences may already be in the active voice, but their subjects are things which are outside the system, for example, “the user.” Does the sentence suggest that an object may need to be modeled to act on behalf of the user? Model categories of classes. Such categories may ultimately become abstract superclasses, but at this stage model them as individual, specific lasses. After all, your design is still fluid; you will probably alter the taxonomy of classes later. Model known interfaces to the outside world, such as the user interface, or interfaces to other programs or the operating system, as fully as your initial understanding allows. These interfaces are likely to evolve more complex structure as your understanding deepens. Model the values of attributes of objects, but not the attributes themselves. For example, if you have a class called Line in your design, it is likely that thas an attribute called length, whose value is a unit of measure such as a floating point number. No class length needs to be modeled, but the class Float is required. The structure of the class Line will hold an instance of a Float, which it wil interpret as a length. No new “length” behavior needs to be added to the class Float just because the class has an application- specific use. ‘he result ofthis procedure is the first, tentative list ofthe classes in your vrogram. Some classes will be missing, others will be eliminated later. Your lesign will go through many stages on its way to completion, and you will ave ample opportunity to revise. ‘ertain generalizations can be made about such first approximations of lasses. They tend to be somewhat sparse, unless the designer is starting with ot of domain knowledge. You are probably missing more classes than you vill eliminate. Also, all parts of your application are probably not comparably detailed. You vill design richness and complexity into those parts of the application you inderstand best. If you don’t understand some subsystem within the pplication, you may realize it is complex without being able to decompose it. And you may not want to halt the process now to do the necessary research. “That's fine. Because subsystems are encapsulations, just as classes, you can reat a subsystem you don’t understand well as a black box. If you inderstand it well enough to specify its interface (an initial set of ‘esponsibilities), then you can design the rest of the application and return to40 DESIGNING OBJECT-ORIENTED SOFTWARE it later, or assign the design of the subsystem to someone who understands it better. In order to see these guidelines in action, we now present a small portion of a requirements specification. A more complete example is given later in this chapter, Drawing Editor Requirements Specification ‘The drawing editor is an interactive graphics editor. With it, users can create and edit drawings composed of lines, rectangles, ellipses, and text. ‘Tools control the mode of operation of the editor. Exactly one tool is active at any given time. ‘Two kinds of tools exist: the selection tool and creation tools. When the selection tool is active, existing drawing elements can be selected with the cursor. One or more drawing elements can be selected and nuaniipulated; if several drawing elements are selected, they can be manipulated as if they ‘were a single element. Elements that have been selected in this way are referred to as the current selection, ‘The current selection is indicated visually by displaying the control points for the element. Clicking on and dragging a control point modifies the element with which the control point is associated. ‘When a creation tool is active, the current selection is empty. The cursor changes in different ways according to the specific creation tool, and the user ‘can create an element of the selected kind. After the element is created, the selection tool is made active and the newly created element becomes the current selection. ‘The text creation tool changes the shape of the cursor to that of an Hbeam. ‘The position of the first character of text is determined by where the user licks the mouse button. The creation tool is no longer active when the user ‘dicks the mouse button outside the text element. The control points for a text clement are at the four comers of the region within which the text is formatted. Dragging the control points changes this region. ‘The other creation tools allow the creation of lines, rectangles, and ellipses. ‘They change the shape of the cursor to that of a crosshair. The appropriate element starts to be created when the mouse button is pressed, ancl is ‘completed when the mouse button is released. These two events create the start point and the stop point.Classes 41 ‘The line creation tool creates a line from the start point to the stop point. ‘These are the control points of aline. Dragging a control point changes the end point. ‘The rectangle creation tool creates a rectangle such that these points are diagonally opposite comers. These points and the other corners are the control points. Dragging a control point changes the associated corner. ‘The ellipse creation tool creates an ellipse fitting within the rectangle defined, by the two points described above. The major radius is one half the width of the rectangle, anu the minor radius is one half the height of the rectangle. The control points are at the corners of the bounding rectangle. Dragging a control point changes the associated corner. Drawing Editor Design: Finding Classes Although this is only a partial specification, itis quite rich. Let's start the design process by picking out the noun phrases. We will not immediately categorize them, though. Instead, for the purpose of teaching you the ‘process, we will start with all the noun phrases, and discuss our rationale for ‘keeping or discarding them one at a ime. drawing editor cursor stop point Ineractive graphics editor element ine creation toot user ‘current selection end point ‘rawing onto! point rectangle creation too! line {ext creation tool lagonally opposite corner rectangle shape ofthe cursor associated comer elipse beam ‘elipse creation tool text positon pont 100! ‘character major ractus made of operation ‘mouse button wih ofthe rectangle ‘editor text element rinor radius time ‘comer hight of Ue rectangle selection tool region bounding rectangle Creation too! crosshair ‘drawing element start point “This lis clearly contains quite a mix of items. Let's apply the principles discussed earlier to see what we get. Model physical objects. ‘The only physical object mentioned is the mouse button. Depending on the type of windowing environment for which this is being designed, the state of the mouse button will ikely be either an attribute of some device (such as a42_ DESIGNING OBJECT-ORIENTED SOFTWARE. ‘mouse) or an event. In neither case would we model the mouse button directly, Model conceptual entities. (On the other hand, it seems likely that such things as line, rectangle, ellipse and text will be useful classes to model for a drawing editor application that ‘manipulates them. Drawing seems like another likely conceptual entity, as does drawing element. Because text is composed of characters, we will also ‘want to model them, Similarly, the user interface object tool seems like a good candidate. Tools come in several flavors, it seems. We have selection tool, creation tool, and. four different kinds of creation tool. Let’s decide to create classes to model Selection Tool, Text Creation Tool, Line Creation Tool, Rectangle Creation Tool, and Ellipse Creation Tool. We will return to the other candidates when ‘we discuss categories. ‘The phrase current selection is found in the specification as well. Tt seems to be a reasonable candidate for a class, since the user must manipulate it, and it is indicated by displaying control points. For the time being, let's keep it in ‘our list of potential classes. Other possibilities for conceptual entities are less clear. We have point, start point, stop point, end point, corner (of various kinds), and major and minor radius, height and wiath of rectangle, and a bounding rectangle. Are these useful classes or not? Let’s apply further principles. ‘Choose one word for one concept. ‘Are there any entries in the above list which seem to repeat ideas previously encountered? Well, right at the top we have the two items drawing editor and interactive graphics editor, followed farther on by editor, More than one concept is certainly not meant here; the second is apparently intended to be an amplification of the first, and the third an abbreviation. Let's strike out interactive graphics editor and editor, then, and refer to the application as a Drawing Editor. We also have drawing element and element, both of which refer to the same concept. Drawing Element is a more descriptive name for entities in a ‘drawing than element. Let's refer to an entity in a drawing as a Drawing Element and remove element. Another possibility are the two entries text and text element. Are these really two separate ideas? Remember that we have the concept of drawing elementClasses 43 above, Is text merely a kind of drawing element, as implied by the words text element? As it is used in the specification, yes. Let's eliminate text in favor of the more descriptive phrase text element, remembering that we can always go back and reconsider any decision that makes us uncomfortable. Let's similarly append the word element to line, rectangle, and ellipse for the same reason. ye wary of adjectives. ‘We have a lot of adjective-noun phrases in the list above. How many of these actually signal a different kind of object? Is selection tool a different kind of tool than creation tool? Is a line creation tool a different kind of tool than a rectangle creation tool? The key to answering this question is whether the classes behave differently. To answer this question, return to the requirements, which state that selection tool selects already extant drawing elements, while creation tools create new ones. Furthermore, a line creation tool creates lines, while a rectangle creation tool creates rectangles. By this measure, then, these, as well as text creation tool, rectangle creation tool, and ellipse creation tool, seem to be different classes. We have the phrases rectangle and bounding rectangle in the requirements. ‘The word rectangle is used in two distinct ways, one of which is equivalent to the way bounding rectangle is used. The word rectangle is most frequently used to refer to a visible element of the drawing: a Rectangle Element. Itis sometimes used, though, to refer to a rectangular region in the coordinate space of the drawing, Both bounding rectangle and region are used in this ‘way as well. Rectangular regions are used to determine the size and location of Elipse Elements and during the composition of text. We will therefore need a class Rectangle to represent such regions, Similarly, we have the noun point and four phrases with point in them: start point, stop point, end point, and control point. It seems clear that we need a class to model points, as the application uses them in a number of ways. We will, naturally, call this class Point. However, it seems unlikely that start points will have any different behavior from stop points ot end points, 50 separate classes are not needed to model them. How about control points, though? Start points, stop points and end points are coordinates; control points, in addition to being coordinates, are visually displayed to indicate the selected element. They do, indeed, add behavior to the system—that of selecting an attribute of the drawing element to be altered. Control Point therefore seems an excellent candidate class.44 DESIGNING OBJECT-ORIENTED SOFTWARE The list of noun phrases also includes commer, diagonally opposite corner and associated corner. Do we need objects to model comers? What is the diagonally opposite comer opposite to? The other corner—the relationship is reciprocal: every comer is diagonally opposite to some other. This seems a ‘Poor choice for a new class, then; it adds no new behavior to the system. ‘Similarly, what is associated comer associated with? It is associated with a control point. How corners and control points know about each other is another question we have not yet answered. Without answering it now, though, we can safely say that the word “associated” describes a relationship between a control point and a corner that adds no behavior to the system not already captured by the idea of corners. ‘We will return to the question of comers in a moment when we discuss modeling attributes. Be wary of sentences with missing or misleading subjects. ‘The specification includes a lot of sentences in the passive voice. Many of these do not present problems, as the missing information can be located in previous sentences. One, however, has the potential to imply new information. “The current selection is indicated visually by displaying the control points forthe element.” What is missing from this sentence is the answer to the question: ‘Who is responsible for these visual indications? Who is doing the displaying? Isit the window in which this is presumably all occurring? Is the current selection itself displaying its own control points? Is the drawing displaying the control points for one of its elements? Or is some global controlling or ‘managing object keeping track of the current selection, and displaying the control points? Are several of these objects collaborating to achieve this effect? Although itis far from clear at this stage, let's assume it is being done by the Drawing Editor, and that we do not need to create a new class. A number of these sentences presume that the user is the subject, or state so explicitly. For example, the specification includes the following: “..the user can create an element ofthe selected kind.” "The creation tool classes discussed. above can be seen as stand-ins for the user in this regard. Model categories. Earlier, we mentioned that we seem to have two different kinds of tools: selection and creation tools. The phrases tool and creation tool refer to categories of classes, Categories of classes can be deeply significant; a laterClasses 45 section, entitled Finding Abstract Classes, focuses entirely upon them. We shall therefore decide to create classes to model these categories, naming them Tool and Creation Tool. Model interfaces to the system. The list of noun phrases includes a few possibilities that seem outside the system. We probably do not need to model a user, for example, although we must certainly create a user interface, Another possibility is the cursor. Presumably, this application runs on a system using a mouse, and the operating system handles cursor motion automatically. In this case, there is no need to model the cursor. Model values of attributes, not attributes themselves. ‘The list of noun phrases includes the suspicious phrases height of the roctanglo, and width of the roctanglo. Height and width are clearly attributes of rectangles; their values are numbers which may change, but their behavior does not change in any way. Maintaining the values for each rectangle's height and width can clearly be the responsibility of rectangles themselves; assuming that various classes of numbers already exist, a new class for these attributes seems to add nothing to the system. ‘The phrases major radius and minor radius occurred in regard to ellipses, and appear to have a similar relationship to them. We can safely discard them as well. ‘The noun position also occurs in the list. Looking back to the specification, we discover that what is referred to is the position of the first character of text. ‘The phrasing makes it clear that the position is an attribute of the text (or perhaps of the individual character). Presumably the value of this attributes is an instance of the class Point. We can therefore safely eliminate position as a candidate class. Similarly, the mode of operation is an attribute of the drawing editor. The shape of the cursor is an attribute of the cursor whose value can be (among, others) a crosshair and an -beam. Corners are an attribute of a rectangle. We will not model any of these for now. ‘The process of distinguishing the values of attributes from the attributes themselves is not always so easy, though. Language can be quite misleading, and sometimes the same word is used for both the attribute and its value. For ‘example, the length (attribute) of a Line is likely to be a Float (value), but the46 DESIGNING OWECT-ORIENTED SOFTWARE. calor attribute) of a Line is likely to be a Color (walue). Bear this in mind as you seek to determine the classes required in your system. ‘Summary of Classes i A preliminary analysis, then, yields the following candidate classes. You can see that we have winnowed the list considerably. These candidates are still preliminary, and doubtless other classes will evidence themselves when we begin designing the system in more detail. For now, though, this is what we have: Character Elipse Creation Too! Rectangle Element Conitol Point Etipse Element ‘Selection Tool Greation Toot Line Creation Too! ‘Text Creation Tool Gurrent Selection Line Element ‘Text Elomont Drawing Point Tool Drawing Ecltor Rectangle Drawing Element Rectangle Creation Toot Record Your Candidate Classes ‘When you have identified candidate classes, write their names down on index cards, one class per card, as shown in Figure 3-1. ‘On the back of the card, you should write a short description of the overall : purpose of the class. Such a statement can help you clarify your motivation for creating this class, and can serve as the kernel of the class documentation later. Class: Drawing ! Figure 31: A Class CardClasses 47 ‘We have found that index cards work well because they are compact, easy to manipulate, and easy to modify or discard. Because you didn’t make them, they don’t feel valuable to you. If the class turns out to be spurious, you can toss the card aside with few regrets. Because they are small, and not on the computer display, you can easily arrange them on a tabletop and view many of them (perhaps all of them) at the same time. You can pick them up, reorganize them, and lay them out in a new arrangement to amplify a fresh insight, You can leave blank spots on the table to represent missing classes. If you discover you have erroneously discarded a class card, itis simple to retrieve it, or make a new one. Itis pointless to insist on cards, however. If you work best with 8 1/2" by 11” sheets of blank white paper, or yellow legal pads, or graph paper, by all ‘means use what works. If you wish to enter your work into a computer, then do so. But at this stage, exploring the possibilities of a variety of models should be easy and fun, and can uncover hidden problems at an early, cost- effective stage. The tool you use should enhance, not hinder, the design process. Finding Abstract Classes ‘Armed with a decent list of candidate classes for an application, you must now switch mind sets slightly. Let's re-examine our list in order to identify as many abstract classes as possible. Identify these classes in order to help identify the structure of the software (they will become superclasses of other, concrete, classes), and to help identify classes you have overlooked, An abstract class springs from a set of classes that share a useful attribute. A useful attribute is one that implies a shared behavior for classes having that attribute. If behavior is shared by several classes, you should design an abstract superclass to capture that shared behavior in one place. Subclasses can then inherit that behavior. The goal isto find as many abstract superclasses as possible. Look for common attributes in classes, as described by the requirements. You can edit your list ifit seems that some attributes do not, afterall, imply shared behavior. Group Classes Identify candidates for abstract superclasses by grouping related classes. A class can appear in more than one group.48_ DESIGNING OBJECT-ORIENTED SOFTWARE ‘When you have identified one group, name the superclass that you feel it represents. Make the name a singular noun or noun phrase. For example, suppose that you have identified a group whose elements are: Display Soreen oe Mouse Its shared attribute is that all the classes are interfaces to physical devices. ‘You might therefore name this group Physical Device. ‘Some of these groups may have already been identified for you. The categories of classes we identified earlier will usually represent just such a group. Most classes created to represent categories will therefore be abstract superclasses of the classes in the category. For example, our drawing editor specification named two categories: Tool and Creation Tool. The category of creation tools contains the classes: Line Creation Too! Roctsngio ereation Toot Ellipse Creation Tool ‘Tot Creation Toot ‘These classes share the ability to create drawing elements. The Tool category contains the classes Selection Tool and Creation Tool. The hierarchy for these classes is shown in Figure 3-2 Tool Selection | | Creation Ee Ellipse Line | [Rectangle] [Text 2] 2 ies Figure 3-2: The Tool Hierarchy Record Superclasses ‘When superclasses have been identified, record them on index cards, one ‘lass per card. Also write its subclasses on the lines below the name. Go backClasses 49 to all your class cards, and record their superclasses and subclasses, if any are known, on the lines below their names. ‘The class cards will now look as shown in Figure 3-3. Ellipse Tool, Line Tool, Rectangle Tool, Text Tool Figure 3-3: Class Card with Superclass and Subclasses If you are having trouble naming a group you have identified: ‘+ enumerate the attributes shared by the elements ot the category, and derive the name from those attributes, or © divide the elements into smaller, more clearly defined categories. If you still cannot name it, discard the group and search for others. For example, suppose you have identified a group with the following elements, which you are having trouble naming: Display Soreen Prnier SCSI Cable Floppy Disk S232 Pon Mouse ‘This lst fails to distinguish between devices and other types of hardware, possibly because you do not fully understand the system of which these devices are a part. For example, you could recategorize it into two different ‘groups as shown below. The category Physical Device could include: Display Screen Printer Floppy Disk Mouse ‘The category Hardware could include: ‘sosi cable S-292 Port50_DESIGNING OBECT-ORIENTED SOFTWARE However, pethaps both the mouse and the printer will be attached through RS-232 ports. In that case, a more appropriate recategorization might call for a category named RS-232 Devices that would include: Printer Mouse Difficulty in categorizing classes can often be solved by clarifying the relationships represented by these classes. Examples of Attributes Identifying attributes in this manner encourages you to form useful patterns of shared behavior with your classes, laying the groundwork for a fruitful use of inheritance and code reusability. Many useful attributes are application- specific. Some common attributes by which classes can be grouped are: Physical vs. conceptual: Display Screen, Windowing Transformation ‘+ Active vs. passive: Producer, Product ‘+ Temporary vs. permanent: Event, Event Queue ‘+ Genetic vs. specific: List, Event List ‘+ Shared vs, unshared: Print Queue, Login Name Discard attributes if they do not help distinguish between classes. Identifying Missing Classes ‘Once you have identified them, extending categories can be a useful way to identify missing classes. (Classes can be missing because they are not important, or because the specification was imprecise. For example, the Drawing Editor is missing an important class because the specification was not explicit. ‘The specification states that drawings can be edited. This implies that drawing elements may be modified, added, and removed from a drawing, ‘The user may wish to change his mind and undo an editing operation, or may wish to place a temporarily removed drawing element at another location in the drawing. This ability to remove and place drawing elements implies the ‘existence of a cut buffer. Just as we did with current selection, it seems useful to model a cut buffer by creating the new class Cut Bulfer. Finding missing classes is not easy. The more experienced a designer is, the easier it will be. To allow you to gain some experience immediately, we now present an example specification for an automated teller machine. Read theClasses 51 specification presented below, and exercise the principles you have learned in this chapter to find the classes of objects you would need fo model the system specified. Automated Teller Machine Requirements Specification ‘An automated teller machine (ATM) is a machine through which bank ‘customers can perform a number of the most common financial transactions. ‘The machine consists of a display screen, a bank card reader, numeric and special input keys, a money dispenser slot, a deposit slot and a receipt printer. ‘These elements are arranged as shown in Figure 3-4, ‘Special Normal Keypad TA AE Keypad Ee a=] i oe & & — Cancel Printer ‘Cash Dispenser St ——— Bank Card Reader Deposit Drawer Figure 3-4: The ATM Machine ‘When the machine is idle, a greeting message is displayed. The keys and deposit slot will remain inactive until a bank card has been entered. When a bank card is inserted, the card reader attempts to read it. Ifthe card cannot be read, the user is informed that the card is unreadable, and the card isejected. If the card is readable, the user is asked to enter a personal identification number (PIN). The user is given feedback as to the number of digits entered52_DBSIGNING OBJECT-ORIENTED SOFTWARE. at the numeric keypad, but not the specific digits entered. If the PIN is, entered correctly, the user is shown the main menu (described below). Otherwise, the user is given up to two additional chances to enter the PIN correctly. Failure to do so on the third try causes the machine to keep the bank card. The user can retrieve the card only by dealing directly with an authorized bank employee. ‘The main menu contains a list of the transactions that can be performed. ‘These transactions are: ‘+ deposit funds to an account, ‘+ withdraw funds from an account, ‘+ transfer funds from one account to another, and + query the balance of any account. ‘The user can select a transaction and specify all relevant information. When a transaction has been completed, the system returns to the main menu. ‘Atany time after reaching the main menu and before finishing a transaction (including before selecting a transaction), the user may press the cancel key. ‘The transaction being specified (if there is one) is canceled, the user’s card is returned, the receipt of all transactions is printed, and the machine once again becomes idle. Ifa deposit transaction is selected, the user is asked to specify the account to which the funds are to be deposited and the amount of the deposit, and is asked to insert a deposit envelope. fa withdrawal transaction is selected, the user is asked to specify the account from which funds are to be withdrawn and the amount of the withdrawal. If the account contains sufficient funds, the funds are given to the user through the cash dispenser. Ifa transfer of funds is selected, the user is asked to specify the account from which the funds are to be withdrawn, the account to which the funds are to bbe deposited, and the amount of the transfer. Tf sufficient funds exist, the transfer is made. Ifa balance inquiry is selected, the user is asked to specify the account whose balance is requested. The balance is not displayed, but is printed on the receipt.