Beginning Java Objects: Chapter 2
Abstraction and Modeling
Reuse of Abstractions
When learning about something new, we automatically search our
'mental archive' for other abstractions/models that we've
previously built and mastered, to look for similarities that we
can build upon. When learning to ride a two-wheeled bicycle for
the first time, for example, you may have drawn upon lessons that
you learned about riding a tricycle as a child. Both have
handlebars that are used to steer; both have pedals that are used
to propel the bike forward. Although the abstractions didn't
match perfectly — a two-wheeled bicycle introduced the new
challenge of having to balance oneself — there was enough
of a similarity to allow you to draw upon the steering and
pedaling expertise you already had mastered, and to focus on
learning the new skill of how to balance on two wheels.
This technique of comparing features to find an abstraction that
is similar enough to be reused successfully is known as
pattern matching and reuse. As we will learn in Chapter
12, pattern reuse is an important technique for object oriented
software development, as well, because it spares us from having
to reinvent the wheel with each new project. If we can reuse an
abstraction or model from a previous project, we can focus on
those aspects of the new project that differ from the old,
gaining a tremendous amount of productivity in the process.
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 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.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
