Package cst.common.businessLayer

Describes the major business concepts used in the system.

See:
Description

Interface Summary

AdminServiceAPI	The service API that is used by the Admin Tool GUI.
CSTServiceAPI
LoggingServiceAPI	This is the main API that developers should use if they want to manage the data repository with another front-end (eg: a web application, web service, servlet).

Class Summary

AbstractFieldModel	Describes the common qualities of data fields used by both TrialSubjectModel and TrialActivityModel.
DateFieldModel	Manages the date value for an activity step for a given subject.
TextFieldModel	A field which holds a String value.
TrialActivityChange	Records a change that is made to a TrialActivityChange.
TrialActivityModel	An activity comprising a sequence of steps which are applied to each subject.
TrialSubjectModel	Represents a subject.
TrialSubjectModelFactory	Produces instances of TrialSubjectModelFactory.
User	A user of the applications.

Package cst.common.businessLayer Description

Describes the major business concepts used in the system. The major themes of this package are:

• provides a centralised place for describing business concepts
• centralises all validation routines that are not related to serialising or deserialising data in persistent storage.
• centralise code which detects changes between old and new instances of data container objects.

The most important class in this package is TrialSubjectModel, which represents a subject. Each instance has a primary key value, and attributes which can be used by the Logging Tool to filter subsets of subject records. These fields are represented by TextFieldModel.

A TrialSubjectModel has one or more activities represented by TrialActivityModel. Each of these in turn has a sequence of date fields, each represented by DateFieldModel. Note that common properties of both DateFieldModel and TextFieldModel are managed by their superclass AbstractFieldModel.

At startup, the ConfigurationManager reads the XML configuration file and defines the properties of a TrialSubjectModel. This template instance is then used by TrialSubjectModelFactory to create new instances of subject records.

The design anticipates that the multiple instances of the Logging Tool may be deployed as components within a client application. To minimise undesirable side effects of static methods, the factory does not use a Singleton pattern to control instantiation of factories. In general, classes in this package have the following characteristics:

• instances are used as data container objects which are mapped to corresponding tables in a MySQL database.
• they have a method for detecting changes between any two of its instances. This code is used to support the application's audit trail feature.
• they can clone themselves producing a deep copy. This feature allows the application to support notions of original and copy records that are used to support synthetic data persistence in the DemonstrationAdminService and DemonstrationLoggingService.

Much of the validation code in the application is centralised in the validate(...)TrialActivityModel.