In software, abstraction is concerned with both the "attributes" and "behavior" of entities. Attributes are 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 might be: name, number of vehicles sold, value of vehicles sold, list of customers, commission rate, total commissions. An action, or behavior, 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 unique attributes. 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 as "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 sometimes so direct 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 that models or simulates accurately what is happening in the real world.

Abstraction of a Salesperson

The figure below can be manipulated to illustrate the concept of abstraction for a SalesPerson. The blue portion of the figure represents the real-world person, while the yellow portion of the figure represents an abstraction, acting as a filter that makes visible only those aspects of the real-world entity that are relevant to the abstraction being formed. Move the yellow filter around in the figure to see what attributes of the real-world entity are relevant.

The examples above motivate the following definition of abstraction:

Abstraction

A named, tangible representation of the attributes and behavior relevant to modeling a given entity for some particular purpose.

This definition also reflects the fact that for computer scientists and software engineers abstractions are not "abstract," ethereal concerns. Instead, abstraction is used to form concrete manifestations of the abstraction. At different stages in the software lifecycle the representation of an abstraction may take different forms. In the early design stages, hand-made drawings, diagrams, and lists may be used. Further in the design stage, a specific design notation may be used, often supported by design tools. Finally, in the implementation stage, the abstraction is represented in software, where it may be visible to the user and capable of conducting interactions with the user.

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 as shown in the figure below. 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.

Abstraction of a Patient in a Medical Database

The figure below can be manipulated to illustrate the concept of abstraction for a patient in a medical database. The blue portion of the figure represents the "real world" person. The yellow portion of the figure represents an abstraction as a filter that makes visible only those aspects of the real-world entity that are relevant to the abstraction of this person from the point of view of a medical database application. Move the yellow filter around in the figure to see what attributes of the real-world entity are relevant.

The interactive figure below illustrates the process of forming an abstraction by simplifying the description of a real-world entity. The central (yellow) areas shows a representation of a complex real-world entity - a person. A real person has many attributes (shown in black) and is capable of many different behaviors (shown in blue). The central area shows some of a person's attributes and behaviors. You could clearly think of many more of each. The person may be viewed from many different perspectives, each view yielding a different abstraction. Select one of the four different views (SalesPerson, Student, CarOwner, and Patient) and press the "Do Abstraction" button. The animation shows the simplification that results by viewing the person from the selected viewpoint. The "Reset" button returns the interactive figure to its original condition.

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. A good abstraction is::

Well named:

The nature of an abstraction is conveyed by its name. An abstraction is well named if the meanings, intuitions, impressions, and expectations generated 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 perfectly communicates an abstraction 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 recognizable by a general population.

Coherent:

The abstraction should contain a related set of attributes and behavior that makes sense from the viewpoint of the modeler. The attributes and behavior must 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, because it does not make sense from the viewpoint of a designer building a sales-tracking system.

Accurate:

The abstraction should contain only attributes or behavior that are displayed by 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 under which this principle may be relaxed. For example, in a virtual environment it may be possible to walk through the walls in a scene, although such behavior clearly violates the behavior of real walls.

Minimal:

The abstraction should not contain attributes or behavior extraneous to 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 not including this attribute would be incomplete.

These properties are clearly subjective and qualitative in nature, implying that the ability to form good abstractions requires good judgment as well as the benefit of practice and experience.

Tasks

1. Define plausible abstractions for an "automobile" from the point of view of:
   
   • the manufacturer
   • the owner
   • the government licensing agency
2. Evaluate your "automobile" abstractions against the four properties of good abstractions.
3. Identify a common, real-world entity and at least three different points of view that would lead to different abstractions of that entity.