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: 8272
Replies to This Discussion
-
Permalink Reply by Model Practice on
-
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
-
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?
-
-
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.
-
-
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.
-
-
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
-
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).
-
-
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).
-
-
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.
-
-
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?
-
-
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.
-
-
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 :-)
-
-
Perhaps raising the level of abstraction does indeed raise the level of obstruction...
- ‹ Previous
- 1
- 2
- 3
- Next ›
© 2019 Created by Mark Dalgarno.
Powered by
