Discussion of Aspect Oriented Development
Download 31.7 Kb.
|
- Navigate this page:
- Introduction
- Static vs. Dynamic Weaving and Invasive vs. Non-Invasive Weaving
- Coordination
- Development in Aspect-Oriented Environments
- Aspect-Oriented Requirement Engineering
- Aspect-Oriented Business Process Management
|
Discussion of Aspect Oriented Development Alex Beatty Department of Software Engineering University of Wisconsin – Platteville beattya@uwplatt.edu Abstract Aspect-Oriented Development is an additional step in the software development fields towards abstraction and decomposition. While Object-Oriented Development has lent a great deal of abstraction to the programming of concerns that can be thought of as real-world objects, it lacks the robustness to describe and effectively capture more abstract concepts. I will be describing and discussing the different ways the advices of an aspect can be woven into the system (static and dynamic, and invasive and non-invasive). I will also be discussing some common crosscutting concerns that make good examples of uses for Aspect-Oriented Development. Lastly I will go over AspectJ pointcuts and advices. IntroductionObject Orientation has been very helpful in meaningfully decomposing software into structures that are easily understood by people. However, strictly following Object Orientation does have some limitations in relation to some common functions (e.g. logging, security, coordination), and these limitations could apply to novel concerns of a large program. Aspect-Oriented Development’s primary driving force is to modularize these “cross-cutting concerns” into a single place, decreasing the system’s code tangling and scattering [1]. A cross-cutting concern is a functionality of a program that will need to be used in many places, or relies on many other parts of a system. Aspect-Oriented Development has these cross-cutting concerns in a separate file, called an aspect. This modularization lends itself to all parts of a system being more re-usable, since the objects in the base code will be handling only their computational concerns and any aspect developed can easily be used in another system where the same cross-cutting concerns are going to be implemented [3]. Aspects consist of pointcuts and advices, which are run at join points that the programmer dictates. A pointcut is a definition of where the programmer would like some additional code to be run (e.g. every time a “set” function is called), and an advice is the code block to be run before, after, or around (if an advice is “around” a join point, the advice can prevent the code in the join point from running) the pointcut. Join points are places in the code that can be hooked into by pointcuts (e.g. a function call) [1]. The advices are then “woven” among the base code of the system. There are two binary ways of doing this: invasive and non-invasive, and static and dynamic. Invasive and non-invasive describes if the base code is modified directly or not (one non-invasive weaving technique is to create new classes that inherit from the base code and have the advice code included [5]); static and dynamic describe when the weaving is done, at compile time or load time or even run-time (compile time is static, the others are dynamic). Static vs. Dynamic Weaving and Invasive vs. Non-Invasive WeavingStatic weaving has the benefit of being able to be run anywhere the base code could be run, as the aspect code has already been included in the compiled code. Alternatively, since the code doesn’t have to be recompiled to be ready to use with dynamic weaving, it allows more flexibility in the application of the aspects being used. In fact, in some cases the aspect can be selected and changed at run-time [3]. One potential downside to this is the requirement of a virtual machine or other special run-time environments. This is not always a important, considering any java-based Aspect-Oriented language already needs to use the java virtual machine to run its base code. One would assume that static weaving would offer improved performance, but AspectJ weaving dynamically offers a 26% increase in performance over its static weaving [4]. Invasive weaving injects the code of the advices into the base code at the points dictated by the pointcuts associated with those advices (this is the way AspectJ works). One way to implement non-invasive weaving involves creating subclasses of each class affected by an aspect, though there are other ways of implementing non-invasive weaving [5]. Non-invasive weaving could potentially suffer performance problems, especially while dynamically weaving, since these new classes would have to be generated while the system is running, which would require processor cycles to accomplish. Common UsesThe functionality most commonly mentioned when introducing Aspect-Oriented Development is logging, that is, keeping track of functions called and variables set, etc. This is obviously a crosscutting concern as to implement it in strict Object-Orientation would require that every function in every class have at least one call to a logging class/function. Other examples include synchronization, error detection and correction, memory management, and security [1]. CoordinationSome systems require communication and coordination between their various parts, this communication is vital to the system running properly, but it cannot be cleanly captured by Object-Oriented processes. Take, for example, an auction system (like the one in “Aspect-Oriented Coordination”). This system could be used to implement an online auction website. Allowing users to start auctions, or to join one and bid on the item being auctioned. This system requires users called “buyers” to communicate with “auction” objects. These auction objects can Figure : Recreation of left side of figure 2 from [3], shows “Private, One Bid” Auction be in three different states: an initial state, during which buyers are allowed to join the auction by using the auction’s “join” method; a “CollectBids” state, in which the auction only accepts bid messages from buyers; and a “CloseAuction” state, where the auction does not accept any messages, but determines the winner and sends messages to each buyer in the auction. Figure 1 shows the coordination protocol of the auction system for a “private one bid” auction, that is, each buyer is allowed a single bid and no other buyer is notified of what each buyer has bid, it also allows for a ‘direct buy’ option which allows a buyer to pay a set amount to automatically win the auction before the time has expired, as a state diagram [3]. It is entirely possible to program this system using Object-Orientation; however, there are some serious drawbacks. Chiefly, there are multiple kinds of auctions; if the company using this system wanted to implement a new protocol in an Object-Oriented system it would entail recreating parts of the system. Either the new system would be created from scratch, meaning all the effort of creating the basic objects (buyers, auctions) would be replicated, or the system could be copy-pasted into a new project, then maintainers would need to go through line-by-line, function-by-function and change the coordination protocols to match the new kind of auction being implemented. These are both inefficient, expensive options. The authors of the paper suggest using a non-invasive Aspect-Orientation approach, specifically using JAsCo [3]. In this way, the buyers and auctions can be programmed to simply handle their own computations and the aspect portion of the system can handle all coordination. The system using non-invasive dynamic weaving also gives the added benefit of being able to switch the mode of the auction, basically on-the-fly, since all that would need to be changed would be the aspect, and this can be done without stopping the system in some non-invasive weaving Aspect-Oriented languages like JAsCo. Figure 2 shows the coordination protocol for a “public English style” auction, in which all buyers are aware of what each other buyer has bid, and all buyers are allowed to place multiple bids. The changes being that when one buyer makes a bid, all buyers are notified of the bid and that at the end of the auction, all buyers are notified of the winner and the amount paid. These changes could easily be found and changed in a copy of the original “private one bid” aspect and woven to create a new style of auction available to the users of the auction system. This would allow the original auction and buyer objects to be used, since they were not changed at all to create this new style of auction.   Figure : Recreation of right side of figure 2 from [3], shows “Public English Style” auction SecurityWith the growth of web development, security is becoming an important part of software systems. Unfortunately, security is not well suited to object orientation, for the same reason that other cross-cutting concerns are not. This draws us toward Aspect-Orientation for development. One of the greatest benefits Aspect-Orientation brings to security programming is the fact that the aspect is completely separate from the base code, meaning any security aspects that need to be written can be done so by security experts, without those experts having to find the specific parts of the code that needs the security involved. They can simply write their security protocols and checks, and then include pointcuts for all generic join points that will need each specific type of protocol/check. For example, cross-site scripting vulnerabilities can be exploited using string input controls to run Directory: ~yangq -> csse411 -> csse411-materials -> f13 f13 -> Web Security a Programmer’s Perspective csse411-materials -> Emotional Annotation of Text David Gallagher csse411-materials -> Christopher Pinski Department of Computer Science and Software Engineering csse411-materials -> Computer Science / Software Engineering uw-platteville csse411-materials -> Security of Mobile Devices Lon Kastenson Abstract csse411-materials -> Developing for Android Erik Nykl Abstract csse411-materials -> Spyware, Malware, and Viruses Anthony Bosnak Department of Computer Science & Software Engineering University of Wisconsin – Platteville csse411-materials -> Personal Computing: Past, Present, and Future Michael Wills f13 -> Asynchronous Programming in. Net 5 Cole Durdan Department of Computer Science University of Wisconsin-Platteville Download 31.7 Kb. Share with your friends:
|