1. Programming (AOP) development background for Aspect
1.1. Software programming methodology development
In the early stages of computer scientific development, developers have written programs with direct machine coding methods. However, a lot of time is spent on considering the machine instruction set, not the problem itself. Gradually, some abstract high-level languages have begun to appear on the underlying machine instruction set. The structured language will appear so that people can decompose the problem based on the process of task execution. However, as there is an increase in problem complexity, we need better technology to help people solve problems. Currently, we can use object-oriented programming (OOP) technology to see the system as a group of collaborative objects, using classes to hide the implementation details inside the interface, and provide a set of public behaviors and interfaces, allowing specific The component can change a specific behavior without accessing the realization of the base class.
Programming Methodology and Programming Language Define our communication between us with the machine. Each new methodology provides some new ways to decompose problems, such as dependent on machine, code, process, class, and so on for machinery. Each new methodology provides a more natural way to map system requirements as programming structures, and the continuous development of these programming methods allows us to create higher complexity systems. Vice versa, that is, we allow the system that is increasingly complex and higher, because new technologies can help us to deal with this complexity.
Currently, OOP has become the choice of most software development projects. In fact, when OOP starts modeling public behavior, its power has been demonstrated. Below we will see that OOP does not completely solve behaviors across multiple modules, these issues may have experienced experience. We will also see the ASPECT-oriented programming (AOP) fill this vacancy, and AOP is likely to move forward in the development process of programming methodology.
1.2. Will the system as a group of Concern
We can regard the system as consisting of a set of Concern. So what is Concern? Concern is a special goal, concept or region of interest. From a technical context, a typical software system consists of many core level Concern and system-level Concern. For example, a credit card processing system includes a core Concern that handles payment, and processing logs, transaction consistency, identification user identity, security, performance and other system-level Concern. These Concern are some cross-cut Concern, and most Concern will affect multiple models. If you use the current programming method, these cross-cut cross cuts across multiple models will make the system difficult to design, understand, implement, and develop.
We regard a complex software system as a combination of multiple Concern, a typical system may be securely managed by business logic, performance, persistent data, log, debugging, identification of user identity, security, multi-threaded room security. , Check for a variety of Concern composed of errors. Similarly, we will also encounter many convern, such as understandability, maintenanceability, traceability, and more, and more. Figure 1 depicts a set of CONCERNs implemented by different models.
Figure 1: A set of convern from the model
Figure 2 is regarded as a bunch of light transmitted through prisms. We use a demand beam to transmit through a prism that can identify convern, and the prism will distinguish every Concern. This view can also be extended to Concern during the development process.
Figure 2: Concern decomposition under prism simulation
1.3. Cross-cut in the system Concern
Developers will create systems based on multiple needs, we can divide these requirements into core module-level requirements and system level requirements. Many system-level demands are generally orthogonal relationships (ie, independent) between the needs of the system level and the core module level (ie, independent), and system-level demand generally cross multiple core modules. For example, a typical enterprise application is generally composed of a number of cross-cut Concern, such as identification user identity, log, resource pool, management (Administration), performance, storage management, etc.. Each Concern has to cross multiple subsystems, such as storage management Concern, will affect each stateful business object. Public class homebusinessclass extends OtherbusinessClassClass {
// Core Data MEMBERS
// Other Data MEMBERS: LOG Stream, Data-Consistency Flag
// Override Methods in the base class
Public void PerformsomeOperation (OperationInformation Info) {
// ensure authentication
// Ensure Info Satisfies Contracts
// Lock The Object To Ensure Data-Consistency In Case Other Threads Access IT
// ensure the cache is up to date
// log the start of operation
/ / ==== Perform the core operation ====
// log the completion of operation
// unlock the Object
}
// More Operations Similar TO ABOVE
Public void save (PersitanceStorage PS) {
}
Public void loading (PersitanceStorage PS) {
}
}
The following is a simple, but it is also a more specific example. Let's consider the implementation framework for encapsulating a business logic.
In the above code, we should consider three things at least. The first is to consider other data members that do not belong to this class core Concern; the implementation of the PERFORMSOMeoperation () method performs many non-core operations, such as the need to process logs, authentication of user identities, multi-threaded security, verification contract, cache Concerne, etc., and also applied to these Concern in other classes; third, unclear whether the SAVE () and LOAD () methods of persistent management should belong to the core part of this class.
1.4. Problems caused by Concern
Although cross-cut Concern spans multiple models, the current technologies are often implemented in one-dimensional method, which makes it possible to be mapped along a single dimension. This single dimension is often the core module level implementation, and other needs are intertwined with the core module level. In other words, the demand space is an N-dimensional space, and the real space is a one-dimensional space, which does not match the demand to implement a very awkward mapping.
1.4.1. Problem
The current methodology to achieve cross-cut Concern has shown that there are many problems, and the performance of these problems can be divided into two categories:
u Code Tangling: The model of a software system may interact with several needs. For example, in general, developers think of business logic, performance, synchronization, log and security. Such a multi-needs intertwined condition will result in the implementation of each Concern in the programming element, that is, the code interleaving problem.
u Code Scattering: Follow the definition because cross-cut Concern across multiple models, so that all of these transverse Concern also cross all of these modules. For example, in a system for use in a database, performance Concern may affect all modules that access the database. 1.4.2. Impact
All in all, code interleaving and code dispersion affects many aspects of software design and development, mainly in:
U can track performance difference: Simultaneous implementation of multiple Concern makes the correspondence between each Concern and its implementation becomes blurred, and the mapping between the two becomes very poor.
u Productivity Decrease: Simultaneous implementation of multiple Concern enables developers to transfer attention from main concern Concern to peripheral Concern, causing a decline in productivity.
u Code Reuse: Since a module is to implement multiple Concern, other systems that require demand for similar functions cannot be heavy, which further causes a decline in productivity.
u Code quality difference: Interlaced code contains implicit issues. Moreover, once you want to implement multiple Concern, some Concern may not cause enough attention.
u It is difficult to develop: limited vision and resource-constrained resources typically generate a design solution that solves current Concern, which is usually inverted to re-implement. Since the previous implementation is not organized by modularization, you need to modify multiple modules to solve the problem. Each change must be modified each subsystem, which will cause the system's inconsistency and require a lot of testing to ensure that re-implement will not cause bugs.
1.4.3. Solutions currently proposed
Since many systems have transverse CONCERN, some techniques have also occurred to make the system to modrew. These technologies include Mix-in classes, design patterns, solutions related to specific application areas.
With MIX-IN Class technology, a Concern can be postponed. The main class includes a MIX-IN class instance and allows other parts of the system to set this instance. For example, in a credit card processing system, the class that implements business logic contains a Logger Mix-in. Another part of the system can set the logger to get the corresponding Logging type. For example, the Logger can be set to be implemented using a file system or message intermediate piece. Although Logging is postponed, the code that activates the logging operation is not controlled in all record log points, and the logging information is not controlled.
Similar to the Visitor mode in the design mode, the behavior design mode can be delayed. However, as the case in MIX-in, the control of the operation, that is, activated the Visiting logic or the activation template method is left in the primary class.
Solutions related to specific applications - such as framework and application servers - allows developers to solve some cross-cut Concern in modularity. For example, an enterprise JavaBeans (EJB) architecture solves cross cuts such as safe, management, performance, persistent persistence such as container management. Bean developers only care about business logic, while deploying developers only care about deployment, such as mapping Bean data into databases, bean developers do not need to care about data. Here, the data persistence transverse CONCERN is implemented with an XML mapping descriptor.
Solutions related to specific applications provide a specific solution to solve specific problems. One disadvantage of this method is that developers need to learn new technologies in each solution. Moreover, since these solutions are applied to a particular field, there is no directly resolving the problem caused by cross cut Concern, but to rely on special solutions.
1.5. Challenges faced by system architects
A good system architect will take into account current and future needs to avoid the system's implementation requires constant patch. But there is a problem here that it is very difficult to predict the future. On the one hand, if the future cross-cut demand is not considered, it may be necessary to modify or re-implement most of the system in the future. On the other hand, if too much considerations have a very low demand, the design amount of the system will increase the system, so that the system is confusing and bloated. Therefore, the system architect is facing such a difficulty in the design: How big is the design? What should I consider when designing? For example, is there a log system that does not need in the system architecture? If the answer is yes, where is the log? What kind of log information is recorded? Similar problems will also appear in demand related to optimizing system performance, because we cannot know the bottleneck of the system in advance. The usual method is to create a system to construct some of its profile, and then adopt optimized transformation to improve the performance of the system. This method potentially needs to change multiple parts of the system indicated by the system profile, and the change in use will cause new system bottlenecks over time. Consider reusable libraries, the system architect is a more difficult task, because he will find that it is difficult to consider all applications of the reusable library.
In short, system architects rarely know each possible convern to consider in the system. Even if the system needs are presented, the details needed to realize the system are not very complete, so the system architecture is facing two difficulties in designing too much or too little.
