Design

Since this is school project, we had to develop a design document for this project, the design document is now very out-dated, so I picked out some sections that are still relevant and post them here.

Entity Design

Object Model

  • Conference

    properties: conference_id, name, description, topic, location, start_date, end_date, url

    1. (has:) one or more editors
    2. (has:) zero or more reviewers
    3. (has:) zero or more authors
    4. (has:) zero or more submitted papers

    ====

  • Author

    properties: user_id, user_name, password, first_name, middle_name, last_name, affiliation, phone, email, addition_contact, create_date ^L

    1. (submits) zero or more papers

    ====

  • Reviewer

    properties: user_id, user_name, password, first_name, middle_name, last_name, affiliation, phone, email, addition_contact, create_date

    1. (reviews:) zero or more papers
    2. (associated with:) zero or more conferences

    ====

  • Editor

    properties: user_id, user_name, password, first_name, middle_name, last_name, affiliation, phone, email, addition_contact, create_date

    1. (associated with:) zero or more conferences

    ====

  • Paper

    properties: paper_id, abstract, title, keywords, status, original_paper, file_name, content_type, last_modified

    1. (submitted to): one conference
    2. (submitted by): one submitter

    ====

  • Review

    properties: review_id, recommendation, feedback, submitted_date, released

    1. (submitted by): one reviewer
    2. (submitted for): one paper

Entity Diagram

Entity Diagram

Database Model

Core Tables:

  • cms_conference
    conference_id - primary key
name - string:255
description - string:5000
topic - string:255
location - string:255
start_date - date (conference start date)
end_date - date (conference end date)
url - string:500 (conference url)
  • cms_user
    user_id - primary key
user_name - string:8-30
password - string:8-30
first_name - string:255
middle_name - string:255
last_name - string:255
affiliation - string:500 (e.g. Drexel University)
phone - string:255
email - string:255
additional_contact - string:5000
create_date - date
user_type – enum: “ADMIN”, “EDITOR”, “REVIEWER”, etc
  • cms_paper
    paper_id - primary key
abstract - string:5000
title - string:500
keywords - string:255
status – enum: "ACTIVE", "PUBLISHED", etc
content_type - string:255 (e.g. "content_type/pdf")
file_name - string:255 (original paper file name)
original_paper - Blob (binary object for storing the original paper)
last_modified - Date
user_id - fk<User.user_id> (user id of the submitter/author)
conference_id - fk<Conference.conference_id> (the conference this paper is submitted to)
  • cms_review
    review_id - primary key
paper_id - fk<Paper.paper_id> (the paper of this review)
user_id - fk<User.user_id> (the reviewer of this review)
recommendation - int<1~5> (publish recommendation, scale 1 to 5)
feedback - string:5000 
submitted_date - date
released - boolean (is the review released)

link tables:

  1. Many-to-Many relationship between editor and conferences: a conference can have 1 or many editors, an editor is associated with 1 or more conferences
  2. Many-to-Many relationship between reviewer and conference: a conference can have 1 or more reviewers, and a reviewer is associated with 1 or more conferences
  3. Many-to-Many relationship between reviewer and papers: a reviewer can review 0 or more papers, and a paper can be reviewed by 0 or more reviewers
  • editor_conference
    user_id - fk<User.user_id> (the editor's user id)
conference_id - fk<Conference.conference_id> (the conference id that the editor is associated with)
  • reviewer-conference
    user_id - fk<User.user_id> (the reviewer's user id)
conference_id - fk<Conference.conference_id> (the conference id that the reviewer is associated with)
  • reviewer-paper
    user_id - fk<User.user_id> (the reviewer's user id)
paper_id - fk<Paper.paper_id (the paper that is being reviewed)

Database Schema

Database Schema

Architecture Design Model

CMS uses a multi-tier design to divide the system into three layers: Presentation Layer, Domain Layer, and Data Layer. This layering architecture is a very common design pattern in data-driven software systems with well documented benefits. These benefits include:

  1. Minimizing dependencies between layers
  2. The option to substitute different implementation for a particular layer (e.g. clients can choose to use different RDBMS (Oracle, MySql, etc) to manage the data layers)
  3. Allowing each layer to be developed in parallel and allowing each layer to be developed and maintained by domain specialist (UI specialist, Database specialist, Business domain specialist).

    CMS is divided into the following layers given the fact that it performs the following three main tasks: gathering user input, storing the input as data, and manipulating the data as dictated by established operational procedures:

  4. Presentation Layer – The user interface or presentation tier. The user can input data, view the results of requests, and interact with the underlying system. CMS is a web-based application with a web-service component. Therefore, this layer contains both the web interface component and the web service component.
  5. Domain Layer – This layer encapsulate the system’s business logics. This involves maintaining data integrity, performing calculations based on inputs, and storing the input data to the data layer. CMS supports different user roles. Different user role is associated with different data access rules, these rules are enforced in this layer.
  6. Data layer – This layer includes a data management system (DBMS). With the current design of CMS, all data is managed and stored in a single database. It can be extended by adding additional data storages to ensure the scalability of the system.

Architectural Diagram

Architectural Diagram