Team LiB
Previous Section Next Section

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

Despite all of 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, rather than in 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: We must be able 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. While it's certainly possible to describe an abstraction in narrative text, a picture is worth 1,000 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 Figure 2-8) notation as our model communication language (you'll learn the basics of UML in Chapters 9, 10, and 11). Think of a graphical model as a blueprint of the software application to be built.

    Click To expand
    Figure 2-8: Describing a landscape in UML notation


    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.

Team LiB
Previous Section Next Section