What Will MDA bring)

MDA overview MDA is short for 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. The development lifecycle of MDA is not very different from the traditional one. The parts of MDA are formal models, that is, models that can be understood by computers. The three models listed below are at the core of MDA: platform independent model (PIM): a model with a high abstraction level and independent of any implementation technology. · Platform-related model (PSM): tailored for a specific implementation technology, allowing you to describe the system model using the implementation structures available in this technology. Pim is transformed into one or more MSPs. · Code: Use the source code to describe the system ). Every PSM will be transformed into code. Traditionally, the transformation from model to model, or from model to code is mainly done manually. On the contrary, the MDA transformation is always executed by tools, and many tools can transform the SMS into code, which is not surprising. The innovation of MDA is to automate the transformation from PIM to SMS. What is software development? In his book agile software development, Alistair Cockburn summarized the industry's views on software development: C. a.r Hoare is a mathematical view, engineering view represented by Bertrand Meyer, handicraft view represented by many programmers, and some Programmers think that software development is a mysterious act of creation. Of course, over the past 20 years, more and more people have held a modeling view on software development. For example, Ivar Jacob son once claimed that software development is modeling. The author of MDA explained also pointed out that code is a model. In his book, Cockburn uniquely states that software development is a collaborative game. Naturally, project leaders with different software development perspectives will focus on different aspects of the software development process. To save resources, we hope that the focus of researchers and Project Leader (practitioners) in the software development field is the one that truly determines the success or failure of the project. Otherwise, the academic community will invest a lot of time to study the factors that do not matter for the project's success or failure. The project leader will put a lot of manpower and material resources into aspects that are irrelevant to the project (as Cockburn pointed out: the environment humidity in the development site? So what is this "crucial" aspect? Is it a tool? Is it a process? Is it the entire methodology? Or a person? Or are there other factors we haven't noticed? Currently, no one knows the exact answer. Maybe every aspect has some impact on the project's success or failure. In any case, because the MDA will have a profound impact on all aspects of software development, no matter what your views on software development, you cannot avoid the MDA. The following describes the impacts of MDA on various aspects of software development. MDA has changed the role and rules of collaborative games. Well, we should regard software development as a collaborative game as Cockburn. However, do any game always have participants and rules? Currently, coders are important players in the game, but this role is no longer available in the MDA version of collaborative games. Instead, it is replaced by the modeler. However, MDA has introduced another new game-this game is not about writing software products, but about writing change rules. The rule market will grow gradually, just as Component-Based Development has started the component market. In the new game, the elites of the original coders will find their new location, and they will be proud to find that the code they write will be reused to an unprecedented extent. As for the changes in game rules, I can't say it all here. Please try it out when you are playing a new version of the game. J. MDA has changed the development process, many project managers focus on the development process. It may be because the process is really important to the project's success or failure, or because the process is the only aspect that the project manager can exert a greater impact on in software development. In any case, changes made to the development process by MDA cannot be ignored. For example, the demand analysis phase of the development process still exists, but the requirement analyst does not need to write the requirement analysis document, but the PIM-platform independent model. What is the difference between the requirement analysis document and Pim? The requirement analysis document is intended for people, designers or programmers, but the PIM reading is primarily an automatic tool similar to the compiler. Since the artifacts generated in the demand analysis stage have changed, the design stage that depends on the results of the demand analysis stage naturally needs to change, and the "encoding" task needs to be completely redefined. The testing and deployment phases will also change accordingly. I will not go into details here. Please read the text of this book. MDA changes development tools. as technology advances, the changes in development tools have never been stopped. When the mainstream development language is assembly, have you ever imagined an IDE that includes Automatic completion, refactoring, and integrated debugger? Have you ever thought that one day the assembly code will not be manually written, but will be automatically generated by the compiler and can be highly optimized? Then, when the abstract layers of mainstream development languages are about to jump again, the development tool revolution will also come. In the world of MDA, "transformation tools" play the role of traditional compilers, while traditional compilers have retired from the current status of compilers (that is, programs that translate assembly languages into machine languages, tools at other layers are removed in sequence. The debugger will also gradually evolve, just as the transition from machine code-level debugging (assembly language-level debugging) to source code-level debugging, to model-level debugging. The most important thing in IDE is not the text-based code editing window, but the graphic-based modeling window. People will talk about a design patterns as they are talking about an API function, and the code pattern (idioms) will be automatically generated by the conversion tool, no longer a concern. Before MDA allows you to re-understand documents, code, and models, we tend to think that the documents or models you want to read do not need to be too precise, because people will always have a strong understanding, the human brain can automatically correct irrelevant errors and complete some omissions. In addition, writing documents or models too accurately is a waste of time, because documents and models cannot be converted into running products. You always need to translate the models again using code. Cockburn and some XP advocates have an even more extreme view: documents and models are not important, so it is important that people take documents or discuss them around the whiteboard where the models are painted, because real communication does not occur when reading documents, but in discussions between people. Okay, maybe it used to be. However, MDA will completely subvert this reality. The model is no longer primarily for people, but for machines. Writing accuracy is no longer a waste of time, because it is only one time (you do not need to manually translate documents and models into code) and you should carefully write it again sooner or later. As for the discussion surrounding the whiteboard-if we are discussing how to encode and implement a model, we are sorry, this discussion is no longer needed. Of course, other aspects of communication are still needed, but you must admit that the game rules have changed, the levels in the game have changed, and you have many new "customs clearance tasks ", many old tasks are naturally canceled. MDA brings mathematical accuracy. Yes, everything that can be understood and automatically processed by machines must be mathematical. You have never encountered such a compiler when compiling a program: "Warning: Line NNN code has ambiguity "? That means you should write the code more accurately. Then, what MDA wants to say is, please make the model more accurate. The MDA tool strictly checks your model to ensure this. MDA provides a new methodology. If software development is a game, methodology is a strategy. Maybe the experts can pass through the game without a strategy, but most people can take a lot of detours under the guidance of the strategy. When MDA develops new game rules, we can naturally look forward to the emergence of new versions of the strategy. Even in the same game, you have different combat tools, different equipment, and different gameplay. So, since MDA has brought many new tools, it is not surprising that new methods have been developed. Now that the methodology is mentioned, I will say a few more words. Translating the term "methodology" in software engineering into "methodology" is actually quite misleading, because the connotation of this word is often not the methodology that philosophical teachers often talk about, but a series of methods you need to follow, or a series of rules that constrain developers. It is not a discipline of research methods, but a collection of methods and rules. According to the number of rules and the intensity of constraints, the methodology can be roughly divided into two types: heavy and light. "Heavy methodology" is formal and rigorous. in projects that adopt heavy methodologies, developers have a strong alternative, because the methodology itself requires developers to record everything they have created (in the format specified by this methodology ), therefore, new participants can quickly get started with these documents (provided that new users are familiar with the format specified in this methodology), so that the impact of job hopping on the project is relatively small. Project managers may prefer this methodology, because there are many factors under their control and the risk is relatively small. Developers do not like this methodology, because in projects that adopt heavy methodologies, they are just replaceable screws and cannot feel their importance. In addition, the lengthy copywriting work is purely altruistic (it is good for managers and new people who may join the project) and has no self-interest (it is boring and time-consuming and takes up the time that can be used for development ). Lightweight methodologies have the opposite characteristics. There are not many items to record, but code and products that can be run are delivered. Of course, there are also test cases. Most communication is verbal, informal, and efficient, but it only exists in the minds of project members. If a member leaves the project, the items in his mind will also be taken away. Because developers often want to have irreplaceable importance, and generally think that writing programs is more fun than writing documents, in addition, you can easily move forward (because you don't have to waste time writing formal documents), so developers generally prefer lightweight methodologies. In general, large projects adopt a heavy-duty approach to learn a little better, because the project has many people and has a long cycle. Even if all the employees love the boss and are loyal to the company, they like the project very much, however, it is very difficult for so many people to change one job for so long and never get sick and never get married and have children. Small projects often adopt a lightweight approach to learn more. Cockburn's crystal method family fully considers the scale of the project. Of course, it also considers the importance of the project and other factors. So is there any method in which MDA is particularly dominant? No. MDA is "light and appropriate. Since XP (eXtreme Programming) is already a signboard of lightweight methods, it is easy to use models to replace the code and propose xm (extreme modeling ). Another feature of the lightweight method is iteration and reconstruction. The excellent synchronization feature of MDA also provides strong support. Heavy-duty methods also benefit from MDA. A major feature of the heavy-duty method is to write detailed documents and create a large number of models. Then, the MDA says: Let's make the documents more detailed and make the model more accurate ...... Detailed and accurate to the machine can understand and automatically compile, this quantitative change to qualitative change is completed. From academia and industry, we have seen that some traditional methodologies are drawing new nutrients from the transformation of MDA, and new methodologies can also thrive from the soil of MDA. Maybe there will be another batch of new legal books related to MDA in the next 20 years. Creative mental work is irreplaceable. All reforms will be re-allocated to some extent, which will lead to new rich and new poor. MDA is no exception. However, what MDA threatens is to honestly translate detailed design documents into C ++ or Java code. The history of social development is the history of the gradual replacement of human labor by machines. Therefore, unemployment is an inevitable price for progress. Do not try to stop the pace of technological advances, because technological advances will also create new job opportunities. For example, MDA is likely to create a new market for changing definition sets. However, as long as your work is creative, it cannot be replaced by machines. Software design requires creativity, either in code or in documents. Before the emergence of MDA, If we carefully write the document and then carefully write the code, we have done two creative jobs, which wastes labor. Some enterprises with high software maturity (CMM) level (especially enterprises in India and Japan) do this: carefully write documents and code is precise translation of documents. More Chinese enterprises do this: The document is perfunctory (the CMM inspection team or superior leaders and customers are perfunctory), and creative work is carried out in the coding stage. The advantages and disadvantages of these practices will not be commented on, but as long as you are doing creative work, you will be able to find the best in the world of MDA, because the tool only saves you time to do boring things, this allows you to focus on the creative process. Some time ago, the industry and it media had "a lot of blue-collar software" voices. I don't know if I really needed them. However, I would like to make a bold prediction: Once the MDA is popularized, the blue-collar software would lose a lot of jobs. Therefore, please do not take "blue-collar software" as your career goal. If you want to establish a foothold in the software development industry in the future, never give up your creative thinking ability.