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
Replies to This Discussion
-
Permalink Reply by Rui Curado on -
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...
-
Permalink Reply by Mountriver TY Yu on -
So, both the code and the models are formalized, then we can carry out automatic transforming between models and code...;-) But, there is the question yet, why we don't straightforward say so called “modeling” as “programming/coding at a newest level of abstraction?” (like 3GL vs. assembly)
There are some discusses about the “simplifying” of models, the modeling of “behavior”, the “graphical” representations, and the levels of abstraction... even someone say “code is model”. I think all of these aspects seem not the answers about the question.
-
Permalink Reply by Andreas Leue on -
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.
-
Permalink Reply by Mountriver TY Yu on
-
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?
-
Permalink Reply by Andreas Leue on
-
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.
-
Permalink Reply by Mountriver TY Yu on
-
Good example! but I'd rather see the different of the outputs come from the three jobs: to regard them as some processes, the 1.) and 2.) maybe produce the same, but for the 3.)(modeling), its output needs to be input into another process yet, a transformation process, then achieves the same result with the processes 1.) and 2.).The transformation（whether manual or automated）is another necessary work with modeling but not modeling. Maybe this is one of different between modeling and coding?
-
Permalink Reply by Andreas Leue on
-
It depends much on the perspective. Of course, with state of the art technology (MDx), the output from 3 is something to be processed by 1 and 2. If you take e.g. the customer perspective instead, there's no difference, it's all about specifying a system and then get the result from this specification, you do not care about 1, 2 or 3.
After all, the sequence does not end with 1/2. Alltogether you might have something like this (just as one of many examples):
PIM -> PSM -> JSP -> Java -> VM-Code -> Interpreter/Assembler -output-> HTML/Javascript -> Interpreter/Rendering Engine/JS Engine -> Graphic Instructions -> Graphic Processor -> Pixels...
Where is "coding" here?
Obviouly, "coding" is a relative term which refers to something which is below some abstraction layer of current interest.
Equally obviously, the abstraction levels inbetween are quite different. So, to me, the question of "Modelling" vs. "Programming" (as it is discussed in the MDx context) boils down to: what kind of abstraction layer is inbetween state of the art (xGL) programming and business domain oriented modelling? This question points into an information architectural direction.
Some characteristics of this last abstraction between xGL and MDx are:
- the interpretation context is not a machine which is instructed to perform activities to the achieve the actual desired result (i.e. declarative instead of procedural)
- given a PSM, the interpretation context might address platform specific constructs (like a UI, a DB, a communication technology etc.)
- in a PIM, the interpretation context should not even address such constructs, it should address only the configuration of business domain related artefacts, there logical placement and the interaction with them (there is much more to say on how this can be specified)
-
Permalink Reply by Mountriver TY Yu on
-
It seems very different between models/modeling and code/programming but difficult to be stated clearly? I think, coding/programming maybe relative and has many different levels but modeling is also. And I see there are some things very important in Andreas's statements above but, I'd like using them to explain the differences between models/modeling and code/programming:
- the perspective
- the business/problem vs. computer/platform
- the interpretation context
- what is it oriented?
- how it can be specified?
…
I think they are related to the essential differences between models/modeling and code/programming, but the differences maybe not only that yet.
-
Permalink Reply by Model Practice on -
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.
|=
-
Permalink Reply by Mountriver TY Yu on
-
But some people like say that, models are rich semantics against the programmes...
Isn't it seems some contradictory here?
-
Permalink Reply by Model Practice on
-
for example if people`s models comprise the business context of the software as well, it can provide understanding of the semantics.
Also think of a state machine that is relatively easy to capture as long as it comes as a model, but when it is implemented, the big picture gets 'lost' somewhere in the code. Here the model (if you don't burn it after coding) still provides some sort of overview understanding.
|=
-
Permalink Reply by Mountriver TY Yu on
-
It makes sense but IMHO, It's questionable the compare of "expressiveness" between modeling language and prgramming language, or of "semantics" between models and code. Because they have perhaps different object expressed or different semantic domain.
© 2019 Created by Mark Dalgarno.
Powered by
