Modelling Revisited

A few years ago I built a big extension on my house. First of all I had to get the plans for the extension drawn up showing what the extension would look like and where the rooms would be. This outline plan I showed to my wife and friends to explain what the extension would look like. Some people had real problems understanding the 2 dimensional drawn representations and so I built a little scale model in cardboard of what the house would look like with the extension. Finally when everyone understood and agreed to the extension I sent the outline plan to the planning authority for their approval.

When I had planning permission I then had detailed building drawings made which showed the structures and walls within the house. This was sent to the Building authority for approval that what I was building was structurally sound. When I had that approval I sent the drawings to a number of builders for their quotes and then finally selected the builder to do the construction. He used the building drawings to work out what should be built where and when, getting individual contractors in to do the building.

The building process was made possible by these successive refinements of plans or models at different levels providing simplification of the complex process of building a house and the communication between all interested parties of what was being built.

Similarly in building a computer application we can use plans and models to provide simplification of complexity and communication of ideas and concepts. There can be multiple levels of plans (or architectures) providing different viewpoints and different types of models such as drawings or three dimensional models.

If software had been around as long as building (some 5000 years) and we had as good an understanding of the process and technologies involved then this top down development approach would probably work as well in software development. The IT industry is relatively new however and so, whilst some elements of the building model work a full top down methodology is less applicable. In fact a more iterative approach seems to be the way that software is best developed.

Whilst the full top down approach of the building model may not be applicable as computer applications have got larger and larger the need for plans or models for simplification and communication has become more and more important. The capturing of high level models of applications using graphical languages such as Unified Modelling language (UML) has been around for a while now and the power of modelling in this space is well understood. With the present focus on productivity and agility modelling is now being examined as a technique to implement applications more quickly.

There are at present two different approaches to this use of modelling for agility: Model Driven Architecture (MDA) from the OMG and Domain Specific Modelling (DSM) or Model Driven Software Development from Microsoft. Both of these are based on the premise that Modelling is a valuable and powerful technique for communication and simplification which will allow the construction of applications much more quickly and flexibly in just the same way as plans are used in building.

MDA is based around the concepts of sets of models or plans at different levels of abstraction and the ability to transform from one level to another and finally to the code and back again automatically with tools. This is like being able to have a set of tools to convert high level planning drawings to building drawings and then to the real building automatically with no builders required.

DSM is based on the concept of a model or plan for each domain or level of architecture and the validation of one domain against another but not the ability to convert automatically from one plan to another. In DSM each level of plan is constructed separately, as with the building plans, and then there are tools to check that each plan integrates with the other plans i.e. to do plan or model validation. In this approach programming is still required but the integration of the various modules is checked by tools. So for example a software system would have a application domain for the application functionality and a deployment domain for the physical servers that the application is to be deployed on. There will be models of each of these domains and then tools to validate that the models will work together. For an example of this approach see the PDC developer session number TLS345. DSM is far more likely deliver solutions to the problems of complexity and change in the sort term based on models that provide different perspectives and useful abstractions. The change and churn experienced in software development means that it must be easy to move between these models (including code) in both directions and all the time which is exactly what DSM provides.

So there are two approaches to using models in software development: MDA leans towards fixing the languages used for modeling (UML 2.0) with only a little room for customizing those languages to the domain. DSM leans towards designing a language to fit the domain. MDA means you develop one tool (e.g. for UML), but requires you to twist the language to work with the domain, and often means that, for example, it is very hard to reverse mappings into code. In DSM the modelling language is designed to fit with the domain. So if you are concerned about generating code onto a particular framework to support a particular domain, a DSM approach would design a language for this task. Inevitably the distance between code and language will be much smaller and reversing the mapping more likely to be possible. Reversing code mappings is important if your developers need to touch the code, which, for the foreseeable future, they will (it takes time to build a generator that produces all the code, especially if you are limited in the changes you can make to the language you are generating from, as in the MDA approach). Inevitably, MDA leads to a more top down approach similar to case which won’t work with software.

There is a good discussion about these different models on the architecture section of DNJ online.

In summary pretty well everyone agrees that we can use models to significantly improve productivity and agility in the software industry, however there is a major difference in the way that various organisations believe that these models should be used. MDA proposes the replacement of programming by models and automatic code generation and DSM advocating the use of models to frame the programming task in terms of models and automatically validate these models against one another.