This is because:

• There are an unlimited number of possibilities. Abstraction is to a certain extent in the eye of the beholder: several different observers working independently are almost guaranteed to arrive at different models. Whose is the best? Passionate arguments have ensued!
• To further complicate matters, there is virtually never only one 'best' or 'correct' model, only better or worse models relative to the problem to be solved. The same situation can be modeled in a variety of different, equally valid ways. As you'll see when we get into actually doing some modeling in Part 2 of this book, we'll look at a number of valid alternative abstractions for our Student Registration System (SRS) case study that was presented at the end of the Introduction.
• Note, however, that there IS such a thing as an incorrect model: namely, one that misrepresents the real-world situation (for example, modeling a person as having two different blood types).
• There is no 'acid test' to determine if a model has adequately captured all of a user's requirements. The ultimate evidence of whether or not an abstraction was appropriate is in how successful the resultant software system turns out to be. We don't want to wait until the end of a project before finding out that we've gone astray. Because of this, it is critical that we learn ways of communicating our model concisely and unambiguously to:
• The intended future users of our application, so that they may sanity check our understanding of the problem to be solved before we embark upon software development,
• Our fellow software engineers, so that team members share a common 'vision' for what we are to build collaboratively.

Despite all of these challenges, it is critical to get the up-front abstraction 'right' before beginning to build a system. Fixing mistakes in the abstraction once a system is modeled, designed, coded, and documented, and undergoing acceptance testing is much more costly (by orders of magnitude) than correcting the abstraction when it is still a gleam in the project team's eye. This is not to imply that an abstraction should be rigid: quite the contrary! The art and science of object modeling, when properly applied, yields a model that is flexible enough to withstand a wide variety of functional changes. In addition, the special properties of objects further lend themselves to flexible software solutions, as we'll learn throughout the rest of the book. However, all things being equal, we'd like to harness this flexibility to expand a system's capabilities over time, rather than repairing mistakes.

What Does It Take to Be a Successful Object Modeler?

Coming up with an appropriate abstraction as the basis for a software system model requires:

• Insight into the problem domain: ideally, you'll be able to draw upon your own real-world experience, such as your former or current experience as a student, which will come in handy when determining the requirements for the SRS.
• Creativity: to enable us to think 'outside the box', in case the future users that we are interviewing have been immersed in the problem area for so long, that they fail to see innovations that might be made.
• Good listening skills: as future users of the system describe how they do their jobs currently, or how they envision doing their jobs in the future, with the aid of the system that we're about to develop.
• Good observational skills: actions often speak louder than words; just by observing users going about their daily business, we may pick up an essential detail that they have neglected to mention because they do it so routinely that it has become a habit.

But all this is not enough, we also need:

• An organized process for determining what the abstraction should be. If we follow a proven checklist of steps for producing a model, then we greatly reduce the probability that we'll omit some important feature or neglect a critical requirement.
• A way to communicate the resultant model concisely and unambiguously to our fellow software developers, and to the intended users of our application. While it is certainly possible to describe an abstraction in narrative text, a picture is worth 1000 words, and so the language with which we communicate a model is often a graphical notation. Throughout this book, we'll focus on the Unified Modeling Language (UML - see following figure) notation as our model communication language (you'll learn the basics of UML in Chapters 10 and 11). Think of a graphical model as a 'blueprint' of the software application to be built.

* Ideally, we'll also have a software tool to help us automate the process of producing such a 'blueprint'.

Part 2 of this book covers these three aspects of modeling - process, notation, and tool - in detail; for starters, however, let's make sure that we understand the basics of objects, which is the focus of the remainder of Part 1.

Summary

In this chapter, we've learned that:

• Abstraction is a fundamental technique that people use to perceive the world, and is a necessary first step of all software development.
• We naturally organize information into classification hierarchies based upon rules that we carefully structure, so that they are neither too general nor too restrictive.
• We often reuse abstractions when attempting to model a new concept.
• Producing an abstraction of a system to be built, known as a model, is in some senses second nature to us, and yet paradoxically is one of the hardest things that software developers have to do in the lifecycle of an information systems project. Yet, it is also one of the most important.