ask me)
| 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...
Microsoft's Domain-Specific Language Tools
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 :
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) :
Business Facades" (fine/coarse-grained interfaces between sub-systems within the system and coarse-grained interfaces between the system and external systems)Business Objects" (where, aside the business entity state handling, business rules checking the system's state locally are implemented)WinUI classes total)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.
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).
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 %.
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.
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.
| [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