On the preliminary study, I think abstractions is not fiction or imagination. An abstraction itself is certain object/entity in the world – in a physical, cognitive or computational space – however, it is never an isolated thing but has certain source or basis that the abstraction is abstracted from, to distinguished from such as fictitious or imagined thing. It has a source where there are objects/entities which are more concrete than the abstraction, and have certain correspondence with the abstraction, that is, a source-objects-to-the-abstraction (source-abstraction for short) correspondence. Notice that the ‘objects’ in this essay are in general sense but not in the Object-Oriented sense.
Abstractions in Computational Aspect
In the field of IT and applications, ‘abstraction’ are often appeared not about cognitive nor physical. So I extended the Table I-1 from the previous essay, as Table II-1.
Table II-1: Extending Types for Abstractions to Computational
|homogeneous||water from rivers,||‘life’ from organisms||a class from the objects|
|non-homogeneous||photo from real world objects,||‘moon’ from the real moon||data from the real worl|
In the table, I added a new space for abstractions, the computational aspects. For the examples in the table, say an abstraction “a class abstraction from the objects” is homogeneous, in the sense that both the class and the objects are carried on the same media, such a language/program (and do not depends on the specific physical materials); an abstraction “data abstraction from the real world” is non-homogeneous, obviously, data in an computer have different media (materials) from the actual thing.
Simplification is a bad word for Abstraction
In such the software field, it appears often explaining abstraction with some words such as ‘simplify’, ‘refine’, ‘reduce’ etc. These words are quite matching the simplest abstraction, as the example “water abstraction from rivers” in the table, yet, a basic definition in many dictionaries: “remove something from somewhere.” However, I have many reasons to argue that, those words, such as ‘simplification’, are bad words for abstraction. It sounds obvious but too apparent to most types of abstraction we concerned.
If you want represent – abstract – some thing from a reality, It had to be expressed in certain data. So I will talk above issue on data modeling. In Navathe&Sham’s book Fundamentals of Database Systems (4th ed.), discussed four abstraction concepts for data abstraction process, which are used in semantic data models or KR schemes (p110-113): (1) classification and instantiation, (2) identification, (3) specialization and generalization, (4) aggregation and association. The (1) and (3) are inverses but (4) are not, I divided them into two types of abstractions. (see explaining later)
Table II-2: Types of Abstractions for Data Modeling
|Objects at Source
|classification and instantiation||instances (objects)||a class||is-an-instance-of (is-a-member-or)|
|specialization and generalization||instances (classes)||a class||is-a-subclass-of (is-a-subtype-of)|
|aggregation||components/parts/ properties||an aggregation (object)||is-a-part-of (is-a-component-of)|
|association||objects playing roles||an association/relationship||is-a-role-of (is-a-participator-in)|
|identification||an individual object||an identifier||is-denoted-by|
Note. In data modeling, it is usually using ‘entity/type’. All ‘object’ and ‘class’ can also add/replace with ‘entity’ and ‘type’ in the table.
Based upon the discussions above, it may
- say a classification (class/type) is an abstraction, since that it has certain common properties/attributes that are selected/copied from some objects/entities at the source;
- say a specialization is an abstraction, since that classes/types themselves can also be objects/entities, and thereby be instances of some super class. A super class/type abstraction from some subclasses is usually homogeneous but the classification is possibly non;
- say an aggregation is an abstraction, since that it is a collection of certain objects/entities at the source, but can be played as an object/entity on another level;
- say an association is an abstraction, since that it is an object/entity with some roles which are played by some objects/entities, and the roles is belonged to the abstraction but not the objects/entities at the source;
- say an identification is an abstraction since that it is denoted an individual object/entity as the source.
Notice that, all the abstractions are not as a simplification, not like “remove something from somewhere” as “water abstraction from rivers”, even if for a class from some objects in data – as a homogeneous abstraction – the class itself ought be a data entity and have certain construct but not some thing that simply extracted from the source. We can find more examples, such as an assembly instruction from machine instructions, an API from operational system, and so on. I think, almost all of the types of abstractions in computational space cannot be understood as ‘simplification’.
Overall, The word ‘simplify’ is not suited to most types of abstraction that interested by us, and, on other hand, it is easy to lead astray, to lead us understanding the modeling for some software and the applied domain as a simple mapping between the Objects of software and the entities in the domain, even more, to lead us to be under a delusion that see a whole of software as a ‘simulation’ or an ‘abstraction’ that extracted some objects what concerned, from the real word.