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.
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: 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:
Read the MDA Guide 1.0 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!
Taken from www.the-technical-diaries.blogspot.com
