Analysis of Stadium as a model driven development tool - Part 1

What is model driven development (MDD)?

In model driven development, a software application is described using models. These models are specified at a higher abstraction level than conventional programming languages. These models are then transformed into a working application by generating code from the model or interpreting the model. In other words, instead of using code to develop applications, users start with a model and the model is transformed into code using a tool.

The idea that models should drive software development is more than 20 years old.  In some cases the tools were only able to generate code templates and the rest of the code had to be written in a conventional way. A common factor in all these approaches is that the proper use of models raises the abstraction level and one can cope with complex systems with less effort.  This can be compared to the evolution of programming languages from assembler to modern high-level programming languages such as C# and Java.

There are some key functionality areas when assessing MDD tools.  It can be divided into modeling support and development support. This blog post will cover modeling support for Stadium. Development support will covered in another blog post.

Modeling support

Abstraction'The ability to enable work on the correct abstraction level for the given task'

The aim of this abstraction is to increase productivity. However abstraction comes with a downside, designers can't change every minute detail they want. If this kind of functionality is needed, we might as well go back to programming. So yes, it comes with rigidity.

In Stadium, designing of pages and configuring of actions are done via models.  These are at a higher level of abstraction i.e. users do not have to worry about javascript, mechanisms used to connect with database, the mechanics involved in executing a query.  These concepts are hidden away from the designer of the application. This is something you will greatly appreciate if you know how many lines of code these abstractions map to.

Stadium however does not abstract sql queries. Stadium designers need to be experts at writing sql queries .

Understandability'The ability of the models to be understood by stakeholders'

From a designer perspective, the model for designing pages is very simple and easy to understand with some introduction. However if the models are seen as a mechanism for communication between designers and business stakeholders, Stadium falls short. Stadium's designer does not have a WYSIWYG forms model and thus cannot be used for communication purposes e.g. grid control is displayed as a single control in the  forms designer, its columns cannot be seen. It can only be seen when the sap file is uploaded on the website.

The model used for calling actions is very simple. However in the case of some actions e.g. decisions, the display can get quite complex and it would be ideal if there was some mechanism to 'package' actions  and drill down only if necessary. This will improve the understandability. 

 It is also worth noting that the notations used for the models are custom notations and do not follow any industry conventions.

Executability'The ability to work incrementally to examine system properties by experimentation.'

The models can be executed fairly easily in Stadium. Designers only have to save the models, upload and view it.  Designers can work iteratively and see changes taking effect. However it is a bit cumbersome as there is no one click and deploy mechanism. Users have to continuously switch between the designer and web application to see changes. There is scope for improvement in this arena.

Model transformation and refinementA transformation is basically the process of extracting the model information and using this information to create a new artifact, for example a unit of code in a language like Java or HTML.  A tool with refinement support allows the designer to define custom refinement rules/model transformations.

In Stadium3, there is no way to define or change how the models are interpreted,  or to define custom transformations.  Stadium provides fixed models  to build web applications. This does keep Stadium very simple.

Stadium designer does not currently have enough support for ensuring correctness of the models. Designers have to upload the applications to check for errors.