Design

Chapter overview

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.

Data access layer

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.

Database design

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

Data object design

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