Enterprise Engineering Forum

企业工程论坛
Categorized as: 其它基础课题   Tagged as: ,, , , ,

Abstraction (II) Simplification is a Bad Word

Author: Mountriver TY Yu,  Source:  EE-Forum.org,  Published: 2011-08-11

Excerpt: An abstraction itself is certain object/entity, it has certain source or basis that the abstraction is abstracted from. Added the computational aspects to extended the four types of abstractions from last essay. Simplification is a bad word for Abstraction. Some discussions on the types of abstractions for data modeling, etc.

Source-Abstraction Correspondence

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

Physical Cognitive 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

Type of
Abstractions
Objects at Source
(concrete)
Abstraction
(abstract)
Source-Abstraction
Correspondence
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.

Copyright

Creative Commons License
Modeling on Black/White-boxes, and Abstract Level by Mountriver TY Yu is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Cite Style

GB7714 style: Mountriver TY Yu. Abstraction (II) Simplification is a Bad Word[EB/OL]. EE-Forum.org, http://www.ee-forum.org/wp/pub/ty/2011-08-p2948.html, 2011-08-11[2017-07-23 10:32]

Chicago style: Mountriver TY Yu, "Abstraction (II) Simplification is a Bad Word", EE-Forum.org, http://www.ee-forum.org/wp/pub/ty/2011-08-p2948.html(accessed 2017-07-23 10:32)

Posted by   2011-08-11(Original)   Hits 7227   Modified 2011-06-13(Locked)
Prev Post: 
Next Post: 

Related Entries:

FMC: How Do We Capture the Idea of a Discrete Dynamic System? Wendt’s Answer
Simplification (Abbreviation, Reduction) is Not the Essential Feature for Concept of Model
An FMC ER Diagram Model of Model-Driven Mechanism (MDM)
Open World and Finite Models
An FMC Block Diagram Model of MDApp

Leave a Response

You must be logged in to post a comment.