Executable Conceptual Models

On Wednesday, we began to dive into executable conceptual models in our Information Architecture class with Dr. Liddle. An executable conceptual model is basically the concept of automatically generating working code from a model created with UML.

When designing complex enterprise systems, there are often times multiple hundreds to thousands of tables that store all of the application data. Modeling this data is perhaps the most important aspect of building a good information system. So, the pain that the executable conceptual model solves is having to translate the monstrosity of a data model into executing code by hand.

Is this even possible? Or is this just pie in the sky? Dr. Liddle is on the scientific board for the OlivaNova project. OlivaNova can take a conceptual model, and compile it down into working .NET code. He says it isn’t elegant, but it does function well. Oscar Pastor, Juan Carlos Molina and Emilio Iborra wrote an article “Automated Production of Fully Functional Applications with OlivaNova Model Execution” by Oscar Pastor, Juan Carlos Molina and Emilio Iborra.

The doubt that I have about these executable conceptual models is their effectiveness to produce good user interfaces. Technology is only half of what makes up a successful Information System implementation. An information system is only as good as it maps or improves business processes. In change and project management, it is critical that those who are most affected by the new system are able to give their input on what will and won’t work.

Designing a system from the user interface has proven to be an effective process in software development. It allows changes to the application to be made while changes are still cheap. A change in design is a lot easier to do when it is still on paper. It is still relatively cheap when the change needs to be made to an electronic prototype. Changes become very expensive when the change needs to be made to fully programmed systems.

Designing from an interface also helps system designers to discover the real model that needs to be implemented behind the scenes. There will be less, “Oh, we need to be able to tie x to y and keep track of z, d, and q” remarks after the system is delivered. This is where I think the weakness of the executable conceptual models lie.

Ruby on Rails, and its imitators, have wowed developers around the world by its ability to automatically generate working code and a user interface from a data model. This auto generation of user interfaces is called scaffolding. This has proven to be very nice in kicking finished products out the door quickly, but is doing this taking a backwards approach?

Jamis Buck, one of the core developers on the Rails project, and renowned programmer on the 37 Signals team says the following about scaffoldings’ place in web development:

“Specifically, the issue I have with scaffolding is this: it puts the emphasis on the application’s model, instead of the user interface. It assumes that you know the domain of the application before you know how the user is going to interact with it. It assumes that the user interface can successfully follow your conjured domain. It assumes, frankly, far too much.” –Jamis Buck

I believe that with a small and simple data model, scaffolding does make sense, and it can save a lot of time. But, when an application begins to reach any level of complexity, the design must go way beyond scaffolding and actually be molded to a user’s specifications.

3 thoughts on “Executable Conceptual Models”

  1. Hey Jimmy,
    Good post. Dr. Liddle’s project sounds a lot like what TenFold has been after all these years.

    Did you know that Jamis worked in BYU OIT before he went to work full-time for 37Signals?

    Adam

  2. Jimmy, we need one minor clarification: I do believe the OlivaNova approach is elegant — it just doesn’t produce the most desirable user interfaces without some hints. In fact, I think one of the major innovations of the OlivaNova Model Execution environment is its ability to model UI patterns. We’ll talk more about this in class, so stay tuned.

    BTW, you wrote a good analysis of the issues of modeling vs. programming.

  3. Jimmy,

    Great Post. I first heard about this from my brother who is a developer for Lockheed Martin. I think it would be a great way of programming. I would much rather read/alter someone’s UML than to decipher their code to make changes. I wish I had a class on this.

Comments are closed.