12.1 The MDA Paradigm Shift

In Chapter 1 we explained that the MDA development life cycle is not very different from the traditional life cycle. What is crucial is that the MDA, when fully implemented, will establish a shift of focus within the life cycle. To explain this vision on the MDA we will take a look at the history of programming.

12.1.1 A Historic Perspective

In short, we can characterize the history of programming along the time line given in Table 12-1. Each period is characterized by the dominant type of programming language. The programming languages used in each period are built on the assets of the previous period.

First there was raw machine code, which automated the wiring of computers. Next , symbolic representations of this raw machine language, called assembly languages, were made, and assembly language programs were converted to machine code by an automated tool called an assembler. Following, there was the time of the procedural programming languages. These were built on top of assembly languages. They were designed to be easier than an assembly language for a human to understand, including things like named variables , procedures, subroutines, and so on. Compilers or interpreters were used to convert the programs into assembly or raw machine code.

Object-oriented programming languages were built on the assets of procedural languages. They extend the procedural languages with much more powerful structuring mechanisms. Often compilers for object-oriented programming languages use a two-step method. First the program is translated into a low-level third-generation language, next this result is compiled into machine code.

Table 12-1. History of Programming

Years	Programming was done by...
1950	Raw machine code
1950 “1965	Assembly languages
1965 “1985	Procedural programming languages
1985 “today	Object-oriented programming languages
today “ . . .	What is next?

12.1.2 A Shift of Focus

Looking back, we see that there has been a shift of focus in the development of computer programs over the years. In the early years the focus was on writing programs using low-level constructs. Later the focus shifted to writing programs using higher level constructs. The fact that these higher level programs had to be translated to programs using lower level constructs is almost forgotten. Programmers need not worry about generating assembly or raw machine code, because the task has been automated and one can rely on a compiler.

Taking the MDA approach, the focus will shift to another level. Nowadays the focus is on code, often written in an object-oriented programming language. In the future the focus will shift to writing the PSM, and from there to writing the PIM. People will forget the fact that the PSM needs to be transformed into code because generating the code will be automated. Maybe some years later there will even be people who will forget that a PIM needs to be transformed into a PSM.

In the future the MDA development life cycle will not be shown to include an artifact called code as we did in Figure 1-2 in Chapter 1. Instead, it will look more like Figure 12-1, leaving out the gray parts . Most people will think that when the PSM is completed, one can go directly to the testing phase.

Figure 12-1. MDA software development lifecycle revised

12.1.3 Too Good to Be True?

When explaining the MDA to software developers, we often get a sceptical response. A typical reply is, "This can never work. You cannot generate a complete working program from a model. You will always need to adjust the code." Is the MDA really too good to be true?

Well, we don't think so; otherwise , we would not have bothered writing this book. We believe that the MDA will change the future of software development radically . One argument for this is that although the MDA is still in its infancy, you can today achieve great gains in productivity, portability, interoperability, and maintenance effort by applying the MDA using a good transformation tool. Therefore it is, and will be, used even when not all of the elements of the framework have been established yet, like the transformation definition language. A second argument comes from the history of computing.

In the early 1960s our industry was in the middle of a revolution. The use of existing assembly languages was substituted by the use of procedural languages. In those days, too, there was a lot of skepticism, and not without reason. The first compilers were not very good. The Algol programming language, for instance, offered a possibility to give hints to the compiler on how to translate a piece of code. Many programmers were concerned that the generated assembler code would be far less efficient than handwriting the assembler code themselves . Many could not believe that compilers would become so good that they could stop worrying about this.

To a certain extent, the skeptics were right. You lost efficiency and speed, and you couldn't program all the assembler tricks in a procedural language. However, the advantages of procedural languages became more and more obvious. Using higher level languages you can write more complex software much faster, and the resulting code is much easier to maintain. At the same time, better compiler technology diminished the disadvantages. The generated assembler code became more efficient. Today we accept the fact that we shouldn't program our systems in assembler. It is even the opposite , if someone says he is planning to write his new customer relationship management system in assembler, he would be declared insane.

What MDA brings us is a similar revolution. Eventually, PIMs can be compiled (read: transformed) into PSMs, which are compiled into procedural language code (which itself is compiled into assembly or raw machine code). The PIM to PSM compilers (read: transformation tools) will not be very efficient for some years to come. Its users will need to give hints on how to transform parts of a model. But eventually, the advantage of working on a higher level of abstraction will become clear to everyone in the business.

In conclusion, we can say that although the MDA is still in its infancy, it already shows the potential of changing software development radically. No, we will not tell you that from this day on you and your team will not have to write a single line of code. Of course you will need to bother with code for the next few years. Instead, we argue that you are witnessing the birth of a paradigm shift, and that in the near future software development will shift its focus from code to models.

The shift of focus from code to models will have consequences on the software development process, the languages used to write models, and the software development tools. We will examine the consequences for each in the following sections.