Having analysed the practical experiment in a variety of different ways and the responses from the questionnaire, an overall opinion of aspect-oriented programming can now be formed. When setting the aims and objectives, a hypothesis was formed based on the research done5, which can now be measured against.
My hypothesis started by claiming that software development processes would improve with the use of aspect-oriented programming, especially productivity and modularisation. The process was not as dramatically different as I feared before programming, but care should be taken to make the most of the new constructs available. The paradigm modularises and abstracts more information and data than object-oriented programming can, which is a positive. Additional time is required to identify the join points for a particular pointcut, depending on the size of the program. However, the length of time for developing each system separately was around three weeks each, which indicates that this potential issue is not as much of a problem as feared, especially when I wrote the methodology. Both had the same results in the end in terms of functionality and interface design.
Maintainability and comprehension were another two criteria defined in the hypothesis. There are opportunities to maintain and evolve software more efficiently, again when developed with care, especially in the case of wildcards, and aspects can be designed separately which could help assignment of work in the real world amongst a development team. Comprehension is often cited as a strength of Java [10] due to its syntax being designed to be as accessible as possible. AspectJ continues this expressiveness, particularly with its pointcut designators, as seen with the results from the questionnaire. Maintenance is difficult to quantify at this time since there has only been one iteration of the system developed. This is something to consider in the future, however the ease of integration whilst testing gives optimism for the results of future development.
The use of aspect-oriented programming also promotes key concepts of object-oriented programming, important concepts which it is best to maintain. Inheritance is maintained for classes, and can even be handled by one aspect, but also can be used for aspects through the use of abstract pointcuts and advice. Reusability is also addressed through abstract aspects, as well as the use of wildcards for looking forward for new pointcuts which could be included, such as the “Validation” aspect taking into account any future method call pointcut using a “Transaction” object as its parameter. Both of these maintain the advantages of inheritance and reusability, such as reduced development time and ease of extension.
As with all languages, they are best used within certain domains and aren’t suited to others [34], however aspect-oriented programming is certainly an opportunity for developers to take advantage of in the future, as long as they prepare a smooth transition, whilst still using the tools they may be familiar with already. This is not restricted to just Java, as many programming languages have been extended with aspect-oriented concepts using additional libraries, such as AspectC++ [23, p458], as well as from paradigms other than object-oriented, such as AspectML6 for ML, a functional language.
9. Reflection
After completing this thesis, there were a number of lessons which could be learnt from such as the research process, the content and my own abilities. There were also topics which could have been addressed but were not covered due to time constraints and lack of resources. This section outlines these reflections.
Research Process
Since the topic of aspect-oriented programming was fairly new to me before writing this thesis, a great deal of research was required from trusted sources. During the research process, I used the following techniques. The majority of research papers were searched from within databases, in particular IEEE Xplorer, the ACM Digital Library and Springer Link, making use of their connection with universities. Initially, key words such as “aspects” and “AspectJ” were the main source of search results, but over time more specialised arguments such as the number of citations and the date of release were also considered, to find the best sources possible as well as more recent thinking on the subject. From the first batch of sources, the references were considered, with the most cited being downloaded as well since papers that are cited by others are most likely to be useful in some way to this thesis. In addition to research papers, several textbooks were used, some of which I already owned but others were sourced such as those by Laddad [23] and Miles [25] through reader evaluations on retailer websites, such as Amazon. When the point came to writing this report, all potential references were assessed on their usefulness, with those not being used listed in the bibliography, based solely on whether they would be cited for a particular reason.
The focus of the research altered over time, depending on the section of the thesis to be completed at that time. Focus started on introducing the subject and researching potential positives and negatives of both the paradigms and the languages involved. Once establishing the basic concepts and existing opinions of both paradigms, the focus went onto learning the AspectJ language and determining best practice for its use. In addition, sources related to interface and database design were required to make certain points in this thesis.
The researching of additional sources did extend beyond the initial estimate of approximately three weeks but overall I was pleased with the outcomes. This process definitely helped with my personal comprehension of the subject, as well as inspiring crosscutting concerns within my system, such as a model of exception handling from Millham and Dogbe [26]. The largest problem was a clear dip in research around the second half of the last decade, which could be attributed to the lack of commercial successes of aspect-oriented development. Attempting to keep the thesis general made searching for additional sources difficult as the more recent papers are concerned with specifics or suggested extensions to the language, which were not the aim of the project.
This is definitely the biggest experience I have had of a thorough research process, and there were some lessons learnt over the course of the process. A reliance on sources which were regularly cited was important, something which I had not taken into account so much previously. It was especially useful for identifying sources that were most likely to teach me the basics as opposed to some specific area which would have distorted my view. Having the process separate to development of software made it easier to keep to the schedule drawn up at the start, maintaining focus on one area of the thesis rather than having the two running concurrently. Overall, I was extremely happy with the outcomes of the research process, and would carry out the same process if required in another capacity.
Share with your friends: |