Using MDSD to develop safe and reliable software

When can we think that the SOFTWARE PRODUCT is really done? Usually, when we no longer provide follow-up support, or the product has been replaced by other products, its life is over, almost all software products will experience from the beginning to the end of the evolution process. But for a long time, the large enterprise-level system will develop toward the trend of being unsustainable and becoming stiff over time. This has led to a stagnation in software development, making it more time-consuming to respond to customer needs.

This article explains how to use the MDSD method to determine these problems. The article first introduces the issues we are addressing-backwards compatibility and escalation issues-that explain why these issues are difficult to solve, and then describe the areas where non-functional concerns are easily hidden in the current software architecture.

The article gives three examples to illustrate how MDSD technology can help us solve software lifecycle problems without losing flexibility. These examples are real agile projects from the electronic healthcare industry, and the authors show how best practices can be applied in other situations.

The lessons learned from the project are summed up as thumb rules (a simplified or empirical approach to complex environments, because rational processing capacity is limited), and at the end of the article, references are made to useful frameworks and tools that are the basis for the current solution.

Introduced

In the field of software engineering, after several years of practice, model-driven software development (MDSD) has proved that it is not a flash in the pan. Today, many of MDSD's promises [1] have become reality, and a number of successful examples continue to emerge.

This article explains how you can use model-driven methods to solve some of the problems in the current software system. Bearing in mind MDSD best practices [2], we will focus on the non-functional requirements of the software lifecycle itself.

Software life cycle

Almost all modern software systems are faced with life-cycle problems. When a product is released or deployed, you have to address issues such as backwards compatibility and migration strategies. We often underestimate product compatibility issues, or ignore the problem entirely in development. When we have to spend a lot of resources to solve product compatibility issues, we will regret. Taking this issue seriously will affect the evolution of the SOFTWARE PRODUCT, as we will see in the following example.

Case: Java.lang.Cloneable

The Java.lang.Cloneable interface in Java illustrates how backward compatibility limits software evolution. The interface was introduced at JDK 1.0 and is only a token and does not provide any interface methods, and the type that supports cloning needs to implement this interface.

In addition, it also needs to provide an appropriate implementation of the Java.lang.Object.clone () method. In fact, the Clone () method seems more persuasive and natural if defined in the Java.lang.Cloneable interface. In reality, however, the interface has never changed, because it will break backwards compatibility. The introduction of the Clone interface method causes a compilation error for all classes that have implemented the interface. For a complete history of this bug, see [3] for a more detailed discussion of java.lang.Cloneable, see [4].

It is necessary to establish a common glossary before analyzing the details of the life cycle issues that already exist in our system.

Backward compatibility

The system can be considered backward-compatible if the following conditions are true:

It can handle the interface of the previous system

It can handle data from previous systems.

Users of the system do not have to care about system version changes

Modifications to the system may cause backward incompatibility issues. This problem can be addressed by introducing the compatibility layer, which is responsible for providing a view of the previous system interface. In such an environment, it is more important to weigh and design a good interface.

The compatibility of binary with source code is not discussed in this article, and the differences between them and the Java language are described in [5].

Update

Updates describe improvements to existing software. With one update, the set of attributes applied is not extended. The main purpose of the update is to provide additional robustness (for example, to fix a security risk). Updates do not involve changes in interface and data descriptions, and do not cause backward compatibility issues. The OSGi version control system [6] defines the version classification mode Major.minor.micro. One update adds only the third digit, the version number of the Micro bit.