Why Models Shouldn’t Be Programs

Here's a great post on "why models shouldn't replace programs":

http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx

Look–Model Driven Architecture is pretty much ignored by practitioners.  In practice, really interesting problems modeled in detail result in models which are as daunting as those in the link above’s example.  The problem is, modeling is to clarify, not to replace, programming. Models must leave out lots of detail to be useful. This is almost the first thing Booch, Rumbaugh, and Jacobson say in "The Unified Modeling Language User Guide"--in my copy, page 6, in italics, in the center of the page: "A model is a simplification of reality", followed by (again, centered and in italics): "We build models so that we can better understand the system we are developing".  If the model becomes so large and complex that it doesn't meet that goal, I submit it has failed.

So: I believe executable design tools must (a) execute the model faithfully, but (b) integrate nicely with existing languages for the detailed work.  Nobody wants to maintain a set of generated classes in synch with a model, and the model should be the application’s core.  It must not try to be the application!