Model-Driven Architecture: Moving from Concept to Practice



Grace Lewis

This library item is related to the following area(s) of work:

Software Architecture
System of Systems

This article was originally published in News at SEI on: February 1, 2005

The SEI is examining technologies and approaches for the construction of systems that are required to interoperate with other systems, with the purpose of examining the gaps between what these technologies and approaches offer and what users expect of them. One of these approaches is model-driven architecture (MDA), produced and maintained by the Object Management Group (OMG), an open membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications.

The goal of MDA is probably one you have heard before: to separate business and application logic from its underlying execution platform technology so that (1) changes in the underlying platform do not affect existing applications, and (2) business logic can evolve independently from the underlying technology [Lewis 04, OMG 03]. A tool that implements the MDA concept allows developers to produce models of the application and business logic and, by means of a model-to-code translator, generate code for a target platform.

At this point you might be asking yourself: how is this different from CASE environments, automated code generators, or even Java? There is something different and interesting about MDA and it is that OMG is working on specifications such as Unified Modeling Language (UML), XML Metadata Interchange (XMI), Meta-Object Facility (MOF), and Common Warehouse Meta-model (CWM) to provide a common modeling representation for vendors to use in their tools. By using this common modeling representation to build applications, not only would applications have better chances of achieving interoperability with other applications, but models could be shared between tools, and therefore the same application could be deployed on multiple platforms. Unfortunately, most current MDA tools have focused on the automated code generation aspects and not on the real strength of MDA, which is the common modeling representation.

Nonetheless, many people are becoming attracted to MDA because of other attributed benefits, such as reduced life-cycle cost, reduced development time for new applications, improved application quality, and a more rapid response to changes in technology, even though the data that supports these claims is limited. To better separate fact from fiction, the SEI has set up an experimentation environment to test these claims. What follows are some preliminary findings related to reduced development time for new applications.

Reducing Development Time with MDA

One element that factors into development time is the amount of code that has to be written that is not generated by the tool. There is currently a wide variation in the amount of code that an MDA tool generates. There are tools that generate infrastructure code but do not generate business- and application-logic code. Typical examples are tools that generate code for J2EE and .NET environments. In these cases, the amount of code still to be written can be large, depending on the complexity and size of the system. Conversely, there are tools that implement what is called Executable UML (xUML). In the xUML approach, business logic is expressed in the models as state machines and an accompanying action language. In these cases, the application and business logic is generated by the tool as well, minimizing the amount of code to be written. As attractive as the idea of not having to write code can be, the SEI has found that representing all business and application logic in a system as a state machine can be difficult and not intuitive for all types of systems. For example, representing a bank account as a state machine would include states such as open, closed, suspended, and overdrawn, and there are clear rules that take an account from one state to another. However, representing a bank customer as a state machine is not so clear because there are potentially only two states, active and inactive, and what takes a customer from one state to another depends on his or her bank account. Also, the action language provided by these xUML-based tools is not complete. For example, if the business logic requires complex mathematical operations, these would have to be provided by external code.

Another element that factors into development time, especially the first time that the tool is used, is the configuration of the model-to-code translators when there are mismatches between the translator and the target environment. Most MDA tools provide guidance on how to modify these translators or rewrite them completely. For example, if the tool provides a C translator for a stand-alone environment, the translator would have to be largely modified or rewritten completely if the target is C language for a distributed environment. The SEI has found that writing a translator or modifying an existing one is not an easy task. During the configuration of the translators, a lot of trial and error is involved in looking at the generated code to analyze any problems, changing configuration parameters in the tool, and repeating this process until the application works. This obviously requires understanding the generated code and the execution platform at least at a conceptual level.

So if the model-to-code translators need to be written entirely or heavily tailored, the development time will not be reduced, or might even be increased, for the first application for which MDA is used. It is likely that development time will go down for the generation of future applications running on the same platform, but this is still something that requires further study. A large initial investment in tool configuration may be reasonable in industry where there is usually a common deployment platform, but in the military where the same application is deployed on multiple platforms, this might be a problem.

The Future of MDA

MDA is a concept that has to be fully embraced and implemented by tools before it can become a widespread and cost-effective practice. Most of the tools that the SEI has investigated are model-to-code generators for one specific platform that use UML to represent models, but the internal representation of these models is specific to the tool and therefore cannot be shared with other tools. The good news is that OMG continues to make progress in its specifications. Until tool vendors start fully conforming to these specifications, an MDA tool is nothing more than an automated code generator, and that is not where the real benefit of MDA lies.


[Lewis 04]
Lewis, Grace A. & Wrage, Lutz. Approaches to Constructive Interoperability (CMU/SEI-2004-TR-020). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2004.

[OMG 03]
Object Management Group. MDA Guide Version 1.0.1., 2003.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.