Blog root page
next post in category
The Model-Driven Architecture (MDA) is an initiative by the Object Management Group (OMG) to standardize infrastructures supporting migration between semantic models that represent different views of the same basic thing. This is especially important in software development where a software solution evolves through several different development stages, such as analysis, design, coding, and testing. In each stage one has a solution that represents some value added to the solution from the previous stage. Typically we can express the solution in each stage as a model. (It is a model of the final software executable because it does not capture every detail of that executable.)
The representation of the model can be fairly arbitrary. Thus the bubbles & arrows of UML and the text of Java both describe a model of the software solution in a well-defined notation. But the fundamental semantics of the solution that is described in both representations will be basically the same -- at least for those elements described in the previous development stage. (Since each stage adds intellectual value, there will be new elements in addition to those from the previous stage.) Because the underlying semantic content is the same but the descriptive notations can be quite different, it is highly desirable to have an unambiguous mapping between stages and their respective representations. Providing that mapping is what MDA is all about.
One core idea of MDA is that every model is a specific instance of some semantic meta model that captures a generic model element semantics. That meta model is much more abstract than any particular software model and it simply describes what model elements mean. Once that meaning is defined, then one can map between meta models without dealing with the details of specific application solutions:
OOA <--------------> OOD <----------> OOPL meta model meta model meta model | | | | | | V V V application application application OOA model <-------> OOD model <------> OOP model
Once the meta models are in place and one has a mapping between them, one can apply those mappings to the individual model elements for a specific application. This allows the tools the developer uses to create each application model to communicate. Thus a tool that does OOD modeling can access the repository in a tool that does OOA modeling and transfer the the relevant elements to the OOD view. This has the potential to make the developer's life a whole lot simpler by making configuration management and requirements traceability much simpler (e.g., one can preserve the OOA model while ensuring the OOD model correctly incorporates all of its semantics).
This was the original view of MDA, a standard to enhance interoperability between different tools used during different phases of the software development. However, it has far a far more powerful application as a basis of automation through translation, which I will address in subsequent posts.
Another core idea behind MDA is the notion of transformation. The basic idea is that one can transform one model instance (e.g., an application OOA model) into another model instance (e.g., an application OOD model) provided one has access to some sort of transformation rules:
[Input Model] [Transformation Model] | | | | V | {Transformation} <------------------+ | | V [Output Model]
Within MDA there are many variations on this theme, but the basic idea represented above is fundamental to MDA's role in software development. It provides the semantic standards that allow the necessary infrastructures to be built supporting the transformation process. As part of that MDA defines a number of different flavors of models that I will deal with in the next post.
The final core notion of MDA is the profile. A essentially defines a configuration for transformation. For example, in an OOA model one only deals with functional requirements. If one is using UML as the notation, then the MDA profile defines UML as the notation. But it also defines what specific elements of UML may be used in an OOA model. This sort of specification ensures consistency when there are are many different alternatives available, which is typically the case for software development.
Before leaving the MDA profile let me point out some other facets as context material in case anyone asks. The OMG has defined a number of frameworks and standards. It has also defined a hierarchy of met models. The Meta Object Facility (MOF) is top dog in the hierarchy and it is intended to have much broader application than simply software development. MDA is an instantiation of a standard within the MOF umbrella. Similarly, UML is an instantiation of OO model semantics within the MDA umbrella, along with other standards, such as XMI. UML itself has four levels abstraction for its semantics.
