Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Adding Code Bodies
Executable models are not exactly the same as code3 because they need to be woven together with other models to produce a system. However, because each model is complete in itself, once woven, the system is complete.
An alternative approach to building a system is to copy the structure of a PIM into a platform-specific model (PSM) and then add code bodies. (Obviously, these code bodies need to be "protected" so that a change in the model or the regeneration of one does not cause the disappearance of the hard-won code.) The PSM can also be expressed as a graphical model that can then be manipulated by adding further code details or otherwise reorganizing its structure. There may be several transformations, and code may be added at each transformation. This has the advantage—it is said—that code is added only at the appropriate time, at the appropriate level of abstraction.
We may also distinguish this type of MDA by its reliance on successive transformation. The typical scenario is to define a profile for a language that has a lower degree of abstraction, as represented by the ovals in Figure 3. For example, a subset of UML may serve as the "analysis" model that has no knowledge of remote or local objects, while another, larger, subset serves as the "design" model which does have knowledge of accessibility. This model is then transformed again into a still less abstract language, perhaps against a profile of a platform such as CORBA.
){kind=link}
Yet code bodies are inherently dependent on the structure of the model for which the code is intended. For example, any code written for a target platform that assumes remote procedure calls can only be used in an environment that uses remote procedure calls, even if the subject matter captured by the model is banking. The result of this approach is that models are not universal, but instead form silos that mix the platform and the subject matter at hand. This is an architectural mismatch. Agile MDA explicitly addresses this problem by treating all models as equal and merging them together at once.
Obviously, models of this sort cannot be executed. In fact, to be blunt about it, these models are really an automation of a heavyweight process. This is not to deprecate that usage—some people have to do it that way—but it ain't agile!
The Agile MDA approach is to build executable, translatable models, which are complete models linked together with others without further intervention or elaboration by a process of translation.
In Agile MDA, because each executable model is a PIM and the model compiler compiles the models to make code, you might ask what happened to the PSM. The PSM is there alright—it's the code. Code is a weaving together of the elements of the PIM and of the required platforms, and it executes too. In Agile MDA, there is no need to manipulate the PSM or to visualize it as a model. We go straight to the ultimate PSM: the code.