Where DSL Meets SPL
SystemsForge clearly had an effective system for managing bounded (limited) variability using configuration options, but some of the configuration settings they needed required a different approach. For example, the company found that different projects required products to have additional properties. In some, they might have a wholesale price; in others, they might have a bit setting for determining whether they could be shipped internationally. Eventually, more than 60 percent of the configuration options were based on these kinds of settings. Also, even at 80,000 lines of code, the code base was still expensive for a small business to maintain and evolve. In particular, making changes to underlying technologies such as the persistence framework required substantial effort.
Consequently, SystemsForge decided to fundamentally change the way that it implemented projects by using domain-specific languages to describe each application. They created languages to describe entities, properties, and their relationships, to describe validation constraints, to describe common controller actions, and to describe common view types and view widgets. Technically, this was both the most challenging and the most interesting step in the evolution of their SPL.
There were both benefits and costs to moving to a DSL-based approach. By using DSLs, they substantially increased the flexibility of the product line because the DSLs supported unbounded (unlimited) variability. It didn't matter what property they wanted to add to an entity or what validation rules they wanted to add; they could describe it in the DSL without increasing the complexity of the underlying framework. Also, it substantially decreased the complexity of the framework. They were able to replace an 80,000 LoC project with only 6,500 lines of code -- a substantial win in terms of maintainability.
However, moving to a DSL-based approach substantially decreased development speed. For example, if they wanted to create a commerce site, instead of just selecting a handful of common configuration options in a couple of hours, developers had to spend a day or more fully describing all of the entities, properties, relationships, validation rules, controller actions, and views required to implement an e-commerce application. This step added up to 80 percent to the time required to create a simple solution, but as the complexity of a given project increased, they often won that time back by using the DSLs to replace a lot of custom code.
To improve the speed of development for simple projects, SystemsForge then reimplemented the wizard-based configuration system on top of the new DSL-based framework. For ease of parsing, they used an XML concrete syntax for the DSLs. To create a new project, they would run the configuration wizard to generate a first cut of the DSL models quickly, and then just manually edit the XML files as the details of the requirements changed. The framework still supported the same extension points as the previous system for integrating project-specific custom code. This brought them back to the efficiency of the original system for simple projects, but added the flexibility of the more-sophisticated DSL-based solution.
Around the same time, SystemsForge ported the project from the Adobe version of ColdFusion to Railo, an open-source alternative for processing ColdFusion scripts. By moving to an open-source implementation, they had more control of the language and were able to get speedy patches and improvements.
More recently, SystemsForge ported the product line to use Groovy and Grails. Groovy is a dynamic language on the JVM that enhances developer productivity while offering interoperability with Java class files. Grails is a convention-over-configuration framework that allows for rapid development of web applications based on top of proven enterprise Java frameworks including Spring, Hibernate, and SiteMesh. The choice to rebuild in Grails was driven by overlap in the capabilities of Grails and the in-house LightBase framework, and Grails was a better solution for more complex systems.
SystemsForge is continuing to investigate new tools and processes. Key research areas include DSL evolution, DSL testing, and tooling that integrates SPL variability management with generation of DSL models as they contemplate the next generation of itsproduct line.
The changes SystemsForge implemented using a software product line approach were driven by client needs. But they were supported by extensive research into best practices in domain-specific modeling and software product lines. Change is the one thing any company can count on, and being prepared to manage change is a prime benefit of the SPL approach.