Application of AOP in large-scale software development projects

Developerworks China > Java Technology > Application of AOP in large-scale software development projects

Document options <Tr Valign = "TOP"> <TD width = "8"> Src = "// www.ibm.com/ I /c.gif"/> </TD> <TD width = "16"> Height = "16" src = "// www.ibm.com/ I /c.gif"/> </TD> <TD class = "small" Width = "122"> <p> <SPAN class = "Ast"> Javascript is not displayed </Span> </P> </TD> </tr> Print this page Send this page as an email Level: Intermediate Yan Li Minli@cn.ibm.com ), Senior Software Engineer, Technical Manager, SOA Design Center of IBM China Software Development Lab Zhigan Ganzhi@cn.ibm.com ), Senior Software Engineer, SOA Design Center of IBM China Software Development Lab Qiang Wang , Software engineer, SOA Design Center of IBM China Software Development Lab Chun guoying Guoyingc@cn.ibm.com ), Software engineer, SOA Design Center of IBM China Software Development Lab Peng liuxin , Software engineer, SOA Design Center of IBM China Software Development Lab November 01, 2005 Ben This article is written by a real large-scale software development project. We try to promote the application of AOP in this project. Here we will analyze some of the practical problems and difficulties we have encountered, and try Some deeper thoughts on Aspect-Oriented Software Development (AOSD. The author of this article will make an objective judgment from the developer's point of view. It is neither an enthusiastic blow to AOP nor an opposition camp of AOP. . Therefore, it can be viewed as an objective analysis and constructive comments from Java developers on the application of AOP technology. About AOP I will not repeat the concept of AOP here. Who created AOP first has always been controversial in the industry, but the widely accepted statement is probably the first by Gregor J Kiczares proposed it in ecoop '97. Then Gregor applied for the AOP patent [us06467086]. Many people may not be convinced because they are more or less early. I had a similar idea, but I didn't want to give him a new name. Whether it's Oop, mop, or AOP, the essential idea is to achieve software development at a level closer to the real world. Modular. From this perspective, the idea of AOP is just a new bottle of old wine. In fact, the emergence of AOP as a new thing is not a technical leap, but a step from software modularization to a certain stage. Stage products. Human Thinking usually has some inertia. After we have tasted the hardships of OOP, we have a new concept to jump out and analyze some disadvantages of OOP, and make changes in a reasonable way. It will inevitably give you a fresh feeling. However, it is undeniable that, so far, the application roles played by the AOP role are more than a supplement to the oop. Therefore, as an important The existence of "op" seems to have been named, but it looks more like an advanced design model. However, in the eyes of many people, the component of AOP is even less than that of OOP, and even AOP is regarded as the future software development A trend. I have been thinking about a problem. The emergence of AOP in the IT industry in year 78 is not very short. The interesting phenomenon is that AOP has always maintained a low fever and is not as expected. Big red and purple. To what extent does AOP help us solve practical problems? Let's try to apply AOP in a real software development project. Add typical application directions promoted by AOP For example, log, transaction, security ), Thread Pool. It must be noted that the scenario we mentioned here is to develop software products of a certain scale, and we finally complete software products of hundreds of megabytes. Therefore, our research scope is neither a programmer's individual Behavior is not a small example. Let's take a look at some interesting discoveries. Back to Top AOP practices We have tried to apply AOP in many ways. Here we use the most representative log as an example. Most people understand AOP, beginning with the separation of classic log concerns. Therefore, this is a well-known case for every AOP enthusiast. In principle, it should be indisputable. Unfortunately, we encountered a very difficult problem during our research. Let's take a look at a classic AOP log example. We assume that, according to the idea of AOP, developers of the main logic should not consider the edge logic when writing code. Therefore, the preceding log code is invisible to the developers of the main logic. Assume that Log4j of the stream is the log recording implementation method, and aspectj is used as the implementation method of aspect. It should be reiterated that the purpose of this article is not to implement a certain AOP platform. Aspectj is mainly because, from the syntax perspective, aspectj is currently the most extensive implementation of all AOP implementations. This kind of cross-concern description of logs is the most typical AOP application, and it has no problems in itself. How do we usually use it? In the sub-aspect implementation that inherits this abstract aspect, specify the position ① Of the starting point, and enter the implemented logic into advice ②. In a small-scale application development environment, this will not be a problem. First, there are not many log entry points, either by using a one-to-one location for direct description, or use unified coding specifications to constrain both Is a feasible solution. Second, the logic in the notification is not very complex. The overall software development process is not subject to any change. The general practice is to be compiled by a dedicated aspect developer in a unified manner. Aspect, which is shared by everyone. However, every developer is not encouraged to write their own aspect, so that it is not a cross-cut, it becomes a sieve With cross-point (cross-point), software development becomes a mess, and the benefits brought by AOP are lost due to the loss of control. So what is the situation in our project? The above two seemingly simple points have problems: (1) With our statistics, there are a total of 70 thousand log calls in the software code of the previous version of the software we developed. If we do not make any relevant summary and describe the entry point one to one, then There are as many as 70 thousand entries in the entry point description on location 1. If you do this, the Code maintenance in the future will be an astronomical cost. So we can only hope to extract the public mode of the 70 thousand-sentence log call. Here we use an optimized log component. The interface is similar to that of log4j. Widely used. We will use log4j as a reference below. Five levels are pre-defined in the log level class: Debug, info, warn, Error, fatal. According to statistics, the fatal type calls are the least. According to the definition of fatal level, we may spend some time organizing code and refining the rules for capturing fatal points. . Next, warn and error accounts for about 7%. This part is hard to handle. logs of the warn/error type are not strictly defined, and the distribution points of codes are difficult to find, You must find the rule at a very high price. Finally, debug, Info accounts for a large proportion of 30%-50%. As the name suggests, this part of code is very random, and no matter how hard it is, it is impossible to find meaningful public rules. This path is still unavailable. There is a saying that may explain this imagination: If the starting point is difficult to describe, the major reason is that the definition of the focus is inaccurate. This statement is justified by taking "log" as an aspect. The granularity seems too large. The only way is to further split the "log" focus. Continue dismantling to an acceptable level. However, our problem does not seem to be resolved. If our project is small enough There is always a certain limit for such splitting. This approach may be feasible. However, unfortunately, our project is very large. After a considerable amount of decomposition, we can finally find the log regularity. We may still need hundreds of thousands. It is difficult to maintain the final result when a statement is used to specify the position of the entry point. Such an approach is fragile or unacceptable for an evolving project. Besides, log levels such as debug No, no matter how you disassemble it, it is impossible to find the perfect rule. Generally, logs in any system maintain logical consistency. After such a layer-by-layer decomposition, logs are Integrity is completely damaged. This is a method of AOP for AOP, which not only reduces the workload, but also brings endless troubles. Well, there's only one last trick left. To use AOP, We sacrifice some log features, pre-define the encoding rules and log principles, and enforce them. Of course, if you want to fully cover all log points, such a log principle can only be very rough. From AOP Technically, it is feasible, but extensive log rules will lead to a soaring amount of log information, which is unacceptable for our software projects, because the log loses its accuracy Maintenance has a great impact, and the impact of a large amount of log information growth on the overall operating performance of the system is obvious. (2) In Figure 1 We are also faced with problems in the second point. You may not be able to see the examples in the figure, because the examples of introducing log in all the documents that introduce AOP are very simple. But in real life The log is relentless. In many cases, the program calls logs for special reasons. Their advice needs to be compiled separately. For example, in the example product, we often need to pass a variable to "log" Aspect, In addition, a local variable is often input. At least now, all AOP implementations do not support capturing local variables, and such implementations will not be available in the visible future. Okay, you have to refactor the code. If you want to upload Parameters must comply with our pre-defined encoding naming rules. However, this imposes a lot of restrictions on programmers, and it is difficult for you to persuade developers to write programs carefully with thick coding specifications. Based on the above two fatal defects, we have encountered considerable resistance in trying to implement log aspect. Back to Top Problem Analysis It seems like a simple thing, and now it is very complicated. The initial enthusiasm has become love and hate intertwined and confused. It must be something wrong. In a large software development project, how should we control the AOP entry point? This involves the development process, version control, and encoding rules. It seems that AOP itself has not provided a clear answer. When we talk about During Oop, more classes, inheritance, and polymorphism are involved, while deeper methodologies are hidden in OOA and Ood. Similarly, when we mention AOP, it seems that Aspect, pointcut, advice ,... However, the Aspect-Oriented essence hidden behind the code is ignored. Therefore, we advocate that when we learn to apply AOP, we should not be overly addicted to code, and should rationally invest more in analysis and design. Energy. This is the first lesson we have learned from the above failures. . We cannot think of AOP as a panacea. It takes effect immediately after taking it. On the contrary, the application of AOP in actual projects requires many considerations, so that the problems caused by AOP can be well understood. In a sense, in terms of Code-level orientation, Java-oriented language extensions and XML are not very different in implementation. However, aspect-oriented technologies should also be reflected in different abstract layers. AoA (Aspect-Oriented Analysis) and AOD (Aspect-Oriented Analysis and Design) are indispensable. Therefore, AOSD (Aspect-Oriented Software Development) it is more appropriate to describe the aspect orientation. Implementation process. Many people are making some useful attempts on AOSD at a higher level, such as IBM The eclipse-based CME project must first address how to define reasonable concerns in the initial stage of software development. It is not important to determine whether the subsequent implementation is based on pure AOP tools. Yes. From the Focus Analysis in the analysis and design phases, you can use AOP directly in the Code and only be feasible in small-scale applications. Once Large-scale applications are oriented, many problems will come one after another. In addition, the aspect-oriented development process must solve many specific problems, such: How can we weigh the public mode of the starting point and the feature description of the starting point? This is a question about how to reasonably control the granularity of AOP. We have mentioned above that cross-cutting concerns The granularity of points is hard to determine. Cross-cutting concerns defined at a high level, The underlying implementation may also encounter problems. For specific AOP implementations, the finer the granularity, the simpler the code, the better. In this way, the aspect code is bound with the core code. It cannot be maintained. In addition, the Code is not elegant. It seems that a piece of code is simply extracted from another place, and the traces hidden deliberately are very heavy. It is difficult to see the benefits of AOP. However, if the granularity is too large Coarse, the AOP code must rely on the summary of the public mode. Such a public mode requires first effort to define and strive for perfection, because the constant changes in rules will bring many problems, avoid rules as much as possible . In addition, the rules must be followed by everyone, which will bring more encoding restrictions. Of course, for specific projects, the number of coding rules is a specific problem, but how to make it appropriate is not Simple question. A realistic problem is how to deal with these concerns when there are multiple cross-cutting concerns in a large development project. In our actual project In most cases, the log focus is entangled with other cross-cutting concerns. The difficulty is the separation sequence of cross-cutting concerns. Continuous open items in one version Because reconstruction is required, this problem is even more prominent. In some cases, if two-way dependency exists between the cross-node concerns, you must modify the logic to block this possibility. Otherwise, the current AOP Implementation method, which is difficult to handle, the code of AOP will be ugly, the Code reconstruction of the main logic will be complicated and difficult to maintain. In a large software development project The lifecycle should be manageable. If AOP is involved in a large scale, many problems will become very sensitive, especially QA. According to the idea of AOP, the focus is to isolate each other. Therefore, in essence AOP leads to loose coupling between software modules. The loose coupling in the software development process will inevitably lead to the complexity of testing. If the focus of the system is controlled in a small scope, this burden can be developed in a small scope. The internal unit is digested, but once the focus is global, this change will spread, resulting in rapid growth of additional testing and QA work. It may impact the existing testing and QA processes. Large After-sales services of software products usually touch the source code when necessary. For example, the third-level service support personnel of IBM will track and correct the source code. Unfortunately, these people must learn it as soon as possible. AOP, otherwise they will be at a loss, because they may not know how the entire application logic is woven together. Software maintenance and service costs may increase accordingly and rely on specific tools. Back to Top Discussion on the development direction of AOSD First, we emphasize AOSD again, instead of pure AOP. The development space for aspect orientation should be not limited to the Code layer. Whether aspect orientation will greatly affect the future The current situation is unclear about the software development model. Aspect-oriented analysis and design should play a leading role in the future of Aspect-Oriented Technologies. With the current Code-layer-oriented AOP usage, frankly speaking, it is just Small-scale design models are not worth too much enthusiasm. Many popular loosely coupled development models, such as SOA and SCA, seem more realistic and reasonable. They all share similar ideas, but have It is more flexible than aspect-oriented. Aspect-oriented analysis and design must solve the following problems: First, the Aspect-Oriented methodology needs to be improved: 1) How can we locate the cross-cutting concerns from specific needs? Such definitions do not come from simple name-based principles. For example, is log a cross-cutting concern in all software projects? If we develop If the object is a J2EE application server like IBM WebSphere, is the transaction or cross-cutting concern? 2) How can we reasonably control the granularity? How can we smoothly transition from the cross-cutting concerns in the design phase to the implementation phase? The problem we often encounter is that there are still mutual dependencies in the implementation phase. How can we avoid these problems in the analysis and design phase? 3) The model expression of focus. How can we express the focus, the relationship between the focus, and the relationship between the cross-cutting focus and the main logic? 4) can this cross-node concern analysis be repeated and verifiable? Is there a feasible general methodology to help us make the identification and standardization of cross-cutting concerns a controllable process? Secondly, Aspect-Oriented software engineering is an unavoidable important issue. Through the above problem analysis, we believe that everyone has realized the impact of AOP on each stage of the existing software process, so it is necessary to standardize It is applicable to the new software development process of AOP. First, aspect-oriented development must follow the iteration mode. However, the existing software engineering methods are not enough for us to have enough confidence in the extent to which they come, Software development is still controllable. Why are we not so upset with the previous Oo, component-based approach, or even the development of updated SOA? This is mainly because in these modes, we can compare It is easy to see the prototype of the complete product. Once the aspect reaches a certain level, the integrity of the software cannot be intuitively perceived. Therefore, the impact of aspect orientation on the development process is inevitable. Especially the opening of stacks How to effectively control each development cycle is also learned. Finally, aspect-oriented development tools are the technical support for large-scale application of AOP. Existing development tools cannot guarantee the efficiency and integrity of Aspect-oriented software development. We need a better integrated development tool. Ajdt can provide some help, but it is far from enough. An ideal AOP development tool should support: 1) A complete view of software products, which combines cross-site attention points and core concerns visually and visually 2) ability to integrate AOP technology into the analysis and design stage of the system 3) test and debug tools based on aspect combinations can be flexibly tested and debug based on different combinations of concerns 4) more flexible and convenient focus definition methods, shielding most Java developers with complicated aspect syntax Back to Top Summary This article summarizes the problems encountered and the progress made through the practical experience of applying AOP in large-scale projects. Through our practice and analysis, we believe that before the great development of AOP And AOP is more suitable for applications in small-scale software development projects. The larger application of AOP not only requires strong support from code-level AOP, but also relies on Aspect-oriented analysis and design technologies and corresponding software. Progress in the engineering field. Finally, we can see that the AOP technology is still in a developing stage. With the continuous emergence of AOP articles, the functions of the AOP tool are constantly enhanced, and developers The acceptance of AOP is gradually increasing. Optimistic, AOP may make great progress in Theory and Practice in the near future, so as to solve the problems mentioned in this article. Let's wait and see. References Aspectj is currently the most widely used and most powerful AOP code-level implementation. We can go from http://www.eclipse.org/aspectj Obtain it. Ajdt is an integrated development environment based on Eclipse's aspectj, which includes the latest version of aspectj. Can be from http://www.eclipse.org/ajdt Obtain it. Http: // aosd.net There are a lot of AOP-related documents and papers. You can also attend an annual AOSD meeting on this website. The AOP @ WORK series on developerworks can help us understand the current situation of AOP. CME is an interesting tool that supports the use of AOP throughout the software engineering lifecycle. It helps developers discover and extract crosscutting concern. You can click http://www.eclipse.org/cme.