Architecture: Business concept design layer

The business layer describes the classes responsible for representing domain concepts. Figure Architecture-Business-1 is a UML diagram showing the main concepts supported in the application.

Figure Architecture-Business-1: Main model concept in the business layer.

TrialSubjectModel is used to uniquely identify and filter activity records relating to trial subjects. It comprises a primary key field and several filter fields; all of the fields are instances of TextFieldModel. The following example shows the kind of values which may appear in the fields:

Primary Key: ("NHS Number", "456M03")
Filter Field: ("Location", "Manchester")
Filter Field: ("Gender", "Male")

Each TrialSubjectModel also has a collection of one or more TrialActivityModel instances. A TrialActivityModel is an activity comprising a primary key field (see TextFieldModel) and a sequence of date fields (see DateFieldModel). Both TrialActivityModel and DateFieldModel support the notion of an orderPosition. For TrialActivityModel, this field refers to the order in which an activity tab pane would appear to end-users. For DateFieldModel, the field supports the order in the sequence of steps. The following example shows what typical values may be in an activity:

Activity "ECG"
Order: 1
Primary Key: ("NHS Number", "456M03")
1. Date Field: ("Received Results", 04/FEB/2008)
2. Date Field: ("Backed up data files", "05/FEB/2008")
3. Date Field: ("analysed", "08/MAR/2008")
4. Date Field: ("sent to cambridge", "10/APR/2008")

TrialActivityModels use a static method detectTrialActivityChanges to compare the field values for original and revised instances of an activity record. The method generates a collection of TrialActivityChange instances which are used to provide an audit trail of changes made to records for a given trial subject. Each TrialActivityChange object records a trial subject identifier, the date of the change, a textual description of the userID of the person who made it.

Most of the validation in CST occurs in the validate(...) method in TrialActivityModel. By default, the method will recognise two kinds of errors:

the sequence of date values do not appear in descending order
date field values are preceeded by other blank date field values.

These validation checks can each be turned off using the TrialActivityModel setting values to false for variables enforceChronology and useStrictValidation respectively.

Most of the main classes implement Cloneable and Displayable interfaces. Cloneable is a marker interface which indicates that the class is making copies of itself. It is common for developers to override this method to provide a way that controls to what extent object members are copied. Invoking the clone() method of TrialSubjectModel will invoke the same method in TrialActivityModel which in turn calls the clone() method in sub-classes of AbstractFieldModel.

Displayable is an interface which is used by list-management routines. The interface has two methods:

	public String getDisplayItemIdentifier();
	public String getDisplayName();

The first method identifies an object in a way that benefits client code which simply wants a handle for a unique key. The second method identifies the object in a way that benefits human end-users. By having all the major model classes implement Dispayable, the application's user-interface code can treat them in a uniform manner.

TrialSubjectModel, TrialActivityModel and subclasses of AbstractFieldModel all recognise separate notions of a display name and a data storage name. The display name is intended to be understood by human end-users and the data storage name refers to the name of a table or field in the MySQL database.

Author: Kevin Garwood