For example, a diagram of a generic cell in the human body might include only a few features of the structures that are found in an actual cell:

This overly simplified diagram doesn't look like a real nerve cell, or a real muscle cell, or a real blood cell; and yet, it can still be used in an educational setting to describe certain aspects of the structure and function of all of these cell types - namely, those features that the various cell types have in common.

The simpler an abstraction - that is, the fewer features it presents - the more general it is, and the more versatile it is in describing a variety of real-world situations. The more complex an abstraction, the more restrictive it is, and thus the fewer situations it is useful in describing.

Organizing Abstractions Into Classification Hierarchies
Even though our brains are adept at abstracting concepts such as road maps and landscapes, that still leaves us with hundreds of thousands, if not millions, of separate abstractions to deal with over our lifetimes. To cope with this aspect of complexity, human beings systematically arrange information into categories according to established criteria; this process is known as classification.

For example, science categorizes all natural objects as belonging to either the animal, plant, or mineral kingdom. In order for a natural object to be classified as an animal, it must satisfy the following rules:

• It must be a living being.
• It must be capable of spontaneous movement.
• It must be capable of rapid motor response to stimulation.

The rules for what constitute a plant, on the other hand, are different:

• It must be a living being (same as for an animal).
• It must lack an obvious nervous system.
• It must possess cellulose cell walls.

Given clear-cut rules such as these, placing an object into the appropriate category, or class, is rather straightforward. We can then 'drill down', specifying additional rules which differentiate various types of animal, for example, until we've built up a hierarchy of increasingly more complex abstractions from top to bottom. A simple example of an abstraction hierarchy is shown below.

When thinking about an abstraction hierarchy such as the one shown above, we mentally step up and down the hierarchy, automatically zeroing in on only the single layer or subset of the hierarchy (known as a subtree) that is important to us at a given point in time. For example, we may only be concerned with mammals, and so can focus on the mammalian subtree:

temporarily ignoring the rest of the hierarchy. By doing so, we automatically reduce the number of concepts that we mentally need to 'juggle' at any one time to a manageable subset of the overall abstraction hierarchy; in the simplistic example above, we are now dealing with only four concepts rather than the original 13. No matter how complex an abstraction hierarchy grows to be, it needn't overwhelm us if it is properly organized.

Coming up with precisely which rules are necessary to properly classify an object within an abstraction hierarchy is not always easy. Take, for example, the rules we might define for what constitutes a bird: namely, something which:

• Has feathers
• Has wings
• Lays eggs
• Is capable of flying

Given these rules, neither an ostrich nor a penguin could be classified as a bird, because neither can fly.

If we attempt to make the rule set less restrictive by eliminating the 'flight' rule, we are left with:

• Has feathers
• Has wings
• Lays eggs

According to this rule set, we now may properly classify both the ostrich and the penguin as birds.

This rule set is still unnecessarily complicated, because as it turns out, the 'lays eggs' rule is redundant: whether we keep it or eliminate it, it doesn't change our decision of what constitutes a bird versus a non-bird. Therefore, we simplify the rule set once again:

• Has feathers
• Has wings

Feeling particularly daring (!), we try to take our simplification process one step further, by eliminating yet another rule, defining a bird as something which:

• Has wings

We've gone too far this time: the abstraction of a bird is now so general that we'd include airplanes, insects, and all sorts of other non-birds in the mix!

The process of rule definition for purposes of categorization involves 'dialing in' just the right set of rules - not too general, not too restrictive, and containing no redundancies - to define the correct membership in a particular class.

Abstraction as the Basis for Software Development

When pinning down the requirements for an information systems development project, we typically start by gathering details about the real world situation on which the system is to be based. These details are usually a combination of:

• Those that are explicitly offered to us as we interview the intended users of the system.
• Those that we otherwise observe.

We must make a judgment call as to which of these details are relevant to the system's ultimate purpose. This is essential, as we cannot automate them all! To include too much detail is to overly complicate the resultant system, making it that much more difficult to design, program, test, debug, document, maintain, and extend in the future.

As with all abstractions, all of our decisions of inclusion versus elimination when building a software system must be made within the context of the overall purpose and domain, or subject matter focus, of the future system. When representing a person in a software system, for example, is their eye color important? How about their genetic profile? Salary? Hobbies? The answer is, any of these features of a person may be relevant or irrelevant, depending on whether the system to be developed is a:

• Payroll system
• Marketing demographics system
• Optometrist's patient database
• FBI 'most wanted criminals' tracking system
• Public library

Once we've determined the essential aspects of a situation - something that we'll learn how to do in Part 2 of this book - we can prepare a model of that situation. Modeling is the process by which we develop a pattern for something to be made. A blueprint for a custom home, a schematic diagram of a printed circuit, and a cookie cutter are all examples of such patterns. As we will learn in Parts 2 and 3, an object model of a software system is such a pattern. Modeling and abstraction go hand in hand, because a model is essentially a physical or graphical portrayal of an abstraction; before we can model something effectively, we must have determined the essential details of the subject to be modeled.

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.