A Practical High Volume Software Product Line

Transcription

1 A Practical High Volume Software Product Line Peter Bell SystemsForge 9/10 St Andrew Square Edinburgh EH2 2AF [44] (UK) [1] (US) Abstract Many Software Product Line case studies focus on the fact that an ROI can be achieved in 3-5 projects. This paper asks the question what has to be done differently to be able to generate 10,000 custom applications a year?" As wholesalers of custom web applications for Small to Medium Sized Businesses, we have to create highly customizable web applications in minutes not months. After 18 months of research and experimentation we have developed a layered system that focuses on the reuse of declarative executable specifications rather than the reuse of imperative code, allowing us to blend speed of development with flexibility of the generated solutions. The system uses a feature modeler to select common functionality and a decision support system to de-skill the customization process. It has a collection of domain specific languages for describing the vast majority of custom functionality required by our clients and an extensible framework allowing any system functionality to be overloaded/extended using custom code if necessary. In this paper we provide an introduction to the key theoretical concepts required to understand the system. We then introduce our domain specific languages for describing web applications. We then look at the process of building applications using SystemsForge and then we highlight our conclusions to date and document some of the outstanding issues that we are still investigating relating to managing domain specific language evolution and interactions. Categories and Subject Descriptors Engineering]: Software Architecture D.2.11 [Software General Terms Design, Experimentation, Languages, Theory Keywords Practitioner Report, Experience, Software Product Line, Domain Specific Language, Language Oriented Programming, Feature Modeling, Configuration Management, Architecture. Copyright is held by the author/owner(s). OOPSLA 07 October 21 25, 2007, Montréal, Québec, Canada. ACM /07/ Introduction At SystemsForge, we are wholesalers that develop custom web applications for website development, marketing and design firms. Our partners often have limited programming expertise in-house and require support with quoting, specifying, generating, hosting and maintaining their clients custom web applications. We typically charge between $1,000 and $5,000 for generating/customizing a project plus an on-going monthly maintenance fee for premium hosting and continued use of the generator. The partners add project management, graphic design and data entry services and typically sell the applications to Small to Medium Sized Businesses (SMB s) for between $5,000 and $50,000. Our projects usually combine standard (content management, e-commerce, newsletter, secure document exchange, etc.) and custom functionality. We specialize in applications that require more customization or integration between components than would be available with pre-packaged solutions but at a lower price point than would be possible with a hand coded system. We provide our partners with a web-based interface for quoting, specifying and maintaining the applications. We handle the application generation along with any custom programming required. In late 2005 we realized that while we had a procedural generator that would generate common applications, it was difficult to customize the generated code and we found it hard to meet increasingly complex customization requirements while still keeping the average project price around $3,000. In short, while the generator worked, it clearly would not allow us to meet rising client expectations in terms of customization or our internal goals for scaling the business. We have spent the last 18 months developing a completely new application generator that we now use to generate all of our applications. The project has been highly successful, allowing us to generate rich, custom, well-architected, easily extensible web applications in under a day. We spent a great deal of time doing research on approaches to speeding up application development and requirements

2 gathering. From programming paradigms to frameworks, code generation, component based development, Software Product Lines and a range of methodologies for capturing requirements more efficiently. This paper starts by providing an introduction to the core concepts that we based the system on. It then explains how we model web applications, the tooling we use to generate projects and the conclusions we reached over 18 months of research and experimentation. It concludes with a summary of the key outstanding research topics relating to managing Domain Specific Language evolution and interactions. 2. Core Concepts From Software Product Lines and Variation Management to Domain Specific Languages and Code Generation, this section introduces the key background concepts that are required to understand the SystemsForge generator. 2.1 Software Product Lines According to the Software Engineering institute at Carnegie Mellon: "A software product line (SPL) is a set of softwareintensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way." [25] With Software Product Lines, instead of designing a single application, the architect develops a process for creating a collection of similar applications with pre-planned variation and extension points. Typically a Software Product Line will be comprised of a framework for building the applications, a library of reusable components, a collection of configuration and extension mechanisms, and process guidelines for developing the applications. There are some excellent books on the subject [5] [22] [13], as well as commercial tools like pure:variants [23] for facilitating configuration management within Software Product Lines. 2.2 Variation Management The hardest part of architecting a Software Product Line lies in exposing the right degrees of variability. On the one hand it is important to provide sufficient flexibility to solve the problems that the various applications will require. On the other hand it is important not to over-engineer a solution to meet requirements that may never arise. In practice, it is easiest to develop a Software Product Line if the architect has already developed at least 2-3 applications within the problem space. While there are many approaches to managing variability, we decided to categorize them into four groups: selection, configuration, DSL customization, and extension. Selection - There are often pieces of functionality that can be re-used between applications; perhaps an authentication system, a product catalog, a shopping cart, or an notification system. Selection-based systems make it easy to reuse such features and provide the quickest approach to building applications. Configuration - The utility of a selection-based system can be greatly increased if configuration of the selected features is also supported. Adding the ability to configure each feature means that each feature can be used to solve a much wider range of problems. DSL Customization - Eventually a complex SPL will reach the limits of a configuration-based approach. Over time configuration systems tend to become unwieldy, as more and more options are required to handle different use cases. A well-designed decision support system can help with this by allowing for dependent configuration options. For example, such a system will not ask about shipping methods if a specific project does not allow for the sale of tangible goods. This can cut down on the number of configuration options encountered when configuring any given system. However, eventually a configuration system becomes either too unwieldy or insufficiently flexible. The next category of variability is customization via Domain Specific Languages (see 2.3 below). For describing elements like Business Objects, Properties, Relationships, workflows or notifications, Domain Specific Languages can provide a powerful mechanism to express custom requirements efficiently without having to resort to a General Purpose Language (GPL) like Java, C# or Ruby. Extension No matter how well a collection of Domain Specific Languages are designed, eventually there will be edge cases that are not worth describing within a DSL*. Because of this it is important to include extension points in any Software Product Line so that any given application can be extended with custom GPL code. The most common approaches to extension are inheritance, events and AOP, although protected blocks and (in some GPLs) mixins can also be used for extending/overloading generated code with custom functionality[1]. * The reason for this assertion is that extending a DSL is often more difficult and time consuming than programming an edge case in a GPL. Existing [18] and future [16] tooling [9] might make extension points unnecessary. 2.3 What is a Domain Specific Language? A Domain Specific Language (DSL) is: "a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem" [10] The benefit of well-defined DSL s is that they raise the level of abstraction at which a system is programmed, allowing for the more efficient development and

3 maintenance of applications by separating intent from implementation. Domain Specific Languages allow for the clear expression of intent: what the application should do. The implementation is handled separately via either framework code for interpreting the DSL or a code generator to compile it into a GPL. DSL s can apply to programming as well as business domains. SQL and Regular Expressions are canonical examples of programming DSL s, but DSL s for describing notifications, workflows, Object-Relational-Mappings or controller functionality would all be good examples of DSL s within the programming domain. Examples of business DSL s include languages for describing the rules for configuring a product, selecting an insurance policy or describing the health benefits to provide to different insured parties. 2.4 Abstract Grammar vs. Concrete Syntax It is important when designing a DSL to decouple decisions about the abstract grammar to support from the concrete syntax(es) to use to represent the statements. The abstract grammar refers to the concepts the language is able to express. The concrete syntax describes the symbols used to actually encode the statements. Abstract grammars can be expressed in a number of ways. For those with a background in language design, Extended Backus-Naur Form (E-BNF) is a common choice. For those more comfortable with an XML concrete syntax, some form of XML schema language (such as DTD[28], XSD[29] or RelaxNG[20]) can be used to describe certain grammars. For data modelers, the database schema for the tables containing their metadata performs substantially the same purpose. Please note that while E-BNF, XML schemas and database models can all be used to express grammars, they are not functionally interchangeable as each allows for different sets of grammars and constraints. There are numerous concrete syntaxes available for representing DSL s. For high-value external DSL s [10] a custom textual syntax may be most appropriate. For other use cases the ability to leverage existing tooling by using XML may make more sense. Creating a more flexible inlanguage DSL [10] by using an API or by extending a general purpose programming language is also an option. A databased approach, storing metadata in database tables can work well for large quantities of metadata, and a visual modeling tool like DSL Tools [19], MetaEdit+ [18], or an Eclipse EMF [8] based tool like openarchitectureware [21] can also make sense for certain projects. Spreadsheet like tables, wizards and content management systems can also be used for entering and editing statements within DSL s. 2.5 DSL Storage vs. Editing Projections It is important to note that the concrete syntax for storing DSL statements may be different from the projection used to edit them. Intentional Software [16] has been working for some time on a system allowing for separating the storage of metadata from the various projections used to edit it [24] [7] and the now defunct Jetbrains MPS [17] took a similar approach, providing various projections for editing DSL s. MetaEdit+ also allow for different projections with diagram, table and matrix editors for model creation. 2.6 Why Call them DSL s? Good developers have been writing DSL s ever since languages supported named function calls. With the recent popularity of DSL s (especially within the Ruby community), there has been a certain backlash [14] against the idea of DSL s. In practice we have found benefit in widely applying the concept of DSL s. The benefit of looking at everything from data models to APIs, from custom tags to visual modeling solutions as DSL s is that it allows us to view problems more generally. Rather than believing that we need an API or an XML configuration file, we can recognize the need to design a DSL and can then use heuristics to select the most appropriate concrete syntax(es) for the use case to edit, store and consume the DSL. For example in our generator, some of the DSL s are edited using a content management system, stored in a database, published to XML and consumed using an API. 2.7 Types of Language We sometimes characterize languages as falling into one of four types: scripting, functional, templating or declarative. The characterization is not strictly true for most GPLs but we find it useful conceptually when thinking about DSL s. Within this characterization schema, scripting languages are designed primarily to imperatively describe how to implement an algorithm or a series of steps. Functional languages describe transformations. Templating languages describe "what goes where", and declarative languages provide atomic pieces of information about an application. In our experience, some of the biggest benefits in describing web applications more efficiently come from developing declarative DSL s for describing discrete (although not necessarily independent) units of intent. For example, we have DSL s for describing Business Objects, their Relationships, their Properties and controller Actions. Each can be described in terms of easy to reuse declarative statements that can be encoded in anything from a custom textual format to an XML config file, a configuration API, a collection of database tables or "boxes and arrows" using one of the many visual tools available.

4 2.8 Frameworks vs. Generators It is important to realize that there is very little difference in intent between well-designed frameworks and code generators. Both are designed to facilitate quicker application development by raising the level of abstraction of programming by using DSL s and conventions to more concisely express application intent. Rather than focusing on building a framework or writing a code generator, we have found it better to focus on developing elegant DSL s. Whether those should be interpreted dynamically via a framework or compiled to GPL code via a generator is a decision that can be late bound and changed easily. It is also important to realize that this is seldom an either/or decision. Most generators include some framework code and many frameworks include some kind of runtime code generation. 3. How We Model Web Applications When we started on the project to redesign the generator, we knew that a simple selection or configuration-based system would not be flexible enough for our needs. While we needed to develop a feature selector and a configuration manager for quickly building common functionality, we knew that we would have to layer them on top of a collection of Domain Specific Languages that would allow us to declaratively express our functional requirements. We also knew that we would have to provide extension points for adding custom code where it was required. This section looks at our meta-grammar, the four core DSL s we designed for describing web applications, and how we were able to use those core DSL s to create secondary DSL s due to a fortuitous similarity between the grammar we used to express our Business Objects and our meta-grammar for describing DSL s. 3.1 Developing A Meta-Grammar To be able to define, manage and manipulate Domain Specific Languages efficiently, it is important to develop a meta-grammar. A meta-grammar is a grammar used to describe language grammars. For instance, if a DSL is implemented using an XML concrete syntax with XSD Schemas for validating the statements, the grammar of the XSD (with the concepts of elements and attributes) can be used as a meta-grammar for describing the DSL. Equally if a DSL is stored in a database, the grammar used to describe the schema for the database (with the concepts of tables, columns and relationships) can be used as a meta-grammar for describing that DSL. We had already created a number of informal DSL s when prototyping our generator, so we compared their structure to the various meta-grammars available and decided that our meta-grammar needed to support the following concepts to express the declarative grammars that we required. Elements Each language was comprised of one or more elements. These would represent distinct, re-usable statements in the language. For example, in our DSL for describing Business Objects the elements would include Business Objects, different types of Properties, has-one and has-many Relationships and Class Methods. Attributes In XML, each element can have 0..n attributes and/or an XML text value for the text between the tag and the matching end tag. We decided to simplify our grammar by looking at XML text grammatically as just another attribute and saying that elements could just have 0..n attributes. In our meta-grammar each attribute is either optional or required and has a data type allowing for more precise automated validation of statements. Relationship Elements within a grammar are often related. We decided to allow for has-one and hasmany optional and required relationships (supporting 0..1, 1..1, 0..n and 1..n relationships). In addition we distinguished between associated and composed relationships in a very specific manner: deleting an instance of an element would automatically delete all instances of composed elements, but would not affect instances of associated elements. Inheritance We decided that we needed to be able to express inheritance relationships, so we added a reserved attribute named extends which allowed an instance of an element to extend/overload the attributes and composed sub-elements of another instance of that element. Where an instance of an element extends another instance, it inherits all of its attribute values and all of its composed elements. To take a simple example, if an UploadImage Custom Data Type extends an UploadFile Custom Data Type, it will inherit all of the attributes of the UploadFile data type, changing only those attributes that it explicitly overloads. Figure 1. The SystemsForge Metagrammar

5 3.2 Collections and Types There were two other distinctions that we did not need to describe as part of the meta-grammar (as they can be described using elements, attributes and relationships), but which helped us when developing new DSL s: collections and types. A collection refers to a related has-one element that has no attributes but may contain a collection of distinct but similar elements. For example, a Business Object may have a collection of Properties. The collection is comprised of 0..n fields, 0..n calculated fields, 0..n calculations and 0..n aggregates each of which is a type of Property. The concept of types relates to the fact that within a collection there are often different types of a thing. In our Business Object DSL, fields, calculated fields, calculations and aggregates are all types of Properties for describing persisted, calculated persisted, purely calculated and joined aggregate Properties respectively. Similarly there are two types of Relationships has-one and has-many. The idea of types of something is useful where different instances of a collection need to have different attributes and/or related Elements. The reason we have different types of Properties is because the attributes required to describe an aggregate property are very different from the attributes required to describe a simple field or a non-persisted property that is calculated based on the values of other fields. We briefly tried modeling types using inheritance but we found the simpler concept of distinct types within a collection was easier to work with. 3.3 The Core DSL s After a great deal of experimentation, we found that for our use case we needed four core Domain Specific Languages to describe Business Objects, Features, Layout Templates and Custom Data Types. Three of these map to the common Model-View-Controller (MVC) pattern, with Business Objects representing the Model, Layout templates describing the View and the Features describing the Controllers and their associated methods. The fourth DSL represents an additional concept that we found necessary to be able to efficiently describe rich applications declaratively. Custom Data Types associate transformations, validations, display rules, editing field rules and controller processing rules to the Properties of Business Objects Business Objects At the heart of any non-trivial web application is a rich Model (architecturally, the M in MVC) that can be described as a collection of interrelated Business Objects. Examples of common Business Objects are Page, User, Product, Article, Category, ProductAttribute, Newsletter, PressRelease and DiscussionThread. In our Business Object DSL, Business Objects have a number of simple Attributes describing their title, name, primary database table, the default ID property to use to uniquely access records and so on. They also have Properties, Relationships, Class Methods, Instance Methods, Object Validations and Initial Values. Properties Every Business Object has 1..n Properties. There are currently four types of Properties: fields, calculatedfields, calculations and aggregates. Fields are properties that are stored in a database (or other persistent store) based on user input and/or imports. calculatedfields are persisted fields that are sometimes or always calculated. Examples would be auto-number or GUID unique identifiers, date/time stamps and fields that depend on the values of other fields. An example of that would be a Name calculatedfield that is calculated by removing non-alphanumeric characters from a Title field. Calculations are properties that are calculated (but not persisted) based on the values of other fields. For example, User.Age is calculated based on the value of User.DateofBirth and Product.DiscountedPrice might be calculated based on the values of Product.BasePrice and User.DiscountLevel. Aggregates are properties that represent an aggregate function on a field or calculatedfield of a has-many related object. An example of an aggregate property would be User.NumberofBids in an auction system that could be a count of the number of bids placed by the user (assuming a User has-many Bids). Another would be Product.CategoryTitles that could be a comma-delimited concatenation of the Titles for all of the Categories that a Product is associated to. Relationships - Relationships are described as has-one or has-many with optional support for filtering, self-joining and intermediate join tables. This makes it easy to get a collection of home Addresses for a User or a list of Products within a Category, as well as getting the Boss for an Employee or the Author of an Article. In addition to facilitating aggregate properties, related objects and related object collections, Relationships also allow for has-one associated Properties using a dot notation. The title of an Employee s Boss, can be retrieved by asking for their Boss.Title. Providing the Employee Business Object has a "has-one" Boss relationship and the Boss has a persisted field named Title, the appropriate title will be returned in the query without having to write SQL or explicitly document the associated property within the Employee object (which would not be very DRY [15]). Class Methods - When we looked at the code we wrote for most of our web applications, within the Model, we found that a lot of the Class Methods were very similar. Because of this, we created a collection of parameterizable base Class Methods to handle the majority of the class method functionality. We also took the time to support rich functionality so the generated systems could easily include capabilities like versioning, auditing, internationalization and rollback. Now when we generate applications, we just describe the Class Methods using metadata. For example,

6 to get a list of articles in a category, we can create a virtual "getcategoryarticles" method just by describing the run time and design time parameters and the base method to pass them to. In our experience this allows the majority of our Business Objects to be implemented without any GPL Service class code, although the system is smart enough to look for a physical method in a class file if a virtual method (described using metadata) does not exist. Instance Methods - We have not yet implemented a DSL for describing Instance methods (which are most often smart getters or setters which calculate or transform values based upon some kind of imperative code). Because of this, most of our more complex Business Objects have a class file containing instance methods. This is an area that we are still investigating because we do not want to end up writing a DSL that is so flexible as to be a badly designed GPL. We are looking at the best way to classify common types of calculations and transformations to develop DSL s for replacing the most common functions (concatenations, common mathematical operations, etc.) that will cut down on the amount of GPL code, making it easier for us to be able to deploy applications to different GPLs automatically. Object Validations - In addition to property validations (which - along with display rules, editing rules and transformations - are handled using Custom Data Types), some Business Objects also have validations that relate to more than one property. Sometimes they are simple conditional validations (if Country == "US" Validate:Length(State) > 1) and sometimes they are more complex. Again we have a DSL for describing the most common types of validations and a system for easily adding custom validation code if it is required. Initial Values - Often it is necessary to be able to describe certain values that must exist for an application to work. Perhaps every application must have a Home Page and an Administrative User. By describing initial values, they are automatically added to the application database on provisioning unless they already exist Features We started by analyzing controller code from a number of projects that we had previously developed. We found that the vast majority of the controller methods could be described using one of a fairly small number of types. Because of this we created a simple DSL for describing Features. A Feature is defined as a collection of logically related controller methods. Examples of Features would be a Cart, Checkout, Newsletter, or DiscussionGroup. Each Feature is comprised of a collection of Actions (the controller methods) that have various types. Each type of action has its own properties. We are still refining the list of Action Types. Right now they include: display Displays a screen that does not require dynamic data from the Model. detail Passes an object instance (optionally including composed objects so a User could include a collection of Addresses or information on their Boss) to a screen for display. display. list Passes a collection of objects to a screen for formdisplay Passes one or more object instances (loaded with default values for add, and with previous values for edit) to a form screen for displaying. formprocess Processes a form and then calls another action depending on whether the processing was successful or not. There are also Action types relating to deleting, importing, exporting and reporting on objects. We use a pseudo-page controller architecture [2] allowing a non-technical user to add new pages to their site, and select (and parameterize) any feature within their project for those pages. We also support multiple dynamic content areas within a page template allowing (for example) a dynamic list of pages in the sidebar, a product detail in the main content area and a list of testimonials in a right hand content area while still using simple controller Actions for each area. In practice we are only currently able to describe about 85% of our controller Actions purely using metadata. However, to add custom controller actions, a developer just needs to add a class file to the feature directory. The system automatically loads the custom code and merges the virtual methods (those described using metadata) with the hand coded ones, making it extremely easy to extend the application when the limits of the Feature DSL are reached Layouts We experimented with many different ways of describing our Views. The first thing we noticed was that if we looked at a site as being comprised of a page template with multiple dynamic content areas, we could more simply describe the layout of each of those content areas. In practice we found that all of our layout screens could be described as one of a relatively small number of types that we codified in out Layout DSL. display A simple layout that does not display any content from Business Objects. detail A layout that displays a single Business Object (and possibly single has-one composed objects and lists of has-many composed objects). list A layout that displays a list of n-instances of a single Business Object. selectlist A layout that displays a list of n- instances of a single Business Object along with a

7 mechanism for selecting/submitting one or more instances (perhaps to edit or delete). formdisplay A layout that displays a form for editing one or more instances of a Business Object. report A layout that displays a report relating to a Business Object We also have a custom layout for describing screens that do not fit into any of the above types, but in our first forty projects using the new generator we have not had to use the custom layout type yet. The purpose of the layout DSL is just to passively generate templates for our partners to customize as all of our clients want more control over their HTML layout that it made sense to build into a declarative DSL. The layout DSL also configures various view helpers for automatically creating methods for paging through lists, generating the hidden form fields for form submissions, etc. simplifying the layout templates substantially Custom Data Types In addition to Business Objects, Features and Layouts, SystemsForge also heavily utilizes the concept of Custom Data Types. Custom Data Types are used to associate transformations, validations, display rules and editing rules to Properties. With Custom Data Types, a Property can quickly be described as an ImageUpload, USPhone or WYSIWYG Property and can use (or overload) a range of rich behaviors specific to those Custom Data Types. Adding new data types is as easy as creating a new class file to describe their functionality and adding it to the project or the shared library. 3.4 Secondary DSL s Of course, four DSL s do not make a rich application generator. Non-trivial applications need languages for describing workflows, tasks, notifications, value lists (for populating drop downs, check boxes and radio button lists), etc. However, because of the way our Business Object DSL works, we can generate and interact with simple DSL s without any additional programming. The Business Object DSL was designed to describe Business Objects like Articles, Pages, Users, Products, Categories and Newsletters, allowing non-technical users to describe, display and manage those objects without custom coding. However, we are also now using it to create and maintain all of our secondary DSL s. The reason that this works is that the Business Object DSL happens to have all of the grammatical elements of our meta-grammar meaning that it can be used for describing other simple DSL s. The Business Object represents an Element, Properties represent Attributes, Relationships represent Relationships, and because Business Objects can extend other Business Objects, inheritance is also supported. We have a range of secondary DSL s for declaratively describing requirements like workflows, tasks, notifications, value lists and authentication methods. We can add new secondary DSL s just by adding a simple XML config file to describe their grammar in terms of a Business Object. 4. Building Applications The interesting thing about most applications for Small to Medium Sized Businesses (SMBs) is that most of the clients do not care about the details of how the majority of their applications work. Most SMB clients are simply not interested in exactly how the newsletter is sent, the authentication method used to secure their document exchange or the administrative interface to their content management system. As long as it meets their needs and (ideally) uses industry best practices, they would rather focus on the small minority of their application that is important to them - whether that is the color of the topbar, the ability to order articles by industry or the usability of the registration form. Because most of our clients do not care about the majority of their applications, it is important to have a way to quickly drop in a best practice content management system or newsletter with minimal effort. However, over a large population of clients the minority of the functionality that they do care about covers almost all of the standard functionality provided, so it is important to be able to customize everything. 4.1 The Problem with Components Historically our generator was built around configurable, reusable pre-coded components (catalog, shopping cart, article admin, newsletter, etc.). Unfortunately, in practice such an approach was not flexible enough, as there was always something that we needed to customize for a particular client that we had not considered when building the components. As we moved from tens to hundreds of projects, the components became too complex and the approach failed to scale. However, we still needed the ability to quickly select preconfigured functionality for the clients who did not care about a given feature. The breakthrough was when we decided to re-use (executable) specifications rather than code. With our new generator, clients can still select standard packages (product catalog, secure document exchange, etc.) to get common functionality without having to specify it from scratch. In addition, a decision support system allows them to configure optional properties for the standard packages. Then if there is anything they want to extend or even overload, because all of the standard packages are just a collection of statements in Domain Specific Languages (as opposed to hard coded functionality), we can just modify their metadata and create a completely custom

8 application based on the standard features, but with any required variability. This approach blends the speed of development of prepackaged functionality with the flexibility of a custom approach and has substantially simplified the process of creating and customizing standard features while simultaneously removing the majority of our core code, making it much easier to maintain and port the framework to different GPLs. 4.2 Feature Modeler The starting point for developing a site is the feature modeler that allows our development partners to select common functionality easily via a web-based interface. The feature modeler allows for a hierarchical tree of features, grouping of features (with minimum and maximum selection constraints), dependencies (one feature requires another) and exclusions (two features that cannot both be selected). 4.3 Configuration Management Each feature has its own configuration wizard comprised of a collection of questions. The answers to each question can be of various data types (enum, string, int, boolean, etc.). Rules can be added to each question to associate additional questions as well as configuration settings and optional metadata to given answers. Each question can also have an article associated to it, so rather than having to explain the relative benefits of usernames vs. addresses for authentication, we can provide that information automatically either for end clients or for our development partners. 4.4 The Interface is The Application If a web application is viewed as a black box system, by definition, it can be fully described by the collection of all of the behaviors of its interfaces. Let us start by taking a simple case of a web application that only displays HTML screens to users based on the URL entered (i.e., no internal scheduled tasks, web API, notifications, imports, exports, log files, etc.). If a complete description is made of all of the screens along with the potential actions from each screen for each essential use case (including all conditional and error flows), it should be possible to generate an application that meets those functional requirements automatically. In short, it is possible to infer an acceptable object model for an application from a sufficiently precise description of its interfaces. For example, if a Property of a Business Object is not used to search, filter, order or display on any screen, the object does not need to have that Property. Whenever we came across a situation where a Property was required but was not described in any of the applications interfaces, it meant that we had found a new interface that was required by the application and had not been described perhaps a log file or an export mechanism. Adding support for log files, imports, exports, a Twitter [27] API for posting or approving content or a Fax/OCR interface for faxing commands into the workflow is just a matter of treating them as additional screens and actions. Where a client has custom requirements outside the scope of our Feature Selector and Configuration Manager, we ask them to list all of their essential use cases and to provide a short 1-2 paragraph description of each use case. We then ask them to describe each screen, action and other interface using the DSL s that allow us to generate the majority of the application and to identify any screens or actions that might require custom code. 4.5 DSL Customization We are currently developing tooling to simplify the customization of DSL statements for a given project, but in general terms we add custom statements to the metadata database and when we generate a project it UNION s the essential metadata for the features selected, the optional metadata associated to the project based on the configuration options and the custom metadata created specifically for the project. The custom metadata overloads the essential metadata if required, so it is possible to change the title of the Product object or the way that Products relate to Categories in a given application while still taking advantage of the rest of the standard product catalog functionality. 4.6 Extension Figure 2. Merging Project Metadata The application architecture is based around a Service class per Business Object that acts as the API to the model both for the HTML controller and for a remote façade that handles Flex, AJAX and web service calls. There is a Data Access Object (DAO [26]) per Business Object that handles SQL queries (with some help from a Data Mapper [12] that takes care of most of the ORM functionality). There is a class for each Business Object to handle instance (as opposed to class) specific concerns and a metadata class

9 for each Business Object to encapsulate run-time access to the metadata for that object. A small custom Dependency Injection (DI) framework handles the injection of all dependencies primarily using mixin injection [3] a type of generic setter injection that allows for the benefits of setter injection (support for circular dependencies) without actually having to write or generate a bunch of dumb setter methods for the DI framework in all of the beans. However, taking advantage of the Liskov Substitution Principle [30] (in reverse), the DI engine is smart enough to check to see if the class files exist for each Business Object in the project or in a shared library directory. If they do, the appropriate classes are instantiated. If not, the base classes are instantiated to play the part of the Business Object classes (so the ProductDAO may really be an instantiation of the BaseDAO). This means that we don t have to have class files unless they require custom code. If a class does require custom code we can just drop in a class file to add new methods or even to overload core methods without having to re-configure the application. This one design decision has allowed us to remove over 90% of the class files in most of our applications, making it much easier to see which objects have custom code so we can focus on removing that by refining our DSL s. 4.7 Look and Feel We do not handle the look and feel of the applications we create. We generate default templates that our design partners can customize and we provide a set of view helper classes for lists, forms and reports that take care of the more complex parts of the templating (such as generating paging links) so the designers can just use a simple templating engine to customize the HTML without having to understand the code used to provide them with %PageLinks% or %Product.Price%. 5. Conclusions Over the last 18 months we have done a great deal of research and experimentation while also building over forty projects to test out the generator. Some of the most important distinctions that we made were: Reusable Specifications By moving from reusing code to re-using executable specifications encoded in our DSL s, we were able to match the speed of development of packaged software while gaining the flexibility of a custom designed solution. Executable Specifications We developed a process (Intent Driven Design [4]) to allow our design partners to provide us with exactly the information required to generate a site as quickly and efficiently as possible. By moving to executable (as opposed to narrative) specifications we were able to almost completely remove ourselves from the specification and development process while also reducing the time taken by end clients and our partners to discover and document their needs. A Layered approach By providing multiple levels at which to customize the applications we were able to speed the development of projects without sacrificing the ability to customize the solutions. The Interface is The Application Understanding that by definition a complete description of all of the interfaces that an application needs to expose provides a full set of functional requirements allowed us to simplify and speed the process of specifying completely custom applications. The Languages are More Important than their Implementations Initially we planned to write a code generator. Now we primarily interpret our DSL s at runtime. By understanding that frameworks and code generators can be used interchangeably we were able to take the best ideas from the literature in both fields and to refactor the way we processed our DSL s independently of designing and managing the DSL grammars and constraints. 6. Outstanding Issues For a system that is so dependent on Domain Specific Languages, we still have a lot of work to do on managing them. Current topics of research include: Automating DSL Transformations We are developing a formal description of different types of transformations for DSL s. Using an XML concrete syntax we are working on a system that will be able to validate, migrate and report on the transformation of statements between different versions of a DSL with a UI for human intervention for statements that cannot be automatically transformed. DSL Validation While we currently use XSD Schemas for validating the grammar of our DSL s, we have not yet selected or developed a richer language for describing semantic constraints within or across our DSL s. We are hoping eventually to develop a system that will be able to capture additional classes of errors by better understanding dependencies within and between interrelating DSL s for certain classes of problems. DSL Versioning As part of our general work on DSL evolution we are also looking at approaches to handling, storing and processing various versions of DSL s which have different grammars and semantic constraints. For our use case, we are looking at a migrations based approach which would allow for the upgrading of all statements to a new language version based on a combination of automated transformations and manual interactions based on the documented transformations between DSL versions. DSL Interfaces With multiple interacting DSL s, we are still investigating the best way for them to

10 interact. We are experimenting with various ways of encapsulating the details of DSL s through interfaces that are less likely to change and/or developing formal methods to document the dependencies between DSL s so we can automatically flag DSL transformations that might affect references from other DSL s. Acknowledgements Thanks to: Ralph Johnson for suggesting it might be worth writing a practitioners report on our experiences at SystemsForge. Olaf Zimmerman for advice and encouragement in developing the paper. Mark Dalgarno for his work with the Code Generation Network and inviting me to present at Code Generation Krzysztof Czarnecki for his work on the encyclopedic and prescient book that introduced me to these concepts [6] and his more recent research into Framework Specific Modeling Languages. Mark Mandell for his help with understanding E-BNF. Sam Larbi for his thoughtful review of the paper. Martin Fowler whose Bliki helped me to better understand everything from Language Workbenches [9] to Dependency Injection [11]. Steve Kelly and Juha-Pekka Tolvanen at MetaCase who have probably forgotten more than I'll ever know about Domain Specific Modeling. References [1] Bell, P. -to-extension-of-software-product-lines. [2] Bell, P. Page-Controllers. [3] Bell, P. Why-I-Love-Mixin-Injections. [4] Bell, P. An Introduction to Intent Driven Design. ColdFusion Developers Journal, December [5] Clements, P. and Northrop, L. Software Product Lines : Practices and Patterns. Addison-Wesley Professional, 2001, ISBN [6] Czarnecki, K. and Eisenecker, U. Generative Programming. Addison-Wesley 2000, ISBN [7] Dmitriev, S. [8] Eclipse, [9] Fowler, M. ench.html. [10] Fowler, M. nguage.html. [11] Fowler, M. [12] Fowler, M. Patterns of Enterprise Application Architecture. Addison-Wesley 2002, ISBN [13] Greenfield, J. et al, Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. Wiley, 2004, ISBN [14] Griffith, B. dsl-api-or-wtf/. [15] Hunt, A. and Thomas, D. The Pragmatic Programmer. Addison-Wesley 1999, ISBN X. [16] Intentional Software, [17] Jetbrains, [18] Metacase, [19] Microsoft, [20] OASIS, [21] openarchitectureware, [22] Pohl, K. and Böckle, G. Software Product Line Engineering; Foundations, Principles and Techniques. Springer, 2005, ISBN [23] Pure-systems, [24] Simonyi C. Christerson M. and Shane C. Intentional Software. OOPSLA [25] Software Engineering Institute, [26] Sun Microsystems, Inc. s/dataaccessobject.html. [27] Twitter, [28] W3C, [29] W3C, [30] Wikipedia, iple.