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 ;)