What are the consequences of applying the MDA on the software development process? Comparing the MDA process to the traditional process, much will remain the same. Requirements still need to be captured and systems still need to be tested and deployed. What will change are the activities of analysis, low-level design, and coding.
During analysis a PIM will need to be developed. There will probably be a special group of people who will perform this task. They will be aware of the functionality that needs to be implemented, and they will be driven by the needs of the business and by the business model.
Most likely there will be a different group of people responsible for the transformation of the PIM to one or more PSMs. They will have knowledge of different platforms, different system architectures, and of the transformation definitions that are available for the transformation tools they are using. They will decide with what parameter values the transformations are to be applied. They will choose between various target platforms and target system architectures. Does the system require a three-layer architecture, or is a simple fat client-server architecture sufficient? Do we use J2EE or the .net as target platform? These are the kind of questions the PSM creator will need to answer. It is the responsibility of the PSM creator to be aware of and act upon quality of service aspects.
To find the answer to these questions, the PSM creator will need some information from the PIM analyst other than the PIM itself. He will need to know about the non-functional business requirements. For instance, when a PIM analyst tells the PSM creator that the system will be used intensively by over five thousand persons, the PSM creator will wisely choose another target architecture, and use another transformation definition than if the system were to be used by a group of five.
Another task of the PSM creator is to respond to changes in both the PIM and the transformation definitions. The PIM and the transformation definitions may change independently of each other. When the business requirements change, only the PIM will be affected. When the target platform changes, for instance because a new version is installed, only the transformation definition will have to be renewed. The PSM creator must respond to these changes because any change must be reflected in the generated PSM. Meanwhile, the previous version of the system that has already been deployed, may contain lots of data that has to migrate to the new version of the system. In the future this task of the PSM creator will need to be supported by tools. These tools may or may not be integrated in the transformation tool.
Because the PSM creator will need transformation definitions, buying or writing transformation definitions will be a task new to the MDA development process. In our view, there will be a third group of people who will write transformation definitions. They will partly be employed by the companies that build software systems, but a large part of this group will be employed by transformation tool vendors . Their tools will only have customer value when transformation definitions are available. Figure 12-2 shows the different participants in the MDA process, the tools they are using, and the artifacts they are producing.
Figure 12-2. Participants, tools, and artifacts in the MDA process