School of computer science and informatics, cardiff university
Download 174.27 Kb.
|
- Navigate this page:
- Further Work
- 10. Conclusion
- References
Other LessonsDuring the course of this thesis, many lessons have been learnt in a variety of areas. Apart from researching, the most important issue with a thesis of this timescale and size is project management, and the ability to maintain a high level of work over four months. It was important to set a timetable right at the start of the experiment, rather than organising the available time every couple of weeks which I have done in the past, whilst keeping in mind that tasks such as programming are very fluid and therefore difficult to estimate correctly and I needed to take that fact into account. Setting targets definitely helped in controlling workflow and allowed enough time to draft this thesis. Some of the estimates turned out to be slightly more than actually required, but the extra time was spent on improving this report. During the course of this thesis, I have seen some personal development in associated skills beyond learning a new language and programming paradigm. One improvement on previous dissertations is the referencing of external sources. My dissertation for BSc did receive comments from examiners that the referencing could be improved. To address this, I ensured that I had recorded all sources shortly after reading or using them to make sure all conventions were followed. Adding justifications to design decisions was also a previous issue with dissertations, so focus was put on this by ensuring that all major decisions were recorded for inclusion in this thesis, particularly during implementation. In terms of the questionnaire experience, I accepted early on that availability of responders would be difficult since the majority would have to come from the masters degree course running at the same time, but they would all be busy with their own thesis. The results may not have differed but having more responses would have made the results a stronger argument for adoption. Also, in any future questionnaire process, face-to-face completion was more effective for understanding the answers given by the responders, and should be the default methodology. Further WorkWhile I tried to keep the thesis as broad as possible in terms of the functionality being explored, due to time constraints, some areas of programming were not considered but could be implemented in the future. One issue this program does not deal with is multiple clients operating on the same database through concurrent threads, which would most likely be a requirement of the banking system developed if used in the real world since it would need to be run from multiple terminals. There are also some aspects of the development process that have not been considered, such as maintainability. Whilst integration testing gives an idea of the ability to maintain AspectJ programs over time, it does not tell the whole story. One possible extension could be adding additional functionalities, and measuring what impact they would have upon the existing code. As stated in the analysis, this experiment took the form of taking a Java program and modifying it into an aspect-oriented program. A further extension could be to go the opposite way, or design the aspect-oriented system from scratch, which would allow for further analysis of the mental model required for both paradigms. One downside of this thesis is that the piece of software developed to prove my hypothesis could not be larger due to time constraints. With more time available, the thesis could have been more in depth and identification of concerns in a program with many thousands of lines of code would have probably given more concrete results rather than having to interpolate the results for large-scale development. Larger programs would require a more sophisticated method of program comprehension to refractor between object and aspect-oriented programming. This could be achieved with program slicing, which Zhao [38] adapted to propose an aspect-oriented approach. 10. ConclusionResearching aspect-oriented programming and implementing a practical experiment using the paradigm within a real world domain has definitely shown that through modularisation of crosscutting concerns, AspectJ promotes a high level of abstraction, one of the key selling points of Java and object-oriented programming, reduces redundancy and allows for a smoother evolution of a system with added requirements. Of course, there are always disadvantages for adopting a new technology which is largely untested outside of the research world. Time and effort is most certainly required to excel at using this paradigm, and while the modularisation model does help clarity by having a select behaviour in one place and not over multiple classes, the mental model required to reach them can be a step up. Over time, these disadvantages would decrease proportionally to the amount of experience developers have in aspect-oriented methodologies. Summing up this thesis, many of the benefits given by object-oriented programming and Java were maintained using AspectJ as well, and adapted for aspects. Inheritance was not only maintained but made clearer by listed all extensions and implementation in one aspect, and could also be used with abstract aspects listing pointcuts to be defined by aspects extending them. These have all been evident during the practical comparison, and should encourage use in a commercial environment in the future. Years, even decades, have passed since the notion of the aspect-oriented paradigm was first published, and AspectJ is just over a decade old, without a great deal of acceptance. After some time of disillusionment with aspect-oriented languages, the level of research has increased and the paradigm is starting to gain in popularity. I am personally encouraged by the results of this thesis, and would certainly use aspect-oriented approaches in the future. Education is certainly the key for the paradigm’s long term success. References[1] Alexander, R. 2003. “The Real Cost of Aspect-Oriented Programming?”. IEEE Software 20 (6), pp. 91-93. [2] Bonér, J. 2004. “What are the key issues for commercial AOP use – how does AspectWerkz address them?”. Proceedings of the 3rd international conference on Aspect-oriented software development, pp. 5-6. : ACM. [3] Brookshear, J. Glenn. 2009. Computer Science: An Overview. 10th ed. : Pearson International Edition [4] Coyler, A. and Clement, A. 2005. “Aspect-oriented programming with AspectJ”. IBM Systems Journal 44 (2), pp. 301-308. [5] Di Lucca, G.A. et al. 2007. “Comprehending Aspect-Oriented Programs: Challenges and Open Issues”. 15th IEEE International Conference on Program Comprehension. [6] Eclipse. AspectJ Development Tools (AJDT). [Online] Available at: http://www.eclipse.org/ajdt/ [Accessed: May 2013] [7] Eclipse. Introducing AJDT: The AspectJ Development Tools. [Online] Available at: http://www.eclipse.org/articles/Article-Introducing-AJDT/article.html [Accessed: June 2013] [8] Eclipse. Inter-type Declarations. [Online] Available at: http://eclipse.org/aspectj/doc/next/progguide/language-interType.html [Accessed: June 2013] [9] Filman, R.E. and Friedman, D.P. 2000. “Aspect-Oriented Programming is Quantification and Obliviousness”. Workshop on Advanced separation of Concerns, OOPSLA 2000. [10] Gosling, J. et al. 2011. The Java Language Specification. 4th ed. : Addison-Wesley. [11] Grekova, E. et al. 2012. “Aspect-Oriented Programming”. [Online] Available at: http://kremer.cpsc.ucalgary.ca/courses/seng403/W2012/papers/6%20Aspect-Oriented%20Programming.pdf [Accessed: 6th July 2013] [12] Hanenberg, S. and Costanza, P. 2002. “Connecting Aspects in AspectJ: Strategies vs. Patterns”. First Workshop on Aspects, Components, and Patterns for Infrastructure Software. AOSD'01, Enschede, April 2002. [13] Hanenberg, S. and Unland, R. 2002. “Specifying Aspect-Oriented Design Constraints in AspectJ”. Workshop on Tools for Aspect-Oriented Software Development at OOPSLA. Seattle, November 4, 2002. [14] Hanenberg, S. and Unland, R. 2001. “Using and Reusing Aspects in AspectJ”. Workshop on Advanced Separation of Concerns, OOPSLA 2001. [15] Hanenberg, S. et al. 2003. “AspectJ Idioms for Aspect-Oriented Software Construction”. EuroPLOP 2003, pp. 617-644. [16] Hilsdale, E. and Hugunin, J. 2004. “Advice Weaving in AspectJ”. Proceedings of the 3rd international conference on Aspect-oriented software development. ASOD ’04, Lancaster, March 2004, pp. 26-35. [17] Java. What is Java and why do I need it?. [Online] Available at: http://www.java.com/en/download/faq/whatis_java.xml [18] Kästner C. et al. 2007. “A Case Study Implementing Features Using AspectJ”. SPLC ’07 Proceedings of the 11th International Software Product Line Conference, pp. 223-232. [19] Kiczales, G. Aspect Oriented Programming: Radical Research in Modularity [Online]. Google TechTalks. Available at: http://www.youtube.com/watch?v=cq7wpLI0hco [Accessed: 8th July 2013] [20] Kiczales, G. et al. “Getting Started with AspectJ”. Communications of the ACM 44.10 (2001), pp. 59-65. [21] Kiczales, G. et al. 2001. “An Overview of AspectJ”. ECOOP 2001 – Object-Oriented Programming, pp. 327-354 : Springer Berlin Heidelberg. [22] Kiczales, G. and Mezini, M. 2005. “Aspect-oriented programming and modular reasoning”. Proceedings of the 27th international conference on software engineering, pp. 49-58 : ACM. [23] Laddad, R. 2003. AspectJ In Action. 2nd ed. : Manning, Connecticut USA. [24] Meyer, B. 1987. “Reusability: The Case for Object-Oriented Design”. Software, IEEE 4(2), pp. 50-64. [25] Miles, R. 2005. AspectJ Cookbook. 1st ed. : O’Reilly. [26] Millham, R. and Dogbe, E. 2011. “Aspect-Oriented Security and Exception Handling Within an Object Oriented System”. 35th IEEE Annual Computer Software and Applications Conference Workshop, pp. 321-326. [27] Munzo, F. et al. 2009. “Inquiring the Usage of Aspect-Oriented Programming: An Empirical Study”. IEEE International Conference on Software Maintenance, ICSM 2009, pp. 137-146. [28] Murphy, G.C. et al. 2000. “Separating Features in Source Code: An Exploratory Study”. ICSE '01 Proceedings of the 23rd International Conference on Software Engineering, pp. 275-284. [29] Murphy, G.C. et al. 2001. “Does aspect-oriented programming work?”. Communications of the ACM 44(10) (Oct. 2001), pp. 75-77. [30] Nino, J. and Hosch, F.A. 2008. Introduction to Programming and Object Oriented Design Using Java. 3rd ed. : Wiley. [31] Pokkunuri, B.P. 1989. “Object Oriented Programming”. ACM Sigplan Notices 24(11), pp. 96-101. [32] Ramakrishnan, R. and Gehrke, J. 2003. Database Management Systems. 3rd ed. : McGraw Hill. [33] Sebesta, R.W. 2013. Concepts of Programming Languages (International Edition). 10th ed. : Pearson. [34] The Saylor Foundation. 2013. “Advantages and Disadvantages of Object-Oriented Programming (OOP)” [Online]. Available at: http://www.saylor.org/site/wp-content/uploads/2013/02/CS101-2.1.2-AdvantagesDisadvantagesOfOOP-FINAL.pdf [Accessed: 23rd June 2013] [35] Tidwell, J. 2010. Designing Interfaces: Patterns for Effective Interface Design. 2nd ed. O’Reilly. [36] Tiobe Software. Tiobe Software: Tiobe Index. [Online] Available at: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [Accessed: 7th August 2013] [37] Wampler, D. 2007. “Aspect-Oriented Design Principles: Lessons from Object-Oriented Design”. Sixth International Conference on Aspect-Oriented Software Development (AOSD’07). [38] Zhao, J. 2002. “Slicing Aspect-Oriented Software”. Proceedings of the 10th International Workshop on Program Comprehension (IWPC ’02). Download 174.27 Kb. Share with your friends:
|