Aspect Oriented Software Development James Friedenberger

Download 28.79 Kb.

Date	06.08.2017
Size	28.79 Kb.
	#28018

Aspect Oriented Software Development

James Friedenberger

Department of Software Engineering

University of Wisconsin – Platteville

friedenbergj@uwplatt.edu
Abstract
Aspect oriented software development is a relatively new type of development that simplifies maintenance and increases usability of software. Aspect oriented development can be implemented at the inception of software or current software can be reworked to use the process. Development using aspects can also allow proprietary and open source software to complement each other by separating features from the main code. Aspect Oriented models introduce new characteristics to use cases and class diagrams to account for their uniqueness. This helps bridge the gap between the currently used models and those that support Aspect oriented software development. Keeping new code whole and separated from the old code makes maintenance easier. It offers solutions to many problems that plague current software development processes. Aspect oriented software development is an exciting new angle on software development that can serve as a good alternative to traditional models.

Introduction
Software development has long organized programs based on functionality. Unfortunately, developers have to think about the big picture and about what other people on their team have to think about. Various parts of the software end up interweaving and causing the system to become more fragile. Object Orientation has allowed for better modularization of code and data. Aspect oriented development focuses on each of the concerns, or focuses, of software and provides for decentralization of software that object orientation does not provide. Aspect orientation separates all features of a program and modularizes all of them. It allows for more efficient software development and easier maintenance.[1]
AOSD (Aspect Oriented Software Development) is the next step in the gradual evolution of software. It allows for greater reusability in software breaking components down into separate pieces. Reuse occurs more frequently since the smaller pieces do not have as many implementation details that often show up in object oriented development. The smaller pieces also allow for better traceability by having fewer features in every module of code. Overall, AOSD can solve many of the problems that plague software engineering in its current form.

Structure and Terms
AOSD introduces a completely new vocabulary to development. Instead of worrying about classes, AOSD arranges common features into areas called concerns. An aspect is the implementation of the concern, which is similar to a class in traditional development. These easily trace to requirements whether they are high or low level. They can include any element of a system, but they work best with systematic behavior. Within the concerns category there is a grouping called crosscutting concerns. These are implementation level concerns that deal with how to execute a certain feature. A crosscutting concern is an aspect that is implemented in several areas of a system.
Join points are points in a system where concerns can be joined into the other code. These are hardcoded in the language and are usually at important places such as method calls or exceptions. Advice is a set of directions at a join point that tell the system what to execute. Advice is unaware that it runs at a join point since the base code might not have knowledge of the implementation of features. A pointcut designator contains several join points. The programmer uses a designator to specify if a certain concern, for example security, is supposed to run at several points within the system.
Weaving is the integration of the various concerns or aspects into the base code. Depending on the language, the components are compiled together, inserted at load time, or changed in the interpreter to use the aspects. Weaving uses the join points to determine when to insert the aspects; they can be static or dynamic. [2]
The structure of Aspect Oriented software is quite a bit different from traditional object oriented software. AOSD separates code into functional code and aspects. The aspects contain such things as event triggers, timers, and other code that has more to do with the implementation rather than the functionality of the program. The implementation code would normally scatter throughout several classes within a program, but with aspects, the code is all in one place. Each aspect has directions or advice for when the aspect should execute. These places, pointcuts, are points that the software can call the aspect and execute the code. A programmer could have an event triggered anytime prescribed methods are called, thus not having to insert the code into each individual method. This structure modularizes all of the code and strips non-functionality out of the base code.[3]

Design

Unified Modeling Language (UML)
AOSD puts a new spin on UML documentation for software. There are several new components introduced in UML that add support for Aspect Oriented Software development. Classes in UML diagrams represent aspects. Several different stereotypes define aspects. Synchronization introduces aspects that use mutual exclusion. Replication makes several instances of a certain aspect that contains methods and attributes. Message oriented aspects characterizes distribution, and coordination defines data that uses triggers and other condition aspects. Several associations have also been created that are based on those stereotypes.[4]
One feature that also shows up in UML is the separation of the different concerns of the program. It increases the modularity of the features and can separate the core code from the features that may or may not be included in different versions of a program. It also keeps nonessential features separated from the main program; consequently, there will not be security code entangled in the main code of the program. For example, a chat program can have the authentication and filter code separate from the main chat program. This keeps the security code separate from the main code. Instead of calling a security function several times throughout the code, it can just be called at every method. When a new user is added to the session, the security functions can be called when the new user is instantiated.[5]

Figure 1: Example of AOSD UML Diagram [6]
Architectural Description Languages
Another type of design for AOSD involves ADL (Architectural Description Language) which is similar to UML. There has not been a tool developed that is able to translate ADL for AOSD purposes, but several ongoing research projects have created innovative syntax. The two main features that incorporate AOSD into the traditional model used for architectural description languages are the specification of connections between interfaces and the introduction of aspects into the software environment.
The specification of connections between interfaces demonstrates the join points. Connections show the relationship between functional code and shows where the execution of aspects occurs. The specification of aspects creates a place to put the implementation code. Along with connections, they can be modularized and kept apart from the functional code. Further specification shows the operations and decisions. ADL can help specify high-level requirements while adapted UML can create lower level requirements.[7]

Requirements Engineering
Requirements engineering also affects AOSD. It is a good place to start when creating a new system because many of the issues dealing with AOSD involve the separation of the functional and non-functional features. Requirements specification works well with component-based modeling. Requirements have to be modularized into aspects that represent features and components that represent the base code. The separation of aspects and base code makes the separation of concerns apparent, which makes it easier to design the system. Identifying aspects at the requirement level makes it easier to create and maintain software throughout the entire lifecycle of the project.[8]

Implementation

Languages - AspectJ
Unfortunately for programmers that want to develop Aspect Oriented Software, many of today’s languages are based on the object-oriented model. In order to accommodate aspects, many of the languages have to either be modified in order to accommodate the differences between object oriented and aspect-oriented programming or sublanguages have to be added to weave the base program and aspects together.
There are several languages that support AOSD, but AspectJ is one of the more widely used languages. AspectJ comprises Java, but with a few differences. The part of Java that deals with mutual exclusion has been separated into its own aspect category rather than part of the language libraries. AspectJ also supports the main components of AOSD including pointcuts and the introduction of aspects. There are a few compilers that allow AspectJ integration with traditional Java development tools such as Netbeans or JBuilder. Aside from the structural differences, AspectJ is similar to Java.[9]
AspectJ is meant to be easy to use for object-oriented programmers. All Java programs can run on AspectJ compilers. Therefore, current Java programs can support aspects and aspect-oriented development. It even creates its own version of Javadoc called AJdoc. AspectJ introduces join points where function calls and returns are. AspectJ can be used as a full software development environment, or, alternatively but not usually used, it can use a sub-language such as Cool and Ridl to implement aspects.[10]

Figure 2: Aspect Code in AspectJ [11]
Aspect Oriented Versus Object Oriented Programming
AOSD is hard to gauge against traditional models without comparing a program implemented in both object oriented and aspect oriented models. A couple of experiments were carried out using six programmers with similar skills; three used the aspect-oriented approach and three used the object-oriented approach. The experiments gauged whether the aspect-oriented model was easier to debug, and whether it was easier to modify. AspectJ was used for the core code and the aspect languages Cool and Ridl were used for the aspects. Java formed the basis of both of the aspect languages. The experiments produced some interesting results.
The first experiment involved already developed code with errors in it relating to mutual exclusion. Mutual exclusion would normally need to have code put in several places throughout a program. AspectJ was used for the aspect-oriented group and regular Java was used for the object-oriented group. The programmers solved each error in succession. Findings showed that in AspectJ it was slightly faster to solve the problem, had a few more file switches between code files and had fewer problems finding the correct place to put solutions in. The compile times were similar, even though AspectJ needed to weave together the base code and aspect.
The second experiment involved modifying written code. AspectJ and Emerald, a language similar to Java, were used for the experiment. The researchers assigned the programmers three tasks that involved adding two methods and a task that was open-ended and was to enhance performance. The AspectJ programmers spent more time completing those tasks than the Emerald programmers. This was mainly due to not knowing the entire AspectJ environment with its sublanguages and disagreements on how to complete the tasks.
The experiments essentially hypothesized that debugging a program that had errors in environment code was easier to debug with an aspect oriented language. The programmers did not have to modify the functional code or worry about the placement of the code. There was more time spent on the actual debugging rather than on analysis about where the code was coming from.
The modification experiment showed that the programmers lacked experience with the aspect style; consequently, they could not properly implement the changes. It would take a programmer with more experience in AOSD to solve the problem for an experiment to determine which type of programming would be better. In addition, there were problems with the sublanguages interfacing with the core Java code. When all of the problems are resolved, it should be easier to gauge the effectiveness of aspect-oriented programming.[12]

Real World Applications

Features
AOSD has many applications in the real world. One of the promising new concepts involves the separation of open sourced and proprietary software. The scattering of code that is present in Object-Oriented programming techniques makes software updates and reuse a nightmare. The implementation of concerns allows software to be managed in more reusable ways. Identification of features can occur early in the development phase, or the feature can be added later if a customer decides to request it. An aspect can even encapsulate all of the solutions needed to fix an error that comes up during the testing phase of the project.[13]

Business Uses
Besides adding features at any phase during the lifetime of the software, AOSD allows for the separation and evolution of open-source software. Since aspects are separate from the base code of a program, it can easily allow companies to take advantage of open source software. The open source software can be a stable program that does not have any of the things that cause problems such as security. These features can be added later; moreover, private companies could create the features. The company does not have to worry about the base code because the company has developed all of the extra features.
This also opens a completely new marketplace for software companies. Not only does it allow private companies and public researchers to use the same base code, but it also keeps the source code in the functional side of the project rather delving into separate areas. Companies can get only the software they need and purchase each feature separately, rather than in one big package. If there is a feature not available that it needs, the company can choose to develop the feature in-house without having to worry about modifying the base code.
The composition and extraction cycle shows the continuing phases that software goes through. It never goes to a final state since features are added at any time during the lifecycle of the software. When new artifacts are added to software, the software is decomposed and recomposed into new packages that include various features. This allows new features and the ability for companies to decipher what the customer needs and what it should get. [14]

Figure 3: Extraction Composition Cycle

Conclusion
AOSD can help overcome many of the challenges that have become apparent with the evolution of Object Oriented Software Development. Object-oriented development cannot overcome several deficiencies within its current framework. AOSD introduces a new level of software architecture that vastly improves the efficiency of the code. AOSD can also integrate features throughout the entire software development process. From the business aspect to the design phase to implementation and maintenance, AOSD makes it easier than ever to completely modularize an entire system. It keeps the functional and non-functional code separate from each other, making it easier to maintain. The improvements in maintenance and the ability to package new features can improve the profitability success of software projects. AOSD may not be the final solution to all of the problems plaguing software development, but it is a step in the right direction.

References
[1] Filman, R. & Friedman, D. (2005). Aspect-Oriented Programming Is Quantification and Obliviousness. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.1-7). Boston: Addison-Wesley.
[2] Filman, R. & Friedman, D. (2005). Aspect-Oriented Programming Is Quantification and Obliviousness. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.3-6). Boston: Addison-Wesley.
[3] Clemente, P., Hernandez, J., Herrero, J., Murillo, J., Sanchez, F. (2005). Aspect-Orientation in the Software Lifecycle: Fact and Fiction. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.409-415). Boston: Addison-Wesley.
[4] Clemente, P., Hernandez, J., Herrero, J., Murillo, J., Sanchez, F. (2005). Aspect-Orientation in the Software Lifecycle: Fact and Fiction. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.413-420). Boston: Addison-Wesley.
[5] Pinto, M., Fuentes, L., Troya, J. (2003) A Dynamic Component and Aspect-Oriented Platform. The Computer Journal, 48, pp. 401-420.
[6] Spring Maintenance. (n.d.). Retrieved November 1, 2009 from Maintenance website. https://src.springframework.org/svn/spring-maintenance/
[7] Clemente, P., Hernandez, J., Herrero, J., Murillo, J., Sanchez, F. (2005). Aspect-Orientation in the Software Lifecycle: Fact and Fiction. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.413-420). Boston: Addison-Wesley.
[8] Blair, G., Blair, L., Rashid, A., Moreira, A., Araujo, J., Chitchyan, R. (2005). Engineering Aspect-Oriented Systems. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.380-398). Boston: Addison-Wesley.
[9] AspectJ. (n.d.). Retrieved October 31, 2009 from Eclipse website, www.eclipse.org/aspectJ.
[10] Colyer, A. (2005). AspectJ. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.123-143). Boston: Addison-Wesley.
[11] Apel, S., Leich, T., Saake, G. (2008). Aspectual Feature Models. IEEE Transactions of Software Engineering, 34, p. 173.
[12] Walker, R., Baniassad, E., Murphy, G. (2005). An Initial Assessment of Aspect-Oriented Programming. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.335-345). Boston: Addison-Wesley.
[13] Harrison, W., Ossher, H., Sutton, S., Tarr, P. (2005). Supporting aspect-oriented software development with the Concern Manipulation Environment. IBM Systems Journal, 44, pp. 309-311).
[14] Harrison, W., Ossher, H., Sutton, S., Tarr, P. (2005). Supporting aspect-oriented software development with the Concern Manipulation Environment. IBM Systems Journal, 44, (pp. 311-313).

Download 28.79 Kb.

Share with your friends: