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.
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.
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.
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.
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.)
Dont 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. Dont claim, for example, that a real
world employee tells you how much to pay it, because it doesnt.
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.