Model interpretation vs. code generation? There were recently two great posts by Johan den Haan and Jordi Cabot on this topic, both generating interesting discussions. I am not going to try to define or do an analysis of pros and cons of each approach as those two articles already do a good job at that (make sure to read them). What I have to add is that if you use model-driven development, even if you have decided for code generation to take an application to production, it still makes a lot of sense to adopt model interpretation during development time.
For one, model interpretation allows you to execute a model with the fastest turnaround. If the model is valid, it is ready to run. Model interpretation allows you to:
- play with your model as you go (for instance, using a dynamically generated UI, like AlphaSimple does)
- run automated tests against it
- debug it
All without having to generate code to some target platform, which often involves multiple steps of transformation (generating source code, compiling source code to object code, linking with static libraries, regenerating the database schema, redeploying to the application server/emulator, etc).
But it is not just a matter of turnaround. It really makes a lot more sense:
- you and other stakeholders can play with the model on day 1. No need to commit to a specific target platform, or develop or buy code generators, when all you want to validate is the model itself and whether it satisfies the requirements from the point of view of the domain. Heck, you might not even know yet your target platform!
- failures during automated model testing expose problems that are clearly in the model, not in the code generation. And there is no need to try to trace back from the generated artifact where the failure occurred back to model element that originated it, which is often hard (and is a common drawback raised against model-driven development);
- debugging the model itself prevents the debugging context from being littered with runtime information related to implementation concerns. Anyone debugging Java code in enterprise applications will relate to that, where most of the frames on the execution stack belong to 3rd-party middleware code for things such as remoting, security, concurrency etc, making it really hard to find a stack frame with your own code.
Model-driven development is really all about separation of concerns, obviously with a strong focus on models. Forcing one to generate code all the way to the target platform before models can be tried, tested or debugged misses that important point. Not only it is inefficient in terms of turnaround, it also adds a lot of clutter that gets in the way of how one understands the models.
In summary, regardless what strategy you choose for building and deploying your application, I strongly believe model interpretation provides a much more natural and efficient way for developing the models themselves.
What are your thoughts?
The TextUML Toolkit version 1.6 has been released. It is the same RC1 build mentioned here a week ago. The listing on the Eclipse Marketplace has been updated, so in addition to the regular update site (http://abstratt.com/update/), if you are using Eclipse 3.6, you can get it even more conveniently using the brand new Eclipse Marketplace Client.
Take a look at the new notation features:
- preconditions on operations
operation withdraw(amount : Real);
precondition { amount > 0 and amount < self.balance; }
begin
self.balance := self.balance - amount;
end;
reference employees : Employee[*]
/* calculated field */
derived attribute employeeCount : Integer := ():Integer { return self->employees.size(); };
- initial values on properties
attribute available : Boolean := true;
You can also try these new features online on AlphaSimple. Sign up or start a guest session to create, validate and run your models on the spot, there is nothing to install!
TextUML Toolkit 1.6 RC1 is now available! You can install it using the Marketplace Client or by pointing Eclipse to the update site:
http://abstratt.com/update
If you find any problems installing this build, please let us know asap so it can be addressed before the final release.
New features
Much of the work in this release went into improving the model building infrastructure to be even more notation agnostic. That work is still ongoing and should be completed in 1.7. But there were plenty of user-facing feature additions as well:
- preconditions on operations (2986923 and 3002571)
- support for a default notation (so file extensions can be optional) (2995372)
- support for implicitly applying profiles/stereotypes (so models are less verbose) (2981580)
- support for derived properties (2928428)
- support for initial values in properties (2115439)
- advanced features (closures, constraints) are now implemented using profiles instead of metamodel extensions (2933692)
In other news
The reason it took so long for a new TextUML Toolkit release to come about was that I have been busy working on AlphaSimple, which went on public beta today. AlphaSimple is an online tool for domain-driven prototyping that currently uses TextUML as modeling notation. Thus, AlphaSimple is also the driving force behind most of the changes that happened in the 1.6 cycle, and you can try them right away by starting a guest session and studying the example projects.
Last week I did a short presentation on “Model-driven prototyping” for the Vancouver Island Java User Group (VIJUG). It was lots of fun, with good participation from the group. I also showed a quick demo of AlphaSimple, our upcoming service for model-driven prototyping, which seemed to be well received.
For the benefit of those not there, here is a web-version of that presentation, with notes showing on the slides (click here for a full screen view).
Comments are very welcome. I would be very happy to discuss the approach with anyone interested.
It’s been a while since the last post, but I have a good excuse. I have been working on a new MDD product named AlphaSimple.
AlphaSimple is our upcoming web-based service that renders functional prototypes straight from rich domain models. The goal is to bridge the gap between design and requirement analysis, creating a fast feedback loop between those two activities. The result is much more precise and complete requirements early in the project lifecycle, and a sound design model that not only will be a breeze to implement, but that even your customers will understand.
We are craving feedback. If you want to take an alpha version for a spin, sign up at alphasimple.com.
Cheers,
Rafael