724 HOW TO FIND THE CLASSES $22.1 then"move"would have been counted as a noun,and so would have yielded a class!We see once again the dangers of putting too much trust in a natural-language document,and the absurdity of making any serious property of a system design,especially its modular structure,dependent on such vagaries of style and mood. The second reason for overlooking classes is that some crucial abstractions may not Panel-drivensystem. be directly deducible from the requirements.Cases abound in the examples of this book.chapter 20.Undo- It is quite possible that the requirements for a panel-driven system did not explicitly cite redo:chapter 21. the notions of state and application;yet these are the key abstractions,which condition the entire design.It was pointed out earlier that some external-world object types may have no counterpart among the classes ofthe software;here we see the converse:classes of the software that do not correspond to any external-world objects.Similarly,if the author of the requirements for a text editor with undo-redo has written"the system must support line insertion and deletion",we are in luck since we can spot the nouns insertion and deletion; but the need for these facilities may just as well follow from a sentence of the form The editor must allow its users to insert or delete a line at the current cursor position. leading the naive designer to devote his attention to the trivial notions of"cursor"and "position"while missing the command abstractions(line insertion and line deletion). The third major cause of missed classes,shared by any method which uses the requirements document as the basis for analysis,is that such a strategy overlooks reuse.It is surprising to note that much of the object-oriented analysis literature takes for granted the traditional view of software development:starting from a requirements document and devising a solution to the specific problem that it describes.One of the major lessons of object technology is the lack of a clear-cut distinction between problem and solution. Existing software can and should influence new developments. When faced with a new software project,the object-oriented software developer See "THE CHANG- does not accept the requirements document as the alpha and omega of wisdom about the ING NATURE OF problem,but combines it with knowledge about previous developments and available ANALYSIS”,27.2. page 906. software libraries.If necessary,he will criticize the requirements document and propose updates and adaptations which will facilitate the construction of the system;sometimes a minor change,or the removal of a facility which is of limited interest to the final users, will produce a dramatic simplification by making it possible to reuse an entire body of existing software and,as a result,to decrease the development time by months.The corresponding abstractions are most likely to be found in the existing software,not in the requirements document for the new project. Classes COMMAND and HISTORY LOG from the undo-redo example are typical. The way to find the right abstractions for this problem is not to rack one's brain over the requirements document for a text editor:either you come upon them through a process of intellectual discovery (a "Eureka",for which no sure recipe exists);or,if someone else has already found the solution,you reuse his abstractions.You may of course be able to reuse the corresponding implementation too if it is available as part of a library;this is even better,as the whole analysis-design-implementation work has already been done for you.724 HOW TO FIND THE CLASSES §22.1 then “move” would have been counted as a noun, and so would have yielded a class! We see once again the dangers of putting too much trust in a natural-language document, and the absurdity of making any serious property of a system design, especially its modular structure, dependent on such vagaries of style and mood. The second reason for overlooking classes is that some crucial abstractions may not be directly deducible from the requirements. Cases abound in the examples of this book. It is quite possible that the requirements for a panel-driven system did not explicitly cite the notions of state and application; yet these are the key abstractions, which condition the entire design. It was pointed out earlier that some external-world object types may have no counterpart among the classes of the software; here we see the converse: classes of the software that do not correspond to any external-world objects. Similarly, if the author of the requirements for a text editor with undo-redo has written “the system must support line insertion and deletion”, we are in luck since we can spot the nouns insertion and deletion; but the need for these facilities may just as well follow from a sentence of the form leading the naïve designer to devote his attention to the trivial notions of “cursor” and “position” while missing the command abstractions (line insertion and line deletion). The third major cause of missed classes, shared by any method which uses the requirements document as the basis for analysis, is that such a strategy overlooks reuse. It is surprising to note that much of the object-oriented analysis literature takes for granted the traditional view of software development: starting from a requirements document and devising a solution to the specific problem that it describes. One of the major lessons of object technology is the lack of a clear-cut distinction between problem and solution. Existing software can and should influence new developments. When faced with a new software project, the object-oriented software developer does not accept the requirements document as the alpha and omega of wisdom about the problem, but combines it with knowledge about previous developments and available software libraries. If necessary, he will criticize the requirements document and propose updates and adaptations which will facilitate the construction of the system; sometimes a minor change, or the removal of a facility which is of limited interest to the final users, will produce a dramatic simplification by making it possible to reuse an entire body of existing software and, as a result, to decrease the development time by months. The corresponding abstractions are most likely to be found in the existing software, not in the requirements document for the new project. Classes COMMAND and HISTORY_LOG from the undo-redo example are typical. The way to find the right abstractions for this problem is not to rack one’s brain over the requirements document for a text editor: either you come upon them through a process of intellectual discovery (a “Eureka”, for which no sure recipe exists); or, if someone else has already found the solution, you reuse his abstractions. You may of course be able to reuse the corresponding implementation too if it is available as part of a library; this is even better, as the whole analysis-design-implementation work has already been done for you. The editor must allow its users to insert or delete a line at the current cursor position. Panel-driven system: chapter 20. Undo￾redo: chapter 21. See “THE CHANG￾ING NATURE OF ANALYSIS”, 27.2, page 906