In my humble opinion, MDA is just another buzz-word that describes how good programs were written from the inception of programming. Any programming by itself is rather worthless. Only when a person writing the program understands who and how will be using it and has a clear vision of the goal, the probability of making useful software is increasing. I started programming in early 1970's and flowcharts were then the means to present the algorithms, data flow and - of course - the work process (now often called - workflow). Using flowcharts - in any form - is important for outlining the limits of the software project and it's place in the work process. Many people were trying to come up with various "abstractions" but in the real world at the end of the day the work process (use cases) will determine the limitation of the program capabilities and the applicable domain. The MDA paradigm/pattern promotes nothing more than "common sense" which is a good guidance under any name.

The idea of MDA is to create high level models. From these models we can derive lower level models using tools as weavers. The MDA / MDE approach is still in development right now. The broad goal is to model at very high level (business model, domain knowledge model) and to derive architectural models, and then UML models, and then source code. The las step needs additional models: hardware models, compiler models, middleware models, etc. in order to create an efficient  source code (this additional models are not that good now). I think genetic programming is not that well suited for MDA because a genetic program must be very efficient.

Frankly said, I cannot see any reasonable way of using MDA approach in genetic programing. MDA is perfect for building large software applications having exact requirement specification and exact software implementation - it is a deterministic process of modeling.