To ensure that both aspect-oriented and object-oriented paradigms are compared evenly, there should be a methodology designed to promote their best use, as well as maintaining a consistency of functionality offered by both versions of the banking system. This section outlines the approach and methodology used for this thesis.
It was important to start with a series of rules to follow in the development of Java and AspectJ programs, which are outlined here. Since this thesis concerns a direct comparison of two paradigms, it is important that both systems are comparable. To make an effective assessment, both versions must share a set of common functionality which is appropriate to the domain. There should also be adherence to the best practice of both paradigms, drawn from a variety of sources. It should be recognised that there is a limited timeframe for development of both systems, and therefore there is a limit of four weeks for development of each system, which gives enough leeway for any problems during implementation. A variety of potential tools are available for running both Java and AspectJ programs. The one chosen for this experiment was Eclipse. This is a familiar development environment for me, and since I have not had experience with using AspectJ, it was important to select a tool that was both recognisable as well as easy to use when developing in an aspect approach. It was also obvious that some sort of external storage would be required for data to be displayed and manipulated using both systems. The most secure method would be through using an external database, and using SQL as the querying language. This would require some time for designing an effective relational database, but would be much more secure than having the database as part of the final, compiled programs. In addition, both versions of the code would need compilation into runnable JAR files for evaluation purposes.
To enable a more exact comparison between object-oriented and aspect-oriented paradigms, both versions of the banking system must implement the same core functions associated with the domain of banking management, key requirements that are the most important uses of a real-world system, whilst considering the amount of time available for development. A variety of different functions also allows for different ways of using the aspect-oriented development process. Activity diagrams for some of the functionality listed can be found in Appendix E, with figures indicated next to the associated functionality when appropriate, and mock-ups of the interface design are shown in Appendix F. The core functions are as follows:
A provision for both logging in and out of the system safely
Maintaining a single MySQL connection between the program and the external database (stored using university servers)
Allow for editing details, as well as addition and removal of customers and staff, some of which will only be accessible by certain levels of staff privilege/rank. (Figure , Figure )
Allow transactions to be logged, which may involve rolling back any database changes if the transaction cannot be completed. (Figure )
Appropriate validation must be enforced, ensuring correct formatting of input, using regular expressions. (Figure )
Sensitive data should be stored securely, especially when transferring from the graphical interface to the “controller”.
Since this experiment is concerned with direct comparisons, both paradigms should be shown in their best light, with both design and implementation adhering to the best practice of each paradigm. These are listed below, and were thoroughly researched through textbooks and research papers, particularly for AspectJ as there is much less guidance of this issue due to the fact that it is still a relatively young language when compared to Java, so much so that most of the criteria for Java is common knowledge to the majority of computer scientists. There are also best practice criteria to follow with the development of an SQL database.
Object-Oriented Programming (Java)
Classes should only have information necessary to their responsibility, and should be restricted to one use only. For example, classes involved in listening for user actions should be separated from code for the user interface.
Use of object-oriented programming’s inheritance property should be made use of, when appropriate. This allows for a reduction in repeated code and promotes reuse.
Information hiding should be maintained, protecting autonomous objects from external classes and methods , restricting against unintended changes.
Polymorphism should be promoted, where appropriate, allowing for the ability to replace an object with its sub-objects
Use of dependency injection; if an instance of an object is required, it should be injected through method parameters, rather than creating one internally
The passing of sensitive information should be through classes and not directly, such as through arrays. This makes the program more secure.
Classes should be open for extension, but not for modification
Aspect-Oriented Programming (AspectJ)
Since aspects are very similar to classes [22, 37], an aspect should only be responsible for one crosscutting concern, but may include a number of pointcuts if required.
The keyword “privileged” should not be a default, and should only be used if necessary.  For example, the extension of a class and use of inter-type declarations would be an appropriate use of this keyword. This avoids unintended changes to the source code and invalid access to variables.
Reuse should be encouraged, through the use, for example, of abstract aspects  and wildcard fields.
Package any aspects used in packages with relevant Java classes, for example, any SQL related aspects should be inside a package with classes querying the database. This promotes dependencies of aspects being placed in similar packages. 
Whilst being mindful of guideline III, wildcards in pointcut designators should be used only when appropriate, to prevent unintended errors such as advising incorrect join points.
Avoid, where possible, two pieces of advice being executed for the same pointcut, to both promote reusability  and avoid confusion when introduced to survey responders. Note that there may be behaviours that require this.
Protect the system against SQL injection attacks, through the use of prepared statements.
Avoid redundancy within the database but promote normalisation , where a single piece of information should be in only one place in the database.
Divide data into subject-based tables, whilst avoiding more than one use for one table, e.g. storing a staff member’s password with the rest of their details.
The database must be external, for security reasons.