It seems that the Software Engineering Podcast is going to keep me busy for a while. For me it is a valuable source of knowledge. I had no idea that I have no idea about software engineering ;-)
Today I listened to the podcast about Model-driven Software Development (MDSD). Wikipedia redirects MDSD to model-driven engineering (MDE), so it seems that the terms in this field are not established yet. A closer look reveals a lot of additional terms which, as far as I can see, all deal with the same basic idea. So far I have seen language-oriented programming, concept programming, generative programming, automatic programming, grammar-oriented programming, meta programming, domain specific modeling, intentional programming, dialecting or code generation.
No matter how you call it the core idea is the following: find the right abstraction of a given problem and use domain specific terms and structures for that. This forms the domain specific language (DSL). Given an instance of that language, i.e. a solution to the given problem, automatic transformation turns it into a semantically equivalent representation in a lower level formal language. This approach has many benefits, from which the podcast mentions the following ones:
- Instead of requiering developers to manually and mentally do the transition from domain concepts down to the software technology concepts the idea is to provide them with domain specific abstractions and let tools like transformers and generators do the mapping. (part 1 - 03:26)
- You can generate glue code, boilerplate code (part 1 - 17:42), build system files, application packages, test cases - at least to some extend -, configuration files and other artifacts that are outside of your execution platform. (part 1 - 23:00)
- It improves software quality because a software generator does not make accidental errors. If it is buggy it introduces systematic errors which can be found more easily. (part 2 - 07:19)
- The models are platform independent. Porting your software to a new platform only requires to write new generators (part 2 - 7:32)
- Automating things is better than getting huge amounts of people to do cheap work (part 2 - 12:32)
- You can do pair programming with domain experts and thus improve the customer integration (part 2 - 15:17)
The idea is not knew, though. Lisp macros are - as far as I known - one of the oldest implementations of code generation. In Lisp speech macros allow you to extend the syntax. From today's view, though, the syntax is the brackets stuff and on top of that syntax you can define a meta-language and its transformation into Lisp code. The XML world is a second example. XML defines a basic language which can be extended e.g. by means of XML Schema in order to define new languages. XSLT is the transformation language which accepts any XML language as input. The output can be arbitrary text or an instance of another XML language.
According to the podcast (part 1 - 24:30) MDA can be considered as a specific flavor of MDSD. It is a set of standards on that field which focus on interoperability between tools. The downside of this approach is that MDSD has to be specified in its full generality which makes things complex. Not always do the input language, the output language and the transformation language share a common syntax like in the case of XML/XSLT, for instance.
So it takes no wonder that more direct approaches are often chosen in practice. For example Scala has built-in support for specifying domain specific languages. Ruby is also very popular for creating DSLs. Python has a very fixed syntax and is thus less applicable for DSLs. Nevertheless a friend of mine and me invented a DSL for mail filtering in Python, which we had done before we have been becoming aware of the whole MDSD topic.
The topic is hot. Here is a potentially incomplete list of related work:
- Microsoft Oslo
- Meta Programming System
- Eclipse Modeling Project
- The TXL Programming Language
- XLR: Extensible Language and Runtime
- Whole Platform
- Intentional Software
Even more related work can be found in the program transformation wiki.