This chapter explains how the design for the Online Project Marking System was formulated. It has been separated into three sections which discuss the design of the data access layer, control logic and user interface.
Firstly we will look at the design of the data access layer, responsible for the management and storage of the application’s data. There are two components of the data access layer to be considered:
1. The relational database providing persistent storage for the application’s data.
2. The data object layer which provides storage within the application for data which has been retrieved from the database.
We will look at the design of both components in the following subsections.
During the requirements analysis phase a number of problems were identified with the existing database implementation. The client supplied the database design created by the previous student [Reed (2005)] which had only been partially implemented in the existing database. The design provided storage for some of the categories of information identified in section 3.3.5 including student, staff and project data and marker allocations. It did not, however, provide a means of storing prize categories and nominations; nor did it supply an adequate means of recording mark form entries.
Appendix F contains the entire revised database design, which is comprised of 26 tables. In this section we will focus upon the particular aspects of the design which were key factors in meeting the software requirements.
The first main oversight in the original database design was to provide a means of indicating a project’s current position in the marking process (e.g. if it has been first or second marked, or both etc.). As Figure 3.1 (page 24) illustrates, there a number of different routes that a project can take through the marking process. The assignment of a status code to each project was seen as the best method for tracking its progression though the process. As Figure 4.1 shows, the key points in the marking process were identified and assigned unique status codes.
Figure 4.1 - Project marking status codes
Having determined the various project status codes, the design of the existing table FINAL_PROJECT (shown in Table 4.1) was revised to include a reference to the project’s status.
Attributes |
Compulsory Field |
Field Type |
Additional Information |
Project_ID |
Y |
Number |
Primary Key |
Other previously defined fields… |
|||
Project_Status |
Y |
Text (3) |
Current status of project in the marking process |
Table 4.1 - The revised FINAL_PROJECT table
In addition, a table entitled STATUSES (shown in Table 4.2) was defined so that a textual description could be associated with each status code.
Attributes |
Compulsory Field |
Field Type |
Additional Information |
Status_Code |
Y |
Text (3) |
Project status code |
Status |
N |
Text (100) |
Description of project status |
Table 4.2 - The STATUSES table
Another major issue to be addressed in the list of requirements was to provide a means of storing completed mark forms. The previous design attempted to satisfy this requirement by providing a table called MARKS to store a mark form’s overall mark and comments. The major oversight in this design was that the marks being assigned in each individual category were not being recorded. This information is needed so that previously submitted mark forms can be retrieved and displayed to the marker. The challenge in designing for this additional storage was that for each category, a marker can assign multiple marks which are averaged to calculate the overall mark for that category. So that this could be reflected in the database design, the table OPTION_MARKS (shown in Table 4.3) was created allowing multiple marks to be associated with a category.
Attributes |
Compulsory Field |
Field Type |
Additional Information |
Opt_Mark_ID |
Y |
Number |
Primary Key |
Mark_ID |
Y |
Number |
Refers to the mark session |
MFCID |
Y |
Number |
Refers to the mark category |
Mark |
Y |
Number |
Mark assigned |
Table 4.3 - The OPTION_MARKS table
In addition to storing every mark assigned to a particular category, a means of storing the overall mark and comments for each category was required. This was achieved by creating a second table called CATEGORY_MARKS (shown in Table 4.4).
Attributes |
Compulsory Field |
Field Type |
Description |
Cat_Mark_ID |
Y |
Number |
Primary Key |
Mark_ID |
Y |
Number |
Refers to the mark session |
MFCID |
Y |
Number |
Refers to the mark category |
Mark |
Y |
Number |
The overall mark assigned |
Comment |
N |
CLOB (Character large object) |
Marker comments |
Table 4.4 - The CATEGORY_MARKS table
Another requirement of the new system was to increase the flexibility of the project mark form so that different marking scales could be applied in each mark category. In order to satisfy this requirement, additional storage was needed to hold the marking scales. The challenge in designing for this requirement was to find a way of storing mark scales so that they could be reused by multiple categories. This was achieved by defining a table called CATEGORY_OPTIONS_GROUP (shown in Table 4.5) which identifies a group of related options which make up a mark scale. A second table, CATEGORY_OPTIONS (shown in Table 4.6) was created to store each individual option.
Attributes |
Compulsory Field |
Field Type |
Additional Information |
COG_ID |
Y |
Number |
Primary Key |
COG_Desc |
N |
Text (100) |
Used to describe the mark scale (e.g. “100% - ten brackets”) |
Table 4.5 - The CATEGORY_OPTIONS_GROUP table
Attributes |
Compulsory Field |
Field Type |
Additional Information |
CO_ID |
Y |
Number |
Primary Key |
COG_ID |
Y |
Number |
Foreign Key – To CATEGORY_OPTIONS_GROUP.COG_ID Identifies the mark scale that the option belongs to |
CO_Index |
Y |
Number |
The order in which options should be displayed |
CO_Label |
Y |
Text (30) |
The label to be displayed for the option (e.g. “Very Good” or “50%”) |
CO_Selected _Value |
Y |
Number |
The mark awarded when the option is selected |
Table 4.6 - The CATEGORY_OPTIONS table
A further means of adding flexibility to the mark form was to allow criteria to be associated with each point on the mark scale. This information could be used to provide guidance to markers when completing the mark form. Since the criteria would vary depending on the category being marked, an additional table called OPTION_CRITERIA (shown in Table 4.7) was defined.
Attributes |
Compulsory Field |
Field Type |
Additional Information |
Op_Cri_ID |
Y |
Number |
Primary Key |
Option |
Y |
Number |
Foreign Key – To CATEGORY_OPTIONS.CO_ID Identifies the option the criteria relates to |
Mark_Category |
Y |
Number |
Refers to the mark category the criteria relates to |
Op_Cri_Positive |
N |
Text (512) |
Positive criteria which suggests that the mark should be assigned |
Op_Cri_Negative |
N |
Text (512) |
Negative criteria which suggests that the mark should be assigned |
Table 4.7 - The OPTION_CRITERIA table
Having extended the database design to provide variable mark scales, the structure of one of the original tables - MARK_CATEGORIES (shown in Table 4.8) required revision so that each category could be associated with a different marking scale. Also, to provide further flexibility, a field was defined called Option_Type to indicate the input method to use for the marking scale (e.g. radio button, check box or drop-down box).
Attributes |
Compulsory Field |
Field Type |
Additional Information |
CatID |
Y |
Number |
Primary Key |
CatName |
Y |
Text (30) |
Category name |
Other previously defined fields… |
|||
COG_ID |
Y |
Number |
Foreign Key – To CATEGORY_OPTIONS_GROUP. COG_ID Identifies the mark scale to use for the category |
Option_Type |
Y |
Char |
R – Radio, S – Drop-down, C – Checkbox Identifies the input method to use for the mark scale |
Table 4.8 - The revised MARK_CATEGORIES table
It was also necessary to review the structure of the newly designed table OPTION_MARKS shown in Table 4.3. Previously, when using a fixed marking scale, the best approach for recording the marks for each category seemed to be to store the actual marks being assigned. However, with a number of different marking scales now being available it was considered more appropriate to identify the option which has been selected as opposed to the value which has been assigned. Table 4.9 shows the revised design for the OPTION_MARKS table.
Attributes |
Compulsory Field |
Field Type |
Additional Information |
Opt_Mark_ID |
Y |
Number |
Primary Key |
Mark_ID |
Y |
Number |
Refers to the mark session |
MFCID |
Y |
Number |
Refers to the mark category |
CO_ID |
Y |
Number |
Foreign Key - To CATEGORY_OPTIONS.CO_ID Identifies the selected option |
Table 4.9 – The revised OPTION_MARKS table
Now that we have looked at some of the particular aspects of the database design, Figure 4.2 illustrates the overall design. Tables which have been taken from the previous design have been indicated and a full specification of every table can be found by referring to Appendix F.
Figure 4.2 - Database table relationships
In addition to the database, it was necessary to design a number of data objects. Data objects provide a means of storing data in the application state once it has been loaded from the persistence layer. The two primary data objects to be defined for this application were for project and mark form data. The data objects, which mirror the tables of the database to a certain extent, are illustrated in Figure 4.3.
Figure 4.3 - Data object structure