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.
