Several presenters shared experiences from model driven software engineering in the session "MDSE in the real world" at the Bits&Chips Software Engineering conference. Earlier InfoQ interviewed Wayne Lobb about developing provably-correct software using formal methods and Hans van Weezep on how Philips is using a model-based migration approach for maintenance of legacy software.
InfoQ did an interview with Rob Howe, host of the MDSE session at the software engineering conference and CEO of Verum, about the state of practice and recent developments in model driven software engineering, the usage of this technology, whether he considers model driven software engineering to be a proven mature technology, and what the future will bring us in model driven software engineering.
InfoQ: For readers who are not familiar with this, can you describe what model driven software engineering is?
Howe: The simple fact that there is no consistent name for the subject – it’s referred to as "model based software development", "model driven software engineering (MDSE)", "model driven development", etc –indicates that there is a lack of clarity about what exactly is meant by the term. My own view is that MDSE is about enabling software engineers to work at a level of abstraction where requirements, architecture and design information is maximally ordered (in terms of information "entropy") and preserved. (Call this the "design work product"). Further, MDSE should provide engineers with the means to verify and validate their designs primarily terms of their "design work product".
In other words, modelling languages and supporting tools should provide the means to precisely and unambiguously capture all essential information relating to the design of a software system. They should allow engineers to reason about, verify, validate, generate code and debug software designs and implementations in terms of the "design work product" that they represent.
My view is necessarily focused on using model driven techniques as a substitute for conventional programming based development. However it is clear from the various presentations at the B&C software engineering conference that there are in fact two separate but related subjects: 1) Model driven software engineering and 2) Model based systems engineering. The first focuses on using modelling techniques as a substitute for programming. The second focuses on using modelling techniques to specify and validate (software) system properties. There is obviously a relationship between the two, but also large differences. Angelo Hulshout wrote about this difference in the Bits & Chips article Model-driven - van navelstaren naar toekomst voorspellen (in Dutch, free registration required).
InfoQ: Can you give a brief update on recent developments in model driven software engineering
Howe: Prof Jan Friso Groote (TU/e) recently mentioned that technology is no longer the limiting factor on applying modelling techniques. I tend to agree with him. In the last years, just in our local region, we have seen a series of tools appear that address various aspects of MDSE, including CIF (TU/e), POOSL (ESI/ASML), CARM (ASML) and the ASD:Suite/Dezyne (Verum). Looking further abroad, Mathworks tools are in routine use in many companies. The issues that we now face are two:
1) how to introduce these tools broadly into the market, on a commercial basis such that the tools can be offered to customers with a Service Level Agreement and can further be developed and,
2) integrating the various tools together to turn what is currently a fragmented offering into something more homogeneous.
InfoQ: Can you elaborate for which kinds of products this technology is being used?
Howe: Coarsely speaking there are three types of work done by software: a) Data processing, b) Calculations and c) Discrete control. Mathworks more or less has the market for model based software design for calculations sown up. Pretty much any company you care to point at uses Matlab for designing algorithms.
Discrete control is less clear-cut. Considering the embedded market, where discrete control is prevalent, in my experience only about 30% of the companies with whom I have contact use tooling for designing this kind of software. Most of these companies are designing products with recognisably complex behaviour. Obviously, in the greater Eindhoven region we’re talking about the wafer steppers, medical equipment, printers and other high tech equipment produced by the usual suspects. But there are a large range of companies who have yet to recognise that the increasingly complex behaviour of software requires the adoption of new engineering techniques and therefore many opportunities.
At the moment there are few companies making use of data modelling techniques, in principle because the tool offering in this area is thin and offers little value.
InfoQ: Do you consider model driven software engineering to be a proven, mature technology?
Howe: MDSE does not yet offer a holistic, homogenous solution for software engineering and probably won’t for another 10 years or more. However it does offer enough of a solution to deliver huge value to companies willing adopt it. Otherwise said, there is no technical reason not to adopt MDSE in those areas where it offers a solution and many business reasons why MDSE should and must be adopted. There are now many software problems of such complexity that they cannot be tackled without model driven tools and techniques if engineers are to produce reliable and robust solutions within a realistic timescale.
So, specifically, I think that MDSE offers solutions of proven value for the majority of aspects of the design of algorithms (e.g. Matlab) and discrete control (e.g., ASD:Suite/Dezyne).
InfoQ: What do you expect that the future will bring us in model driven software engineering?
Howe: In general I think that we’re at the dawning of the age of MDSE. In the next 5 – 10 years we will see a significant shift towards MDSE, to the extent that I believe that by the end of this period perhaps 60 – 80% of software will be designed using model based techniques. MDSE itself will become more homogeneous, with tools from different vendors working coherently together. No single tool or language will offer a total solution – there’s no "Esperanto" to be found in software engineering. Design verification will become routine and will provide an increasing scope. Requirements/use case validation will also become increasingly automated. And the total scope of MDSE will increase as more tools come to market.
The big question though is how all this will impact the existing legacy code base? I do not believe that in the foreseeable future tools will appear that, in the general case, will automatically convert legacy code into models. Why? Simply because (problem) legacy code is by its very nature a disordered system and models represent a more highly ordered system – at least if they are to be of any more use than the code. Thermodynamics does not allow us to go from a disordered system to a more highly ordered one without doing work. So converting code to models will always require some degree of manual intervention and annotation. The key will be to provide (general purpose) tooling that decreases and simplifies the manual work involved as far as possible.
Ultimately I believe that liability and legislation will drive the adoption of MDSE. Considering the Toyota case, a legal precedent has been set that the only defence against liability claims for software defects is the adoption of current best software engineering practice. As formal MDSE design verification is shown to be best practice it will become necessary for the market to adopt it.
