you're reading...

Abstraction (III) Make Long Story Short

It is easy to be long-winded when writing with the topic “abstraction”[1]: it seems a bit like a bottomless pit, when I attempt to think about it in depth. Let me make the long story short, to writing some of my conclusions, while it may be a bit hasty.

Where the abstract levels based on

In the previous discussion, I thought, a basic features of an abstraction is that it is abstracted away from some basis (source). Indeed, an abstraction must had a source or basis: it seems no any counter example in all things called as abstraction. In another aspect, the basis of an abstraction is often an abstraction yet; some of abstractions can be classified into an abstract hierarchy — such as the abstract levels that often mentioned in software field — all abstractions in the same hierarchy should be traced to an original basis, here, call it the base of an abstract hierarchy. It appears to be repeatedly forgotten or ignored in many cases, such as, some discussions of MDA/MDE.

Understanding computing from an abstract perspective

In essence, from an abstract perspective (see the figure), a software application is a union of two kind of abstractions which are from two different sources: the outside world and the computer world[2], it has two kind of abstractions: the abstractions of the things of outside world (the domain it applied in, or the problem domain ), and the abstractions of things inside world of computer (or from the IT domain, such as code/software, resources/hardware)[3], where the abstractions may be appeared as some models that defined explicitly, or in some other forms. Furthermore, these two kind of abstractions should have two different abstract hierarchies which have different bases, perhaps can be called as the outside abstract hierarchy from applied domain and the inside abstract hierarchy from computer/IT domain.

Is software an abstraction of real world

It has become very clear when changing the real world to outside world: there are two things — two bases (sources), as stated above — which need to be abstract from. So, the answer is, software is not an abstraction of real world or of a problem domain but, it has/processes some abstractions from both the outside world and the computer itself.

[1] some previous discussions see part I and part II on the blog, and some relative discussions on MDSN at Is Software Abstraction of Real World? and Note on Languages and Abstraction.
[2] some times maybe using “real world”, as well as the “real world” and “brain” in cognitive topics.
[3] see discussions on this blog, such as Talking Models and Domains to Enterprise Applications: an Addition, etc. It needs more discussion about the meanings and the relation between IT domain and “the world inside a computer”, and the outside world.

(a discussion for the opinions in this post on MSDN at here)


About TY

interested in models & modeling, software, information systems, applications & engineering for enterprises



  1. Pingback: Three Spaces for Entities and Models of Applications « THINK IN MODELS - October 28, 2011

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s



Subscribe notifications of new posts by email.

Join 60 other followers

%d bloggers like this: