In a number of situations, traceability is a helpful asset in the application of MDA. In Chapter 3 we saw that a PIM usually does not contain all information necessary to implement the complete system. A user must fill in the gaps in the PSM manually. When the user has the possibility of changing the PSM, he can potentially also change parts of the PSM that are generated. Obviously, this is a source of trouble.
The least a tool should do is warn its user that the changed part is generated from a PIM. It would be better when the tool can suggest further changes in either PSM or PIM. When, for instance, the user changes the name of an operation in the PSM, the tool might suggest that the corresponding operation in the PIM be renamed as well. An even better tool could perform the renaming. To be able to offer this type of support to its user, the tool needs to trace back the operation in the PSM to an operation in the PIM.
Another situation where traceability is useful is when the project is well underway. The PIM is developed, the PSM is generated and its gaps are filled, code is generated, and then some requirements change. Often it is easier to indicate what part of the PIM is affected by the changed requirements than to tell which part of the code must be adapted . When parts of the code and parts of the PSM can be traced back to elements in the PIM, an impact analysis of the requested changes is far easier to make.
In the case where the system has been delivered and bug reports come in, the parts of the code that are erroneous can be found by looking at the elements of the PIM that represent the faulty functionality. Even when bugs are fixed "quick and dirty" in the code, traceability is an asset, because the necessary changes to the PSM and PIM can be listed by the tool or even automatically executed.