Channels ▼
RSS

Parallel

Tame The Code Beast


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.

Conclusion

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video