What is MDA?
Model Driven Architecture (MDA) is a new way of developing software which
promises faster development, less code to maintain, and higher code quality.
MDA is a standard by the Object Managment Group (OMG),
which is known for their other Standards CORBA and UML. OMG describes MDA
as follows:
MDA defines an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform.
And this is one of the key points of MDA: Separation of the business knowledge (the domain model of your application, the system functionality) from the technical knowledge (the experience, patterns, libraries you use, when you write programs).
How can this be achieved? The first thing is, that you need to model your application independent from a technological platform. Actually you should already be familiar with this concept, as a probably already have written use cases or sketched UML diagrams. What you than have is a so called platform independent model (PIM) in MDA speech.
But what exactly is a model? The MDA standard says:
In the MDA, a model is a representation of a part of the function, structure and/or behavior of a system.
So a model is not only a UML-Model, but may also be a textual use case, or even the source code of your program (which is certainly a good representation of the behavior of your program ;). So, if you want, a model is about every artifact you create, when you develop software.
An important concept of MDA is, that there are several levels of abstraction: A class model is more abstract than the source code and the source code is more abstract the the assembly code. But all those models represent the same software.
This is nothing new. What is really new and the key point of MDA is, that the models are no longer separate artefacts (and need to be maintained separately), but with MDA you start with the most abstract model - the PIM - and derive new, more concrete models from it, the so called Platform Specific Models (PSMs), till you come to your source code. If a software artefact is a PIM or a PSM is just a matter of what you consider as the platform.
In model driven software development (MDSD) the so called
model transformation, in which your PIM together with
some other information is transformed into the PSM, is not only
done once, but each time you build your project. So, if you
make changes to your abstract model, those changes will be
reflected in the actual program, as soon as you do a new build.
This "other information" is actually as important as the model itself. When you draw a class diagram of an application based on textual use cases, you do model transformation by hand. But to automate model transformations, you need:
- A so called formal model, which follows certain syntax rules.
- Some additional information like annotations (which elements of the PIM will be transformed into specific PSM elements, e.g. which classes are persistent) and templates (the blue prints for the PSM elements).
- A tool, which actually transforms your PIM (together with the annotations and templates) into a PSM, which can, but doesn't have to be source code.
Most MDA tools use UML as the formal language for models. Annotations
are done via stereotypes, tagged values, or UML profiles.
Many MDA tools come also together with a set of ready to use templates for different kind of technical platforms, most often seen: EJBs.
I don't really think, this is, what a professional software developer wants, because each company and individual has its own picture of the best architecture for an application. So, if you really want to do MDA, you will need to write your own templates. But surely the provided templates are a good starting point.
After you have seen, what MDA is (in my point of view ;) let me summarize the benefits of using MDA to develop software:
- Once you have a set of templates, you can develop on a much abstracter level than programming: You only need to change your model to change your application. This means less code to maintain (the model is much smaller than the generated source code) and high quality code (at least the code, which is generated).
- If you need to upgrade an application to a new technical platform, you don't need to develop everything anew, but only the templates. The business model stays.
- If you develop a new application on a technical platform, on which you already have developed another application, you can reuse the templates and only need a new business model.