What will MDA bring?
Purple cloud
MDA overview
MDA is an abbreviation of Model Driven Architecture. It is a software development framework defined by OMG. The key is that the model plays a very important role in the software development process. In MDA, the software development process is driven by the modeling behavior of the software system.
There is no big difference between the MDA development life cycle and the traditional life cycle. The workpiece of the MDA is a form model, that is, a model that can be understood by a computer. The three models listed below are at the core of MDA:
• Platform Independent Model (PIM): High-abstract hierarchical, independent of any realization model.
· Platform-related models (PSM): Do tailored to a specific implementation of technology, allowing you to use this technology to implement the model of the system. PIM will be transformed into one or more PSMs.
· Code: Description of the system with source code (specimering). Each PSM will be converted into code.
Traditionally, from the model to the transformation of the model, or from the model to the transformation of the code, it is mainly manually completed. In contrast, the MDA transformation is always performed by the tool, and many tools can transform PSM into code, which is not surprising. The innovation of MDA is to automate the transformation of PIM to PSM.
What is software development?
Alistair cockburn summarizes the industry's view of software development in his Agile Software Development book: the English view represented by Car hoare, with the engineering concept represented by Bertrand Meyer, and has a manual artist represented by many programmers. Some programmers believe that software development is mysterious creation. Of course, in the past 20 years, there are more and more people to build a design of software development, such as Ivar Jacobson, claim: software development is modeling. The author of the MDA Explained book also pointed out that the code is a model. Cockburn raised uniquely in his book: Software development is a collaborative game.
Naturally, project leaders who have different software development concept will pay attention to different aspects of software development process. In order to save resources, we hope that the focus of researchers and project leaders (practitioners) in the field of software development are the aspects that truly determines the success or failure of the project. Otherwise, the academic community puts a lot of time effort to study the factors that have no loss of the project. The project leader uses a large number of human materials to control the insignificant aspects of the project (such as cockburn pointed out: the environmental humidity of the development site), Don't you?
So, what is this "critical"? Is it a tool? Is it the process? Is it the entire methodology? Is it still? Or don't have any factors we have not noticed? Currently, no one knows the exact answer. Perhaps, each aspect is affected by the success or failure of the project. Anyway, because MDA will have a profound impact on various aspects of software development, you can't avoid MDA no matter what your point of development is. I will briefly describe the impact of the MDA on all aspects of software development.
MDA changed the role and rules of collaboration games
Ok, let's follow the Cockburn's statement, we look good as a collaboration game. However, any game always has participants and the rules of the game? At present, the codec is an important game player, but in the MDA version of the collaboration game, there is no such role, and it is replaced by the modeling. However, MDA has also introduced another new game - this game is not writing software products, but writes transform rules. The transform rules market will gradually grow, just like the component-based development launched the component market. In the new game, the elite characters in the original codec will find their new location, and they will proudly discover that the code they write will get an unprecedented multiplex. As for the change in the rules of the game, I am not saying it here. Please feel slowly when you play new version of the game. JMDA has changed the development process.
Currently, many project managers pay attention to the development process. Perhaps because the process is really important to project success, perhaps only because the process is the only aspect of the project manager in software development. In any case, MDA changes to the development process cannot be ignored.
For example, the demand analysis phase of the development process still exists, but the demand analyst is no longer a demand analysis document, but the PIM-platform independent model. What is the difference between demand analysis documentation and PIM? What is a designer or programmer is a designer or programmer, but read PIM is similar to the auto tool similar to the compiler.
Since the workpiece generated during the demand analysis phase changes, the design phase of the dependency analysis phase will naturally change, and "encoding" will need to be fully redefined. There will also be corresponding changes during the test, deployment and other stages. No more detail here, please read the text of this book.
MDA changed the development tool
With the advancement of technology, the change in development tool has not stopped. When the mainstream development language is compilation, you can imagine IDE that is automatically completed, reconstructed, and integrated debuggers? You have thought that one day assembly code is no longer written but automatically generated by the compiler and can be highly optimized? Then, when the abstract level of the mainstream development language is about to jump again, the revolution of the development tool will come. In the world of MDA, the "Transform Tool" played the role of traditional compiler, and the traditional compiler returns to the current assembler (that is, translating the assembly language into a machine language program), and the remaining layers are retracted in turn. The debugger will gradually evolve, just like the transition from the machine code level debugging (assembly language-level debug) to the source level debugging, slowly transition to the model level debugging. The most important thing in IDE is no longer based on the text-based code editing window, but based on the graphic modeling window. People will talk about a design mode (IDioms), which will now be automatically generated by the transform tool, which is completely generated by the conversion tool, no longer concerned.
MDA let you re-recognize documents, code, model
In the past, we tend to think that the document or model giving people don't need to write too accurate, because people will always have a strong understanding, and people's brain can correct some irrelevant mistakes and complements Some omissions. In addition, the document or model is written too accurately, because the documentation and model cannot be turned into a product, you always need to re-translate the model with the code. Cockburn and some XP advocates more extreme: documentation and model are not important, people have the discussion of the document or the whiteboard to paint the model, because the real communication is not to happen to the reading document, but happened In the discussion of people and people.
Ok, perhaps it is true. But MDA will completely subverting this reality. The model is no longer mainly to see, but mainly to the machine. The precise written is no longer a waste of time, because only written over again (you don't need to translate the document and model to code) and write it again in the morning and evening. As for discussions around the whiteboard - if it is discussed how to implement a model, then I am sorry, this discussion is no longer needed. Of course, other communication is still needed, but must be admitted that the rules of the game have changed, the level in the game has changed, you have a lot of new "customs clearance tasks", and many old tasks are naturally canceled. MDA brings mathematical accuracy
Yes, all things that make the machine understand and automatically handle must be mathematically accurate. Have you encountered such a compiler message when compiling: "Warning: The NNN line code has an unity"? That means, please write the code more accurate. So, MDA is to say, please build a model more accurate. The MDA tool will strictly check your model to ensure this.
MDA provides soil for new methodology
If the software is developing is a game, then methodology is Raiders. Perhaps the master does not need to be Raiders, but most people can take less detours under the guidance of the Raiders. MDA has developed new game rules, then we can naturally expect new versions of Raiders like rain. Even with the same game, you have different combat tools, different equipment, and different equipment. So, since MDA brought a lot of new generations, new methods learned that it was not surprising.
Since mentioning methodology, I will say a few more words. In fact, "Methodology" in software engineering is "Methodology" is actually misleading, because the connotation of this word is often not a philosophical teacher often hanging on the "world view and methodology" of the mouth, but means A range of methods you need to do with the way, or a series of regulations for developers. It is not a "research method", but a collection of methods and rules.
Method can be divided into heavy and light types in accordance with the strength and constraints of the rules. "Heavy Methodology" is more regular and rigorous. In projects using heavy-duty methodology, developers have strong replaceability, because the methodology itself enforces the developer to record all what he created (according to this Methodology specified format), so newcomers participating in the project can quickly go up with these documents (provided newcomers are also familiar with this methodological specified format), so that developers are also relatively small. Project managers may prefer such methods to learn, because the factors they control are more, and the risk is relatively small. Developers will not like this method, because in projects with heavy-duty method, they are just replaceable screws, it is difficult to feel their importance. Moreover, it is unfavorable (very boring time), which is not good (very boring for the manager).
Light methodology has the opposite qualities. There are not many things in the case, delivery is the code and the product you can run, and of course there is test case. Most exchanges are oral, informal, very efficient, but only in the minds of project members. If the member leaves from the project, then these things in his mind will take away. Because developers often want to have irreplaceable importance, and generally feel that writing procedures are fun than writing documents, they can easily go forward (because there is no need to waste time to write regular documents), so developers It is generally more than a lightweight methodology.
In general, large-scale projects use heavy-duty methodology, because the project is more, the cycle is long, even if all employees are very loved to wear the boss is very loyal to the company like this project, but so many people do not hop in such a long time. It is quite difficult to do if you are not sick. Small projects often use lightweight methods to learn well. Cockburn's crystal method family fully considers the factors of the project size. Of course, it is also considered other factors such as the project. So, have MDAs that have a certain type of method to learn special extravators? No, MDA is "lightweight and salty". Since XP (extreme programming) is already a signboard of a lightweight method, then self-all his own matters replace the code with an model, and XM (extreme modeling) is proposed. Another feature of lightweight methods is iterative and reconstructed, and the optimal synchronization characteristics of MDA have also provided strong support. The heavy method can also benefit from MDA. The heavy-duty method has a large feature is a detailed document. Create a large number of models, then MDA said: Let the document more more accurate, let the model more accurate ... Detailed accurate to the machine can understand and automatically compile, this amount change The conversion to the rendering is also completed.
From academic and industry, we have seen that some traditional methods are learning from new nutrients from the change of MDA, and new methodologies can also grow from the soil of MDA. Perhaps in the next 20 years, there will be a number of new methodological books involving MDA.
Creative mental labor is irreplaceable
All reforms will reassign social resources to some extent, which will cause new rich and new poor light eggs. MDA is no exception. However, MDA threatens to translate detailed design documents into C or Java code.
The history of social development is the history of a machine gradually replacing human labor. Therefore, some people are unemployed is an inevitable price of progress. Do not try to block the skills of technological progress, because technological advances will also create new work opportunities. For example, MDA is likely to create a new transformation definition set market. However, as long as you work in work, you cannot be replaced by the machine.
Software design is a needle, this creativity or is embodied in the code, or in the document. Before the MDA appears, if we carefully write a document, then write code seriously, then we have done two times, which isted to waste labor. Some software maturity (CMM) levels high (especially India and Japanese companies) are doing this: Seriously write documents, the code is the precise translation of the document. More Chinese companies do this: documentation is perfunctory (perfunctivate CMM inspection group or perfunctory leadership and customer), creative labor is done during the coding phase. The advantages and disadvantages of these practices don't comment, but as long as you do create a creative job, you will be like a fish in the MDA's world, because the tool just saves you the time of boring, so you can concentrate your energy to creative During the process.
There have been "a large number of software blue collar" in the industry and IT media, I don't know if I really have this need. But I am here to predict: Once MDA is popular, the software blue collar will unemployment. So I respect you should not take the "Software Blue Collar" as your career goal. If you want to stay in the software development industry in the future, please never give up your ability to create sexual thinking.
