Exercise Solutions

These are the answers that are publicly available. (There are also some answers with restricted availability. And a note their about availability.)

If you have any suggestions or corrections you'd like to proffer, do please email me if you can. This is only a first draft.

There used to be a change log recording the build up of this file as the chapters were uploaded, one by one. That change log has been cleared now that all the chapters are up.

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 1

Question 1.1
Research or recall at least two more definitions of objects and of object-orientation. Compare and contrast those definitions with the ones given in Section 1.1.1.

Rumbaugh et al., in Object-Oriented Modeling and Design (1991) "define an object as a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand. Objects serve two purposes: They promote understanding of the real world and provide a practical basis for computer implementation." This definition is trying to be general and to serve as a definition of something that might be found in real world models (called subject matter models in Deacon) as well as something that might be found in software. There could be difficulties in trying to cover both real world models and technical models with a single definition. The definition of Rumbaugh et al. is sufficiently non-specific, though, that it succeeds in covering both whilst avoiding inaccuracies. However, someone trying to understand exactly what might constitute an object be would be left with questions, especially in technical models: both data structures and functions would qualify as objects under this definition, for example.

Deacon, in Section 1.1.1 defines an object as "a cohesive and loosely-coupled, self-processing, implementation-hiding, meaningful software agent that exhibits identity and that usually has a personal and persistent state. An object makes itself useful through, and hides its implementation behind, a message-accepting interface." This covers software objects but not real world objects. Deacon avoids providing a definition that covers both analysis and design models.†

Sommerville, in Software Engineering (7th edition, 2004), says "An object is an entity that has a state and a defined set of operations which operate upon that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required." This is a more software-object-oriented definition than that of Rumbaugh et al. Deacon still goes further, though, and includes what might be considered style judgments. Despite its near-universal acceptance, Sommerville doesn't mention encapsulation and information hiding, for example.

†[If this exercise were to be set after more of the book had been read -- chapter 2 and 4 perhaps -- the answer could go further: Deacon avoids providing a definition that covers both analysis and design models, claiming that there are enough differences between the objects of the real world (which he terms entities) and the objects of the software, that trying to provide a common definition isn't feasible or helpful.
Someone familiar with object technology could go on to consider my inclusion of identity as part of the essential character of an object, pointing out that this might tend to exclude some value objects like dates and complex numbers. My definition could be criticized for insisting on identity and yet admitting stateless objects (which are surely no less peculiar than value objects).]

Question 1.2
Describe how, in the face of changing problems, practices and people, analysis has evolved, or should have evolved, since the 1950s. Include a consideration of the appropriateness of the terms that have been used for the job.

This is a revision question. Everything I would have expected in an answer is in the chapter. The answer might have mentioned: the problem realm moving from arithmetic and maths, through clerical applications to just about anything today; the "analysis" strategy moved from "Eh? What analysis? Mathematics is an entirely adequate specification language in its own right." through systems analysis and the era of computerization, to my claim that we need to re-title analysis as "subject matter analysis" today, since many (or most) developments are not computerizations and if there is a system to analyze, there's a strong chance it's already an unanalyzable computer system; the people have moved from single pioneers to multiple teams; job titles like analyst-programmer appeared in the middle, computerization, years and job titles like designer and architect appeared in recent years; and terms like analyst-programmer and systems analysis are probably over-used and misused today, again because computerization is becoming a rarity and because typical systems are big enough that a design phase is essential.

Question 1.3
(Practitioners) Consider the development unit you work for. It might be the entire development team of a small software house, or it might be a team of around a dozen people in a larger organization. If your team is part of a team that’s part of a very large organization, you might consider your immediate team and the next one up.
Without being unduly tough on yourself or unduly optimistic, assess where you think you are in the CMM (capability maturity model) scale mentioned on page 9. When your unit has a successful project, is it more luck than judgment? Or can your unit “turn the handle”? What self-awareness does the unit have? What quantification is there?
By all means do a little more research on CMM, especially its recommendations as to what each level should do in order to move toward the next. (And note the observation that you cannot skip a level.) If, in your research, you encounter one of the extensions of the CMM, such as Imperial College’s, with zero and negative levels, I hope you don’t recognize your unit’s level there.

What did you find? Success only through coincidence and heroic effort? Teams producing the goods rather than heroes, but teams without insight? Teams with insight into their own practices and processes? Quantification and metrics? Optimizing, self-aware, self-healing team? Or did you feel that to reach even level 1 was a distant goal? If you haven't come across the zero and negative-level extensions to the official CMM scale, they are in the miscellany section.

Question 1.5
Consider one or two subject matters that you have a degree of familiarity with. You might or might not have developed computer systems dealing with your chosen subject matters. Note down a few (half a dozen maybe) of the key creatures or entities as we will be calling them. Although we will have entire chapters on choosing entities, it’s not that difficult to start and you will almost certainly discern a few reasonable ones.) You might review these choices after you’ve completed the chapter on entities.)

Of course, the answer here depends entirely on what subject matter you've chosen. However, there are a few general points against which you can check your answer. Are your entities really there? If your subject matter was managing the local video rental shop, did you include the printer just because there's one behind the counter? The "real" entities would be Renter, Video, DVD, Snack Item, Shelf Category, etc. Notice the last one. It's more subtle. It's not the wooden or metal shelf itself; it's the concept of the place to put something. Real and relevant subject matter entities needn't be physical or tangible. Do your entities exhibit identity? Did you include something like Studio (Miramax, etc.)? That would be a difficult one; renter address would almost certainly not exhibit identity in this context, and thus be modeled as an attribute; whereas Renter would and thereby achieves entity status. I would initially consider studio not to exhibit identity, i.e. to be modeled as an attribute rather than an entity; but it's a tricky one; probably more information would have to be sought. Did you give your entities strong, colorful names? Did you have something like Renter, or did you have something like Customer?

Consider and list the processing that your entities carry out. (An entity that carries out some processing changes the state of itself or another entity.) Don’t read any further until you have done that. Have you done that? Now read your lists and ask yourself if your entities really do carry out those processes. Don’t claim, for example, that a real world employee tells you how much to pay it, because it doesn’t.
If you realize that you’ve invented some processing, ask yourself how reliable your invention is likely to be, and how much agreement you would get from other developers. If you decide that your entities’ processing is honest and real, picture typical software objects like Java objects or C++ objects doing that processing and assess how reasonable that would be. (If your experience of object-oriented programming is slight, then carefully put your lists away and review them in a few months’ time.)
Do you find that you agree or disagree with the position of this book, that either your entity’s processing is unreal or it would be a poor method allocation for its corresponding object?

Again, it depends on your example, but let's stick with the rental store. Did you write down something like a renter moves to a new address, or a game cartridge breaks? Those are certainly actions in the real world but, and maybe you just have to trust me on this, they won't ever make good methods (member functions) for the software objects. The address is an attribute or relationship that the store employee updates, the renter object won't run a move() function. And, again, a renter or employee will note that a cartridge is broken and will update the system. A Java cartridge object won't run anything like a dysfunction() function. Perhaps you wrote down that a renter issues an overdue letter. Well, that's quite likely to be a good method for a software object (although we don't have much evidence for that assertion just yet); however, it's an invention -- the real world renter simply doesn't do that. Let's leave invention until after we've assembled as many facts as possible.

Most people start off surprised to hear that modeling operations and processing as characteristics of subject matter entities is invention rather than fact-finding. That's probably mostly a decade or more of methodologists having suggested otherwise. Hopefully, when you really looked, and really looked honestly at your subject matter entities, you did indeed find that whilst not irrelevant, processing is something to be very careful with; and that if a subject matter entity operation did suggest a good method for an object, then really, honestly it wasn't actually something a subject matter did -- you invented it. And if you did list some actual processing that your subject matter entities really did carry out (and if you have some experience of object-oriented designs), the object technology counterparts of your subject matter entities would not be likely to benefit from matching methods.