The Model Driven Software Network

Raise your level of abstraction

What is the essential difference between MODELING and PROGRAMMING?

 

When the level of abstruction was rised from punched tape to assembly, 3GL or 4GL, even visual IDE, we always call the jobs “coding” or “programming,” the articles “source code” and “object code,” and can automatically transform the high level works into the lower.

 

However, sometime we started to use the “modeling” and “models” rather then “coding/programming” and “(scource) code.” We still believe that we can automatically carry out the transforming from the high level(the models) into the lower(it's still called as code).

 

Why must we change the words, even said “using modeling languages as programming languages?”

 

What is the essential difference between MODELING and PROGRAMMING, models and code, modeling languages and programming languages?

Views: 7724

▶ Reply to This

Replies to This Discussion

Permalink Reply by Model Practice on March 24, 2011 at 11:13
what I mean is that independent from its domain, even if it comes in different notations, every languages has a certain level of expressiveness.  think e.g. of the chomsky hierarchy.
Permalink Reply by Mountriver TY Yu on March 24, 2011 at 13:35

Well, ...maybe I sensed some thing you said.

According to your clues, it seems can say
a machine language maybe close to recursively enumerable or context-sensitive language corresponding to Chomsky hierarchy Type-0 or Type-1, and
a high-level programming language maybe more close to a contex-free language at the Type 2, thus
a modeling language such as UML is basically close to a regular language at Type-3, it (a model by it) can be taken such as some business context then has rich semantics to describe a system include software  intended.

Is that so?

Permalink Reply by Model Practice on March 24, 2011 at 22:01

roughly, yes. where I think in much smaller bits than the whole UML.

 

by the way, regular languages have the same expressiveness as (relational) Monadic Second Order Logic. This is how Finite Model Theory comes in.

Permalink Reply by Model Practice on March 24, 2011 at 22:22
the point is that languages from propositional logic up to chomsky-0 form a hierarchy, where modeling comes from the low and programming from the high end.
Permalink Reply by Mountriver TY Yu on March 25, 2011 at 3:49
I see, it looks so beautiful! You point out something more clearly, also I was looking for. Maybe it is one of the important piece of a jigsaw.
Moreover, in respect of such as the question about the difference and relationship between models and code, I have some thoughts in other sides yet. I'll share it for comment as soon
Permalink Reply by Bill Lewis on September 26, 2011 at 17:56
The intent of modeling is to express business specifications; the intent of programming is to implement specifications via databases and executables. The gap between the two results from assuming that specification models are abstract to the extent of leaving out essential details. On the contrary--specification models expressed in sufficient yet implementation-independent detail should be transformable completely and accurately into databases and execution units (programs).
Permalink Reply by Mountriver TY Yu on September 27, 2011 at 2:28

Hi! Lewis,

Would you explain the 'business specifications' more?

Is it a model of/to/on/in(?) an application system / the requirements for an app system / the functions and behaviors of a app system in a business, even the the business (problems related to the system) ... ?

 

I think this is a very good question (as you said at next reply):

Does raising the level of abstraction indeed raise the level of obstruction?

My answer is no, if we get enough good approaches to make and use abstractions and, one of the key is the two ways to abstracting (modeling).

Permalink Reply by Bill Lewis on September 27, 2011 at 13:05
In my opinion, business specifications for a software application need be nothing more or less than structured expressions of 1) the data used by the business, and 2) what should and should not happen to that data.
Permalink Reply by Mountriver TY Yu on September 27, 2011 at 15:28

Well, data (base) and the rules, operations, that's all.

I think it can perhaps be regarded as a classical philosophy to enterprise applications but,

it also has been challenged by equally classic problems: the change of data (and the schema), the islands of data, and so on...

it seems have no essential improvement in the past three decades?

Permalink Reply by Bill Lewis on September 27, 2011 at 15:42

Agreed, no improvement--things have actually gotten worse, I think.

I believe the root cause of the classic problems is that we really haven't gotten to a viable, persistent structure/model (syntax and semantics) for specifications yet. This is what I've been working at for a while now.

Permalink Reply by Mountriver TY Yu on September 27, 2011 at 16:00

That's a very long topic...I wrote some thought like this, your comment?

It's 00 o'clock. Have a nice day, and good night, for me :-)

Permalink Reply by Bill Lewis on September 26, 2011 at 17:58
Perhaps raising the level of abstraction does indeed raise the level of obstruction...

RSS

Badge

Loading…

Get Badge

© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service