I. Overview
II. MDA Benefits
1 Productivity
2 Portability
3 Interoperability
4 Maintenance and Documentation
III. The Model Driven Architecture
1 The MDA Development Life Cycle
Platform Independent Model
Platform Specific Model
Code
Raising the Level of Abstraction
2 Automation of the Transformation Steps
IV. MDA Tools
V. Specifications
1 The Pervasive Services
2 Domain Facilities
3 MDA Applications
VI. Summary
VII. Reference
I. Overview
Model-Driven Architecture (MDA™) is a software design approach that its sponsor, the Object Management Group (OMG), officially launched in 2001. MDA supports model-driven engineering of software systems. MDA provides a set of guidelines for structuring specifications expressed as models. The MDA approach defines system functionality using a platform-independent model (PIM) using an appropriate Domain Specific Language. Then, given a Platform Definition Model (PDM) corresponding to CORBA, DotNet, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run, using different Domain Specific Languages, or a General Purpose Language like Java, C#, Python, etc. Automated tools generally perform these translations, for example tools compliant to the new OMG standard named QVT. The OMG documents the overall process in a document called the MDA Guide. MDA principles can also apply to other areas such as business process modeling where the PIM is translated to either automated or manual processes.
The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), the XML Metadata interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
II. MDA Benefits
Let us now take a closer look at what application of MDA brings us in terms of improvement of the software development process.
1 Productivity
In MDA the focus for a developer shifts to the development of a PIM. The PSMs that are needed are generated by a transformation from PIM to PSM. Of course, someone still needs to define the exact transformation, which is a difficult and specialized task. But such a transformation only needs to be defined once and can then be applied in the development of many systems. The payback for the effort to define a transformation is large, but it can only be done by highly skilled people.
The majority of developers will focus on the development of PIMs. Since they can work independently of details and specifics of the target platforms, there is a lot of technical detail that they do not need to bother with. These technical details will be automatically added by the PIM to PSM transformation. This improves the productivity in two ways.
In the first place, the PIM developers have less work to do because platform-specific details need not be designed and written down; they are already addressed in the transformation definition. At the PSM and code level, there is much less code to be written, because a large amount of the code is already generated from the PIM.
The second improvement comes from the fact that the developers can shift focus from code to PIM, thus paying more attention to solving the business problem at hand. This results in a system that fits much better with the needs of the end users. The end users get better functionality in less time.
Such a productivity gain can only be reached by the use of tools that fully automate the generation of a PSM from a PIM. Note that this implies that much of the information about the application must be incorporated in the PIM and/or the generation tool. Because the high-level model is no longer "just paper," but directly related to the generated code, the demands on the completeness and consistency of the high-level model (PIM) are higher than in traditional development. A human reading a paper model may be forgiving—an automated transformation tool is not.
2 Portability
Within the MDA, portability is achieved by focusing on the development of PIMs, which are by definition platform independent. The same PIM can be automatically transformed into multiple PSMs for different platforms. Everything you specify at the PIM level is therefore completely portable.
The extent to which portability can be achieved depends on the automated transformation tools that are available. For popular platforms, a large number of tools will undoubtedly be (or become) available. For less popular platforms, you may have to use a tool that supports plug-in transformation definitions, and write the transformation definition yourself.
For new technologies and platforms that will arrive in the future, the software industry needs to deliver the corresponding transformations in time. This enables us to quickly deploy new systems with the new technology, based on our old and existing PIMs.
3 Interoperability
We have been incomplete regarding the overall MDA picture. As shown in Figure 1, multiple PSMs generated from one PIM may have relationships. In MDA these are called bridges. When PSMs are targeted at different platforms, they cannot directly talk with each other. One way or another, we need to transform concepts from one platform into concepts used in another platform. This is what interoperability is all about. MDA addresses this problem by generating not only the PSMs, but the necessary bridges between them as well.
Figure 1. MDA interoperability using bridges
If we are able to transform one PIM into two PSMs targeted at two platforms, all of the information we need to bridge the gap between the two PSMs is available. For each element in one PSM we know from which element in the PIM it has been transformed. From the PIM element we know what the corresponding element is in the second PSM. We can therefore deduce how elements from one PSM relate to elements in the second PSM. Since we also know all the platform-specific technical details of both PSMs (otherwise we couldn't have performed the PIM-to-PSM transformations), we have all the information we need to generate a bridge between the two PSMs.
Take, for example, one PSM to be a Java (code) model and the other PSM to be a relational database model. For an element Customer in the PIM, we know to which Java class(es) this is transformed. We also know to which table(s) this Customer element is transformed. Building a bridge between a Java object in the Java-PSM and a table in the Relational-PSM is easy. To retrieve an object from the database, we query the table(s) transformed from Customer, and instantiate the class(es) in the other PSM with the data. To store an object, we find the data in the Java object and store it in the "Customer" tables.
Cross-platform interoperability can be realized by tools that not only generate PSMs, but the bridges between them, and possibly to other platforms, as well. You can "survive" technology changes while preserving your investment in the PIM.
4 Maintenance and Documentation
Working with the MDA life cycle, developers can focus on the PIM, which is at a higher level of abstraction than code. The PIM is used to generate the PSM, which in turn is used to generate the code. The model is an exact representation of the code. Thus, the PIM fulfills the function of high-level documentation that is needed for any software system.
The big difference is that the PIM is not abandoned after writing. Changes made to the system will eventually be made by changing the PIM and regenerating the PSM and the code. In practice today, many of the changes are made to the PSM and code is regenerated from there. Good tools, however, will be able to maintain the relationship between PIM and PSM, even when changes to the PSM are made. Changes in the PSM will thus be reflected in the PIM, and high-level documentation will remain consistent with the actual code.
In the MDA approach the documentation at a high level of abstraction will naturally be available. Even at that level, the need to write down additional information, which cannot be captured in a PIM, will remain. This includes, for example, argumentation for choices that have been made while developing the PIM.
III. The Model Driven Architecture
The Model Driven Architecture (MDA) is a framework for software development defined by the Object Management Group (OMG). Key to MDA is the importance of models in the software development process. Within MDA the software development process is driven by the activity of modeling your software system.
In this section we first explain the basic MDA development life cycle, and next illustrate how MDA can help to solve (at least part of) the problems mentioned in the previous sections.
1 The MDA Development Life Cycle
The MDA development life cycle, which is shown in Figure 2, does not look very different from the traditional life cycle. The same phases are identified. One of the major differences lies in the nature of the artifacts that are created during the development process. The artifacts are formal models, i.e., models that can be understood by computers. The following three models are at the core of the MDA.
Figure 2. MDA software development life cycle
Platform Independent Model
The first model that MDA defines is a model with a high level of abstraction that is independent of any implementation technology. This is called a Platform Independent Model (PIM).
A PIM describes a software system that supports some business. Within a PIM, the system is modeled from the viewpoint of how it best supports the business. Whether a system will be implemented on a mainframe with a relational database or on an EJB application server plays no role in a PIM.
Platform Specific Model
In the next step, the PIM is transformed into one or more Platform Specific Models (PSMs). A PSM is tailored to specify your system in terms of the implementation constructs that are available in one specific implementation technology. For example, an EJB PSM is a model of the system in terms of EJB structures. It typically contains EJB-specific terms like "home interface," "entity bean," "session bean," and so on. A relational database PSM includes terms like "table," "column," "foreign key," and so on. It is clear that a PSM will only make sense to a developer who has knowledge about the specific platform.
A PIM is transformed into one or more PSMs. For each specific technology platform a separate PSM is generated. Most of the systems today span several technologies; therefore it is common to have many PSMs with one PIM.
Code
The final step in the development is the transformation of each PSM to code. Because a PSM fits its technology rather closely, this transformation is relatively straightforward.
The MDA defines the PIM, PSM, and code, and also defines how these relate to each other. A PIM should be created, and then transformed into one or more PSMs, which then are transformed into code. The most complex step in the MDA development process is the one in which a PIM is transformed into one or more PSMs.
Raising the Level of Abstraction
The PIM, PSM, and code are shown as artifacts of different steps in the development life cycle. More importantly, they represent different abstraction levels in the system specification. The ability to transform a high level PIM into a PSM raises the level of abstraction at which a developer can work. This allows a developer to cope with more complex systems with less effort.
2 Automation of the Transformation Steps
The MDA process may look suspiciously much like traditional development. However, there is a crucial difference. Traditionally, the transformations from model to model, or from model to code, are done mainly by hand. Many tools can generate some code from a model, but that usually goes no further than the generation of some template code, where most of the work still has to be filled in by hand.
In contrast, MDA transformations are always executed by tools as shown in Figure 3. Many tools are able to transform a PSM into code; there is nothing new to that. Given the fact that the PSM is already very close to the code, this transformation isn't that exciting. What's new in MDA is that the transformation from PIM to PSM is automated as well. This is where the obvious benefits of MDA come in. How much effort has been spent in your projects with the painstaking task of building a database model from a high-level design? How much (precious) time was used by building a COM component model, or an EJB component model from that same design? It is indeed about time that the burden of IT-workers is eased by automating this part of their job.
Figure 3. The three major steps in the MDA development process
At the time of writing, the MDA approach is very new. As a result of this, current tools are not sophisticated enough to provide the transformations from PIM to PSM and from PSM to code for one hundred percent. The developer needs to manually enhance the transformed PSM and/or code models. However, current tools are able to generate a running application from a PIM that provides basic functionality, like creating and changing objects in the system. This does allow a developer to have immediate feedback on the PIM that is under development, because a basic prototype of the resulting system can be generated on the fly.
IV. MDA Tools
An MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels. In the following section "model" is interpreted as meaning any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. For example an analyst may create a UML initial model from its observation of some loose business situation while a Java model may be automatically derived from this UML model by a Model transformation operation. An MDA tool may be one or more of the following types:
- Creation Tool: A tool used to elicit initial models and/or edit derived models.
- Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
- Transformation Tool: A tool used to transform models into other models or into code and documentation.
- Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel.
- Test Tool: A tool used to "test" models as described in Model-based testing.
- Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution.
- Metadata Management Tool: A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
- Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.
Some tools perform more than one of the functions listed above. For example, some creation tools may also have transformation and test capabilities. There are other tools that are solely for creation, solely for graphical presentation, solely for transformation, etc.
V. Specifications
OMG recognizes (based on analogy to the CORBA-based Object Management Architecture) three levels of MDA-based specifications:
- The Pervasive Services, including
- The Domain Facilities, in industries such as Healthcare, Manufacturing, Telecommunications, Biotechnology, and others; and
- Applications themselves, perhaps created and maintained by a software vendor or end user company or enterprise using MDA tools to run an MDA-based methodology, but not standardized by OMG.
1 The Pervasive Services
This category will include at least
- Directory and Naming Services
- Event Handling/Notification Services
Additional Pervasive Services may be defined, either from the list of CORBAservices already standardized by OMG or from other suggestions from OMG members. Transactions and Security, the other two most popular CORBAservices, may or may not be part of this group - in the Component world, transactionality and security are attributes of a running system, rather than services that a program calls, because of the way the Component Container or Application Server is set up to run transactionally and securely as part of an application's environment.
OMG members are already taking the group's well-established CORBAservice specifications and mapping them back to PIMs where they can serve all platforms through the MDA development pathway.
2 Domain Facilities
OMG's Domain Task Forces started to write their specifications in the MDA in mid-2001, led by the Life Science Research Domain Task Force, working in Biotechnology, which was the first Domain Task Force to modify its Mission and Goals Statement to reflect its work in MDA.
All of our Domain specifications are listed on this web page. In addition to the Life Sciences MDA specifications, other notable MDA-based entries are the Software-Defined Radio and Super Distributed (that is, ubiquitous) Objects entries. Our Work in Progress page lists 15+ ongoing processes adopting new MDA-based specifications.
3 MDA Applications
MDA-based development tools are available now, and enterprises everywhere around the world starting their application development by building a PIM instead of writing code. Even now, MDA is being used for large, mission-critical applications including the F-16 fighter jet mission software and a two-million-transaction per day bank payment system. If you're not convinced of the value of MDA already, look through these stories. We think you'll be ready to try MDA by the time you've read just a few!
VI. Summary
The Model Driven Architecture is a framework for software development, defined by the OMG. Key to MDA is the importance of models in the software development process. Within MDA the software development process is driven by the activity of modeling your software system.
The MDA development life cycle is not very different from the traditional life cycle. The artifacts of the MDA are formal models, i.e., models that can be understood by computers. The following three models are at the core of the MDA:
· Platform Independent Model (PIM), a model with a high level of abstraction, that is independent of any implementation technology.
· Platform Specific Model (PSM), a model tailored to specify your system in terms of the implementation constructs that are available in one specific implementation technology. A PIM is transformed into one or more PSMs.
· Code, a description (specification) of the system in source code. Each PSM is transformed into code.
Traditionally the transformations from model to model, or from model to code, are done mainly by hand. In contrast, MDA transformations are always executed by tools. Many tools have been able to transform a PSM to code; there is nothing new to that. What's new in MDA is that the transformation from PIM to PSM is automated as well.
VII. Reference
2. http://www.answers.com/Model-driven%20architecture
3. http://www.omg.org/mda/specs.html
