School of computer science and informatics, cardiff university

Project Management

Figure : Backup File Storage

Once this methodology was completed, the design and implementation of both versions could start.

6. Java Design & Implementation

When designing the Java system, which also acts as the basis for the AspectJ implementation, to ensure the required functionality was included, the design was split into sections which would be combined in the final version. Each section represented a core functionality, which was then implemented separately, taking into account the popular Model-View-Controller design pattern [30, p989] for interface design. Due to the time constraints upon this thesis, less importance was given to the look of the graphical interface, as long as the design functions correctly and displays appropriate information to keep the user informed. Figure illustrates the stages of development and the progression of the integration of functions. Note that the data structure is kept separate because the classes involved are used in multiple blocks of the system, and were implemented and tested separately using unit tests before integrating with all previous blocks that require them. To help identification, classes associated with a particular role are given the same prefix, such as adding “Edit” to any class related solely with editing of customer and staff details.

Figure : Java Class Workflow

Modularity is a key aspect of object-oriented programming, and it is good convention to ensure classes only have the information necessary for their task. Classes should also be responsible for only one task, in order to promote strong cohesion, as well as having classes which have loose coupling, to reduce interdependence and coordination between classes. The structure of the base code of this system has been designed to address this, and to promote security of information and SQL connections. This is done by keeping key areas of the system apart, namely the graphical interface, the listeners which interpret the inputs from the GUI, and the classes which are responsible for database connections and queries. For example, the login screen is created in the “LoginScreen” class, which has a “LoginListener” keeping track of any user actions, and “LoginSQL” to query the database for a successful login procedure. The naming convention of added suffixes to indicate a class’s use is also useful for maintenance or for someone unfamiliar with the system to immediately follow its internal process, and has been maintained throughout the system.

Object-oriented programming promotes the use of inheritance, both to reduce excessive code and encourage reuse. When appropriate, this property has been implemented in the banking system. The main use of inheritance can be seen with the interface and its use of tables to display information on both customers and staff. It became apparent during the design phase that both JPanel instances required were, on the whole, offering the same functionality and requiring a similar layout for consistency purposes, although there were some differences in the actions possible, such as allowing transaction logging on the customer panel and promoting or demoting on the staff panel. This appeared to be a good position to use inheritance, which took the form of a superclass handling the creation of the table and its population, given parameters to indicate its role, and subclasses displaying information relevant for the superclass’s usage. In this case, the extension took the form of different buttons for the different actions.

Reusability is another concept encouraged in object-oriented programming. This is restricted, in the real world, by the domain that is being programmed in, and in this system there were not that many classes applicable to this concept. The main example is the “TablePanel” class; an abstract class which displays a table of information as well as default buttons for returning to a menu and refreshing the table. This abstract class is extended by “CustomerPanel” and “StaffPanel”, and has been designed to allow for flexibility in terms of the options available to the user, whilst maintaining a consistent layout style, and could be adapted for future panels, such as listing customers who are overdrawn on their account(s). Polymorphism, another of the best practice criteria, in which subclasses define their own behaviours whilst sharing functionality from the parent class, was also added to the Java system. Since “CustomerPanel” and “StaffPanel” extend the “TablePanel” class, and to exploit the power of polymorphism, instances of both child classes are stored as “TablePanel” instances in the “MainWindow” class.

Reuse is not restricted to code already within a given system, but also code from external sources which have proved successful. The “SpringUtilities” class [39] was used for “TransactionFrame” to allow for both a grid of labels and input methods, with a panel below with a series of buttons for user decisions. The class is not part of the standard Java libraries, and was included as the intended layout would have been more complicated as there would have to be at least two different Swing layouts, hence reducing the code required due to complexity.

One obvious consideration when designing the system was how the SQL connection would be managed, and passed through the relevant classes. Having multiple connections to the same database from the same system is clearly undesirable and needless, so one connection was maintained throughout from login to logout, or closure of the application. This was achieved through dependency injection, where instances are passed through as parameters and used, rather than creating a new local instance. Dependency injection was adhered to by only storing a copy of the connection in SQL classes; otherwise the connection is injected through parameters straight through the rest of the system. This adheres to one of the best practice criteria. The SQL system is handled using an external JAR file, downloaded from MySQL’s official website [40], another example of reuse.

Another criterion to follow for best practice was information hiding. All internal variables were declared as ‘private’ within objects, and any other object requiring a certain value must call the relevant getter method, with setter methods for some variables such as those within the data structure. Another key consideration when designing the data structure was security of information both coming from and being input into the database. Initially, key information was just passed through to methods using arrays and individual parameters. This is clearly not sensible, and against one of the best practice principles listed previously. The problem of security was solved by passing information through instances of classes, with setter and getter methods used to amend and access key information. These are the classes in the “structure” package.

Since this system should be secure, any SQL queries and updates must be implemented in safety against any hacking attacks. One such example is SQL injection, which is when a malicious SQL statement is inserted instead of the intended one. To avoid this, programmers are discouraged from using statements of the form of the first string in Figure . Instead, parameterisation is used, adding wildcard ‘?’ at any position a user input is required, using prepared statements, which stops embedding of user input, as seen by the second example.


“SELECT * FROM table_name WHERE table_attr = ” + input_var;

“SELECT * FROM table_name WHERE table_attr = ?”;

There were some interface design decisions based on making the use of the system easier, which in turn would aid the survey process. The “MainWindow” class was given a special kind of layout manager called “CardLayout”. This allows multiple panels to be added to the layout, and then for the user to transfer between them in one frame rather than needing popup windows when an associated button is pressed. This avoids unnecessary clutter on screen, but does require a button taking the user back to the main menu on each panel that is stored in the “MainWindow” class.

Another core functionality not covered previously is validation of user inputs, achieved using regular expressions, which were originally tested separately before being incorporated using example inputs, for postcode and email address validation. Regular expressions are widely used for the parsing of information and checking its validity, and it therefore seemed sensible to implement them for input validation, which is achieved using the built-in library. The tests are listed in Appendix A, and the code is found in the “sources” package, in “RETest”.

In Appendix E is a UML diagram of the class structure of this system (Figure ), and the source code is also supplied with this submission.