Doga, I'm also a Joe Yoder and Brian Foote fan, and have followed their work, and the work of Ralph Johnson, for many years. An adaptive object model is effectively a software factory with an interpretive run time, instead of code generation. You can use our technology to build one. You can also follow our progress on an adaptive object model that dynamically provisions datacenter facilities and automates deployment based on metadata describing the components to be deployed and the infrastructure configuration required to support them. This work is part of our Dynamic Systems Initiative. Metadata driven runtimes have been used extensively in the past, and are notoriously hard to debug. Generative techniques help address this problem, but are less responsive to change. In practice, a combination of adaptive and generative methods usually provides the best overall solution. The key to both is defining the problem domain, and then developing both design time and run time assets for that domain to facilitate the development, deployment, execution, operation and maintenance of solutions.
A common design time asset is a domain specific language that captures appropriate abstractions for the domain. Models developed using the DSL can then be used to generate either code, where debugging and correctness are more important than run time adaptation, or metadata to be interpreted, where run time adaptation is more important than debugging and correctness. The run time is either a framework in the code generation case, or a run time engine in the adaptive object model case. Metadata interpretation, as expressed through adaptive object models, is usually appropriate only when the domain is well understood enough that the range of possible variations in the solution can be predicted, and their correctness demonstrated, usually through formal model analysis or similar techniques. This allows the run time to be parameterized with metadata that modifies the run time in response to changes in requirements, operating conditions or other factors. An adaptive object model is usually the result of prior experience in the domain based first on manual construction, from which patterns are harvested, then on manual framework completion using a framework based on the patterns, and then on a generative approach based on a domain specific language that wraps the framework. It is usually only after enough experience has been gained that the framework can then evolve into a dynamically reconfigurable run time. A prime example of an adaptive object model, and of the evolutionary pathway just described, is a relational database management system. RDBMS and the SQL language were the result of prior experience with hand coded data access, frameworks providing indexed sequential access methods (ISAMs), and early data modeling efforts based on ISAMs.
For more on managing variation in product lines, I highly recommend the work of Jan Bosch, of the University of Groeningen in the Netherlands. He has written a number of papers describing trade-offs among variability management mechanisms, with several examples of run time adaptation.
Jack Greenfield | Architect | Enterprise Tools | Microsoft | 
index > Visual Studio Team System - Architects > Adaptive Object Modelling