1.2 Abstraction


Abstraction is a design technique that focuses on the essential aspects of an entity and ignores or conceals less important or non-essential aspects. Abstraction is an important tool for simplifying a complex phenomenon to a level where analysis, experimentation, or understanding can take place. For example, in attempting to understand the mechanics of the solar system, early mathematicians and astronomers applied abstraction to a "planet", treating the planet as a body all of whose mass is concentrated at a single point. Such an abstraction ignores a wealth of details about each planet - its actual diameter, its atmospheric content, its average temperature, etc. However, these details are not relevant to understanding and modeling the basic orbital mechanics of the solar system.

In software, abstraction is concerned with both the "attributes" and "behavior" of entities. Attributes refer to the properties or characteristics associated with an entity while behavior refers to the set of actions that the entity can perform. In a software object, attributes are represented by data that is associated with the object. For a sales tracking system relevant attributes of a salesperson, see Figure 1.2.1, might be: name, number of vehicles sold, value of vehicles sold, list of customers, commission rate, total commissions. An action of the object corresponds to an operation or function associated with the object. Actions for a "salesperson" might include "sellCar", "reportIncome" and "increaseCommisionRate".

Abstraction is vital to creating tractable software objects because the real-world objects are far too complex to be captured in complete detail. Consider the simple "salesperson" object referred to above. A real "salesperson" has an identity, a family genealogy, a medical history, a genetic profile, a credit record, a set of talents, and many more. Similarly there is a rich set of actions of which the salesperson is capable (sellCar, answerPhone, buyHouse, haveChild, getSick, increaseCreditLimit, payBills, etc.). Trying to capture even a small part of this enormous detail in a software object is pointless. It is important to capture only those aspects of a "salesperson" that are relevant to the development of a particular system (e.g., the sales tracking system).

The objects in an object-oriented system are often intended to correspond directly to entities in the "real world". Objects such "salesperson" and "automobiles" that might occur in an automobile dealership tracking system correspond to the actual people on the staff of the dealership and the actual cars owned and sold by the dealership. The correspondence between the software objects and the real-world entity that they represent is often so direct and real that computer-based theft or fraud often involves tampering with the software objects that are trusted by others to correspond to real-world artifacts. This sense of correspondence is also expressed as the "program" being a "simulation" or " model" of the real-world, changes in one being reflected in the other. A "good" program is one which models or simulates accurately what is happening in the real-world.
 


Figure 1.2.1: Abstraction of a SalesPerson 

The examples above motivate the following definition of abstraction:

Abstraction
A named collection of attributes and behavior relevant to modeling a given entity for some particular purpose.
A single entity may have many valid abstractions. While the genetic profile of a salesperson is not relevant to a sales tracking system, it may be relevant to a medical database system. This alternative abstraction is shown in Figure 1.2.2. Correspondingly, the medical database system developer would not consider the number of vehicles sold to be a relevant aspect. The name of the abstraction is useful to distinguish among different abstractions for the same entity and among abstractions for different entities. A critical part of object-oriented design is deciding which attributes and behavior to include in a given abstraction.
 

Figure 1.2.2: Abstraction of a Patient in a Medical Database 


 
 

Properties of a Good Abstraction


While there may be many abstractions of the same entity, each abstraction should have certain properties that distinguish it as a "good" abstraction. These desirable properties are:

well named
the nature of an abstraction is conveyed by the name given to that abstraction. An abstraction is well named if the meanings, intuitions, impressions, and expectations implied by a name accurately reflect the nature of the abstraction. Whether a name is meaningful depends on the community of people who will use the abstraction. In some cases the name might be a technical term in an application domain that communicates an abstraction perfectly to the group of people in that application area but may mean little to a non-technical group. In other cases, abstractions for widely known entities (e.g., "Automobile" or "ZipCode") may have names recognizeable to a general population.
coherent
the abstraction should contain a related set of attributes and behavior that make sense from the viewpoint of the modeler. The attributes and behavior have to be what is needed and expected in a given setting. For example, defining a SalesPerson abstraction that consists of the attributes "commisionRate", "family", and "talents" is not a coherent abstraction, it does not make sense from the viewpoint of a designer building a sales tracking system.
accurate
the abstraction contain only attributes or behavior that are a part of the entity being modeled. The abstraction should not be endowed with "powers and abilities" far beyond those of the actual entity. While this principle is usually observed, there are special circumstances where this principle may be relaxed. For example, in a virtual environment it may be possible to "walk through the walls" in a scene. Such behavior clearly violates the behavior of real walls.
minimal
the abstraction should not contain extraneous attributes or behavior for the purpose for which it is defined. For example, adding a mailAddress or telephoneNumber attribute to the SalesPerson abstraction would be extraneous if these additional attributes were not required for the sales tracking system.
complete
the abstraction should contain all of the attributes and behavior necessary to manipulate the abstraction for its intended purpose. Assuming that the sales tracking system needed to know the commisionRate for each SalesPerson, an abstraction which did not include this attribute would not be complete.
These properties are clearly subjective and qualitative in nature. This fact implies that the ability to form good abstractions requires good judgment and the benefit of practice and experience.
 
 

Exercises.

 
  1. Define plausible abstractions for an "automobile" from the point of view of:
  2. Define plausible abstraction for a "book" from the point of view of:
  3. Define plausible abstractions for an "airplane flight" from the point of view of:
  4. Evaluate your "automobile" abstractions against the four properties of good abstractions.
  5. Evaluate your "book" abstractions against the four properties of good abstractions.
  6. Evaluate your "airplane flight" abstractions against the four properties of good abstractions.
  7. Identify a common, real-world entity and at least three different points of view that would lead to different abstractions of that entity.