Understanding of model-driven software development

As an object-oriented programmer and a programmer accustomed to component development, he has gone through several steps to understand model-driven software development.

First of all, I think of the running options in many software to adapt to different business combinations of users. When we combine options based on our own needs, we will get different interfaces and business rules. Common examples include reports, data validation, and processes.

Then the web page enters my field of view. Use technologies such as JSP, PHP, ASP, and CGI to generate active interfaces. Too many pages are generated using scripts. When we change the script, the screen on the browser also changes.

XML is something closer to this idea. Simply put, the formatted data + how to display constitutes XML. XML itself is only data, and it is not a software. However, you can use the definition in the middle of it to get the same display. This is not to mention the power of standards. At the same time, I also see that the same data changes the XSL, DTD, and so on. We can see that it is another form of data expression. Changes in the content and form of the display are caused by changes in the XSL and DTD data. Isn't this a model?

Let's look back at various script programs. Each script has its own interpreter. Use them as driving engines and scripts as custom models. When the script (model) changes, the running of the program also changes.

These are simple instances. Let's look at the development history of the software from a programmer's perspective.

In fact, the software development we are currently using can be seen as a model. Software development has gone through the static library & dynamic library & component technology. We can see that the software development is constantly improving flexibility and system scalability. In the era of static libraries, code is loaded during compilation, while dynamic libraries are loaded when programs start to run. Components are loaded as needed. Such loading is not necessarily implemented by your program code.

Middleware has become a trend, and Java is a pioneer. Compile the original code into an intermediate language and then explain it using the interpretation engine (Java Virtual Machine. An intermediate language is a dynamic model that is interpreted by the engine during running. Ms. net. All. NET languages are first compiled into a common intermediate language. Then explain the intermediate language code during system running. The disadvantage is that the running speed is reduced. What are the advantages of this approach? The first thing that comes to mind is the platform. Java is an example. At the same time, programmers can get rid of the constraints of specific platforms and concentrate on business implementation.

This is only a benefit for developers. But we can see that the continuous improvement of the model makes the developer closer to the business logic to be expressed. The dynamic model during the running period increases the flexibility of the model, and less code changes in order to focus more on the business. As a result, let's assume that the business personnel of our customers can design software in a certain period of time?

I think this is very likely.

The prototype method in software development and the idea of gradually approaching the truth are very useful. In order to get the real ideas of users and better conform to the actual business logic, the system analysts first make a prototype to improve the prototype to meet the needs of users.

Although the object-oriented design is based on objects from the very beginning, the user's business processes can be understood only after several rounds of integration.

At the beginning, we provided a model definition (or modeling) tool for users to define their own businesses. In this way, when users can modify this model, that is, business personnel are truly involved in the software development era. Therefore, modeling tools must conform to users' habits of thinking and use real-world concepts to build software.

Object-oriented and UML modeling can help us understand the development of model-driven software. However, model-driven software development is not good or OOA. In this world, we see entities. The entity and object are not the same. An object can be an object, a component, or a system. In more cases, entities are understood as reports, material orders, production plans, customers, and sales situations.

UML helps our system analysts develop and design software. It is more close to the Code layer. However, complex graphics and text descriptions do not reduce users' privacy and resistance to the software. For the moment, there are not many system analysts who need to learn UML, at least in China who can understand UML diagrams. It is a problem to understand the user's business needs from the perspective of a software professional. When you talk to the user about how to handle the material order, he will be very enthusiastic. In his view, his job is to process tickets and reports. Who is willing to learn something irrelevant to their work? Unless of course you are particularly interested.

The model is to help users design their own systems. It is the er between virtual services and real services in software. By expressing entities, rules, and businesses, the model enables you to understand business operations in software in a user's way of thinking.

Therefore, I think the model-driven method is the next generation software development method.

It should include OOA, OOD and other methods, which can be reflected in the study of OMG (http://www.omg.org. OMG's current research is based on UML, MOF, and CWM. Although the research on OMG is too technical, it is not an application-layer solution, but the ideas are consistent.