Architecture: Presentation design layer

The presentation layer manages the user interface code used to present the LoggingTool and AdminTool to end-users. Code in the LoggingTool GUI uses information in user requests to make calls to LoggingServiceAPI and GUI code in the AdminTool makes calls to AdminServiceAPI. None of the GUIs are aware how the data repository is implemented, an aspect of design which allows the tools to provide transparent support for both in-memory and database versions of the back-end.

When the tools are run in "demonstration" mode, the background colour of the panels appears in dark gray. When they operate in production mode, the forms have a typical light gray background colour.

All code related to supporting GUIs is found in these code packages:

cst.loggingTool.view
cst.loggingTool.view.reports
cst.adminTool.view

A few GUI convenience classes appear in package cst.util. The following sections describes important classes used to create the screens of each tool.

Logging Tool

Most of the classes used to generate the LoggingTool are defined in packages cst.loggingTool.view and cst.loggingTool.view.reports.

Main Dialog

The main dialog is provided by LoggingToolDialog. A collection of subclasses of AbstractMenu, DatabaseMenu, FiltersMenu, OptionsMenu, ReportsMenu, HelpMenu are responsible for managing the features in the corresponding menu options shown in the dialog. The NavigationBar class manages four main features:

a search field facility which causes the application to find a record with a given unique identifier
navigation buttons which cause the currently displayed record to change
a sub-panel which displays the ith index of some total number of trial subject records which meet the current filter criteria.
A message box which indicates what filter conditions are responsible for limiting the set of trial subject records being displayed.

Figure Arch-Presentation-1: Major classes responsible for making the user interface of the Logging Tool.

The main display area comprises a label indicating the primary key for the current trial subject and a JTabbedPane object for showing activity data. Each tabbed pane is rendered by a TrialActivityView , which presents data from a TrialActivityModel record.

A TrialActivityView comprises the following elements:

a title which appears in the title of a tabbed pane
a sequence of DateFieldView s which render the sequence of date fields and
CommentFieldView which allows users to specify notes relating the progress a trial subject makes in the activity of the currently displayed tab pane.

Activity Report Dialog

Change History Dialog

Figure Arch-Presentation-2: The main dialog for showing the history of changes made to the activity data for a trial subject. ShowActivityChangeHistoryDialog is responsible for creating the dialog the end-users see.

ShowActivityChangeHistoryDialog is the main class responsible for rendering the change history for a given trial subject. The JTable object in the main pane is a view for ActivityChangeTableModel which, expresses the fields of instances of TrialActivityChange in tabular form.

Admin Tool

Most of the code used to manage the user interface for the Admin Tool appears in the


cst.adminTool.view

package.

Main Dialog

Figure Arch-Presentation-3 shows the classes responsible for rendering the main screen of the tool. The tool sometimes invokes an editor (in the case of editing users) or calls the AdminServiceAPI object.

Figure Arch-Presentation-3: AdministrationToolApplication and AdministrationToolEditor

AdministrationToolApplication initialises the administration tool either through method calls or through command-line arguments. AdministrationToolEditor creates the main dialog for the tool. TransferTrialSubjectData is responsible for importing and exporting trial subject data. UserRegistryEditor is responsible for supporting the dialog used for editing users.

When users press "Change Administrator Password", or "Delete Database", AdministrationToolEditor calls createDatabase(...) and deleteDatabase methods in the implementation of AdminServiceAPI .

Note that the "Synchronise Database..." feature will be implemented in future releases.

User Editor Dialog

The dialog used to edit users of the system is provided by UserRegistryEditor and is shown in Figure Arch-Presentation-4.

Figure Arch-Presentation-4: UserRegistryEditor manages the dialog used to edit user accounts in the system

The class makes calls to addUser(...), deleteUser(...) found in AdminServiceAPI. UserRegistryEditor will also call UserEditor to let administrators edit the userID or password of an end-user.

Author: Kevin Garwood