School of computer science and informatics, cardiff university
Download 174.27 Kb.
|
- Navigate this page:
- 8. Analysis
- Results of Surveying
TestingSince my experience with programming in AspectJ was minimal prior to developing this system, a strict testing policy was required to be confidence on an aspect’s errors or potential issues when weaved into the core concerns (Java classes). As listed in the methodology, testing took the form of both unit testing and integration testing, depending on the scenario. As stated previously, each aspect that was added to the system was hypothesised and implemented in a test program. Each of these was then tested separately (see Appendix B) on a series of test cases. In addition to the testing of the aspects, the interface was tested again, using the same test plan used for the Java system, listed in Appendix A. This was done because the methodology dictated that both systems should have the same functionality, as well as the same interface design, and therefore should pass the same integration tests. These two processes tested both the abilities of aspects and the weaving process and whether it was successful, whilst maintaining the same functionality. 8. AnalysisWith both versions of the same banking system complete, an analysis of aspect-oriented programming could commence. This assessment is split into three sections. The first is concerned with the opinions and information from the research carried out prior to programming4. Secondly, the responses from the questionnaire will give a present-day verdict on the paradigm, as well as addressing the key concepts of readability and comprehension. Looking at my own experience, the paradigm will be assessed in terms of software development, and the positive and negative factors of using it in a small-sized program, and interpolating the findings to a larger program. Finally, the findings should be compared back to the original hypothesis of this thesis to evaluate whether the experiment as met expectations. Results of SurveyingSince experience, in general, amongst computer scientists of using aspect-oriented techniques is low, it would have been foolish to survey them about programming a particular problem in AspectJ. So instead the focus was on readability and comprehension, both of AspectJ’s syntax and the control flow of object-oriented and aspect-oriented programs. Whilst no one who was surveyed had used aspect-oriented programming, having read the provided reading material they were all open to its potential. Some responders did need to read certain sections of the provided appendix again to help their understanding. Appendix D gives the questionnaire in full, and provides solutions to the practical questions, determined before any surveying commenced. Some surveying was conducted face to face, however due to time and availability of responders the majority were carried out in isolation. This fact will be taken into account, and no participants have been identified. The following table outlines the results of the questionnaire, according to the accuracy of the answers given for the practical based questions. Responses were grouped by the number of errors since each question had multiple parts to each answer and having a simple correct or incorrect system would not give a fair reflection since they are two contrasting results. Table : Results of Questionnaire
The first main question dealt with the syntax of pointcuts and whether their use and semantics were clear. On the whole, this question was answered quite well. The results showed that the AspectJ syntax is understandable for those with little experience, although there were some difficulties with understanding. Responders were given two examples of pointcuts from the source code in isolation, and asked to state their meanings based on the pointcut designators. This question was designed to establish the expressiveness of AspectJ’s syntax, and the examples were chosen to give as many different designators as possible, which totalled five types. One responder thought that they were given a method declaration and not a pointcut, which was slightly concerning, but still translated pointcut designators correctly. Many identified the logical operators included, and that an ActionEvent parameter was being captured by the pointcut correctly. Once syntax was introduced, the next stage of the questionnaire dealt with functionality and whether the control flow required was clear, asking to follow the control flow during the function of adding a transaction associated to an account. Responders were asked to identify the classes and methods involved with adding a transaction to the database, and whether they could identify the crosscutting concern involved. There was a difference between the number of correct responses for the Java and AspectJ questions, but the results for AspectJ were better than expected. The identification of the aspect related to the task of transaction was good, but could have been influenced by appropriate naming conventions used, which is something to bear in mind. The one incorrect response was from a face-to-face questioning, and was from a responder who got quite confused, although by their own admission they are not as confident with Java as others. Also with the AspectJ responses, nobody mentioned the “Commit” aspect, which handles commitment of database changes, which was surprising. Finally, responders were asked whether their opinions had changed after answering the rest of the questionnaire, as well as giving some benefits and disadvantages that they see with aspect-oriented use. In addition, responders were free to explore the supplied code to learn more. The opinions given did correlate with the experience the responder had with Java, one in particular said aspect-oriented programming would be a “good thing to strive towards” but would not use it at this moment due to their inexperience. This links in with the criticism that there is a higher level of understanding required. Seven responders did list a benefit as making the code easier to maintain, something which was only mentioned by two people after they had read the appendices provided, showing the advantage of experiencing code rather than just reading about the paradigm, and the removal of redundancy was also praised. One response asked the question “Is aspect-oriented programming actually any different?” and whether it would be worth investing the time into learning. Overall, one pattern that emerged was that those who had the most experience with Java were more able to comprehend aspect-oriented programming, as well as the syntax and structure of AspectJ code. This shows that the learning gap between the two paradigms may not be as large as some critics have believed. The number of responders was twelve. There were difficulties with finding people with enough time and at the right level of experience, but the result does give a strong indication on the factors being assessed. Download 174.27 Kb. Share with your friends:
|