Project History

Use Cases Scenarios
Use Case Requirements
Bugs and Known Limitations

User Manuals Getting Started
General Tour
Configuration Options
Logging Tool Tour
Administration Tool Tour

Developers Architecture
Analysis of Design
Creating Plugins
Future Enhancements

Future Enhancements

This page lists future enhancements we expect to make to the software in the near future.

FE-1: Add feature for simultaneously updating the same field in case study members chosen by the end-user

Currently users may change one record at a time or make mass changes by importing log data from a spreadsheet. Tim Gaysin identified a need to be able to update an activity step for multiple case study members selected through the Logging Tool. The following sequence of diagrams describe how the feature will be implemented will appear to data curators.

Step 1: A new menu item "Batch Update" will appear in the Options menu. Note that the words "case study" and "case studies" are terms which are defined in the configuration file. Users will select this option to begin updating the same activity step in multiple records they specify.

Step 2: In the first step of doing batch updates, users will specify which case studies they want to update. This will either be done by manually typing in a primary key identifier or by loading a single column text file containing lists of identifiers.

Step 3: Once users choose the case studies to update, they will specify the activity step that needs to be changed and a date value.

Step 4: If errors are encountered, then the errors will be displayed to the user and none of the changes to the database will be made.

Step 5: If no errors are encountered, then a dialog will appear, indicating how many records were updated.

FE-2: Enhance Performance

The versions of the Administration and Logging tools which work with a fake in-memory database were only intended to demonstrate prototypes. They were not intended to manage large-scale data sets. However, it is clear that demonstration services can use a lot of memory. Memory consumption could be greatly reduced if TrialActivityModel were modified.

Currently, TrialActivityModel has properties which serve two purposes:

These two types of properties were included in the same class for convenience. However, they should now be separated into two Java classes. TrialActivityModel should hold data but activities such as validation should make use of a new class TrialActivityProperties which would hold these properties:

TrialSubjectModelFactory will be modified so that the instances of TrialActivityModel used to hold activity data will refer to the same TrialActivityProperties object. This would be a great improvement over the current system, where thousands of TrialActivityModel objects will maintain their own copies of configuration fields.

FE-3: Improve error handling for configuration file errors

A future release will have improved handling of errors generated by the ConfigurationManager when it reads a configuration file. In particular, error handling will be improved to make it easier for developers to detect whether CST had problems initialising their plugins.

Author: Kevin Garwood

(c)2010 Medical Research Council. Licensed under Apache 2.0.