The Model Driven Software Network
Raise your level of abstraction
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?
Tags:
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.
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).
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 :-)
© 2019 Created by Mark Dalgarno.
Powered by