As an analogy, consider SQL queries. A SQL query essentially describes the data you want and the query engine in the database figures out how to fetch it. You don’t specify indexes, files, sectors, join algorithms or any low level details. The database derives a query plan (program) by looking at the execution costs, decides on the best approach and then runs it. We can do the same thing at a higher abstraction level.

Suspend your disbelief for the moment and assume you had a complete description of the database (e.g. Entity-Relation Model or an Object-Relational Model) and a description of all the HTML forms for the user interface. Given no middle-tier logic, I propose that it would be straight-forward to generate an optimal middle-tier for such an application. As proof, look no further than the tools I listed in the previous section.

However, the application we just generated will be too simplistic. For real applications, we’re going to need to add other models into the mix such as

• Validation or Business-Entity integrity model
• Navigation Model
• Business Process Model

But rather than modelling implementations in UML, let’s capture the requirements of the model and then extend our code generator to consume the new model and generate appropriate code. You can argue whether we’re actually capturing requirements or just creating a very abstract design model. The point is to model the highest level abstraction that we can code generate from. This cycle of model and generate becomes the primary activity of software development.

For some requirements, this model and generate paradigm might not be cost effective and it would be better to invoke binary components or external web services. The trick then is to specify the conditions under which the external service must get called so the code generator can weave in calls to it at the right points. Again the key is how to capture the requirements for invoking it.