Why rapidly innovating in software requires the use of Model Driven Software Engineering
Limitations of code centric software engineering
Conventional, code centric software engineering uses empirical, trial-and-error techniques to establish product quality. Writing code manually is highly error prone. To prevent these errors from propagating to the released product, traditional software development teams carry out a host of unit, integration and system tests. These take up valuable time, in particular when they uncover errors, which then need to be fixed. Unfortunately, most software systems are so complex that it is neither technically nor economically possible to fully test them and as a consequence defects reach customers. The trend towards increasing system complexity only exacerbates these problems.
One way to reduce cycle time is by using more efficient methods to create software. Automation can greatly streamline otherwise error-prone and time-consuming manual processes. Automatically verifying, validating and generating code shortens the development cycle significantly and has the added benefit of eliminating the vast majority of software bugs altogether. Time saved can be spent on designing new features or even entirely new products.
The benefits of MDE
Model driven engineering (MDE) is a way to develop software by automatically generating computer programs from models instead of writing them by hand. It focuses on capturing on an abstract level all the topics related to a specific problem domain, rather than on the computing concepts necessary to implement it.
By hiding unnecessary detail, MDE keeps complexity manageable and makes the understanding of and communication about a software system simpler and less error prone. Software is generated automatically from verified and validated models, reducing the chances of mistakes propagating even further. Furthermore, the decoupling of a problem domain from underlying implementation details dramatically increases the lifespan of a software system and allows it to evolve with technology advancements. MDE thus greatly increases productivity and product quality, and decreases both product lifecycle management costs and total cost of ownership.
Horizontal and vertical MDE
MDE comes in various flavours, depending on the domains addressed. The two main categories are ‘horizontal’ and ‘vertical’. Horizontal MDE refers to using modelling tools and techniques that enable MDE across a wide range of markets and applications, from developing watches to medical systems. Horizontal MDE tools provide the means to rapidly develop algorithms, control applications, data models, user interfaces and more. For horizontal MDE there are a variety of commercially off the shelf tools available that provide economies of scale and reduce the cost of adopting MDE while delivering a factor 3-5 increase in efficiency and 99% reduction in customer reported defects. Examples include tools from Mathworks, Verum and Cordis.
Vertical MDE refers to modelling a very specific, niche problem domain. In this case the trick is to capture the specific concepts through which architects, engineers and other stakeholders communicate with one another about the domain. At a very high level of abstraction, the concepts unique to the domain and the relationships between them are captured and converted into formal, well defined, so-called domain-specific languages (DSLs), which the stakeholders can use to communicate just the way they would using work floor jargon.
The advantage of vertical MDE is that it ultimately results in a factor 10 or more efficiency gain and greatly increases the lifespan of the IP that it is used to capture. By decoupling IP from implementation detail, it also allows new technologies to be more easily adopted. The disadvantage of vertical MDE is that it requires a custom-built DSL to be developed for every domain that is modelled, greatly increasing adoption costs and creating secondary challenges, such as the ongoing development and maintenance of the DSL itself.
Adopting MDE
Whether horizontal or vertical, the adoption of MDE is a stepwise endeavour. The starting point is usually in a part of an existing software system where a problem has cropped up, or where things need optimizing. Indicators that the introduction of MDE should be considered include increasing field quality problems, decreasing predictability of software development, decreasing feature output and customer/engineering team dissatisfaction.
The introduction of MDE into an existing software system depends significantly on your engineering team’s ability to split the system up into subsystems. MDE can and should only be introduced incrementally into existing software, sub-system by sub-system, starting with those sub-systems most amenable to being re-engineered and best able to justify the investment on the long term.
Horizontal MDE should be considered for all complex cyber-physical systems and should initially be applied to those areas of the system where algorithmic or behavioural complexity are found. Vertical MDE should be adopted when you have complex, unique IP that is captured in software and that is core to the long-term viability of your business.
The extent to which MDE should be adopted depends on the ROI that you experience. MDE can be used to facilitate a large part of the software development lifecycle, but not everything. Commercially available horizontal MDE tools have a lower investment threshold and therefore lead to a more rapid ROI and can be used more widely. The cost of developing a DSL to support vertical MDE can be very high, thus constraining its application to only those areas of a system where the ROI is clearly justified.
Key success factors
Although the introduction of MDE ultimately reduces development cycle times, companies are often put off by the up-front investment. Firstly, introducing MDE requires taking away resources from conventional software engineering. The short-term consequence is an exacerbation of pain, namely due to a further slowdown in feature delivery. Another difficulty is that the gains do not come at once, but gradually over a period of one to two years and in some cases the rewards are not visible after one project. Therefore, the introduction of MDE should be driven by business strategy and should not be treated merely as a process improvement.
MDE causes some companies to look at it as some sort of silver bullet. Some engineers expect everything to be a walk in the park, now that all code will be generated automatically, and human intervention is no longer needed. This is not the case. MDE should be viewed as the gun that fires the silver bullet: it will work as long as it is handled by somebody willing to use it the correct way.
Another criticism of MDE often raised by software engineers to postpone its adoption is that it does not yet offer a holistic, homogenous solution for engineering complete software systems and probably won’t for another ten years or more. However, it does offer enough of a solution to deliver huge value to companies willing to adopt it. Otherwise said, there is no technical reason not to adopt MDE in those areas where it offers a solution and many business reasons why MDE 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.
MDE in practice
In recent years, ASML has made great strides in the use of both horizontal and vertical MDE. For example, Altran is playing a major role in the development of DSLs in which ASML’s software architects and engineers write specifications and Altran’s software factory then implements them. The DSLs are developed for various layers in software architecture. They are used to automatically generate the production software for ASML’s Twinscan systems as well as to validate and, to some extent, verify it.
Start-up Liteq, now part of Kulicke & Soffa, applied MDE to develop the entire control and application software for the Liteq 500, a lithographic advanced packaging production system for semiconductors. Using Verum’s software design tools, a small team of engineers realized a large, complex software system that is both reliable and robust. They dealt with the uncertainties of 3rd party software, coped with requirements that evolved over time, decreased the amount of testing they performed and consider themselves to have become better engineers as a consequence. They accomplished all this while sustaining in excess of a 2.5 times productivity improvement over the entire product development cycle when compared to a conventional, code based development approach.
