Download preview PDF. Skip to main content. This service is more advanced with JavaScript available. Advertisement Hide. Conference paper. Keywords AOP maintainability reusability separation of concerns. This is a preview of subscription content, log in to check access. Bartsch, M. Basili, V. In: Encyclopedia of Software Engineering, pp. Beltagui, F. Bieman, J. Bowen, T. Guidebook for Software Quality Measurement.
Breivold, H. Brichau, J. Chaumun, M. Then, implementations of the GoF design patterns. It was found the paper presents the state-of-the-art in implementing cross- that not only Decorator, but also Proxy can take advantage cutting concerns.
In addition, reflective programming was explored and applied to the scenerios to avoid code employed for Prototype to provide a default implementation scattering and code tangling. Finally, the paper provides for cloning. In each case, the obtained implementation is guidelines outlining which paradigm is appropriate for which highly reusable. What is wrong with AOP?
In: Encyclopedia of Software Engineering, pp. We advocate for [4] Beltagui, F. We argue that the existing metrics are [6] Boudreau, M.
MIS Quart. We aslo describe some bugs in the tool that Modular Aspect-Oriented Reasoning. Technical Report , Iowa is widely used to evaluate AO software.
We have fixed and State University, extended this tool to collect our metrics. Finally, we present [8] Davison, R. Information Systems Journal 14 1 , pp. We found that there is no pattern whose AO implementations exhibits lower coupling, [9] Dijkstra, E. Netherlands, while 22 patterns present lower coupling in the OO [10] Figueiredo, et al. In: 30th Inter. In: between modules of the Observer pattern.
In: Workshop on Multi- cohesion in both implementations. We compare two versions Java and AspectJ of quantitative study. In: 4th Inter. We found that there is no evidence that [15] Greenwood, P. In: 21st European Conf. LNCS, vol. We also University of give a rationale for our coupling metric. Chicago Press, [18] Leavens, G.
Using the Persistence Aspects with AspectJ. The experiment encompasses [20] Steimann, F. In: 8th Inter. Evolvability and reusability are quality characteristics that we cannot measure directly. Instead, we can perform an experiment that involves maintenance tasks and then we can measure how much effort is required to evolve the system and how much of the existing code can be reused in the consecutive release.
The amount of reuse is usually measured by comparing the number of reused "items" with the total number of "items" [12], where items depend on the granularity chosen, e. Since we are going to measure code reuse, we have chosen the granularity of LOC, yet we count only these reused lines that are part of the modules reused by applying the composition mechanisms of the underlying programming language. In their work, the difficulty of evolvability is defined in terms of atomic changes to the modules in a program.
At the core of this approach is the ability to transform source code edits into a set of atomic changes, which captures the semantic differences between two releases of a program. Zhang et al. For the purpose of our study, we have slightly modified their catalog. Firstly, we consider deleting a non- empty element as an atomic change.
Our list of atomic changes is follows: add an empty module, delete a module, add a field, delete a field, add an empty method, delete a method, change body of method, add an empty advice, delete an advice, change an advice body, add a new pointcut, change a pointcut body, delete a pointcut, introduce a new field, delete an introduced field, change an introduced field initializer, introduce a new method, delete an introduced method, change an introduced method body, add a hierarchy declaration, delete a hierarchy declaration, add an aspect precedence, delete an aspect precedence, add a soften exception declaration, delete a soften exception declaration.
Thus, we have to simulate maintenance tasks in a laboratory experiment. The producer generates items and places them in the buffer. The consumer removes items from the buffer and consumes them. However, the producer must not place an item into the buffer if the buffer is full, and the consumer cannot retrieve an item from the buffer if the buffer is empty.
Nor may the two processes access the buffer at the same time to avoid race conditions. If the consumer needs to consume an item that the producer has not yet produced, then the consumer must wait until it is notified that the item has been produced. If the buffer is full, the producer will need to wait until the consumer consumes any item.
We assume to have an implementation of a cyclic queue as shown in Fig. The put.. The nextToRemove attribute indicates the location of the oldest object. The location of a new object can be computed using nextToRemove, numItems number of items and buf.
We also have an implementation of a producer and a consumer. The experiment encompasses five maintenance scenarios which deal with the implementation of a new requirement. We have selected them because they naturally involve the modification of modules implementing several concerns.
A thread has to be blocked when it tries to put an element into a full buffer or when it tries to get an element from an empty queue.
In addition, both put.. Thus, they have to be wrapped within synchronization code when using Java Fig. Since the code supporting the secondary concern may throw an exception, there is also a technical concern of error handling. The core concern here is associated with adding and removing item from the buffer. The presented implementation tangles the code responsible for the core functionality with the code responsible for handling errors and for cooperating synchronization.
Moreover, the implementation of both secondary concerns are scattered through the accessors methods. As a result, the put Object and get methods contain similar fragments of code. The secondary concerns are implemented in ErrorHandler and SynchronizedQueue. SynchronizedQueue::waiting is a hook method to introduce an explicit extension point. This joinpoint is used by ErrorHandler to wrap wait invocation.
Despite of lexical separation, SynchronizedQueue is explicitly tied to the Queue class, and so cannot be reused in other contexts. New aspects for Stage I SynchronizedQueue.
This makes it difficult to know what changes to Queue will lead to undesired behavior. Whenever an item is removed, the time how long it was stored should be printed to standard output. A Java programmer may use inheritance and composition as reuse techniques Fig. It means that e. A slightly better solution seems to be using AOP and implementing the timing as an aspect Fig. Unless explicitly prevented, an aspect can apply to itself and can therefore change its own behavior. To avoid such situations, the instantiation pointcut is guarded by!
Moreover, the instantiation pointcut in SynchronizedQueue has to be updated. It must be the same as in Timing.
This can be done only destructively, because AspectJ does not allow for extending concrete aspects. The only problem is that four concerns are tangled within the LogTimeBuffer class.
A module that addresses one concern can generally be used in more contexts than one that combines multiple concerns. The AO solution is also noninvasive and it reuses the modules from the earlier stages. It just requires defining a new aspect Fig. When advice declarations made in different aspects apply to the same join point, then by default the order of their execution is undefined.
Thus, the declare precedence statement is used to force timing to happen before logging. The bufferChange pointcut enumerates, by their exact signature, all the methods that need to captured. Such pointcut definition is particularly fragile to accidental join point misses. An evolution of the buffer will require revising the pointcut definition to explicitly add all new accessor methods to it. There is no efficient solution of this problem neither using Java nor AspectJ. In both cases, the condition for waiting on an item has to be reinforced by a lock flag.
The flag is unset after getting the last item. In Java Fig. The reason is that in LogTimeBuffer logging is tangled together with synchronization, so it cannot be reused separately.
The duplicate implementation might be a nightmare for maintenance. Thus, all code corresponding to the synchronization concerns has to be reimplemented Fig.
A new method to get N items and locking mechanism are introduced to Queue by means of inter-type declaration. Highly Influential. View 3 excerpts, references background. Software reuse. View 2 excerpts, references methods. Design method for interoperable Web Services. Discussing aspects of AOP. Aspect-oriented programming is a new evolution in the line of technology for separation of concerns technology that allows design and code to be structured to reflect the way developers want to think … Expand.
View 1 excerpt, references background. Object Orientation and Web Services. Role-based security for configurable distributed control systems. Related Papers.
0コメント