Model-Driven Development in Keel, Page 2
Another option of a model-driven tool is Middlegen, which can be found at http://boss.bekk.no/boss/middlegen/. Middlegen is especially well suited for generating Java code using an existing relational database as the "model." Given that many applications do indeed revolve around the database, this may be the right choice for some projects.
Middlegen even includes a handy utility to allow you to connect to your database (via JDBC) and view and even alter tables. Alternately, you can use plain old SQL, or the database GUI tool of your choice. Once the database is the way you want it, it is a matter of a quick "Ant" build to generate the corresponding code via one or more "plugins."
Middlegen also, like AndroMDA, leverages XDoclet to create an associated configuration (e.g. JDO mappings). This allows us to prepare a plugin for each of the component types we want created, use Middlegen to crank out the corresponding code from the database, and then use XDoclet to automatically create the configuration files as well.
In our example of using Middlegen with Keel, we can immediately put to use the JDO plugins for Middlegen, using them to create persistent beans for Keel's JDO implementations. With a little work, we can create a custom plugin to use Keel's own Persistence service instead of JDO, if we prefer this. Again, Middlegen creates the actual Java classes (one per table), complete with the Keel-specific XDoclet tags for generating the configuration. Changing our database schema then becomes a simple matter of re-generating the appropriate classes—no manual coding to worry about (or to possibly introduce errors with).
Middlegen, though, is not restricted to only database beans classes; it can generate other Java code as well, such as Struts JSP pages and Actions. For use with Keel, we easily can prepare a plugin that creates a Model class to maintain each selected database table.
Middlegen uses Velocity as its internal template engine, but a developer also can write custom Java code, in the unlikely event that the required logic cannot be expressed as a Velocity template.
So, having discussed a few of the available tools, what is the development process like with model-driven development? As the name would imply, development with this technique starts with a model, whether it be a database design or a UML diagram, or even an XML Schema file. Once we've created the model description in the appropriate format using our design tool of choice, we go into the generation "cycle." Depending on the tool we choose, we either initiate generation from within our IDE (in the case of EMF), or via "Ant," as with AndroMDA and Middlegen. (Of course, many IDEs today can launch Ant from within the IDE in any case, as a convenience). Now, we review the generated files and begin the process of "filling in the blanks;" that is, providing the actual implementation code.
In the case of database beans (such as JDO or other persistence layers), we might also execute XDoclet (again, via Ant) to generate the appropriate configuration files.
If the tool we used supports it (and most now do), we then can go back and make alterations to our original model as required, and repeat the cycle: generate, code, and so forth.
Given our description of the process of Model-driven development, what are the benefits?
- Documentation: Beginning with a design model, whether it is UML or even just a database design, gives a project a head-start on documentation. UML is much more readily explained to non-technical stakeholders in a project than the corresponding code, and most database tools also can diagram a relational design in a readily understandable form.
- Accuracy: Transcribing an existing design into Java classes is much more accurately done by automation than by hand, avoiding irritating and time-consuming bugs resulting from a "mis-match" between design and code (or between code and database). Using a modeling tool can improve coding accuracy by automating this process entirely.
- Efficiency: Creating JavaBean classes that simply mirror a design already specified by a model is tedious and prone to errors. If the time consumed in creating these classes can be put to better use elsewhere, developer efficiency as a whole can be increased, and the project can move along by putting work into other parts of the process.
Model-driven development can help ensure the consistency of your development process, boost developer efficiency, and help ensure that a specification is accurately represented by the code that implements it. Given the level of tools available today, it is an easy technique to try out, and can be done entirely with open-source projects. It may be time to have a look at model-driven development for your own projects.
If you are already using Eclipse, EMF is worth careful consideration, particularly in conjunction with a UML plugin. It is a bit harder to get started with than the other tools we've reviewed, but the finished cohesive environment is very powerful once the effort is expended.
If your existing UML tool already is able to generate XMI, perhaps AndroMDA is the right choice because its ability to directly "digest" XMI and produce Java code can put your existing UML tool to work right away. If you are looking for an "Ant"-driven tool, AndroMDA also fills the bill.
If, like many projects, your project requires you to model directly from your database, Middlegen may be the right tool for the job because its ability to produce code directly from any JDBC datasource is unique among the tools we've reviewed. Mapping of persistent classes to the database is often one of the more tedious tasks in application development, even if you choose to use your modeling capabilities only in this one area of your project's development.
About the AuthorMichael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at firstname.lastname@example.org.