With traditional development you would write a script to modify the database schema to create a joining table, write another data transformation script to copy all existing product to category associations to the joining table, write a third script to get rid of the old tbl_Product.CategoryID field and then modify your code, tests and documentation to capture the new relationship between products and categories.
If this was a rare occurrence it might not matter too much, but we spend almost all of our development time modifying systems - not creating them. We build a first cut of the system and then often spend weeks or months modifying it from what the client originally asked for to what they actually want. And then the application goes into production and needs to be maintained and modified for years to come. Maintenance is the *big problem* in software engineering and a traditional artifact based approach (working on database schema, data, program code, tests and documents as separate artifacts) can make small changes to the application a large undertaking.
Imagine if instead, we applied transformations to our applications. Instead of manually going through all of the steps to add a property to a business object or to change a relationship from 1.1 to 1..* we just described the parameters of the transformation required and allowed an automated system to regenerate all of the artifacts (code, docs, tests and scripts to transform the db structure and to transform the data based on the transformation rules). In this way we would be able to easily transform any given code base or database to a new version of the system (and for reversible transformations, back again). We would also be writing much DRYer applications as we would be expressing our real intent (move from 1..1 to 1..*) rather than describing all of the things we want the system to do (changing the db schema, copying the data, cleaning up the schema, modifying the code, the docs and the tests).
What do you think? Obviously this is non-trivial to solve in the general case, but I've been working a lot with my Software Product Line and for a useful set of transformations this seems like an approach that might be implementable.
I have been fascinated ever since I read a number of papers on transformation based program development while doing background research onto my "automated evolution of statements in evolving domain specific languages" paper for the DSM forum at ooPSLA last year, but I'm really starting to think that a mainstream capability to allow you to express intent in terms of the required deltas could be incredibly useful. After all, the intent is to "change relationship" and that would be an incredibly concise way to express that intent.
Putting aside (for a moment) the practicalities of implementing such a system (expect some more postings on that over the summer when I get the time to work on this for real), how would you like to be able to simply express the changes required to your application and to have the changes in the underlying artifacts implemented automatically?
Right now I see it as something I would use for applying transformations to models rather than code. So if you wanted to change the relationship between business objects, I could automate that as I describe those relationships using a DSL so there are lots of techniques I could apply to implement the changes to the model (and therefore to the underlying artifacts that the model generates) automatically. Writing something that would parse and apply transformations automatically to code written in a 3GL would be much more difficult (one more reason why writing code in a 3GL should be a last resort rather than a first choice for implementing most application intent).