MDA camp Division

MDA has been put forward for 5 to 6 years. Its main standards are MOF, UML (including OCl), XMI, and CWM. Currently, qvt (query, view, and conversion of models) is a standard being developed ). These standard families are associated with each other to form the huge architecture of MDA. It can be said that MDA is composed of a series of standard families and the idea of model-driven development. The subsequent researchers have different focuses based on their own interests, resulting in the split of the MDA camp ?).

Four camps
Cook divided the MDA investigator into three camps. Martin flower also agreed with his opinion and discussed the attitudes of these three camps towards language workbench in detail. In addition, Martin proposed an MDD camp. To sum up the opinions of the two of them, the MDA camp can be divided into four parts, some of which are completely opposite, while some are inclusive:

1. uml pim camp: use UML to establish Pim, use model conversion to generate the MNS, and finally use the MNS to generate code;
2. mof camp: MOF is used instead of UML, and MOF is used for modeling language and model conversion;
3. executable UML camp: Build a UML compiler and use UML directly as a programming language so that UML can be executed.

(The above is from Steve Cook's blog. The original Article is as follows:
1. the uml pim camp: MDA involves the use of UML to build platform independent models (PIMS) which are transformed into platform specific models (psms) from which code is generated.

2. The MOF camp: MDA does not involve the use of UML, but instead the crucial technology is MOF, and the definition of modelling languages and Language Transformations using MOF.

3. the executable UML camp: MDA involves building a UML compiler, making it a first class programming language .)

4. Model Driven Development camp: they do not belong to the MDA camp, because they do not care about the omg mda series specifications. They are concerned with model-driven development ideas. It can be said that MDA is the implementation of MDD on the OMG specifications.

Some researchers divide MDA into two camps: narrow and broad. As mentioned above, the narrow sense of MDA is the first three camps, while the broad sense of MDA is the MDD camp. I think so.

Uml pim camp

The uml pim camp can be said to be the most powerful at present, because it is so consistent with the original idea of MDA that everyone knows the most about UML to establish Pim, and then convert it, j2EE ,. net), and then generate the code. Everything seems so smooth, compatible with previous technologies, and there is no lack of support from tools and vendors.

However, it is also the most criticized camp. The biggest problem is whether UML is platform-independent. If UML is not platform-independent, it is obviously not suitable for building Pim. The reason for the rejection of UML in the MOF camp is that they believe that MOF is the source of MDA. Excessive use of UML will lead to the inability to build Pim, because UML itself is a platform. I think the argument about platform independence is enough. At the beginning, C was considered platform-independent, as long as it could be re-compiled on different operating systems; later, CORBA also claimed to solve the problem of network platform incompatibility; then it came to J2EE. However, when you solve the problems related to the previous platform, the new technology you created also becomes a new platform, such as the CORBA platform and J2EE platform. In order to solve the incompatibility between different CPU hardware platforms, the operating system was invented; in order to solve the problems of different operating systems, the advanced language was invented; in order to solve the problem of network incompatibility, the middleware was invented; in order to solve the problem of middleware incompatibility, technologies such as MDA and Web Service were invented. Currently, the models created using UML are basically platform-independent. I (I am from the UML PIM camp) think it is appropriate to use UML to establish Pim.

Another problem in the uml pim camp is that UML is too cumbersome. The uml2.0 standard is filled with a variety of inactive fillers, which not only makes UML more practical, but also increases the complexity of UML, reduced availability. It is like using a hammer, but UML provides a tool for the entire room, which has been turned over for a long time but has not found a suitable hammer. Alas... Therefore, people in the MOF camp decide to build a hammer by themselves. In any case, like UML, they all stick labels produced by OMG.

When the current UML cannot fully meet the requirements, UML provides a standard Expansion mechanism, namely, profile (including stereotype and tagged value ). However, many people think that the extension mechanism of UML is the same as that of UML itself. It is too complicated to use MOF to re-build a Modeling Language (I don't think so, profile is relatively simple ).

Another unavoidable problem is that the uml pim camp pays more attention to the structure of the system than to the semantics (actions/processes) of the system ), therefore, many people tend to remove the UML action semantics, or do not use the UML action semantics at all.

Although uml pim has so many shortcomings, its advantages are also obvious: 1. compliance with standards; 2. for common software practitioners, learning UML is easier than learning MOF. 3. you can use more tools.

MOF camp

Using MOF to directly build modeling languages and model conversion languages is called the "heavyweight" method in some books. Using UML profile to expand UML to generate a new modeling language is called the "lightweight" method. It can be seen that learning and using MOF is a time-consuming task, but it does not block the pace of the MOF camp. They believe that MOF is the core of MDA and pure MDA.

The four-layer models defined by MoF almost completely eliminate previous model concepts. On the basis of previous models (M1 layer and M2 layer fuzzy concepts), MOF defines m3 and M0 layers. Among them, the M2 layer can accommodate all the known Modeling Language specifications in the past, and then define a unique m3 layer to create all these modeling languages. Currently, in all known model technologies, only MOF has an M3 layer and is customized. In this way, MOF is compatible with all modeling technologies and becomes an independent meta-model tool. At present, almost all modeling tools are known as MOF compatible, because it is too easy to do so. You just need to modify your model specifications a little. It can be thought that all modelers who do not want to use UML will surely fall to the MOF camp after the emergence of MDA. Moreover, most of the creation and users of new model languages and DSL will be directed to MOF (using UML profile is better for these people to use MOF without flexibility ).

At the beginning of the formulation of MDA, OMG was wise to leave MOF out of UML, which increased the vitality of MDA and allowed the MDA technology to compete with new technologies, it is better to divide MDA into several camps. The disadvantage of MOF is that it is difficult to learn and has fewer tools, while its advantage is its flexibility. We have not studied MOF in depth.

Executable UML camp

People in this camp will never mind that I call UML the fourth generation language. When the third-generation language (advanced language) became familiar, the debate began over the fourth-generation language. Whether the fourth generation belongs to a descriptive language such as SQL or an intelligent system similar to the Agent System, or grid? Nervous system? Web service? However, people in this camp will proudly tell you that the fourth generation of language is an executable UML, and other influences, regardless of the coverage of the problem domain, are inferior. (Maybe my language is a little excited. Don't hit bricks ...)

The people in this camp have a nice name, "Model programmer ". When UML can actually be executed, the demand for high-level language programmers will be as scarce as the current assembler programmers. (Here, I think of the days when I wrote a draft for "Model programmer" on the mdachina forum with a few netizens the year before. I was a father in the twinkling of an eye .) Executable UML is also a hot topic in MDA research, especially when the MDA technology was proposed, all mdaers were excited to imagine the emergence of the UML compiler, the model at hand can be directly converted into executable programs. On the OMG website, I introduced three books that can execute UML.

Of course, in the foreseeable future (within 2 or 3 years ?), I can't even imagine a UML compiler that does not generate high-level language code at all. It may be implemented in a certain local field, but it is impossible at present to be as complete as an advanced language compiler. The reason is very simple. The current UML expression capability is limited, and it cannot fully carry the information required by the program. Even after UML expands the action semantics.

Is it possible to further expand UML? Of course it is possible! At the beginning, no one thought that advanced languages could completely replace assembly, but few people now use assembly (except for special areas such as drivers ). However, the current dilemma is that UML is too bloated and has been abandoned by many people due to its large size. Will the further expansion of UML be more objectionable to everyone?

For this dilemma, I suggest dividing UML into two parts: the UML front-end and the UML back-end. The front-end is simplified on the basis of the current UML to make it easier to learn and practical. The back-end is to define the UML compiler and can add more semantic aspects. In this way, the people who can execute the UML camp can work to define the UML background so that they can fully carry the semantics that can be expressed by the current high-level language, so that the execution of the UML becomes possible. Similar to a Java virtual machine, a UML virtual machine may also appear. On this virtual machine, models written in the UML foreground can run automatically. If detailed details are not defined in the console, therefore, a large number of default values can be added to the background for running.

MDD camp

The MDD camp does not necessarily belong to the MDA camp because it is independent of the many specifications of the MDA. They are typical "tailism". If they are useful, they can be used. If they are useless, they can be discarded. Many people claim to be supporters of MDA, but have never followed any MDA specifications. They arm their development methods with model-driven ideas. However, they may be more clear about the essence of MDA. After all, they have not made a white bubble in lengthy MDA specifications.

On the other hand, they are more pure supporters of MDA, because the beginning of the MDA guide says: MDA is an approach to system development, which increases the power of models in that work. it is model-driven because it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. MDA is a method, not just a specification.