|
|
If we eliminate enough detail from an abstraction, it becomes generic enough to apply to a wide range of specific situations or instances. Such generic abstractions can often be quite useful. For example, a diagram of a generic cell in the human body, such as the one in Figure 2-1, 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.
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 that 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 in Figure 2-2.
When thinking about an abstraction hierarchy such as the one shown in Figure 2-2, 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, shown in Figure 2-3, 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 our simplistic example, we're now dealing with only 4 concepts rather than the original 13. No matter how complex an abstraction hierarchy grows to be, it needn't overwhelm us if it's properly organized.
Coming up with precisely which rules are necessary to properly classify an object within an abstraction hierarchy isn't always easy. Take, for example, the rules we might define for what constitutes a bird: namely, something that
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 (see Figure 2-4).
If we attempt to make the rule set less restrictive by eliminating the "flight" rule, we're 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, as shown in Figure 2-5.
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 that
Has wings
As Figure 2-6 shows, 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.
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, plus
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 can't 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's "most wanted" tracking system
Public library
Once we've determined the essential aspects of a situation—something that we'll show you how to do in Part Two 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'll see in Parts Two and Three, 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.
|
|
