Cyril J. Jandia, May, 2008 (unfinished paper, experimental tool fully functional though... ask me)

AppBuilder

An attempt to achieve agile code generation "in the large" of N-tier .NET Back Office applications (and possibly other kinds) using a domain-specific modelling language implemented with Microsoft's Domain-Specific Language Tools

AppBuilder in action...

Notes:

* please allow 20 secs. or so for the Flash video clip of this AppBuilder demo to initialize, as your mileage may vary;
* the player provides a cursor for pause/fast forward/replay/etc as you probably don't have the time to view the full 40 minute-long clip...
* interactive modeling between minutes 0 and 28, codegen between minutes 29 and 30, build in minute 31 (zero warnings, zero errors), then execution at minute 35 and on...

Software Factories

Microsoft's Domain-Specific Language Tools

Content

  1. Introduction
  2. Context
  3. Goals
  4. Non-Goals
  5. Devised design
  6. Domain-Specific Modelling Language
  7. Validation of model instances
  8. Code generation
  9. Contemplated further work
  10. Conclusion
  11. References
  12. Figures

screenshot

1. Introduction

The Idea

My idea of building a (MS Visual Studio-integrated, Model-Driven, Codegen-enabled) Software Factory to generate business application code came from considering the following :

A Sustained Software Development Effort

Starting from September 2005, we three developers (Olivier, Guillaume, Cyril) have worked full-time during eleven months (660 man days) to implement, "from scratch", the Back Office part of a country-wide production/delivery/management system to manage paper/electronic service vouchers (see Business domain below). Today in production : 30,000 affiliates, 600,000 beneficiaries, 50 millions vouchers/tokens, after one year and half of system up-time (for the main figures).

(Note, however, this one is still considered as a "young", or "small" Back Office system ; big ones currently in production in bigger countries have to handle up to almost 5 times as big volume, for the local subsidiaries)

So, for this, the following amounts of code have been produced, only for the Back Office application in the strict sense (i.e., the system part used by the call-center operators, by a small part of the marketing/subsidiary management teams, and called by the Front Office's extranets' web services and the IVR's) :

The Devil's Details

  1. hand-written : a small framework/toolkit providing 150+ specialized base classes (for UI, remote object activation, persistence, helpers such as formaters, etc) upon which the rest has been built (client tier, business tier, data access layer)
  2. hand-written : 60 classes and 60 interfaces for the "Business Facades" (fine/coarse-grained interfaces between sub-systems within the system and coarse-grained interfaces between the system and external systems)
  3. hand-written : 105 classes for the "Business Objects" (where, aside the business entity state handling, business rules checking the system's state locally are implemented)
  4. hand-written : the corresponding 100+ NHibernate mappings (XML files)
  5. hand-written : 25 helper classes for some facades' specifics (parsers for proprietary file formats used for interchange with some external systems ; e.g., banking-related, paper vouchers printers-related, etc)
  6. hand-written/designed : 120 WinForms (client tier screens) built using 22 reusable, screen-agnostic user controls (thus, 142 WinUI classes total)
  7. designed : 75 reports (.rpt)
  8. designed : 100 typed datasets (defined using Visual Studio's dataset designer, generating the C# and the XSD's)
  9. hand-written : the various SQL scripts for the creation of the tables (64), views (120), stored procedures (a dozen), and a few user-defined functions

A Strategic Coding Pattern Choice

Important to note, as additional item (j) : right from the start of the project, we had decided that, as much as possible, the developers should strictly follow, all through the three tiers, the documented client/caller code patterns defined for a proper use of the toolkit in (a). Of course, there were also client/caller code patterns to be followed for the "glue" between the tiers.

Lines Of Code

In all, the enumeration above represents, as far as the hand-written C# code alone is concerned (excluding (a)) : a little less than 120,000 LOC (75,000 LOC for the business/data access layer and 45,000 for the UI).

The Bottom Line Observation

Observation : a very big part of this code is nothing more than very repetitive, rather tedious "plumbing" (more or less technical) between the three tiers and/or with the toolkit (a). Sadly, we have no accurate measure yet about this proportion, but we suspect it to be quite easily greater than 90 %.

Back To The Rationale Idea

Hence the idea : try to generate as much code as possible of this part, from a model, and also thanks to the choice made in (j).

Hopefully, it should help to save us some time on similar projects and allow us to focus more on the implementation quality of the business (more statistics, business intelligence, etc) and/or on some other areas requiring specific performance optimizations : on resource usage and/or execution speed.

The Microsoft DSL Tools For Visual Studio (2008) To The Rescue

For that, I decided the Domain-Specific Modelling approach, for which the DSL Tools provide a very good support, is probably today the best device at hands to express our code generation needs and address them rapidly, in a user-friendly way, as the DSL Tools are designed to enable the construction and use of such a custom tool within Visual Studio's IDE itself.

2. Context

Business domain

Fundamentals
The System produces paper or virtual/electronic Vouchers/Tickets/Tokens (belonging to classes of Products) that the Customers buy on behalf of the Beneficiaries (<< Issuing process >>), the latter using those Tokens to pay for Services (less often, Goods) at the Affiliates'. Of course, periodically (<< Reimbursement process >>), the Affiliates return the Tokens they accepted from the Beneficiaries to the System, in order to be Refunded by it.
Basic B2B model
In this model, the Customers are Companies (or Administrations, Associations...) in either sector (private/public) and the Beneficiaries are their Employees (or Members...). The Affiliates are Companies in the private sector (Affiliates are also sometimes called Acceptors).
Derived B2C model
In this model, the Customers are the Beneficiaries themselves (often, Individuals or their families).
Main element out of the System's scope
(In the B2B model) The System never tries to represent/manage the transactions between the Customers and the Beneficiaries (the System just can't, and it is of no interest anyway).

Application domain

...

Architecture of target applications

...

3. Goals for AppBuilder

...

4. Non-Goals for AppBuilder

...

5. Devised design

...

6. Domain-Specific Modelling Language

...

7. Validation of model instances

...

8. Code generation

...

9. Contemplated further work

...

10. Conclusion

...

11. References

...

12. Figures

...

[Anders Hejlsberg] "Partial types allow classes, structs, and interfaces to be broken into multiple pieces stored in different source files for easier development and maintenance. Additionally, partial types allow separation of machine-generated and user-written parts of types so that it is easier to augment code generated by a tool."
[Steve Cook, March 2005] "I think good programmers will use whatever tools they can find to make themselves efficient. Good programmers don't like doing boiler-plate, repetitive, dull work. They want that to be done automatically. What they want to do is the piece that really makes the difference. A very important aspect of software factories is the automation of those menial, boiler-plate tasks so that you can be more efficient at putting the real business value into the system."
"[...] software production [...] would be a mature industry if software projects succeeded on the whole, instead of failing on the whole, as they do."
[Stuart Kent, June 14th, 2004] "[...] Remember that the use of code generators is meant to increase productivity. So look for those cases where putting information in a model and generating code will save time and/or increase quality. [...] For example, look for cases where you can define a single piece of information in a model, that the generator then injects into many places in the underlying code. Then, instead of changing that piece of information in multiple places, you just change it once in the model and regenerate."
[Gareth Jones, Krzysztof Cwalina, 2004] "[...] Delegate methods provide a step on the way towards enabling a separation in the collections programming model between structure and algorithm."
[From AppBuilder's source code (---.AppBuilder\Dsl\DomainModel\TypeEntry.cs)]

"I have made this letter longer than usual, only because I have not had the time to make it shorter."
Blaise Pascal

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.