The Model Driven Software Network

Raise your level of abstraction

I have seen some people believe or like the proposition: “software is abstraction of real world.”

Do you agree it?

Tags: abstraction

Views: 94

Reply to This

Replies to This Discussion

don't know, but haven't heard of a real world bill that's able to reckon its sum, yet?

|=

Hi |=,

May be, in the futrue, my grandsons will say: “I never heard of a bill needs to reckon its sum manually!” as there are not paper bills in their world. ;-)

I don't think that software is an abstraction of the real world. Software usually cooperates with/supports the real world. It usually fills the "missing parts" in a human-defined process or automates a human task.

 

I am excluding simulation software, of course, which has the exact purpose of replicating a specific aspect of our world.

 

Because software is abstract, we need to bring the world to the same level as software (that is, to abstract the real world) so that software can cooperate/connect with it.

 

Hi Rui,

Would you like to explain these

- Software is not (an) abstraction vs. Software is abstract, isn't there some conflict?

- Does an abstraction have certain source/base?

- What (where) are the abstractions of the real world? Are they models?

OK, I'll rephrase that.

 

Excluding simulation software, whose purpose is to simulate the real world, software is not an abstraction of the real world. Software *works with* abstractions of the real world. These two sentences seem to say the same thing, but they don't.

You can abstract over real-world things, but you can also abstract over concepts, math, etc. For instance, a database table is an abstraction of a "non-real-world" thing, Don't confuse a table (a meta-concept) with what it may represent in the real world (a concept).

 

By definition, an abstraction is a mental *model*. That's the ultimate source. Whether you put that on "accessible media" (paper/file) it's another thing.

 

So, my final statement should be : "Software *can* be an abstraction of the real world".

 

A hard topic, nevertheless...

Techically, software program (if that's what you mean by 'software') is a model. So yes, it is an abstraction or simplification of a part of real world. The part being either a business system that needs to be built or an existing system (running program).

Hi Andriy,

- Do you say that a model is an abstraction?

- What is the 'program' you mentioned? is a program in java, or is a program in machine code at RAM? And,

- If they are models, What are their 'subjects' (originals, or SUS, Systems Under Study)?

Model captures knowledge about a SUS. Abstraction/simplification is a very useful property of models. (A perhaps useful side note is that depending on the use of a model, the model can be a 'specification' or a 'representation' of a SUS).

A program in Java or machine code or any other programming language is a model. However, nowadays the abstraction levels of these languages is too low (certainly that of machine code), so noone calls such programs models.

It is easier to answer the last question with help of an example. Let's say that the part of real world under study (SUS) is a tank station. In this domain typical real world objects are tank, fuel dispensers, fuel, cars, drivers, etc... An example (software) system could assist a human operator to detect requests to tank, grant requests, transfer due amount to cashier, etc..

A software developer experienced with the domain, will very likely able to outline code corresponding to these domain objects. How precise and easy such outlining is, depends (among others) on the used programming paradigm (e.g. domain objects are easier to capture in OO than procedural languages). Moreover, if software is designed in domain-driven way (see DDD or Domain Driven Design), one would literally see classes in the domain layer of the system, that (classes) correspond to the domain objects: tank, fuel dispenser, fuel, car, driver, etc.

And of cause software is abstraction of more things then domain objects. Moreover, the answer to your question also depends on the definition of "real world". A hard topic indeed.

Howdy!
It seems quite difficult to have some constructive results if not changing the topic somehow...
(Maybe we should put 'models' aside temporarily, although that topic is more appealing)
I think, the more fundamental questions maybe (in the context such of software engineering):

a. What is an abstraction?
- I think that, at least, it need to be out of the mental range, right?

b. What is the meaning about abstract level or say something is more abstract than other?
- I am very interested in Rui's statement:  “Because software is abstract, we need to bring the world to the same level as software (that is, to abstract the real world) so that software can cooperate/connect with it.” so it's necessary that to answer this question.
The programming languages level (machine code, assembly, high-level language...) is the best clues?

Or,
c. We don't need the notion of  'abstraction', it can be removed with Occam's razor?

"Only through the sun-like nature of the eye are we capable of seeing light."
(Goethe, or less poetic Plotinus)

 

I think software primarily serves some purpose, which is typically (always) related to something concerning the real world. Software manipulates, reflects, simulates, describes etc. the real world. Naturally, software is (should be) structured to serve it's purpose the best possible way. For economical reasons (Occam's razor...), the relation between software and it's domain should be a simple one (isomorphic...), and therefore relevant parts of the real world are reflected within parts of the software.

Hi, Andreas!
Thank you bring me more 'sunshine' this morning!
Your opinion is very close to that I am thinking.
To serve some purpose for the real world, software must have/reflect certain nature or information about some part of the real world, and, it is in or part of software but not the whole. I think this is significant to modeling for or constructing software.

RSS

Badge

Loading…

© 2012   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service