2.4. Inherent Challenges

Despite the fact that abstraction is such a natural process for human beings, developing an appropriate model for a software system is perhaps the most difficult aspect of software engineering because

  • There are an unlimited number of possibilities. Abstraction is in the eye of the beholder to a certain extent: 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 Two of this book, you'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 whether 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's critical that we learn ways of communicating our model concisely and unambiguously to the following people:

    • 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 of what we're to build collaboratively

Despite all these challenges, it's 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, documented, and undergoing acceptance testing is much more costly (by orders of magnitude) than correcting the abstraction when it's still a gleam in the project team's eye. This isn't 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 you'll learn throughout the rest of the book. However, all things being equal, we'd like to harness this flexibility in expanding a system's capabilities over time instead of in repairing mistakes.

2.4.1. 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 the following:

  • 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're interviewing have been immersed in the problem area for so long that they fail to see innovations that might be made.

  • Good listening skills: These will come in handy 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 isn't 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. Although it's certainly possible to describe an abstraction in narrative text, a picture is worth 1,000 words, so the language with which we communicate a model is often a graphical notation. In several chapters of this book, we'll make use of Unified Modeling Language ((UML) notation as our model communication language (see Figure 2-8). (A brief introduction to UML will be provided in Chapters 9 and 10.) Think of a graphical model as a blueprint of the software application to be built.

    Figure 2.8. Describing a landscape in UML notation

    NOTE

    You'll learn how to interpret UML diagrams in Part Two of the book.

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

Part Two of this book covers these three aspects of modeling—process, notation, and tool—in detail. For starters, however, we'll make sure that you understand the basics of objects, which is the focus of the remainder of Part One.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset