Sample sections, in PDF, are available for some of the book’s chapters. To reduce the file sizes somewhat, they have been produced to a slightly lower resolution than the camera-ready copy was, and some large TIFF plates have been omitted. There are also one or two illustrations that appear in a sickly cyan. Two of the evils of our industry befell me: outsourcing and hard-coding. It was suggested that an external illustrator do the informal illustrations and the external illustrator hard-coded (rather than parameterized!) the book’s second color to printer’s cyan.
Chapter 2 (Models) introduces the main themes of the book. It explains, for example, the important differences between analysis and high-level design and justifies that something is needed between requirements and high-level design. There are two possibilities. It’s just possible that the one-day-in-hundred inspired moment will bless one of the very lucky or the unusually inspired one-developer-in-hundred with a brilliant metaphor. But notice the odds against (1 in 10,000). For the rest of us, enduring our normal degree of inspiration, the traditional route (analysis) can work well, provided that we understand exactly what analysis can and should accomplish; and, even more importantly, what analysis cannot and should not be expected to furnish.
Misconceptions about analysis abound. Although the primary elements of the real world or subject matter (“entities” as they were known by semantic modelers), do make good suggestions as to objects, they don’t directly suggest classes. Despite what many treatments of analysis say, it’s actually not worth attributing actions to subject matter entities. This is better treated as a design activity, because in today’s typical software, objects’ actions are invented and are not directly suggested by the analysis model (pure computerization was an ephemeral thing of the 1960s and is rare today). State machines suffer many misconceptions. A class or entity that cannot be adequately described without a state machine is a class or entity that we would try to re-abstract or re-design. Only a few of entities and classes found in hard real-time subjects and systems should need state machines. And for those state machines that are needed, it’s very important to realize that their content and interpretation vary from phase to phase. Despite what many treatments imply, a state machine describing the life of a subject matter entity has a different agenda to that of a state machine describing the implementation of a class.
There are also several common misconceptions about the transition into design, and about how design should be begun. For example: in this approach, wanting actually to be object-oriented rather than class-oriented, we begin with instances rather and not with classes; messages are more important than methods (member functions). This can all be summed up as outside-in design and not inside-out design.
Finally, because the differentiation of the phases is often muddled in traditional approaches, analysis and design are often poorly focused, take longer than they should, and are not as productive as they should be. If we get clear as to exactly what each activity can, should, and should not be aiming to achieve, we can move away from ponderous, inefficient development methods
Chapter 5 (Analysis Inputs) goes into detail on how to ensure that the requirements are as useful as possible and that the time spent in capturing them is as productive as possible. The essential thing is not to try to do the analysis or design at the same time as requirements are being elicited and captured. Treated carefully and correctly, the requirements offer us one of most definitive and factual beginnings for a development project.
Chapter 12 (Technical Model) describes detailed, technical design. Even when we reach this detailed phase — class design for example — we still have to be careful. For example: well-designed types are usually not given enough prominence by traditional approaches; often too much attention is given to concrete or semi-concrete classes; although it is fairly well recognized, it is by no means universally realized that inheritance (of implementation) is far from being the wonder-drug/silver bullet that early hopes fastened upon; and state machines are used are often rendered useless and uninterpretable by trying to use as much as possible of the UML, rather than as little as possible!