Industrial experiences of this kind of "MDA" show improvements in productivity and quality with a FACTOR of between 5 and 10 times compared to UML-based MDA implementations.....ehr....hypothetical UML-based implementations of MDA that is :)
About Me
Wednesday, February 22, 2006
Hard Fact: MDA Works!!!
Industrial experiences of this kind of "MDA" show improvements in productivity and quality with a FACTOR of between 5 and 10 times compared to UML-based MDA implementations.....ehr....hypothetical UML-based implementations of MDA that is :)
Thursday, February 16, 2006
Defining DSLs, Best Practices
Monday, February 13, 2006
Defining DSLs based on RUP
Evgeny Rahman and Jarrod Bellmore from the Worcester Polytechnic Institute have investigated a method for defining DSLs based on the Rational Unified Process. Hats off for their thesis work. While I will not argue the suitability of RUP for defining DSL's (I can imagine a whole future battle between DSL-RUP aficionado's contra Agile DSL guerilla's), I do have much respect for the topic choice they decided on for their thesis work. Defining DSL's certainly will be a key issue. Now that the technology is there and more vendors announcing support for DSM, the next obstacle that those wanting to adopt DSM will be faced with, will be "Ehrrrrrr.....so how do we actually define our own modeling language"?
Next-generation DSM tools may even offer support for various DSL definition processes, including the creation of all documentation for decision making processes during the DSL definition and maintenance. Remember that like developers today, language designers will change jobs in the future and for those that replace them good documentation about the choices made by their predecessors about the DSLs in use and their evolution over time, will help in making future decisions on where to go with the languages in use.
Thursday, February 09, 2006
Interview with Steven Kelly
Tuesday, February 07, 2006
You already speak DSL!
Actually, this is not correct.
I dare say that virtually every developer already speaks DSL! When discussing about the problem domain of the software under development, each development team has their own jargon in which they speak about the software or system. No one speaks about the software in Java, C or, mind you, in Cobol or Assembler. Developers all speak about their software in a language that uses terms and rules from the problem domain he or she works in. Usually, the expert developer speaks that language best and DSM gives him (or her) the means to make each "less fluent" developer "speak" that language fluently.
The idea of course: Give the expert a tool to efficiently create modeling tool support for his/her DSM language and provide this language to the rest of the developers.
Unlike with UML, with DSM developers do not have to learn a new language, that, all things considered, is never really optimal to "discuss" about the software. Instead, with DSM the expert provides them with the language they already know so that "discussing" about the software in your verbal DSL comes closer to developing the software in your visual DSL.