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:
When we program, we create a mental model of the system (or sub-system) and write the source code based on in.
When we model, we are actually *formalizing* (and eventually sharing/discussing) that mental model.
We must then conclude that modeling is always present in software development, but rarely formalized...
I think there are two reasons, an objective and a marketing one.
Objectively, a program is a sequence of instructions to be executed by a machine. "Coding" emphasizes the fact that the text is not easily readable by a human - quite the opposite of the intent of our models. A model shall more or less declaratively describe what the purpose of the system is, if not ontologically refer to the reality domain itself.
In the various attempts of "modelling behaviour" and "modelling UIs" the difference becomes crucial: we can of course (mis)use models to do programming, but the results are not satisfying. It is crucial for successful abstractions to abandon from these low level programming aspects and focus instead on the distinguishing properties of the desired systems.
The marketing reason is obvious: from time to time we want to have a new name for what we're doing, for better and for worse.
Yes, the “marketing” is a factor which can not be ignored. But let's our talk about the meanings itself here. I think, by Andreas's words, the “distinguishing properties” vs. “low level programming”(sequence of instructions), which is closed to the keys. And perhaps it's possible and necessary to be explained more clearly.
I advocate an opinion that “model is not code” and it's significant to the implementation of such as model-code transformation, sync, round-trip, reverse, and so on. Do you agree?
Well understood, "model is not code" seems right to me (for completeness' sake, I'd like to add that there is another meaning of "model is code": to emphasizes that there should be only one single source of the system, and not two: a model, which is translated by humans to code, and both of them have to be maintained; this meaning corresponds to "code as design" idea).
> “distinguishing properties” vs. “low level programming”(sequence of instructions)
To be more specific, an example:
1.) Programming: Writing code in a JSP-Page, which accesses some objects's properties to retrieve data from a subobject and put it into certain edit fields
2.) Tool Supported Programming (Layouting/Widget Assembly/UI Wiring): drawing buttons with a UI designer and attaching callbacks or data from objects to it
3.) Modelling: annotating a business domain class with the stereotype «DataType»
While all three might achieve the same result, from the MDx perspective 1 and 2 are "coding" and 3 is modelling.
From my perspective:
Programming: using a very expressive language and restrict it by coding rules.
Modelling: using a very restricted language, s.t. it is expressive enough, but also easy enough to handle (read, write, ...), for creating different views on a thing.
|=
But some people like say that, models are rich semantics against the programmes...
Isn't it seems some contradictory here?
© 2019 Created by Mark Dalgarno.
Powered by