| Abstraction of a SalesPerson |
|---|
 |
Abstraction is concerned with both the "attributes" and "behavior". Attributes refer to the properties or characteristics associated with an entity. Attributes typically correspond to the data that is recorded for an 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. The "behavior" represents the set of actions that the object can perform. An action usually corresponds to an action that the real-world entity might perform. 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 (singSong, doDance, haveChild, getSick, increaseCreditLimit, payBills, etc.). Trying to capture even a small part of this enormous detail in a software object is pointless. What is important is to capture those aspects of a "salesperson" that are relevant to the development of 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.
| Abstraction of a SalesPerson |
|---|
| |
The examples above motivate the following definition of abstraction:
It is important to realize that 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 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.
| Abstraction of a Patient in a Medical Database |
|---|
 |
Properties of a Good Abstraction
While there may be may abstractions of the same entity, each
abstraction should have certain properties that distinguish it as a
"good" abstraction. These desirable properties are:
These properties are clearly ones that required a substantial amount of judgment. This fact implies that the ability to form good abstractions also requires good judgment gained by practice and experience.
|
|
| Exercises |