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 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. Many hotels have no floor 13, so the arithmetic may be a bit more elaborate. See exercise E22.1, page 745. “BEYOND SOFT￾WARE”, 6.6, page 147