Wednesday, 16 November 2011

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.

Thursday, 10 November 2011

Stadium3 Release : 3.2.1952.4311

Build 3.2.1952.4311 is available for download. It includes:

New Features
  • New search feature in designer - Designers can now search for pages, controls, connections etc
  • New ChildGridIterator action for iterating child grid rows
  • Filter fields - Default values can be obtained from database
  • New system variable for logged in user name
  • DataGrid Image column can now get image url from database

Bug fixes
  • Panels with fixed height now display scrollbars
  • Maintenance message will be displayed to users when refreshing an application
  • Security is applied when navigating to pages directly
  • Fix for messagebox not responding to Enter
  • Link control on master page now works
Looking forward to feedback on the new features.

  • This will be the final release for this year
  • This is also the final release on Framework 3.5
What next:
  • Upgrading to Framework 4.0
  • Making some small changes to make Stadium look better, like Johan said 'putting some lipstick on'......

On a personal note, I have really enjoyed the interactions with all the stakeholders of Stadium, especially this year.  I have learned a lot from you, thank you!

Monday, 7 November 2011

Stadium usage statistics

We have performed an analysis on all the Stadium applications that are currently running at our clients.  The aim of this excercise is really about learning and gaining knowledge about how Stadium is used.  It will also be used in future when identifying opportunities and developing enhancements.

Top 10 applications (based on page count)
Bulk Deregistration321

Least Used Controls
 Guage                                0
 CheckBoxList                         1
 RadioButtonList                      1
 RSSFeedViewer                        1
 TreeView                             1
 ReportListViewer                     2
 ReportViewer                         11
 URLViewer                            14
 RDLViewer                            15
 Chart                                20
 TextBox                              27

Least Used Actions
 CallAssemblyMethod                   0
 CallWebService                       0
 ExportToExcel                        1
 CheckBoxListIterator                 2
 SaveControlValues                    14