Before moving to an SPL approach, the biggest problem SystemsForge had was managing the complexity of product features: There were just toomany configuration options to implement them all at runtime. To tackle that complexity, SystemsForge created a software product line that used a concatenation-based code generator -- meaning the code was linked together in a chain.
This approach worked all right to create multiple applications for clients with similar needs, but it wasn't flexible enough to scale to multiple clients with differing requirements. Consequently, SystemsForge decided to move its SPL to a template-based generator that promised to be more concise, more flexible, and more powerful than the concatenation-based one.
There are a number of product options to support an SPL. The SystemsForge team looked at various ones, including MetaEdit+ for building modeling environments, Microsoft's domain-specific language tools, the openArchitectureWare project (now part of Eclipse Modeling Tools), various UML-based code generators, and products such as CodeFluent, a model-driven tool for creating .NET applications that's described as a "software factory." The company also examined products such as pure::variants and BigLever, which specialize in SPL management market. In the end, SystemsForge opted to write its own code-generation framework, in ColdFusion, in less than 2,500 lines of code. It decided the benefits from control outweighed the robustness of third-party software. While it lacked the sophistication of commercial alternatives, it was a useful starting point.
Over time, the SystemsForge team raised the runtime framework's level of abstraction to replace a lot of the repetitive generated code with a runtime interpretation of XML models. It also created a standard interface to the metadata so metadata storage could be decoupled from the implementation of the generator. And finally, SystemsForge reimplemented a front-end wizard that made it possible to build applications such as e-commerce systems faster than before.
Working With Custom Code
For most SPLs, developers need to support some degree of truly custom, project-specific code. When the company built its first version of SystemsForge, before using SPL, it used a large core framework with project-specific directories for assets (images, CSS, etc.) and custom code. Generally developers did ad hoc customization of features rather than having a well-structured approach to application extension.
When moving to the SPL template-based generator, SystemsForge developed a smaller framework with numerous extension points. Events/listeners let it add custom functionality such as login, saveDomainEntity, and before/after controller actions. Subclassing generated code let SystemsForge overload specific generated methods. Mixins, partial classes, and includes let it mix generated and handwritten code into one runtime script -- while still saving it as two separate files. That allowed active regeneration without losing hand-coded changes. Generated custom tags let SystemsForge reuse complex generated logic such as list pagination and complex administrative user interface widgets in view code. Protected regions let the company customize specific parts of a view template while still allowing for active regeneration of the code as configuration options were changed.
These changes extended the viability of the product line. By having a well-structured, template-based, code-generation step with well-defined extension points, SystemsForge was able to create more than 100 applications with a code base of about 85,000 lines of code, including framework and generator code but excluding project-specific custom code. That's far less than the 140,000 lines with the concatenation- based generator. If they started with an approved HTML/CSS design, configuration would typically take one to two hours; project communications would add another four to six hours; and the custom code would take another week or two to write and test, depending on the complexity.