This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Thought I'd start a new thread to avoid having this issue get muddled into the whiteboard wars. I'm less concerned with the diagramming aspect, more interested in the design-vs-code synchronization.
I'm curious to hear from people who have actually hands-on-tried some of the model-driven development tools. Which have you tried? Was it for something more interesting than "hello world?". Did you keep using the tool, or drop it like a hot potato?
I've taken two stabs at it so far, once using Rose about 4 years ago, and recently poking at Eclipse EMF. Rose, at least back then, was a bit fragile and unfriendly for doing this kind of work.
EMF doesn't seem fragile, which is a step up, but so far I'm not all that thrilled with how it generates code enough to push to use it in a real project. If almost all the functionality depended on EMF-generated classes and interfaces it might seem a bit more useful, but I don't think that matches actual project reality. In particular, real-life projects involve using a lot of external libraries and coding idioms suited to those libraries (think of Digester). So far I get the feeling that in a real project I'd find smaller and smaller numbers of classes or interfaces in the code being generated or tracked by EMF, most of it instead being changed to suite the (often very useful and powerful) external libraries.
Not being an EMF power-user, it is possible that I just haven't gone through enough of the learning curve to have picked up on the commonly-applied ways of making the most of the tool. I would be curious if anybody else has had good success themselves with EMF, or frankly with any other tool that seems in the same category and applicable for Java development.
I'm curious. When you were using them, did it seem like you were you the only person using those tools for what they were intended? I mean, the only person using the capabilities to model and generate code from models, roundtrip models from code, etc? Or were multiple people on the team working more or less the same way? I'm curious how typical daily patterns of development were either:
- helped by the MDA-ish tool
- hindered by it
- no difference
- the daily activity was unchanged but those activities broke stuff produced by the tool
- effort needed to be duplicated, tasks performed in the tool for the tool users, and metaphorical equivalents outside the tool for the non-users
- worked in areas of code primarily stomped on by one developer, versus areas stomped on by many developers
For example, if you refactor some code and cause classes to appear, disappear, get renamed, etc., how did the tool fair? If you use widgets like JAXB or vendor-specific web service tools that generate their own code, how well did the approaches co-exist? Those are just specific examples, but not trying to limit consideration to just those issues.
Interesting that you mentioned ERWin. While I was thinking about Java coding, Erwin actually provides a good example of having issues come up, or not come up, depending on the kind of work you do or the database product you are using. It can be either really convenient with its logical vs physical modelling distinction and easy reverse-eng of a physical database, or a massive hindrance when roundtripping at the physical level if you've performance tuned or used vendor-specific features Erwin doesn't know about (and sadly seems only infrequently updated to deal with).
Not intending to start an ERWin discussion thread, just noting that I'm curious what analogous challenges came up in practice on the Java side of things, where either the tool couldn't accomodate the work or the team was nudged into working differently to accomodate aspects of the tool they actually didn't expect to work around.
Joined: Dec 12, 2003
For the Java modeling tools, I pretty much only use them if everyone else is using them too. Otherwise, the code and models get out of sync and there's a danger that when I leave that the team won't have the skills to continue using the tool.
On the DB side of things, it's common that only one or two people might use it. The DB is critical, but it's such a small part of the overall effort that the impact of having a portion of the team with ERWin skills is much less.
My project uses a vendor framework. They built code generation on Rational Rose. We export from Rose to XMI standard XML, transform it once with a 3rd party tool that makes it a lot simpler, then use XSL to generate code.
Given a data structure it generates DTO and DAO classes for Oracle, UDB and/or MQ-Series.
Given a service interface it generates an abstract class with all abstract methods. This is regenerated so developers never modify it. We only work on concrete sub-classes. It also generates a Business-Delegate-like client and stub. The clients have pluggable protocols including remote EJB, XML/HTTP and raw sockets.
The vendor built extensions to Rose to capture many additional attributes. Their brochures may call this MDA but I see it as conventional code generation. Rose can read database metadata to build structures, but the Java is strictly one way.
All in all it's pretty successful. Data structures and service interfaces are far and away the most stable parts of our system so we go relatively long stretches without modifying and regenerating anything. We have customized the XSL fairly easily because most of it looks like plain Java.
I'd be very tempted to try this approach again if I had a new system to do from scratch because it generates so much of the fussy template driven stuff that I hate to write by hand. Since I have this vendor framework I haven't kept up to date on others. I'd hope some of the open source stuff is doing just about as well.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi