22 Iow to find the classes oremost among the goals of object-oriented methodology,since the structure of O-O software is based on decomposition into classes,is that it should give us some advice on how to find these classes.Such is the purpose of the following pages.(In some of the literature you will see the problem referred to as"finding the objects",but by now we know better:what is at stake in our software architectures is not individual objects,but object types-classes. At first we should not expect too much.Finding classes is the central decision in building an object-oriented software system;as in any creative discipline,making such decisions right takes talent and experience,not to mention luck.Expecting to obtain infallible recipes for finding the classes is as unrealistic as would be,for an aspiring mathematician,expecting to obtain recipes for inventing interesting theories and proving their theorems.Although both activities-software construction and theory construction -can benefit from general advice and the example of successful predecessors,both also require creativity of the kind that cannot fully be covered by mechanical rules.If(like many people in the industry)you still find it hard to compare the software developer to a mathematician,just think of other forms of engineering design:although it is possible to provide basic guidelines,no teachable step-by-step rules can guarantee good design of buildings or airplanes. In software too,no book advice can replace your know-how and ingenuity.The principal role of a methodological discussion is to indicate some good ideas,draw your attention to some illuminating precedents,and alert you to some known pitfalls. This would be true with any other software design method.In the case of object technology,the observation is tempered by some good news,coming to us in the form of reuse.Because much of the necessary invention may already have been done,you can build on others'accomplishments. There is more good news.By starting with humble expectations but studying carefully what works and also what does not,we will be able,little by little and against all odds,to devise what in the end deserves to be called a method for finding the classes.One of the key steps will be the realization that,as always in design,a selection technique is defined by two components:what to consider,and what to reject
22 How to find the classes Foremost among the goals of object-oriented methodology, since the structure of O-O software is based on decomposition into classes, is that it should give us some advice on how to find these classes. Such is the purpose of the following pages. (In some of the literature you will see the problem referred to as “finding the objects”, but by now we know better: what is at stake in our software architectures is not individual objects, but object types — classes.) At first we should not expect too much. Finding classes is the central decision in building an object-oriented software system; as in any creative discipline, making such decisions right takes talent and experience, not to mention luck. Expecting to obtain infallible recipes for finding the classes is as unrealistic as would be, for an aspiring mathematician, expecting to obtain recipes for inventing interesting theories and proving their theorems. Although both activities — software construction and theory construction — can benefit from general advice and the example of successful predecessors, both also require creativity of the kind that cannot fully be covered by mechanical rules. If (like many people in the industry) you still find it hard to compare the software developer to a mathematician, just think of other forms of engineering design: although it is possible to provide basic guidelines, no teachable step-by-step rules can guarantee good design of buildings or airplanes. In software too, no book advice can replace your know-how and ingenuity. The principal role of a methodological discussion is to indicate some good ideas, draw your attention to some illuminating precedents, and alert you to some known pitfalls. This would be true with any other software design method. In the case of object technology, the observation is tempered by some good news, coming to us in the form of reuse. Because much of the necessary invention may already have been done, you can build on others’ accomplishments. There is more good news. By starting with humble expectations but studying carefully what works and also what does not, we will be able, little by little and against all odds, to devise what in the end deserves to be called a method for finding the classes. One of the key steps will be the realization that, as always in design, a selection technique is defined by two components: what to consider, and what to reject
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 that
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 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 bibliographical notes
$22.1 STUDYING A REQUIREMENTS DOCUMENT 721 they may be opened and closed.Then to express the useful properties of doors it suffices to include in class ELEVATOR the query and commands door_open:BOOLEAN: close door is 444 ensure not door open end; open door is “40 ensure door_open end In another variant of the system,however,the notion of door may be important enough to justify a separate class.The only resource here is the theory of abstract data types,and the only relevant question is: Is"door"a separate data type with its own clearly identified operations,or are all the operations on doors already covered by operations on other data types such as ELEVATOR? Only your intuition and experience as a designer will tell you the answer.In looking for it,you will be aided by the requirements document,but do not expect grammatical criteria to be of more than superficial help.Turn instead to the ADT theory,which will help you ask customers or future users the right questions. Chapter 21. We encountered a similar case in the undo-redo mechanism design.The discussion distinguished between commands,such as the line insertion command in a text editor,and the more general notion of operation,which includes commands but also special requests such as Undo.Both of these words figured prominently in the statement of the problem; yet only COMMAND yielded a data abstraction (one of the principal classes ofthe design), whereas no class in the solution directly reflects the notion of operation.No analysis of a requirements document can suggest this striking difference of treatment. Is a new class necessary? Another example of a noun which may or may not give a class in the elevator example is floor.Here (as opposed to the door and operation cases)the question is not whether the concept is a relevant ADT:floors are definitely an important data abstraction for an elevator system.But this does not necessarily mean we should have a FLOOR class. The reason is simply that the properties of floors may be entirely covered,for the purposes of the elevator system,by those of integers.Each floor has a floor number;then
§22.1 STUDYING A REQUIREMENTS DOCUMENT 721 they may be opened and closed. Then to express the useful properties of doors it suffices to include in class ELEVATOR the query and commands door_open: BOOLEAN; close_door is … ensure not door_open end; open_door is … ensure door_open end In another variant of the system, however, the notion of door may be important enough to justify a separate class. The only resource here is the theory of abstract data types, and the only relevant question is: Only your intuition and experience as a designer will tell you the answer. In looking for it, you will be aided by the requirements document, but do not expect grammatical criteria to be of more than superficial help. Turn instead to the ADT theory, which will help you ask customers or future users the right questions. We encountered a similar case in the undo-redo mechanism design. The discussion distinguished between commands, such as the line insertion command in a text editor, and the more general notion of operation, which includes commands but also special requests such as Undo. Both of these words figured prominently in the statement of the problem; yet only COMMAND yielded a data abstraction (one of the principal classes of the design), whereas no class in the solution directly reflects the notion of operation. No analysis of a requirements document can suggest this striking difference of treatment. Is a new class necessary? Another example of a noun which may or may not give a class in the elevator example is floor. Here (as opposed to the door and operation cases) the question is not whether the concept is a relevant ADT: floors are definitely an important data abstraction for an elevator system. But this does not necessarily mean we should have a FLOOR class. The reason is simply that the properties of floors may be entirely covered, for the purposes of the elevator system, by those of integers. Each floor has a floor number; then Is “door” a separate data type with its own clearly identified operations, or are all the operations on doors already covered by operations on other data types such as ELEVATOR? Chapter 21
722 HOW TO FIND THE CLASSES $22.1 if a floor(as seen by the elevator system)has no other features than those associated with Mamy hotels have its floor number,you may not need a separate FLOOR class.A typical floor feature that nofloor 13,so the comes from a feature of integers is the distance between two floors,which is simply the arithmetic may be a difference of their floor numbers. bit more elaborate. If,however,floors have properties other than those of their numbers-that is to say, according to the principles of abstract data types and object-oriented software construction,significant operations not covered by those of integers-then a FLOOR class will be appropriate.For example,some floors may have special access rights defining who can visit them;then the FLOOR class could include a feature such as rights:SET [AUTHORIZATION and the associated procedures.But even that is not certain:we might get away by including in some other class an array floor rights:ARRAY [SET [AUTHORIZATION]] which simply associates a set of AUTHOR/ZATION values with each floor,identified by its number. Another argument for having a specific class FLOOR would be to lim it the available See exercise E22.1. operations:it makes sense to subtract two floors and to compare them (through the page 745. infix "<"function),but not to add or multiply them.Such a class may be written as an heir to INTEGER.The designer must ask himself,however,whether this goal really justifies adding a new class. This discussion brings us once again to the theory of abstract data types.A class does not just cover physical"objects"in the naive sense.It describes an abstract data type -a set of software objects characterized by well-defined operations and formal properties of these operations.A type of real-world objects may or may not have a counterpart in the software in the form ofa type of software objects-a class.When you are assessing whether a certain notion should yield a class or not,only the ADT view can provide the right criterion:do the objects of the system under discussion exhibit enough specific operations and properties of their own,relevant to the system and not covered by existing classes? The qualification"relevant to the system"is crucial.The aim of systems analysis is "BEYOND SOFT. not to "model the world".This may be a task for philosophers,but the builders of software WARE”,6.6.pag systems could not care less,at least for their professional activity.The task of analysis is 147. to model that part of the world which is meaningful for the software under study or construction.This principle is reinforced by the ADT approach(that is to say,the object- oriented method),which holds that objects are only defined by what we can do with them -what the discussion of abstract data types called the Principle of Selfishness.If an operation or property of an object is irrelevant to the purposes of the system,then it should not be included in the result of your analysis-however interesting it may be for other purposes.For a census processing system,the notion of PERSON may have features mother and father;but for a payroll processing system which does not require information about the parents,every PERSON is an orphan
722 HOW TO FIND THE CLASSES §22.1 if a floor (as seen by the elevator system) has no other features than those associated with its floor number, you may not need a separate FLOOR class. A typical floor feature that comes from a feature of integers is the distance between two floors, which is simply the difference of their floor numbers. If, however, floors have properties other than those of their numbers — that is to say, according to the principles of abstract data types and object-oriented software construction, significant operations not covered by those of integers — then a FLOOR class will be appropriate. For example, some floors may have special access rights defining who can visit them; then the FLOOR class could include a feature such as rights: SET [AUTHORIZATION] and the associated procedures. But even that is not certain: we might get away by including in some other class an array floor_rights: ARRAY [SET [AUTHORIZATION]] which simply associates a set of AUTHORIZATION values with each floor, identified by its number. Another argument for having a specific class FLOOR would be to limit the available operations: it makes sense to subtract two floors and to compare them (through the infix "<" function), but not to add or multiply them. Such a class may be written as an heir to INTEGER. The designer must ask himself, however, whether this goal really justifies adding a new class. This discussion brings us once again to the theory of abstract data types. A class does not just cover physical “objects” in the naïve sense. It describes an abstract data type — a set of software objects characterized by well-defined operations and formal properties of these operations. A type of real-world objects may or may not have a counterpart in the software in the form of a type of software objects — a class. When you are assessing whether a certain notion should yield a class or not, only the ADT view can provide the right criterion: do the objects of the system under discussion exhibit enough specific operations and properties of their own, relevant to the system and not covered by existing classes? The qualification “relevant to the system” is crucial. The aim of systems analysis is not to “model the world”. This may be a task for philosophers, but the builders of software systems could not care less, at least for their professional activity. The task of analysis is to model that part of the world which is meaningful for the software under study or construction. This principle is reinforced by the ADT approach (that is to say, the objectoriented method), which holds that objects are only defined by what we can do with them — what the discussion of abstract data types called the Principle of Selfishness. If an operation or property of an object is irrelevant to the purposes of the system, then it should not be included in the result of your analysis — however interesting it may be for other purposes. For a census processing system, the notion of PERSON may have features mother and father; but for a payroll processing system which does not require information about the parents, every PERSON is an orphan. Many hotels have no floor 13, so the arithmetic may be a bit more elaborate. See exercise E22.1, page 745. “BEYOND SOFTWARE”, 6.6, page 147
$22.1 STUDYING A REQUIREMENTS DOCUMENT 723 If all of the operations and properties that you can identify for a type of objects are irrelevant in this sense,or are already covered by the operations and properties of a previously identified class,the conclusion is that the object type itself is irrelevant:it must not yield a class. This explains why an elevator system might not include FLOOR as a class because (as noted above)from the point of view of the elevator system floors have no relevant properties other than those of the associated integer numbers,whereas a Computer Aided Design system designed for architects will have a FLOOR class-since in that case the floor has several specific attributes and routines. Missing important classes Not only can nouns suggest notions which do not yield classes:they can also fail to suggest some notions which should definitely yield classes.There are at least three sources of such accidents. Do not forget that,as noted,the aim of this discussion is no longer to convince ourselves of the deficiencies of the"underline the nouns"approach,whose limitations are by now so obvious that the exercise would not be very productive.Instead,we are analyzing these limitations as a way to gain more insight into the process of discovering classes. The first cause of missed classes is simply due to the flexibility and ambiguity of human language-the very qualities that make it suitable for an amazingly wide range of applications,from speeches and novels to love letters,but not very reliable as a medium for accurate technical documents.Assume the requirements document for our elevator example contains the sentence A database record must be created every time the elevator moves from one floor to another. The presence of the noun"record"suggests a class DATABASE RECORD;but we may totally miss a more important data abstraction:the notion of a move between two floors.With the above sentence in the requirements document,you will almost certainly need a MOVE class,which could be of the form class MOVE feature initial,final:FLOOR. --Or INTEGER if no FLOOR class record (d:DATABASE)is .. ..Other features... end--class MOVE This will be an important class,which a grammar-based method would miss because of the phrasing of the above sentence.Of course if the sentence had appeared as A database record must be created for every move of the elevator from one floor to another
§22.1 STUDYING A REQUIREMENTS DOCUMENT 723 If all of the operations and properties that you can identify for a type of objects are irrelevant in this sense, or are already covered by the operations and properties of a previously identified class, the conclusion is that the object type itself is irrelevant: it must not yield a class. This explains why an elevator system might not include FLOOR as a class because (as noted above) from the point of view of the elevator system floors have no relevant properties other than those of the associated integer numbers, whereas a Computer Aided Design system designed for architects will have a FLOOR class — since in that case the floor has several specific attributes and routines. Missing important classes Not only can nouns suggest notions which do not yield classes: they can also fail to suggest some notions which should definitely yield classes. There are at least three sources of such accidents. Do not forget that, as noted, the aim of this discussion is no longer to convince ourselves of the deficiencies of the “underline the nouns” approach, whose limitations are by now so obvious that the exercise would not be very productive. Instead, we are analyzing these limitations as a way to gain more insight into the process of discovering classes. The first cause of missed classes is simply due to the flexibility and ambiguity of human language — the very qualities that make it suitable for an amazingly wide range of applications, from speeches and novels to love letters, but not very reliable as a medium for accurate technical documents. Assume the requirements document for our elevator example contains the sentence The presence of the noun “record” suggests a class DATABASE_RECORD; but we may totally miss a more important data abstraction: the notion of a move between two floors. With the above sentence in the requirements document, you will almost certainly need a MOVE class, which could be of the form class MOVE feature initial, final: FLOOR; -- Or INTEGER if no FLOOR class record (d: DATABASE) is … … Other features … end -- class MOVE This will be an important class, which a grammar-based method would miss because of the phrasing of the above sentence. Of course if the sentence had appeared as A database record must be created every time the elevator moves from one floor to another. A database record must be created for every move of the elevator from one floor to another