What is the differences between Traditional code-b

问题:

I've found this paragraph in the literature but I didn't understand the meaning of it

Design practice is moving from traditional code-based engineering, with a strong division of work along the development life cycle, to model-driven engineering approaches where all people in the design flow can have their saying on the models.

Any help would be very appreciated

回答1:

I am not sure that I agree with the way the sentence was written, but then I may be missing some context and, in any case, it is not the gist of the question.

Traditionally, computer time was expensive so design typically happened on paper - reams of paper sometimes. Designer would write down the requirements. During the design phase, they drew some diagrams on paper using plastic "RapiDesign" templates (I still have mine...) to depict program and data flow diagrams, ladder (logic) diagrams, signal diagrams, etc. Once that was done, various techniques were used (such as "Structured English") to define how the programs would run. The programmers would then take this information and actually write code (assembler, COBOL, FORTAN, C) that could be run on computers.

The next step in evolution was to build software tools to better handle some of the work. The modeling tools were born, many with different ways of showing the information. These early modeling tools were glorified drawing programs with little semantics established to support the model. They were basically good enough to automate the process and make it easier to revise the drawings. Early releases of Rational Rose (based on the Booch notation) and Popkin System Architect would be examples of such tools.

As these tools added more capabilities and associated methodologies, they also added some semantics (sometimes implied in the methods). This made it possible for these tools to start generating some code. As these tools were mostly interested in object-oriented approaches, the code generated was mostly the class definitions. The lack of behavioural semantics prevented the creation of the actual running code.

In parallel, the UML (Unified Modeling Language) made its apparition in order to help join the various languages, starting with Booch, OMT, and Objectory. As the UML evolved, its meta-model became more complex, more strict, and more behavioural semantics were added. More recently, an abstract language framework (ALF) was also defined in recognition that the actions that a program need to take can not always be expressed using the graphical UML notation.

Note that other methods have also appeared in parallel to UML. Some notable approaches that implemented a model-driven engineering approach are ROOM and SDL, both rather domain specific and both providing capabilities to the evolution of UML (e.g., ROOM: structured classes, SDL: Message Sequence Charts).

This is now were we are, in the model-driven engineering world, where formalised models with defined semantics are used in the design process, instead of drawins on paper and blackboards, to drive the code used.

In some specific domains with supporting tools, you can even see cases where the complete application is generated and deployed from a model - the model is becoming the code.

This whole modeling history is also a continuation of the evolution of the generation of running software, where the level of abstraction was kept rising from programmable gate arrays, to binary, assembler, 2GL (e.g., C), 3GL (e.g., C++), and now models.

回答2:

Code-based engineering means that the most of work is done while coding and in code. It is not a widely used term. It is not a project management method, on the contrary, it appears as a negative description of some bad PM practices, when a developer starts to code almost immediately after (s)he gets the task. This method was used before and alas, is used now, too.

The source of longevity of code-based programming is that in its best variant it is quite usable for short projects - up to 1k lines. We can write the description/model right into commentaries, rewrite them one or two times using Structured English (I am accustomed to name Pseudocode) and go to code into the same file(s). It really works for smaller project, people start from smaller projects and often are accustomed to this method as students and move to others developer algorithms with difficulties. But they MUST, because the method doesn't work for bigger projects.

Model-driven engineering means that the product created is periodically compared against the model of it. The model is changed, too, and is a constantly moving target that the team needs to reach. The term appeared in Agility programming, so, it is relatively modern.

It is opposed to test-driven and requirements-driven engineering, not to code-based engineering. It is possible to make code-based AND model-driven project. But I wouldn't advice it.

回答3:

History

Code-based engineering to me means that programmer creates some model in his mind and writes corresponding code. When the requirements change programmer changes the model in his mind and rewrites the code. Such a programmer is also known as programmer-analyst. (s)he creates code from vague often unwritten requirements and does not need anything else. one man show

Future

On the contrary the model-driven engineering means that before the coding work is done, the requirements must be clear enough, written down and some "model" of the target system and of the code must be created. Using some modeling standards like BPMN, UML etc. This modeling thing is usually done by some non-programmer, some "analysts". Programmer then takes the model (after it was approved) and materializes the ideas into code. This approach scales better especially for large systems.

The ideal end of this approach would be that no code (with bugs) would have to be written manually at all. The modeling tools should support Model Driven Architecture (MDA) and perhaps even Executable UML so that the result of the modeling would be more then set of "pictures" and clarified requirements. It could become skeleton of source code forming the backbone of the application or it could be even model-click-and-run product.

Reality

e.g. Sparx Systems Enterprise Architect contains many Model Driven Generation (MDG) Technologies that make this approach reality to some extent. You can turn existing code (many languages supported) into the UML model through reverse engineering and after modification generate code (many languages supported) from the model. Many UML modeling aspects (behavioral, structural) are supported. If you want to get some real picture and your interest is more than "academic research" then I recommend you to play with this software.

(It is not free, but you can obtain evaluation license and for serious work it will pay the costs multitude of times as there is tremendous amount of effort put into the product. I'm biased because I'm their happy customer)

回答4:

You may consider difference between code-based and model-based approaches as movement to higher abstraction level programming language. For example there are assembler languages and higher level languages like C/C++, Java etc. So, model languages like UML is just a next step toward to abstraction from technical details and more concentration on problem to be solved. As any language it requires compilation/code-generation to "low" level languages, which is Java in EMF case.