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
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.