720 HOW TO FIND THE CLASSES $22.1 22.1 STUDYING A REQUIREMENTS DOCUMENT To understand the problem of finding classes,it may be best to begin by assessing a widely publicized approach. The nouns and the verbs A number of publications suggest using a simple rule for obtaining the classes:start from See the biblio- the requirements document(assuming there is one,of course,but that is another story);in graphical notes. function-oriented design you would concentrate on the verbs,which correspond to actions ("do this");in object-oriented design you underline the nouns,which describe objects.So according to this view a sentence of the form The elevator will close its door before it moves to another floor. would lead the function-oriented designer to detect the need for a"move"function;but as an object-oriented designer you should see in it three object types,ELEVATOR,DOOR and FLOOR,which will give classes.Voila! Would it that life were that simple.You would bring your requirements documents home at night,and play Object Pursuit around the dinner table.A good way to keep the children away from the TV set,and make them revise their grammar lessons while they help Mom and Dad in their software engineering work. But such a simple-minded technique cannot take us very far.Human language,used to express system requirements,is so open to nuance,personal variation and ambiguity that it is dangerous to make any important decision on the basis of a document which may be influenced as much by the author's individual style as by the actual properties of the projected software system. Any useful result that the "underline the nouns"method would give us is obvious anyway.Any decent O-0 design for an elevator control system will include an ELEVATOR class.Obtaining such classes is not the difficult part.To repeat an expression used in an earlier discussion,they are here for the picking.For the non-obvious classes a syntactic criterion-such as nouns versus verbs in a document that is by essence open to many possible stylistic variants-is close to useless. Although by itself the "underline the nouns"idea would not deserve much more consideration,we can use it further,not for its own sake but as a foil;by understanding its limitations we can gain insights into what it truly takes to find the classes and how the requirements document can help us in this endeavor. Avoiding useless classes The nouns of a requirements document will cover some classes of the final design,but will also include many "false alarms":concepts that should not yield classes. In the elevator example door was a noun.Do we need a class DOOR?Maybe,maybe not.It is possible that the only relevant property of elevator doors for this system is that720 HOW TO FIND THE CLASSES §22.1 22.1 STUDYING A REQUIREMENTS DOCUMENT To understand the problem of finding classes, it may be best to begin by assessing a widely publicized approach. The nouns and the verbs A number of publications suggest using a simple rule for obtaining the classes: start from the requirements document (assuming there is one, of course, but that is another story); in function-oriented design you would concentrate on the verbs, which correspond to actions (“do this”); in object-oriented design you underline the nouns, which describe objects. So according to this view a sentence of the form The elevator will close its door before it moves to another floor. would lead the function-oriented designer to detect the need for a “move” function; but as an object-oriented designer you should see in it three object types, ELEVATOR, DOOR and FLOOR, which will give classes. Voilà! Would it that life were that simple. You would bring your requirements documents home at night, and play Object Pursuit around the dinner table. A good way to keep the children away from the TV set, and make them revise their grammar lessons while they help Mom and Dad in their software engineering work. But such a simple-minded technique cannot take us very far. Human language, used to express system requirements, is so open to nuance, personal variation and ambiguity that it is dangerous to make any important decision on the basis of a document which may be influenced as much by the author’s individual style as by the actual properties of the projected software system. Any useful result that the “underline the nouns” method would give us is obvious anyway. Any decent O-O design for an elevator control system will include an ELEVATOR class. Obtaining such classes is not the difficult part. To repeat an expression used in an earlier discussion, they are here for the picking. For the non-obvious classes a syntactic criterion — such as nouns versus verbs in a document that is by essence open to many possible stylistic variants — is close to useless. Although by itself the “underline the nouns” idea would not deserve much more consideration, we can use it further, not for its own sake but as a foil; by understanding its limitations we can gain insights into what it truly takes to find the classes and how the requirements document can help us in this endeavor. Avoiding useless classes The nouns of a requirements document will cover some classes of the final design, but will also include many “false alarms”: concepts that should not yield classes. In the elevator example door was a noun. Do we need a class DOOR? Maybe, maybe not. It is possible that the only relevant property of elevator doors for this system is that See the biblio￾graphical notes