School of computer science and informatics, cardiff university
Graphical User Interface (GUI)
Download 174.27 Kb.
|
- Navigate this page:
- Logging
Graphical User Interface (GUI)Tidwell [35] said that one important consideration in interface design is to keep the user informed on what the system is doing, and some sort of confirmation for their actions. A widely used technique is popup messages after some sort of user input. In the case of the Java system, they were used to indicate success or failure of database updates, and giving reasons for these errors, some of which have already been considered with the validation aspect. Following this procedure for every section of code that could generate a popup window led to repeated code, which in many cases repeated the same informative phrase. This is definitely a cross-cutting aspect of the program, and was therefore placed in the “Popup” aspect. As far as possible, the displayed messages were kept the same as the Java system, with parameters such as staff and customer identification numbers obtained through the relevant pointcuts using the advice added to messages related to removal of staff and customers. While the addition of staff is not included in this development cycle, it would be one of the next requirements of the system, and the same functionality as adding customers would be required. This could be an extension in the future as another crosscutting concern. 
Figure : Popup Message Aspect A universal concern for all programs written in any language is exceptions, and this banking system is no different. In particular, focus was put on “SQLException” and exceptions from the validation of user inputs, as discussed previously, because these are the most frequent potential exception types. Once caught, a prompt should be displayed for the user to inform them on the state of the system. Millham and Dogbe [26] proposed a method of incorporating security measures in aspects as part of a system, with the aim of increasing modularity, reuse and centralisation of exception handling. Initially, I hoped that the aspect involved could replace all try-catch blocks in the system, giving a uniform approach to exception handling. However, when hypothesising and testing the idea, there were limitations, such as only being able to use before advice when using a handler as a pointcut. After experimenting with exception handling, including adding around advice for all advice in the “Validation” aspect, in the end the try-catch blocks had to remain in the code; however the code replicated in several catch blocks was removed and is now executed in aspects. It is more of a compromise than the original idea, but it is an area in which improvements could be made if time was available. According to the compulsory functionality set in the methodology, there must be a provision to deny access to certain options if a staff member was not ranked high enough. For this system, those options are removal and promotion or demotion of staff. Since AspectJ has provision for having constructors as pointcuts, this issue was chosen to test the abilities of the language. The aspect “Buttons” is used to add additional JButton instances to the GUI, when the user’s ranking is high enough. It makes use of the concept of inter-type declarations, by declaring variables for the “StaffPanel” rank (JButton instances) and then displaying them in the GUI. Doing this reduces the amount of memory required in instantiation of an instance of “StaffPanel”, which in the Java version defines the JButton instances which may or may not be used, but in the aspect they are only defined if required. Figure shows the sequence that the classes associated to this concern. This aspect could be reused in any future modification if features in the GUI are required for the highest rank only, such as the aforementioned staff removal function. 
Figure : Sequence Diagram for StaffPanel, using the Buttons aspect Since this system is displaying information, and also allowing access to change database values, the ability to refresh tables of information was paramount. This is in place in the Java version using the refreshTable() method in “TablePanel”, and it is called after every successful user action on the data. As this code is repeated in multiple places, an aspect to control table refreshing was identified, and placed in the “Refresh” aspect.
The logging to pointcut activity was particularly important whilst integrating aspects with the base code during testing. One design idiom for AspectJ is the “Abstract Pointcut” [10, p8], where a pointcut is defined at an abstract level and then extended by every aspect that requires that pointcut, as well as advice to be used for all instances. The “AbstractLogger” abstract aspect defines a pointcut called logPointcuts(), as well as before advice which adds a message to the log indicating entering the pointcut. A number of other aspects extended the “AbstractLogger” class, which were determined by their importance. These are shown in Figure . 
Figure : AbstractLogger extensions diagram Download 174.27 Kb. Share with your friends:
|