School of computer science and informatics, cardiff university
Download 174.27 Kb.
|
- Navigate this page:
- 7. AspectJ Design Implementation
- General Considerations
- SQL Related Aspects
- Static Crosscutting Program Rules
TestingAs stated in the methodology, Java testing would take the form of two approaches used when most appropriate. Unit testing was used for the logic behind the available actions, as well as classes designed to be persistence like “Customer”. Integration testing was used when the functions were combined over time with a test plan drawn up to ensure that navigation around the interface was correct, something which is not possible with unit testing. JUnit was used as the syntax for unit testing, which was used for areas of the program concerned with logic and storage. The first set of tests involved the creation of instances of classes which formed the data structure, asserting that the values passed through the setter methods were correctly assigned. Secondly, the SQL classes were supplied with test data, and executed queries and updates to the database related to their purpose, followed by checking the database using the MySQL Workbench [42] to double-check a valid query or update. Since each function was coded separately, some integration testing had to be used to test the action performed against the design requirement. This took the form of a test plan, which can be found in Appendix A, primarily concerned with the actions of the user when completing a task and the feedback from the program model, since GUI unit testing is considered difficult, as stated in the methodology.
Reading the research material, it was clear that there were many different uses of aspects available. The textbooks by Laddad [23] and Miles [25] were useful for guidelines on how to combine pointcut expressions, and gave inspiration for several of the aspects implemented. Both books, in my opinion, were very useful for beginners to the language, and indeed the paradigm. General ConsiderationsThe methodology used for the AspectJ design phase was split into two sections, addressing both identification of crosscutting concerns and testing the theory behind a potential aspect in isolation on a test environment. The identification section took the form of both drawing from the textbooks and papers read as background to this thesis, and refractoring the Java system for operations or behaviours which are repeated in multiple locations [28, p8]. From these identified aspects, in a separate Eclipse project, a series of experimental programs were created and tested to ensure that the theory behind the aspects functioned as intended, and also to check my ability in programming in AspectJ as a practical exercise. The latter was especially important due to the lack of experience I have with programming in an aspect-oriented way, and are included with submission of this thesis. Sticking to the best practice issues from the methodology, each crosscutting concern was modularised within one aspect. To avoid excessive importing of classes for the aspect code to use, the aspects were positioned in the same package as the classes primarily required, although some imports from Java libraries and other packages were required. SQL Related AspectsThe first crosscutting concern identified was validation, more specifically the validation of input data that would then be used within SQL queries or updates in the relevant objects. This aspect is an example of pre-condition validation [20]. There are eight methods in the Java version which achieve this functionality, some of which share parameter types and/or method names. In addition, there is significant replication of code, which is undesirable due to it being a drain on time and resources, especially if it were to occur in a larger system. As with the Java version, validation was subjected to matching against regular expression appropriate to the input. In addition to the two main pointcuts for validation, an additional three pointcuts dealt with execution of queries or updates involving instances of “Account”, “Staff” and “Transaction”. Whilst the advice associated to them is used only once currently, the pointcut designators include wildcards which will allow future modification of the base code without having to consider validation of the listed parameters, improving software evolution. For example, one feature that could be added is the addition of staff, which would require the same validation as when editing a staff member’s details. 
Figure : Validation Aspects and Method Pointcuts Another aspect from handling SQL within the system was the committing of changes to the database, or rolling back if errors occur. Most of the “…SQL” classes require these safeguards against invalid changes, and each repeats code for both tasks. Reducing redundant code is a benefit of using aspects, and therefore this concern was implemented separately from the base code in “Commit”, using after advice which checks the boolean result returned by the methods involved and then made the commitment or rollback of data outputted by the program, depending on the result’s value Static Crosscutting & Program RulesThe aspects discussed so far have been dynamic in form, i.e. their behaviour is performed during runtime, and also reacts to the user’s inputs. Static crosscutting concerns are concerns which are dealt with at compile time. One main example is implementation and extension declarations. This has been implemented in the AspectJ system in the “Extension” aspect, which provides a list of parent declarations. The “CustomerPanel” and “StaffPanel” classes extend “TablePanel”, and the definition for these has been placed in one file. For all classes which implement ActionListener, as well as declaring that this implementation takes place, the “Extension” aspect also forces a naming restriction upon the classes that can extend it, through the use of wildcards. These statements are described as introductions, and are classified by Hanenberg & Costanza [12] as direct ancestor and direct member introductions referring to interface and extension definition respectively. declare parents : *Listener implements ActionListener; Figure : Declaration of ActionListener child classes The statement in Figure puts an implementation constraint on any class which has a suffix of “Listener”, but does not require the rest of the name to be the same. This sets a naming convention for any further additions to the system, which is beneficial for readability and clarity of the purpose of that particular class, as well as consistency, although care should be taken as implementing this aspect required the renaming of the “TableListener” class to “TableMonitor” because it required implementation of ListSelectionListener. Having all extension definitions in one place makes it much clearer to the programmer what is being extended without having to search through source code, which is definitely useful for a larger program with hundreds of classes. When programming, it is important to lay out some ground rules of where certain objects can be defined. Inspired by the implementation of business rules by Laddad [23], the “NotThis” aspect achieves this in the system, but has been written solely to maintain security. The pointcuts associated with this are checking for constructor calls which are not made in a specified location. The disallowing of invalid instantiations prevents bypassing of security measures, such as logging in, and frames being displayed at the wrong time and potentially changing information in the database incorrectly. The constructor calls that are restricted are:
Any attempt to use these constructors in incorrect classes will result in an error message to the console or command line and the system exiting. Download 174.27 Kb. Share with your friends:
|