Introduction
The Model Driven Architecture (MDA) is a fairly new resource in the software development field.
The MDA is a framework for software development that been defined by the OMG (Object
Management Group). It is an approach to creating good designs that can cope with multiple
technology deployments of a software system and is based on widely used standards like the
Unified Modelling Language(UML). The intention of the MDA is to create machine-readable models
that can be understood by automatic tools that generate schemas, code skeletons, testing models,
test packs, and integration code for multiple platforms and technologies.
The central idea of the MDA is to develop and maintain an abstract design of a system that can be
automatically transformed into multiple platform designs and finally transformed into the code that
will realize those deployments.
The core of the MDA depends on the models that are created as part of the software development
process.
There are three models at the heart of the MDA. They are:
- Platform Independent Model (PIM) - The PIM is a highly abstracted model that is independent
of any implementation technology. It describes a software system that supports a part, or the
whole, of business. The software system is modelled from the perspective of how it best
supports the business. The type of technology on which the PIM is to be implemented does not
form a part of the software system at all. The PIM may include generic functions, scenarios
(process descriptions of how the system realizes a business requirement) and class
descriptions.
- Platform Specific Models (PSM) - Using the PIM as a foundation it is then transformed into one
or more platform specific models, which describes in detail how the PIM is implemented on a
specific platform, or technology. Depending on the platforms across which the software system
is going to be deployed PSM's will be created - one per platform, or technology. It is common
to have many PSM's per PIM.
- Code - The detailed designs defined in the PSM's are then transformed into code in the final
step of the MDA software development process.
The transformation of PSM's into code is fairly straightforward and a number of tools on the market
support, to varying extents, this transformation. The most complex part of this process is the
transformation of the PIM's into PSM's. At this time it seems that the sophistication levels of the
tools available are not yet there to allow for the automated transformation of PIM's to PSM's.
Benefits
When the vision of the MDA is realized there are a number of benefits it would bring to the software
development community. The two main benefits are:
- Productivity - The developer will focus on the development of a PIM. From the PIM the PSM's
and Code will be automatically created via transformations. Because the focus is on the PIM,
quite a lot of the technical details of the underlying technologies and platforms do not need to
be considered. The Majority of the code will be created through the automated transformation
process and as such relatively small parts of code will need to be written (Yes! Coding will still
happen). With less focus on the coding and detail design for specific platforms, the developers
can spend more time in accommodating business problems. This will ensure better business fit
and hopefully a happier user community.
- Portability - Portability is achieved via the PIM that is transformed into PSM's for the multiple
platforms on which deployment will take place. With the transformation between PIM and PSM
automated the PIM becomes totally portable.
Downsides
There are a number of downsides to the MDA as it exists currently. They are:
- Current tools (if they exist?) for automatic transformation from PIM to PSM are not yet
sophisticated enough. These automated transformation tools will rely heavily on transformation
definitions and rules.
- The PIM's, if defined loosely, might not deliver the systems required. To ensure that the PIM's
and subsequent PSM's and Code align with business requirements, the PIM's need to be
defined precisely. Imprecise definitions will lead to faulty and incomplete systems that may
create a huge maintenance overhead.
- Portability (in the future), trough transformation from PIM to PSM will probably be cater for the
popular platforms, but for the less popular platforms may still remain an issue. Emerging
technologies may also be plagued by not having automated transformation tools available in
early stages of release.
References:
