Todd Humphries: Did you have a 'Eureka!' moment when modelling made sense
for the first time and just became obvious or was there one particular time you
can think of where your opinion changed?
Rafael Chaves: When I was first exposed to UML back in school it did feel cool to be able to think about systems at a higher level of abstraction, and be able to communicate your ideas before getting down to the code (we often would just model systems but never actually build them). The value of UML modeling for the purpose of communication was evident, but that was about it. I remember feeling a bit like I was cheating, as drawing diagrams gave me no confidence the plans I was making actually made a lot of sense.
After that, still early in my career, I had the opportunity of working in a team where we were using an in-house code generation tool (first, as many have done, using XML and XSLT, and later, using UML XMI and Velocity templates, also common choices). We would get reams of Java code, EJB configuration files and SQL DDL generated from the designer models, and it did feel a very productive strategy for writing all that code. But the interesting bits (business logic) were still left to be written in Java (using the generation gap pattern). It was much better than writing all that EJB boilerplate code by hand, but it was still cumbersome and there was no true gain in the level of abstraction, as we would model thinking of the code that would be generated - no surprise, as there was no escaping the facts that we would rely on the Java compiler and JUnit tests to figure out whether the model had problems, and in order to write the actual business logic in Java, we had to be very familiar with the code that was generated. So even though I could see the practical utility of modeling by witnessing the productivity gains we obtained, there was a hackish undertone to it, and while it worked, it didn't feel like solid engineering.
It was only later, when I was doing research for my Masters, and I was finally exposed to the approach of executable modeling and MDA, that I finally understood there was authentic value to modeling. Real gains in level of abstraction. Validation and execution of models long before a target platform was even chosen. Full code generation, including business logic. Ultimate platform independence. It finally made all the sense in the world. It made so much sense to me that I could not believe that was not how everybody was writing software. Since then, I have been obsessed with building tools to help bring the approach to the mainstream.
TH: What would you like to see in future versions of the UML standard? What do you think UML is lacking that would help MDD progress?
Rafael Chaves: When I was first exposed to UML back in school it did feel cool to be able to think about systems at a higher level of abstraction, and be able to communicate your ideas before getting down to the code (we often would just model systems but never actually build them). The value of UML modeling for the purpose of communication was evident, but that was about it. I remember feeling a bit like I was cheating, as drawing diagrams gave me no confidence the plans I was making actually made a lot of sense.
After that, still early in my career, I had the opportunity of working in a team where we were using an in-house code generation tool (first, as many have done, using XML and XSLT, and later, using UML XMI and Velocity templates, also common choices). We would get reams of Java code, EJB configuration files and SQL DDL generated from the designer models, and it did feel a very productive strategy for writing all that code. But the interesting bits (business logic) were still left to be written in Java (using the generation gap pattern). It was much better than writing all that EJB boilerplate code by hand, but it was still cumbersome and there was no true gain in the level of abstraction, as we would model thinking of the code that would be generated - no surprise, as there was no escaping the facts that we would rely on the Java compiler and JUnit tests to figure out whether the model had problems, and in order to write the actual business logic in Java, we had to be very familiar with the code that was generated. So even though I could see the practical utility of modeling by witnessing the productivity gains we obtained, there was a hackish undertone to it, and while it worked, it didn't feel like solid engineering.
It was only later, when I was doing research for my Masters, and I was finally exposed to the approach of executable modeling and MDA, that I finally understood there was authentic value to modeling. Real gains in level of abstraction. Validation and execution of models long before a target platform was even chosen. Full code generation, including business logic. Ultimate platform independence. It finally made all the sense in the world. It made so much sense to me that I could not believe that was not how everybody was writing software. Since then, I have been obsessed with building tools to help bring the approach to the mainstream.
TH: What would you like to see in future versions of the UML standard? What do you think UML is lacking that would help MDD progress?
RC: I actually wrote a post about this a while ago which I think
addresses that exact question:
TH: You've written in the past about misconceptions and myths
you've come across trying to promote MDD, in your experience is it usually
experienced software engineers or new graduates who are the most accepting of
modelling principles and why do you think that might be?
RC: Talking specifically about MDD (and not modeling in
general): I think in general less experienced developers will buy into MDD more
easily than more experienced developers. More senior folk will tend to resist
more to the idea that the much of what they do (and are very proud of) could be
done automatically.
Re: modeling in general - I, for one, will resist to the
idea of modeling as something inherently beneficial - unless your models are
actually what drive the software development (they are the primary artifacts),
I see modeling as superfluous and wasteful.
TH: Do you think MDD is easier to pick up for someone who
has little to no 'real-world'/practical experience of software development or
for those with many years traditional development experience?
RC: Hard to say - I do think experience is usually beneficial,
and a more experienced modeler will in general produce better results than a
novice modeler. OTOH, I think it is much easier for a novice developer to build
high quality applications using the MDD approach than manually crafting the
application (because MDD allows you to encapsulate and reuse skills/expertise).
TH: Are there any books, blogs or other sources that you
would recommend for someone new to or inexperienced with MDD? Any tips of
your own or those that helped you that you'd care to share?
RC:
Join the ModelDrivenSoftwareNetwork
Read about Executable UML
Follow @seidewitz on Twitter
H. S. Lahman recent book (Model Based Development)
Markus Volter book on MDSD is a good introduction as well.
There
will be a market for reusable business applications (which can target multiple
platforms), and a market of target platform-specific code generators (which can
accept applications from different domains).
Read about Executable UML
Follow @seidewitz on Twitter
H. S. Lahman recent book (Model Based Development)
Markus Volter book on MDSD is a good introduction as well.
Study the codebase of enterprise applications in Java or C#
(or even RoR) and look for the implementation patterns
Look at an application and learn to consciously separate
problem domain concerns (which are implementation independent) and
solution domain concerns (which are implementation specific)
TH: Back in November last year you said "I
think we still live in the dark ages of software development And, what is
your vision or dream of how software development might look in ten years?
Twenty?
RC: We would use a language that is at higher level of
abstraction than 3GLs which would allow us to naturally express technology
independent solutions, and then target different platforms with ease. The
target platform won't put constraints on how we reason about solutions, and the
development tool we use won't put constraints on what platform we target.
This is a great introduction to UML for beginners as well as being interesting to those who are working with executable modeling and been through it all...
Thank you Rafael for such considered answers and creating a great read!
No comments :
Post a Comment