Level: Intermediate Mikko Kontio (mikko.kontio@softera.fi), Production Manager, Softera
13 Sep 2005 Tools do much of the work in a Model Driven Architecture (MDA) process, so it makes sense to choose yours carefully. This month, learn how to categorize MDA tools and evaluate them according to the needs of your organization.
One thing you may have noticed in the recent discussion about MDA is that almost every part of the process is done with tools. Tools are used for requirements gathering, domain modeling, and code generation, among
other things. So in this column, I'll focus on the tools that do so much of the work in MDA.
Rather than an overview of selected tools, which you can find elsewhere on the Web, I'll categorize the kinds of tools available and explain their usefulness in different parts of the MDA process. This will enable you to comparatively evaluate tools of the same type, as well as let you look at such issues as productivity, efficiency, and ease of use.
Categorizing MDA tools
The first thing to consider is that many products that are sold as MDA tools actually aren't. Code generation tools and modeling tools developed prior to the specification of MDA are not specifically MDA tools, although they may be applicable to an MDA process.
The fundamental idea of the MDA approach is to separate the application architecture into three distinct models: the Computationally Independent Model, the Platform Independent Model, and the Platform Specific Model. Each model is evaluated and carefully marked up, after which code is generated from the markup. The MDA tools you choose -- whether they were released prior to or following the MDA specification -- should support this division and not just generate code from a class diagram.
Three basic types
The purpose of categorizing MDA tools is to help you understand the kind of tools available, clearly define the terms of evaluation, and compare tools of the same type. I suggest that MDA tools can be usefully separated into three categories:
- Commercial or open source
- Partial or complete implementation
- Code generation from the model or execution of the model
Let's look at each tool category in detail.
Commercial or open source
For many developers, the question of whether a tool is commercial or open source is important. Open source tools tend to overlook business objectives and focus more on satisfying the needs of the developer. With open source tools you are typically freed of mandatory license fees, but you often have to work harder to gain information about the tool. As with commercial tools, some open source tools have been around for a long time; others are newer, untried products. Some open source tools are very slick and professional; others require more home assembly.
If you are considering using open source tools, evaluate the tools in real time, using working examples. Consider the stumbling blocks you encounter and how easily you overcome them. You'll soon know which tools are most suited to your project.
Partial or complete
It's important to consider how much of the design and development process you want your MDA tool to handle for you. Partial tools typically use the output of Unified Modeling Language (UML) design tools to generate code. Complete tools handle everything from requirements gathering to code generation. Vendors of complete tools say that getting everything in one package is wise because you don't have to jump between different programs. Vendors of partial tools say that buying the complete package is expensive and you can put together a solid MDA development environment for less money by using partial tools.
If you're evaluating partial tools, be sure that your UML tool and your MDA tool both support the same version of Meta Object Facility (MOF). Tools that use a standards-based import format rely heavily on MOF for modeling. You can think of MOF as the meta model underneath your modeling language. In most cases, you don't have to give any thought to the inner workings of MOF. MOF-style models are typically stored and passed in XML Metadata Interchange (XMI) files. Most partial tools support XMI as the input data format. UML design tools can export the model as an XMI file, which is an XML file that contains the elements and relations of the model. Some of the tools even use XMI as their Internal file format when they save the project.
Some tools, like Rational Rose/Rational Software Architect, take data input in a proprietary format; that is, one other than XMI. Some can even use the database schema of your project, such as an open source project
Middlegen. While this could be a nice business move, it limits users' access to other tools.
Generation from the model or execution of the model
Complete tools can be divided into two important groups, those that generate code and those that support Executable UML. The former means that the tool generates source code files from the model; the latter means that the tool can execute the model, and analysts and designers can check and demonstrate its functions in the process. I'll look at each of these tool types separately.
Model-and-generate ...
A number of MDA tools can completely model an application and generate some or most of its code. While this approach offers convenience up front, it can result in problems down the line. Most model-and-generate tools don't actually generate source code that can be compiled and executed without modification. They aim to generate 80 percent of the code and leave the rest to the developer. The problem arises when the developer makes changes to the structure of the source code. It doesn't matter how big the changes are, they typically lead to a situation where the model is out of date with the code.
Some tools seek to resolve this problem with sophisticated reverse-engineering features, which make it possible to update the changes in the source code by reverse engineering them into the model; but really it's better practice to make structural changes in the model. You could try a number of approaches to encourage developers to make changes in the model. For example, if you set your development environment to automatically make a new build every night, any changes in the code would be written over. Of course, this unsophisticated method would soon earn you a not-so-nice reputation among your colleagues! Better to offer developers a tool that makes it easier to modify the model and generate code from there.
... or model-and-execute?
Model-and-generate tools use UML and some extensions to model everything about the application so that the model can be executed in the tool. Some of these tools generate normal code like Java™ language, C++, or Cobol, and some use their own proprietary languages and generate executable packages that can be executed within their own application server. The latter case sounds a bit scary in that it locks you into a particular tool provider and technology. What if you need to do a Java application that runs on JBoss? It is a workable and time-saving solution for some cases, however.
The potential downside of these tools is that making a UML model that can be executed isn't easy. You have to be completely fluent in UML (you can actually think of it as a foreign language) to get the real benefits of a model-and-execute tool.
In conclusion
The usability, practicality, and quality of the tool you choose will have a huge impact on how well your organization will adapt to the MDA approach. In this column, I've given you three ways to categorize MDA tools. The first, whether the tool is open source or commercial, will help you choose a tool that is right for the culture of your organization, among other things. The second, whether the tool offers a partial or complete MDA solution, will help you factor in such considerations as cost, quality, and flexibility. The final category, whether the tool generates code from the model or executes the model, asks whether your organization and the type of projects you handle would do better with a solution that requires more effort after the code has been generated, or before, when the model is being generated. See Resources for listings of popular MDA tools.
Resources Learn
Discuss
About the author  | | | Mikko Kontio works as a Production Manager for the leading-edge Finnish software company, Softera. He holds a Masters degree in Computer Science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. Mikko can be reached at mikko.kontio@softera.fi. |
Rate this page
| 
