The following article comes from the Enterprise Engineering Forum (http://www.ee-forum.org) discussion group
Understanding of model driver software development
Shark (Sharksz@sina.com) 2002-05-21
As an object-oriented programmer, it is used to programmers developed by components, and has experienced several steps for the awareness of model-driven software development.
The first thing I think is: In order to adapt to different business portfolios, many software have run options. Different interfaces and business rules will be obtained when we need to combine the options in your own needs. Comparable: Reports, check, processes, etc. for data.
Then the web page entered my field of view. An active interface is generated using techniques such as JSP, PHP, ASP, and even CGI. And too many of these Pages are generated with scripts. When we change the script, the screen of the browser also changes.
XML is something closer to this idea. Simplely speaking formatted data how to display, constitute XML. And XML itself is just data, it is not a software. But you should get the same display in the middle of the definition. This can't be said to be a standard power. At the same time, I also see that the same data changes the XSL, DTD, etc. of them, we see another expression of data. The change in XSL, DTD, and the like as data causes a change in display content and form. Is this not a model?
Look back to see various scripts. Each script has its own explanation. Take them as a drive engine, the script is made as a custom model. When the script (model) changes, the operation of the program will also change.
These are simplicity examples. Then look at the development of the software itself from a programmer's vision.
In fact, the software development we are now seeing is a model. Software development experienced static library à dynamic library à components technology. It can be seen from it is that the development of software is constantly improving the scalability of flexibility and lifting systems. In the era of static library, the code is loaded at compile, and the dynamic library is that the program is loaded when running. The component is loaded when it is needed, which is not necessarily implemented by your program code.
The intermediate language has become a trend, and Java is a pioneer. First compile the original code into an intermediate language and then explain with an interpretation engine (Java virtual machine). The intermediate language is a dynamic model that is interpreted during the run. Ms.Net is behind another. All .NET languages are compiled into a public intermediate language. Then explain the intermediate language code during the system run. This is obvious: the running speed is reduced. What is the benefit of this practice? The first thing you think should be the span of the platform. Java is an example. At the same time, the programmer got rid of the constraints of the specific platform, concentrate on the implementation of the business.
This is only the benefits of developers. But we can see that the model is continuously improved, and its result is that the developers are closer to business logic wanting to express. The dynamic model during operation has increased the flexibility, and fewer code changes to more on the business's focus. As a result, we envisaged to a certain period of time, is it the business personnel in our customers or design software?
I think this is very possible.
The prototype law in software development and the gradual approaching real ideas are very useful. In order to get the real idea of the user, the system analyst is more in line with the logic of the actual business. First, make a prototype, and ultimately achieve the system that meets the needs of users.
Although object-oriented design is thinking from one of the objects, the user's business process is needed to have a multi-wheel mill to truly understand.
If we offer a model definition (or model) tool to the user, let the user define their own business. In this way, when the user can modify this model, it is the arrival of the business person to actually participate in the Software Development Age. So modeling tools must comply with users' thinking habits, build software with the concept of the real world.
Object-oriented, UML modeling, etc. can help us understand the development of model-driven software. But model-driven software development is not OOD, OOA. In this world, we see entities. Entities and objects are different. The entity can be an object, a component, a system. The entity is understood to be, such as reports, material orders, production plans, customers, sales, and so on. UML is to help our system analyst for software development design, it is more in close to the code. However, complex graphics and text descriptions do not reduce users' mystery and inactive psychology. Do not say that users need to learn UML, at least in China can understand the UML map system analysts. Using a software professionals to understand the user's business needs, this itself is problematic. And when you talk to the user how to deal with the material list, he will show a very high enthusiasm. Because in his view, his job is to handle material orders, handle reports, etc. Who is willing to learn a thing that is unhappy with himself? Of course, you have special interest.
The model is to help users design their own systems. It is a mappier between the virtual services and the real business in the software. In the model, the business operations in the software are understood by the user's thinking method by expressing the expression of the entity, rules, business, etc.
So, I think the model driver is a method of developing software development.
It should include OOA, OOD, etc., which can be embodied in this study from OMG (http://www.omg.org). OMG current research is based on the basis of UML, MOF, and CWM. Although OMG research, too technically, it is not an application level solution, but the idea is consistent.
The above power is taken into jade, welcome everyone to refer to discussions.
