Software Factories (and Prolog)
I'm reading 'Sofware Factories', the book where the VS.NET Enterprise Tools guys explain how they think the software development process can be improved dramatically.
It's a 600 page book, with solid theoric background on patterns and modeling (it's not a patterns book, it refers to the roles they play in an application).
The 30 second elevator pitch is that we cannot continue to develop software as craftsmen and we need a more industrial approach to it. They believe that a mix of modeling tools, frameworks, patterns and code generation can make that a reality, and I fully agree.
I think it will be an important book to help changing the mind of the developers who think they need to manually code each line of their applications.
I read from page 1-140 during a (long) flight, and as I wanted to get to the meat of it, I skipped 300 pages, to the part where they explain how they think the application code will be generated.
Their basic code-generation construct is a rule like:
IF
(WS_DSL: ?wsl is a web service) and
(WS_DSL: ?wsl offers port ?p1) and
(WS_DSL: ?p1 request message ?m1) and
....
THEN
.. Generate code somehow (using a template for the code snippet, use a CodeDom or just use WriteLine)
The 'IF' part queries the metadata model, and the 'THEN' part generates the code.
As we generate code in Prolog, this made perfect sense to me. It looks exactly as the kind of code we use in our code generation engine. In fact, they take Prolog as a valid implementation language for code generators saying that the main drawback is that the metadata needs to be written in Prolog (which is not a problem if you don't write it manually, even if Prolog is simpler to write than XML for metadata ;).
The other approach that seems valid to them is to evaluate the 'IF' part using a query language like XQuery/XPath or SQL. That makes things easier, but you will still need to evaluate all the IFs for every rule and you won't have backtracking so I still think Prolog is much better.
One problem that I see with their approach of using one Domain Specific Language for each domain, is that the metadata from one domain is not isolated from metadata for the rest of the domains. For example, if you have a DSL for defining Business Components and you have a DSL for defining web services, then you'll probably use the metadata in the first model as an input in the second one, and you'll need to have them synchronized (i.e., if I rename a Business Component I need to rename the entry in the web services diagram).
They probably can address this with 'model to model' synchronization, or by having a way to centralize metadata, like having a reference to the Business Component DSL in the Webservices DSL. Anyway, if this is stored in XML files then it can be hard to manage (e.g., no referential integrity), so it's probably better to use a database for this, but then everything looks more complex.
Perhaps this was discussed in one of the 300 pages I skipped. If that's the case, I'll found out later this week and let you know ;)