July 05, 2004
4.0 OO mapped into MDA
MDA is about providing common semantic meta models that can be used to create concrete models using different notations. The meta models allow one to unambiguously transfer information between those concrete models. Though MDA was inspired by OO development in general and UML in particular, this principle is widely applicable to situations where models are used -- beyond OO or even software development.
For a traditional OO development I see the correspondence as:
Domain Analysis Design Language Machine Metamodel -> Metamodel -> Metamodel -> Metamodel -> Meta Model | *:1 | 1:* | 1:* | 1:* | | | | | | | | | | | Requirements -> OOA Model -> OOD Model -> OOP Model -> Executable | | | | | | | | CIM PIM PSM PSM Functional Nonfunct. Nonfunct. Strategic Tactical
Because the various meta models are defined within a consistent semantic framework, it is possible to map corresponding notational entities between then unambiguously. Since the concrete models (CIM, PIM, PSM) are instantiations of the corresponding meta model, that makes it possible to map unambiguously between the concrete models as well.
The mapping may not be 1:1, though, because there may be multiple alternatives in one metamodel for a single artifact in another metamodel. That's because software models reduce the level of abstraction moving left to right while additional concerns are addressed at each level. In contrast, most problem spaces are quite complex compared to the computing space and a major task of OOA is map the problem domain into a single mathematically precise notation.
In an OO development context it is important to note that everything model to the left of the Executable is a specification for the stage to the immediate right. However, everything to the right of Requirements is a solution model for the specification on its immediate left. Each stage has a particular focus and the level of abstraction of the solutions decreases as one moves to the right.
In an elaboration environment the application developer provides the bulk of the intellectual content to the concrete models. In such an environment the role of MDA is to support interfaces between the tools employed for each stage so that the models can be seamlessly integrated. In a translation environment, though, the transformation engine typically goes directly from the PIM to a final PSM (3GL model) or the executable. The transformation engine provides the intellectual content for OOD/P through the use of complex transformation and platform models of the computing environment itself.
One of the crucial things that MDA provides is standardization and a byproduct of that standardization is the ability to make the PIMs and PSMs executable. Thus one can execute a PIM model to validate the solution for functional requirements. That validation will say nothing about meeting nonfunctional requirements, but one can demonstrate unequivocally that functional requirements are satisfied by the solution.
In an elaboration process a major benefit of having an executable PIM is to validate the solution for functional requirements prior to committing to the rest of the development. In a translation environment, the PIM /is/ the solution to the customer's problem and no further added value is required from the application developer, other than specifying nonfunctional requirements for the transformation engine.
(Translationists run the same test suite for functional requirements against the code that they run against the model; only the test harness changes.)
Note that if the PIM is not an executable solution, there is no substantive difference between the CIM and the PIM when using OO development. The PIM already expresses the functional solution purely in the customer's terms because that is what OOA is about. While the PIM is based on the same mathematics as that which prevails in the computing space, that mathematics is not limited to the computing space. Nor is it specialized mathematics for the computing space because it is chosen as a bridge that provides rigorous
mapping between both domains. (In fact, there are OOR specification techniques around that even use the same subset of UML as a PIM profile.) So the only thing that distinguishes a PIM from a CIM is that
it describes a particular resolution of functional requirements.