Detail
Design
Client:
Dr. Darren Lim, Assistant Professor
Project: Java
Online Learning Tool (J.O.L.T.)
Delivered
by: 518 Interactive
Team Members:
Erik Stegmann
Lawrence Gregory
Connor Vander Bogart
Jedidiah Turnbull
Christopher Hughto
Revision: 1.0
Date: 3/08/2010
Contents
1.4 Product
Overview and Summary
2.2 Functional
Requirements Inventory
2.2.1 Functional
Requirements: Student:
2.2.2 Functional
Requirements: Faculty:
2.2.3 Functional
Requirements: Course Coordinator:
2.2.4 Functional Requirements:
Administrator:
2.3 Non-Functional
Requirements
3 Architectural
Design Specification
3.1 Development,
Operating, and Maintenance Environments
3.4.4 Course
Coordinator Web Site Map
3.4.5 Administrator
Web Site Map
4 External
& Internal Design Specification
4.1 User
Screens with respective User Command Summaries
4.2.3 Student
Registration Page
4.2.4 Student
Registration Page (Error Message – Invalid Fields)
4.2.5 Student
Registration Page (Error Message – Invalid Email)
4.2.6 Student
Registration Page (Completed)
4.2.12 Course
Enrollment (Invalid PIN)
4.2.13 Course
Enrollment (Completed)
4.2.15 Student
Section Home (Populated)
4.2.18 Student
Solution Attempt (Compile Error)
4.2.19 Student
Solution Attempt (Incorrect Output)
4.2.20 Student
Solution Attempt (Timeout)
4.2.21 Updated
Problem Set Overview Screen (Navigate Away)
4.2.22 Student
Solution Attempt (Completed)
4.2.23 Updated
Problem Set Screen
4.3.1 Faculty
User Case Narrative
4.3.7 Create
Problem (Invalid Field)
4.3.8 Create
Problem Compiler Error
4.3.9 Faculty
Sandbox (Unpopulated)
4.3.10 Faculty
Sandbox (Populated)
4.3.13 Create
Problem Set (Error)
4.3.14 Create
Problem Set (No Problems Added Error)
4.3.15 Create
Problem Set (Completed)
4.3.16 Edit
Problem Set (Completed)
4.3.17 Activate/Assign
Problem Set
4.3.19 Create
Announcement (Add Recipients)
4.3.20 Create
Announcement (Missing Field)
4.3.21 Create
Announcement (Complete)
4.3.23 Edit
Gradebook (Editing)
4.4.1 Course
Coordinator User Case Narrative
4.4.2 Course
Coordinator User Screens
4.4.2 Course
Coordinator Home Page
4.4.6 Create
Course Section (Error)
4.4.2 Edit
Gradebook (Editing)
4.4.2 Create
Problem (Invalid Field)
4.4.3 Create
Problem Compiler Error
4.4.1 Course
Coordinator Sandbox (Unpopulated)
4.4.2 Course
Coordinator Sandbox (Populated)
4.4.5 Create
Problem Set (Error)
4.4.6 Create
Problem Set (No Problems Added Error)
4.4.7 Create
Problem Set (Completed)
4.4.8 Edit
Problem Set (Completed)
4.4.9 Activate/Assign
Problem Set
4.4.11 Create
Announcement (Add Recipients)
4.4.12 Create
Announcement (Missing Field)
4.4.13 Create
Announcement (Complete)
4.4.15 Accept
Private Problems to Course Pool
4.4.17 Create
Announcement (Add Recipients)
4.4.18 Create
Announcement (Missing Field)
4.4.19 Create
Announcement (Complete)
4.5.1 Administrator
User Case Narrative
4.5.2 Administrator
User Screens
4.5.6 Create
Course Coordinator
4.5.13 Edit
Gradebook (Editing)
4.5.15 Create
Problem (Invalid Field)
4.5.16 Create
Problem Compiler Error
4.5.17 Course
Coordinator Sandbox (Unpopulated)
4.5.18 Course
Coordinator Sandbox (Populated)
4.5.21 Create
Problem Set (Error)
4.5.22 Create
Problem Set (No Problems Added Error)
4.5.23 Create
Problem Set (Completed)
4.5.24 Edit
Problem Set (Completed)
4.5.25 Activate/Assign
Problem Set
4.5.27 Create
Announcement (Add Recipients)
4.5.28 Create
Announcement (Missing Field)
4.5.29 Create
Announcement (Complete)
4.5.1 Accept
Private/Course Problems to Global Pool
4.6.15 Graphical
Representation Key
4.6.16 Graphical
Representation (Entity Relationship Diagram)
5.1 Appendix
1: Sources of Information
5.2 Appendix
2: Glossary of Terms
5.3 Appendix
4: Current Timeline
This
document finalizes the software requirements identified for the Java Online Learning Tool (J.O.L.T) for
the client, Dr. Darren Lim, Assistant Professor of the Computer Science
Department of Siena College. The
software requirements have been previously defined in the Software Requirements
Specification (SRS) document as well as the Preliminary Design document;
however, the requirements defined within this document supersede those of the
previous documents.
This
document also formally defines the final user interface for J.O.L.T.
The interface is organized by user type, starting with Student, then
progressing to Faculty, then Course Coordinator, and finally
Administrator. The user-specific
interfaces are laid out in a sequential manner, starting with the first task a
user completes to the last task a user completes.
This
document serves these main purposes:
·
To
provide a finalized interface design for all users of J.O.L.T.
·
To
provide a complete Requirements Inventory.
There
are several supplementary documents to this design document, which are
available under the “Documents” menu of the 518
Interactive Website. These documents
include:
·
Data Flow Diagram Document:
Provides a graphical representation of how data is transmitted and
manipulated within J.O.L.T.
·
Activity Diagram Document: Provides a graphical
representation of how specific tasks are accomplished within J.O.L.T.
·
Data Dictionary: Provides a repository of all
the data entities that J.O.L.T utilizes.
·
Test Plan Document: The Test Plan Document outlines
the testing that is to be done to see if J.O.L.T meets all requirements.
NOTE: All screenshots provided in this
document are intended to be final in design and functionality, however, 518
Interactive reserves the right to modify the actual user interface of the final
product (J.O.L.T) on an as-needed basis, with consent of the client, Dr.
Lim. Such changes shall be documented on
the 518 Interactive website.
NOTE:
All
references to Source Code imply Java™
Source Code, made to work with Java™ Version 1.6
The
requirements and screen designs in this document comprise the scope of J.O.L.T’s requirements and
interface. This Detailed Design document
supersedes any prior documents as the descriptor of J.O.L.T’s requirements and interface design.
This
document is intended for 518 Interactive,
Dr. Lim, members of the Spring 2010 Software Engineering II class, and the
other clients, Dr. Lederman and Dr. Breimer.
The
proposed Java Online Learning Tool (J.O.L.T)
is a comprehensive web application designed to enhance the experience of
learning the Java programming language.
J.O.L.T shall allow for students enrolled in programming courses to
solve programming problems, which are created and entered by the Computer Science
faculty. J.O.L.T shall provide a
personal gradebook for all students, as well as a course gradebook for Computer
Science faculty members which will be used to track progress.
The
following list outlines the required functionality to be included in the final
solution.
Java
Online Learning Tool will be a web-based application viewable on the major
browsers. Browsers included will be Internet Explorer 8, Mozilla Firefox,
Safari, and Google Chrome.
All
references to Source Code imply Java™
Source Code, made to work with Java™ Version 1.6
The
requirements are listed according to User Type, as follows:
·
Will
be able to register online with the system
o
Will
receive email confirmation following registration
·
Will
be able to log into system.
o
A
failed log in will display an appropriate error message.
o
A
link to an identity validation page will be provided if password is forgotten.
o
3
Failed login attempts will lead to system lockout.
·
Will
be able to enroll into courses they are currently taking
o
PIN
number provided by instructor required to enroll into course on the system
·
Will
be able to view announcements sent to them.
o
Will
be able to delete their announcements
·
Will
be able to view problem sets for each course they are in enrolled in
o
Will
be able to view each individual problem within the problem set
o
Will
be able to view hints and solutions to individual problems, if provided by
problem creator.
·
Will
be able to submit solutions to individual problems within active problem sets in
the form of Java™ source code
o
Code
will be compiled by the system online
o
Student
will receive immediate, automatic feedback on compile errors, if any
o
Student
will receive immediate, automatic feedback on how their solution compares to
the test cases
·
Will
be able to complete problem sets
o
Will
be able to navigate to individual problems in a problem set without completing
them in a specific order
o
Will
be able to save any progress made for a problem or problem set
·
Will
be able to view grades for each assignment in each class they are enrolled in.
·
Will
be able to view all previously submitted solutions
o
Will
have access to their solutions and grades for all prior classes they were
enrolled in.
·
Will
be able to log out
·
Will
be able to log into system.
o
A
failed log in will display an appropriate error message.
o
A
link to an identity validation page will be provided if password is forgotten.
o
3
Failed login attempts will lead to system lockout.
·
Will
be able to create individual problems
o
Individual
problems that are partially completed by faculty are saved to a sandbox area,
until they are complete.
§
Once
complete, problem gets transferred to private pool.
·
Will
be able to create problem sets
o
Will
be able to import previously created problems to a problem set
o
Will
be able to import problems from the course pool to a problem set
o
Will
be able to import problems from the global pool to a problem set
o
Will
be able to individually create each problem for a problem set
·
Will
be able to assign problems they create to a category
·
Will
be able to assign a grading scheme to problem sets
o
Will
be able to assign a point value to specific problems within the problem set
·
Will
be able to assign problem sets to the sections they teach
o
Will
be able to set activation date and time of problem set
o
Will
be able to set expiration date and time of problem set
·
Will
be able to submit problems to a Course Pool
·
Will
be able to search a Course Pool for problems
·
Will
be able to search the Global Pool for problems
·
Will
be able to view a grade book for each of the courses
·
Will
be able to modify grades for all students in each of the courses they are
currently teaching
·
Will
be able to post announcements to students in their courses
·
Will
be able to view announcements sent to them.
·
Will
be able to log out
·
Will
be able to log into system.
o
A
failed log in will display an appropriate error message.
o
A
link to an identity validation page will be provided if password is forgotten.
o
3
Failed login attempts will lead to system lockout.
·
Will
be able to create faculty accounts
·
Will
be able to assign faculty to a section
·
Will
be able to create problems and problem sets for courses they are in charge of
o
Individual
problems that are partially completed by Course Coordinators are saved to a
sandbox area, until they are complete.
§
Once
complete, problem gets transferred to private pool.
·
Will
have access to course tools which will provide statistics on problems and
grades for a course
o
Will
be able to create reports over multiple sections of a course involving all
problems and problem sets or any subset thereof.
o
Reports
may include general statistics such as number of participants, average score,
median, low score, and high score.
·
Will
be able to manage the course pool for each course they are in charge of
o
Will
be able to add, modify, or delete any problem in their course pool
o
Will
be able to submit problems to the global pool
·
Will
be able to modify grades for all students currently enrolled in a course they
currently manage
o
Will
be able to keep track of all grades and any adjustments that are made
·
Will
be able to create announcement for all faculty and students of courses they
manage or any subset thereof
·
Will
be able to log out
·
Will
be able to log into system.
o
A
failed log in will display an appropriate error message.
o
A
link to an identity validation page will be provided if password is forgotten.
·
Will
be able to manage all accounts on the system
·
Will
be able to create course coordinator and faculty accounts
o
Will
be able to assign courses to course coordinators
·
Will
have the same abilities as a course coordinator
·
Will
be able to manage the global pool of problems
·
Will
have access to tools for management of all accounts
o
Will
be able to modify all account information for any user
o
Will
be able to delete accounts
o
Will
be able reset locked accounts
·
Will
be able to create announcements for all course coordinators, faculty and
students, or any subset thereof
·
Will
be able to log out
·
Will
accept and attempt to compile all Java™ source code submitted by students
o
Will
output compile errors, when applicable
o
Will
create Java™ Byte Code upon a successful compilation
·
Will
execute all successfully compiled Java™ solutions
o
Will
monitor students’ submissions while they are running for runtime errors
o
Will
kill a student’s submission if it takes too long to run (Timeout)
·
Will
record the output generated from the students’ submissions
A
non-functional requirement is a requirement that specifies criteria that can be
used to judge the operation of a system, rather than specific behaviors. They are typically used to describe the
qualities of a system. Given this
definition, there is no concrete way to measure whether or not a non-functional
requirement has been met.
Non-Functional
requirements have not been formally defined for J.O.L.T.
J.O.L.T
will be developed in Siena College’s Software Engineering Lab, located in Roger
Bacon, third floor. The members of 518 Interactive will be using the
following resources:
Windows
Machine:
·
Operating System: Microsoft Windows Vista
Enterprise
§
Build:
6002
§
Revision:
18005
§
Service
Pack 2
·
Processor: Intel® Core™2 Duo CPU
§
Model: E7500
§
Speed 2.93 GHz
·
Memory (RAM): 4.00 GB
·
System Type: 32-bit
·
Dual Monitor Setup
·
Software Installed:
§
Microsoft
Office 2007 (Including Microsoft Project)
§
Macromedia
Dreamweaver, Fireworks, Flash , Freehand, Studio (2004 Versions)
§
Internet
Explorer, Mozilla Firefox, Google Chrome
Macintosh
Machine:
·
Operating System: Apple Mac OS X
·
Version
10.4.11
·
Model:
iMac5
·
Processor: Intel Core2 Duo
§
Speed:
2 GHz
·
Memory (RAM): 1.00 GB
·
Dual Monitor Setup
·
Software Installed:
·
Microsoft
Office 2004 for Mac
·
Macromedia
Dreamweaver, Fireworks, Flash, Freehand, Studio (2004 Versions)
·
Safari,
Mozilla Firefox
J.O.L.T will be implemented, and
designed to run on the following specifications:
·
Operating System: CentOS (Linux) Release 5.2
(Final)
·
Server Name: oraserv.cs.siena.edu
·
CPU Type: x86_64
·
Web Server: Apache Version 2.2.9
·
PHP Version: 5.2.6
·
Database: MySQL Version 5.0.45; Oracle
Version 9i
·
Java™ Version: 1.6.0_10-rc
·
Java™ SE Runtime Environment: Build 1.6.0_10-rc-b28
·
Java HotSpot™ 64-Bit Server VM: Build 11.0-b15, mixed mode)
Users of J.O.L.T will be able to access
the web application through an Internet connection, with any of the following
browsers (of the latest version):
· Microsoft
Internet Explorer
· Mozilla Firefox
· Apple Safari
· Google Chrome
· Opera Software’s
Opera Browser
The
production environment is the set of hardware, software, and tools that a
system will run on. J.O.L.T is planned
to be run on Siena’s oraserv server (oraserv.cs.siena.edu), which has the following
characteristics.
·
Operating System: CentOS (Linux) Release 5.2
(Final)
·
Server Name: oraserv.cs.siena.edu
·
CPU Type: x86_64
·
Web Server: Apache Version 2.2.9
·
PHP Version: 5.2.6
·
Database: MySQL Version 5.0.45;
·
Java™ Version: 1.6.0_10-rc
·
Java™ SE Runtime Environment: Build 1.6.0_10-rc-b28
·
Java HotSpot™ 64-Bit Server VM: Build 11.0-b15, mixed mode)
Deployment
Diagrams are a Unified Modeling Language (UML) based diagram used to show
devices and execution environments for a system. It represents the physical layout of the
System. The Deployment Diagram for J.O.L.T
below shows the different browsers connecting via HTTP to J.O.L.T. It also shows the Development Environment
connecting via SCP. Finally J.O.L.T is
using various components and devices such as a database, and temporary
directory.
Dropbox
is a file sharing utility that 518 Interactive uses as a source control
mechanism during development. It stores
the ‘Test’ version of the site, which automatically synchronizes all connected
computers. This ensures that all
developers have the most up-to-date source code at all times.
PHPMyAdmin
is a web-based database manager. It
allows the development team to easily view and alter the contents of the
J.O.L.T database through a web browser using a graphical interface. There is currently a version of PHPMyAdmin installed
on oraserv.cs.siena.edu under 518 Interactive’s account.
A Web
Site Map is a diagram that shows the structure of a website. It allows the user to see the functionality
available at any part of the site. The
following elements are used to build a Web Site Map:
Home Page: Denotes the main page for each
user within J.O.L.T.
Home: Denotes the initial page that
all users see when navigating to J.O.L.T.
Overlay/Dialog: Denotes a window that appears
within the current page (Not blocked by popup blockers)
Web Page: Denotes a generic page within J.O.L.T.
Page Redirect: Denotes a forced change (by J.O.L.T)
in where the user is within the system.
Link: Shows links on a given Web Page.
Possible Page Result Link: Denotes a
page that a user *may* see, depending on conditions within the page they are
currently on.
Part of Common Header: Denotes pages that are common to
all users, regardless of position within the diagram.
This
shows the initial pages for J.O.L.T. All
subsequent Web Site Map diagrams show the User Home Pages broken down.
Unless
otherwise specified, all screenshots which are depicted in browsers are taken
with Mozilla Firefox Version 3.60
The
screens provided within this document are intended to be final in terms of
appearance and functionality, however, 518 Interactive reserves the right to
modify the appearance and/or functionality of any screen as long as:
Note: User Command Summaries appear
under each screenshot in this section.
Students
shall have the ability to register an account with the System. Once registered, students will be able to log
into the system via their unique username and password. Once logged in, students will be able to
enroll in only the courses they are currently taking. Students will have the ability to view
problems in a categorized manner.
Students will also be able to take exams and solve individual problems
created by their instructor. Students
will be able to solve problems by submitting Java source code, which the system
will compile and run against provided test data. While solving a set of
problems, students will be able to navigate from problem to problem without
completing them in a specific order. Students will be able to save their
progress for any individual problem and work on it again during a later
session.
Students
will have a report card view which will allow them to view their own grades and
progress in all current and past courses.
Students will be able to browse all of their own solutions as well.
This is
the initial screen that Students will be presented with when they navigate to J.O.L.T. It prompts for a username and password, and
provides a link for registration and forgotten password. As well as links to
the “About” and “Support” pages.
This is
the screen that Students will be presented with when they click the “Register”
link on the Login Page. Students are
asked to provide information that is required to register with J.O.L.T. By
clicking on “Register” with all of the correct fields the user ‘s account will
be created in the database. At the top, Home will take the non-logged in user
back to the home Log in Page. The “About” button will allow the user to view
information pertaining to the objectives of J.O.L.T and its creators. Clicking
the “Support” button will provide the user with information if they are
encountering any difficulties.
This is
an example of an error message that Students would see if they fail to fill out
all fields for registration. All functionality remains the same as the original
registration page.
This is
an example of an error message that Students would see if they fail to provide
a valid email address. All functionality
remains the same as the original registration page.
This is
a confirmation overlay that is displayed to Students when they successfully
provide all required fields for registration.
A confirmation email is sent to the email address that they provided.
This
error message will appear when a Student user enters an incorrect Username.
This is
what the Student will see after entering a valid username and invalid
password. This screen indicates that the
Student has 1 more login attempts before their account is locked out.
This
screen appears when a Student user has too many incorrect login attempts for a
particular username, and is locked out of the system.
This header appears on all pages that the user has. The “Home” button brings the user to their homepage, the “Profile” button brings them to their profile page, the “Support” button brings them to a support page where they can get assistance, and “Log Out” will terminate the user’s session with J.O.L.T. This header functionality is common to all user types in J.O.L.T. The “(S)” on the right indicates user type. (S = student, F = Faculty, CC = Course Coordinator, and A = Administrator).
This
screen appears once a Student user successfully authenticates with J.O.L.T. This screen indicates that the Student is not
enrolled in any courses. Using the
inline form, the student can enter a course pin to register for a section.
This overlay
is displayed when a user attempts to enter an incorrect PIN to enroll in a
course. Clicking “OK” brings the user back to the student homepage.
This
screen is shown when a Student user enters a correct PIN to register for a
course. The newly added course is displayed on the screen. Clicking on the course name will bring the
student to the section homepage.
Clicking on the “Home” button brings the user back to this page.
This is
an example Section Home Page that a Student user would see once selecting a
Section on their Home Page. This screen
indicates that there are no tasks pending, and no announcements. The “Gradebook” button brings the student to
their grade book.
This is the section homepage with an active assignment as well as an announcement. Clicking the task brings the student to the Problem Set Overview screen. Clicking the announcement opens the announcement in a dialog.
This is
an example Problem Set Overview Screen.
This screen shows each problem within the problem set, as well as each
problem’s category, difficulty point value, and completion status.
This is
an example Solve Problem screen. The
Student User is presented with the Problem Name, Description, and a text area
for inputting Java™ Source Code. The
text area is pre-populated with a method signature. Clicking on the “Previous”
and “Next” buttons brings the user to a different problem in the problem
set. The “Overview” button brings the
user back to the problem set overview screen.
This is
the Solve Problem Screen with an example Compile Error. This is shown when a Student enters Java™
Source Code that is not syntactically correct, and then pushes the “Compile,
Save, Run” Button.
This is
the Solve Problem Screen with incorrect output.
This is shown when a Student clicks the “Compile, Save, Run” button
after entering Java™ Source Code that is syntactically correct, but produces
the wrong output.
This is
the Solve Problem Screen with a timeout error.
This is shown when a Student clicks the “Compile, Save, Run” button
after entering Java™ Source Code that is syntactically correct, but fails to
complete execution within a reasonable amount of time.
This is
an example Problem Set Overview screen with an incomplete problem. This occurs when a student navigates away
from a problem once attempting (unsuccessfully) to solve it.
This
screen appears when the Student enters a Java™ solution that passes all of the
provided test cases.
This is
an example Problem Set Overview Screen showing a completed problem.
This is
an example of the Student gradebook for a particular section. This screen is sortable by name, due date,
and grade. The Assignment Name fields
are clickable, with each link bringing you to the respective Problem Set
Overview.
This screen appears when the Student clicks
the “Profile” button in the header of any page.
It shows the Student’s profile information.
This
screen allows a Student user to edit their profile information. The Students gets here by clicking the “Edit
Profile” button on the Student Profile Page.
All error checking in the registration page applies to this page.
This
overlay appears when a user clicks the announcement title on their homepage or
section homepage. Clicking “Close” removes the overlay and keeps the
announcement in the system. Clicking “Delete” will remove the announcement from
the system.
This
screen shows a Student who has just logged out of J.O.L.T by clicking the
Logout button in the header.
Faculty
shall have the ability to log into the system via a unique username and
password. Once logged in, Faculty will
be able to select a course and then create individual problems as well as
problem sets for that course. Each
problem will be categorized based on type and difficulty. Faculty will be able to assign a grading
scheme to problems and problem sets.
Each problem created will have the ability to be modified; however, all
changes will be recorded into the System as a new problem. This will allow users to view problems and
problem sets in a temporal manner. Problems that are partially completed will
be saved to a “sandbox” where they may finish it at a later date.
Faculty
will have the ability to submit their problems and problem sets to a “Course
Pool”, which will allow other faculty members who teach the same course access
to their problems and problem sets. Faculty will have the ability to search a
Course Pool or the Global Pool.
Faculty
will have a grade book view which will allow them to see the progress of each
student that they instruct or have previously instructed. Faculty will have the
ability to alter any grade that was assigned to a student in their course.
Faculty will have the ability to send a broadcast message to students that they
instruct.
The
Faculty User shall have the following screens available.
This is
the initial screen that Faculty will be presented with when they navigate to J.O.L.T. It prompts for a username and password, and
provides a link for forgotten password.
Note that faculty accounts are created by Course Coordinators and/or the
Administrator. No self-registration is
allowed.
Note: All validation that appears on
the student screens applies to this page for Faculty.
This is
the Faculty Home Page. This page is
pre-populated with their courses by the Course Coordinator. From here, the Faculty can select a course,
or create an announcement.
This is
the Section home page for a Faculty member.
From here, they can manage the gradebook, assignments, sandbox and
pools. They can also create a problem or
problem set, and view the course information.
This is
the Create Problem page for a faculty member.
From here, the faculty enters all information about a problem.
This
screen shows an error message indicating an invalid field is present on the
Create Problem Screen.
This screen shows an error message pertaining to a
compiler error in the Faculty member’s solution code.
This is
the Faculty sandbox. The sandbox stores
all problems that are not completed and ready for the pool.
Clicking a problem name in the sandbox will bring up a window to edit the problem. The user can also select a problem to and click ”Delete” to remove it from their sandbox. The user can also Create Problems from this page (The problems created from that create problem screen do not necessarily mean that they will be saved in the sandox.
This is
the edit problem screen that the Faculty user will see when they choose to edit
a problem from their private pool, the course pool, the global pool, or the
sandbox. It is simply the create problem screen populated with the information
the user provided. All error checking on
the Create Problem screen exists on the edit problem screen as well.
This is
an example of the Create Problem Set Screen.
Faculty can use problems from their own pool, the course pool, or the
global pool when creating a Problem Set.
Clicking on a problem in the problem set area will allow the faculty
user to edit the problem. Point values
can be assigned to each problem.
This is
an example error message showing invalid fields on the Create Problem Set
Screen.
This is
an example error message showing a Problem Set with no problems added to it.
This is
a confirmation message showing a created Problem Set. This is an overlay dialog that will redirect
to their pool management screen.
This is
the screen for Editing an existing Problem Set.
The format of the screen is identical to the Create Problem Set
screen. All error screens for Edit
Problem Set are identical to the ones for Create Problem Set.
This is
the screen to activate a Problem Set for a specific course. Problem Sets can either be activated
instantly, or set to be active at a later date.
Problem Set Deactivation is also accomplished on this screen. Note that
this screen is only used for manual deactivation. J.O.L.T will automatically deactivate problem
sets once the expiration date and time have been passed.
This is
the screen to create an announcement to be broadcast to users. Users select recipients of the announcement,
and provide a title and announcement text.
This
screen shows an announcement with populated data and selected recipients. Using the left and right arrow buttons add
and remove users from the recipient list.
This
shows an error message for a missing field when creating an announcement. This
appears once the user selects the “Submit” button.
This
shows a successfully created announcement.
This appears once the user selects the “Submit” button. Clicking on
“Close” removes the overlay, but keeps the user at the announcement screen in
case they wish to send another announcement.
This is
the gradebook view for a specific course for a faculty user. Clicking on an Assignment Name brings the
user to the Problem Set Overview screen.
Clicking on the grade allows the user to change the grade.
This
shows a user editing a student’s grade.
Clicking the grade opens an overlay dialog where a new grade may be
entered. A comment field is also provided, but not required.
Clicking
the “Manage Pools” button on the Section Home Page brings the user to this
screen. Multiple problems can be
selected at once. Problems in the
private pool can be copied to the course pool.
Problems in the private pool can also be removed from the pool. Note
that deleting a problem from a pool does NOT remove the problem from the
database.
Clicking
the “Profile” button in the header will bring faculty members to this screen,
where they can view their profile information.
There is a button to update their information as well.
This
screen allows a Faculty user to edit their profile information. The Faculty user gets here by clicking the
“Edit Profile” button on the Faculty Profile Page. All error checking that the student user has
also exists on this screen.
This
screen shows a Faculty who has just logged out of J.O.L.T by clicking the
Logout button in the header.
The
Course Coordinator shall have the ability to log into the System via a unique
username and password. Once logged in,
the Course Coordinator will be able to create Faculty accounts. The Course Coordinator will also be able to
create courses and assign the courses to specific Faculty members. The Course Coordinator will have access to
course-wide reporting tools, which will allow for statistical analysis of
problems and problem sets.
The Course Coordinator will be able
to manage the “Course Pool” for each course they manage. The Course Coordinator will be responsible
for adding, modifying, and deleting problems and problem sets from the pool. The Course Coordinator submits problems and
problem sets to the “Global Pool” for use by all faculty members. Problems that
are partially completed will be saved to a “sandbox” where they may finish it
at a later date.
The Course Coordinator will be able
to send broadcast messages to faculty members and students that participate in
the courses that the Course Coordinator manages, or a subset thereof.
The
Course Coordinator shall have the following screens available.
This is
the initial screen that Course Coordinator will be presented with when they
navigate to J.O.L.T. It prompts for a
username and password, and provides a link for forgotten password. Note that Course Coordinator accounts are
created by the Administrator. No self-registration
is allowed.
Note: All validation that appears on
the student screens applies to this page for Course Coordinator.
This is
the screen that the Course Coordinator is presented with after they
successfully log in. From here, they can
Manage Pools, Manage Courses (that they coordinate), Manage their Sandbox,
Create a Problem, Create a Problem Set, and Create an Announcement. They can also manage the faculty accounts
that teach the courses that the course coordinator manages.
This
screen is used by the Course Coordinator to create a Faculty account. All error checking on the registration screen
applies to this screen.
This
screen allows a Course Coordinator to edit a faculty member’s account. Entering a value in the password fields will
update the user’s password.
From the
Manage Courses button, the “Create Section” button will show this overlay
dialog, which will allow the course coordinator to create a section for any
course that they manage. Note the Course
Enrollment Pin is automatically generated by the system. The Pin can be later changed, if necessary.
This
screen indicates an error in one or more fields while creating a new
section. This appears after clicking the
“Create Section” Button.
This overlay
allows a Course Coordinator to edit an existing Course Section. Clicking on the
course name under the “Manage Courses” screen will bring the user to this
overlay. All error checking applies to
the edit screen as the create course screen.
This is
the gradebook view for a specific course for a Course Coordinator user. Clicking on an assignment name brings the
user to the Problem Set Overview screen.
Clicking on the grade allows the user to change the grade.
This
shows a user editing a student’s grade.
Clicking the grade opens an overlay dialog where a new grade may be
entered. A comment field is also provided, but not required.
This is
the Create Problem page for a Course Coordinator member. From here, the user enters all information
about a problem.
This
screen shows an error message indicating an invalid field is present on the
Create Problem Screen.
This screen shows an error message pertaining to a compiler error in the Course Coordinator member’s solution code.
This is
the Course Coordinator sandbox. The
sandbox stores all problems that are not completed and ready for the pool.
Clicking a problem name in the sandbox will bring up a window to edit the problem. The user can also select a problem to and click “Delete” to remove it from their sandbox. The user can also Create Problems from this page (The problems created from that create problem screen do not necessarily mean that they will be saved in the sandbox.)
This is
the edit problem screen that the Course Coordinator user will see when they
choose to edit a problem from either their private pool, the course pool, the
global pool, or the sandbox. It is simply the create problem screen populated
with the information the user provided.
All error checking on the Create Problem screen exists on the edit
problem screen as well.
This is
an example of the Create Problem Set Screen.
Course Coordinators can use problems from their own pool, the course
pool, or the global pool when creating a Problem Set. Clicking on a problem in the problem set area
will allow the user to edit the problem.
Point values can be assigned to each problem. By selecting problems in
the pools using the checkboxes and clicking the “Add to Problem Set” button the
problems in the pool are added to the problem set area located underneath the
“Total Points” and “Number of Problems” fields.
This is
an example error message showing invalid fields on the Create Problem Set
Screen.
This is
an example error message showing a Problem Set with no problems added to it.
This is
a confirmation message showing a created Problem Set. This is an overlay dialog that will redirect
to their pool management screen.
This is
the screen for Editing an existing Problem Set.
The format of the screen is identical to the Create Problem Set
screen. All error screens for Edit
Problem Set are identical to the ones for Create Problem Set.
This is
the screen to activate a Problem Set for a specific course. Problem Sets can either be activated
instantly, or set to be active at a later date.
Problem Set Deactivation is also accomplished on this screen. Note that
this screen is only used for manual deactivation. J.O.L.T will automatically deactivate problem
sets once the expiration date and time have been passed.
This is
the screen to create an announcement to be broadcast to users. Users select recipients of the announcement,
and provide a title and announcement text.
This
screen shows an announcement with populated data and selected recipients. Using the left and right arrow buttons add
and remove users from the recipient list.
This
shows an error message for a missing field when creating an announcement. This
appears once the user selects the “Submit” button.
This
shows a successfully created announcement.
This appears once the user selects the “Submit” button. Clicking on
“Close” removes the overlay, but keeps the user at the announcement screen in
case they wish to send another announcement.
This is
the Pool Management screen for Course Coordinators. Clicking the “Manage Pools” button on the
Section Home Page brings the user to this screen. Multiple problems can be selected at
once. Problems in the private pool can
be copied to the course pool. Problems
in the private pool can also be removed from the pool. Note that deleting a
problem from a pool does NOT remove the problem from the database.
Clicking
the “Pending Problems” button brings the Course Coordinator to this
screen. From here, the Course
Coordinator has the ability to approve or reject problems to the Course
Pool. Clicking the problem name allows
the Course Coordinator to view the problem details.
This is
the screen to create an announcement to be broadcast to users. Users select recipients of the announcement,
and provide a title and announcement text.
This
screen shows an announcement with populated data and selected recipients. Using the left and right arrow buttons add
and remove users from the recipient list.
This
shows an error message for a missing field when creating an announcement. This
appears once the user selects the “Submit” button.
This
shows a successfully created announcement.
This appears once the user selects the “Submit” button. Clicking on
“Close” removes the overlay, but keeps the user at the announcement screen in
case they wish to send another announcement.
Clicking
the “Profile” button in the header will bring course coordinators members to
this screen, where they can view their profile information. There is a button to update their information
as well.
This
screen allows a Course Coordinator user to edit their profile information. The user gets here by clicking the “Edit
Profile” button on the Course Coordinator Profile Page. All error checking that the student user has
also exists on this screen.
This is a sample report format that the course coordinator will see. Various statistics will be available on a per-problem basis. Statistics are tracked across multiple classes.
This
screen shows a Course Coordinator who has just logged out of J.O.L.T by
clicking the Logout button in the header.
The
Administrator shall be able to log into the System via a unique username and
password. Once logged in, the Administrator will be able to create and manage
Course Coordinator, Faculty, and Student accounts. The Administrator has the
same abilities as a Course Coordinator.
The Administrator will be able to send broadcast messages to all users,
or a subset thereof. The Administrator
will manage the “Global Pool” of problems and problem sets.
The
Administrator shall have the following screens available.
This is
the initial screen that the Administrator will be presented with when they
navigate to J.O.L.T. It prompts for a
username and password, and provides a link for forgotten password.
Note: All validation that appears on
the student screens applies to this page for the Administrator. Note that the
administrator account cannot get locked out.
This is
the home page for the Administrator. From
here, they can Manage Pools, Manage Courses, Manage their Sandbox, Create a
Problem, Create a Problem Set, and Create an Announcement. They can also manage all user accounts, and
Create Courses and Sections.
This
screen is reached from the “Manage Users” button on the Administrator home
page. This screen allows the
Administrator to edit and add user accounts.
This is the screen the Administrator uses to create a Course Coordinator account. All fields are verified for correct values.
This is the screen the Administrator uses to create a Faculty account. All fields are verified for correct values.
This is the screen the Administrator uses to create a Student account. All fields are verified for correct values.
This screen is the same for all user types. The administrator has the ability to update all fields for user account management.
Clicking on the “Manage Courses” button brings the administrator to this screen, where they can create sections, create courses, and manage existing sections and courses (by clicking on them).
This overlay
allows the Administrator to create a course from the “Manage Courses” screen.
The Administrator can also create sections as seen in the course coordinator
screen “ Create Course Section/” All error checking applies.
This is
the gradebook view for a specific course for the Administrator user. Clicking on an Assignment Name brings the
user to the Problem Set Overview screen.
Clicking on the grade allows the user to change the grade.
This
shows a user editing a student’s grade.
Clicking the grade opens an overlay dialog where a new grade may be
entered. A comment field is also provided, but not required.
This is
the Create Problem page for the Administrator.
From here, the user enters all information about a problem.
This
screen shows an error message indicating an invalid field is present on the
Create Problem Screen.
This screen shows an error message pertaining to a compiler error in the Administrator member’s solution code.
This is
the Administrator sandbox. The sandbox
stores all problems that are not completed and ready for the pool.
Clicking a problem name in the sandbox will bring up a window to edit the problem. The user can also select a problem to and click “Delete” to remove it from their sandbox. The user can also Create Problems from this page (The problems created from that create problem screen do not necessarily mean that they will be saved in the sandbox.)
This is
the edit problem screen that the Administrator user will see when they choose
to edit a problem from their private pool, the course pool, the global pool, or
the sandbox. It is simply the create problem screen populated with the
information the user provided. All error
checking on the Create Problem screen exists on the edit problem screen as
well.
This is
an example of the Create Problem Set Screen.
Administrators can use problems from their own pool, the course pool, or
the global pool when creating a Problem Set.
Clicking on a problem in the problem set area will allow the faculty
user to edit the problem. Point values
can be assigned to each problem.
This is
an example error message showing invalid fields on the Create Problem Set
Screen.
This is
an example error message showing a Problem Set with no problems added to it.
This is
a confirmation message showing a created Problem Set. This is an overlay dialog that will redirect
to their pool management screen.
This is
the screen for editing an existing Problem Set.
The format of the screen is identical to the Create Problem Set screen. All error screens for Edit Problem Set are
identical to the ones for Create Problem Set.
This is
the screen to activate a Problem Set for a specific course. Problem Sets can either be activated
instantly, or set to be active at a later date.
Problem Set deactivation is also accomplished on this screen. Note that
this screen is only used for manual deactivation. J.O.L.T will automatically deactivate problem
sets once the expiration date and time have been passed.
This is
the screen to create an announcement to be broadcast to users. Users select recipients of the announcement,
and provide a title and announcement text.
This
screen shows an announcement with populated data and selected recipients. Using the left and right arrow buttons add
and remove users from the recipient list.
This
shows an error message for a missing field when creating an announcement. This
appears once the user selects the “Submit” button.
This
shows a successfully created announcement.
This appears once the user selects the “Submit” button. Clicking on
“Close” removes the overlay, but keeps the user at the announcement screen in
case they wish to send another announcement.
This is
the pool management screen for the administrator user. Clicking the “Manage Pools” button on the
Section Home Page brings the user to this screen. Multiple problems can be selected at
once. Problems in the private pool can
be copied to the global pool. Problems
in the private pool can also be removed from the pool. Note that deleting a
problem from a pool does NOT remove the problem from the database.
Clicking
the “Pending Problems” button brings the Administrator to this screen. From here, the Administrator has the ability
to approve or reject problems to the Global Pool. Clicking the problem name allows the Administrator
to view the problem details.
Clicking
the “Profile” button in the header will bring the Administrator member to this
screen, where they can view their profile information. There is a button to update their information
as well.
This
screen allows the Administrator user to edit their profile information. The Administrator user gets here by clicking
the “Edit Profile” button on the Administrator Profile Page.
All
error checking for previous users for this screen applies to the Administrator.
This
screen shows the Administrator who has just logged out of J.O.L.T by clicking
the Logout button in the header.
The
logical data stores are a set of tables that represent the different fields for
the MySQL database. The first part of this is a tabular, text-based
description, followed by a graphical representation of the tables.
This
table stores all information regarding announcements within the system.
announcement |
||||
Field |
Type |
Null |
Default |
Comments |
announcementId |
int(5) |
No |
|
unique ID for each announcement |
fromUser |
varchar(30) |
Yes |
NULL |
username of announcement sender |
toUser |
varchar(30) |
Yes |
NULL |
username of announcement receiver |
sendDate |
int(20) |
Yes |
NULL |
Timestamp of announcement |
subject |
varchar(50) |
Yes |
NULL |
Subject of announcement |
message |
varchar(1000) |
Yes |
NULL |
Announcement Text |
This
table lists all assignments (past and current) for all courses in the system.
assignment |
||||
Field |
Type |
Null |
Default |
Comments |
assignmentId |
int(9) |
No |
|
Unique id for each assignment |
assignmentName |
varchar(30) |
Yes |
NULL |
Name of Assignment |
beginOn |
int(20) |
Yes |
NULL |
timestamp of when problem should be activated |
endOn |
int(20) |
Yes |
NULL |
timestamp of when problem should be deactivated |
problemSet |
int(9) |
Yes |
NULL |
id of problem set that the assignment refers
to |
assignedTo |
int(9) |
Yes |
NULL |
Section id that assignment is assigned to |
This
table stores course information for the system.
course |
||||
Field |
Type |
Null |
Default |
Comments |
courseId |
int(9) |
No |
|
Unique course id for each course |
courseName |
varchar(30) |
Yes |
NULL |
Course Name (i.e. Intro To Programming) |
courseNumber |
varchar(10) |
Yes |
NULL |
Course Number (i.e. CSIS-010) |
createdBy |
varchar(30) |
Yes |
NULL |
Username that created the course |
managedBy |
varchar(30) |
Yes |
NULL |
The Course Coordinator that manages the course |
poolId |
int(9) |
Yes |
NULL |
Id of the pool that belongs to the course |
This
table shows which students are enrolled in which section it also shows past and
current enrollment information.
enrolledStudents |
||||
Field |
Type |
Null |
Default |
Comments |
username |
varchar(30) |
No |
|
username of student enrolled in section |
sectionId |
int(9) |
No |
0 |
section id of section that student is enrolled
in |
This
table shows all grade adjustments made by Faculty, Course Coordinators, and Administrators.
gradeLog |
||||
Field |
Type |
Null |
Default |
Comments |
assignment |
int(9) |
No |
|
Assignment Id of changed grade |
faculty |
varchar(30) |
No |
|
Username of individual who modified grade |
student |
varchar(30) |
No |
|
Student whose grade was changed |
timestamp |
int(10) |
No |
|
Date/Time of Grade Modification |
oldGrade |
int(9) |
No |
|
Original grade for student. |
newGrade |
int(9) |
No |
|
New grade for student. |
comment |
varchar(100) |
Yes |
NULL |
Comment of grade change (Optional, viewable by
student if set) |
This
table contains the information for all pools in the system.
pool |
||||
Field |
Type |
Null |
Default |
Comments |
poolId |
int(9) |
No |
|
unique id for each pool |
poolType |
int(1) |
Yes |
NULL |
type of pool (0=sandbox, 1=private, 2=course,
3=global) |
poolOwner |
varchar(30) |
Yes |
NULL |
userid of pool owner |
This
table stores all information regarding each problem of the system.
problem |
||||
Field |
Type |
Null |
Default |
Comments |
problemId |
int(9) |
No |
|
unique id for each problem |
problemName |
varchar(30) |
No |
|
Name of Problem |
problemCategory |
varchar(30) |
No |
|
Category of problem |
problemDescription |
varchar(500) |
No |
|
description of problem |
problemActive |
int(1) |
No |
0 |
field indicating that problem is active (i.e.,
that it passes all checks, a valid solution is specified, etc) and can be
used in a problem set. |
totalAttempts |
int(9) |
No |
0 |
number of times this problem has been
attempted to be solved. |
correctAttempts |
int(9) |
No |
0 |
number of times this problem has been
sucessfully solved. |
createdOn |
int(10) |
No |
|
timestamp of when the problem was created. |
createdBy |
varchar(30) |
No |
|
username if problem creator |
methodSignature |
varchar(100) |
No |
|
method signature of problem |
methodName |
varchar(40) |
No |
|
name of method of problem |
numParameters |
int(1) |
No |
1 |
number of parameters the method contain |
parameters |
varchar(60) |
No |
|
parameter types, in object format (Integer,
Boolean, Character, etc) |
numTestCases |
int(2) |
No |
|
number of test cases for this problem |
parm1Name |
varchar(20) |
Yes |
NULL |
Name of first parameter of problem |
parm1Type |
varchar(10) |
Yes |
NULL |
Data type of first parameter of problem |
parm2Name |
varchar(20) |
Yes |
NULL |
Name of second parameter of problem |
parm2Type |
varchar(10) |
Yes |
NULL |
Data type of second parameter of problem |
parm3Name |
varchar(20) |
Yes |
NULL |
Name of third parameter of problem |
parm3Type |
varchar(10) |
Yes |
NULL |
Data type of third parameter of problem |
parm4Name |
varchar(20) |
Yes |
NULL |
Name of fourth parameter of problem |
parm4Type |
varchar(10) |
Yes |
NULL |
Data type of fourth parameter of problem |
parm5Name |
varchar(20) |
Yes |
NULL |
Name of fifth parameter of problem |
parm5Type |
varchar(10) |
Yes |
NULL |
Data type of fifth parameter of problem |
resultType |
varchar(10) |
Yes |
NULL |
Data type of result of problem |
solution |
varchar(1000) |
No |
|
Faculty provided solution |
publishSolution |
int(1) |
No |
0 |
Field indicating that the solution should be
published for the students to see. |
This
table links problems to pools in the system. Problems may exist in more than
one pool.
problemLocation |
||||
Field |
Type |
Null |
Default |
Comments |
problemId |
int(9) |
No |
|
Problem ID identifying a unique problem in the
Problem table |
poolId |
int(9) |
No |
|
Pool ID identifying the pool that the problem
resides in |
status |
int(1) |
No |
0 |
Status of problem (0=pending approval,
1=approved) |
This
table shows data regarding the problem sets.
problemSet |
||||
Field |
Type |
Null |
Default |
Comments |
setId |
int(9) |
No |
|
Unique id for each
problem set |
setName |
varchar(30) |
Yes |
NULL |
Name of Problem Set |
setCategory |
varchar(30) |
Yes |
NULL |
Category of Problem
Set |
setDescription |
varchar(500) |
Yes |
NULL |
Description of
Problem Set |
numProblems |
int(2) |
Yes |
NULL |
Number of Problems in
problem set |
problem1Id |
int(9) |
Yes |
NULL |
Id of Problem #1 in
Problem set |
problem1Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem2Id |
int(9) |
Yes |
NULL |
Id of Problem #2 in
Problem set |
problem2Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem3Id |
int(9) |
Yes |
NULL |
Id of Problem #3 in
Problem set |
problem3Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem4Id |
int(9) |
Yes |
NULL |
Id of Problem #4 in
Problem set |
problem4Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem5Id |
int(9) |
Yes |
NULL |
Id of Problem #5 in
Problem set |
problem5Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem6Id |
int(9) |
Yes |
NULL |
Id of Problem #6 in
Problem set |
problem6Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem7Id |
int(9) |
Yes |
NULL |
Id of Problem #7 in
Problem set |
problem7Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem8Id |
int(9) |
Yes |
NULL |
Id of Problem #8 in
Problem set |
problem8Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem9Id |
int(9) |
Yes |
NULL |
Id of Problem #9 in
Problem set |
problem9Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem10Id |
int(9) |
Yes |
NULL |
Id of Problem #10 in
Problem set |
problem10Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem11Id |
int(9) |
Yes |
NULL |
Id of Problem #11 in
Problem set |
problem11Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem12Id |
int(9) |
Yes |
NULL |
Id of Problem #12 in
Problem set |
problem12Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem13Id |
int(9) |
Yes |
NULL |
Id of Problem #13 in
Problem set |
problem13Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem14Id |
int(9) |
Yes |
NULL |
Id of Problem #14 in
Problem set |
problem14Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem15Id |
int(9) |
Yes |
NULL |
Id of Problem #15 in
Problem set |
problem15Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem16Id |
int(9) |
Yes |
NULL |
Id of Problem #16 in
Problem set |
problem16Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem17Id |
int(9) |
Yes |
NULL |
Id of Problem #17 in
Problem set |
problem17Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem18Id |
int(9) |
Yes |
NULL |
Id of Problem #18 in
Problem set |
problem18Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem19Id |
int(9) |
Yes |
NULL |
Id of Problem #19 in
Problem set |
problem19Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem20Id |
int(9) |
Yes |
NULL |
Id of Problem #20 in
Problem set |
problem20Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem21Id |
int(9) |
Yes |
NULL |
Id of Problem #21 in
Problem set |
problem21Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem22Id |
int(9) |
Yes |
NULL |
Id of Problem #22 in
Problem set |
problem22Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem23Id |
int(9) |
Yes |
NULL |
Id of Problem #23 in
Problem set |
problem23Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem24Id |
int(9) |
Yes |
NULL |
Id of Problem #24 in
Problem set |
problem24Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
problem25Id |
int(9) |
Yes |
NULL |
Id of Problem #25 in
Problem set |
problem25Point |
int(9) |
Yes |
NULL |
Point value for this
problem |
This
table shows information about each section in the system.
section |
||||
Field |
Type |
Null |
Default |
Comments |
sectionId |
int(9) |
No |
|
Unique id for each section |
semester |
varchar(6) |
Yes |
NULL |
Semester that section is active for |
year |
int(4) |
Yes |
NULL |
Year that section is active for |
courseId |
int(9) |
Yes |
NULL |
ID of course section belongs to |
sectionName |
varchar(30) |
Yes |
NULL |
Name of section |
sectionNumber |
varchar(30) |
Yes |
NULL |
Number of Section |
faculty |
varchar(30) |
Yes |
NULL |
Faculty username in charge of section |
coordinator |
varchar(30) |
Yes |
NULL |
Coordinator for course that section lies in. |
enrollPin |
varchar(10) |
No |
|
PIN for section that students use to enroll in course |
This
table links problems sets to pools in the System. Problems sets may exist in more than one
pool.
setLocation |
||||
|
|
|
|
|
Field |
Type |
Null |
Default |
Comments |
setId |
int(9) |
No |
|
Problem Set ID identifying a unique problem in
the Problem Set table |
poolId |
int(9) |
No |
|
Pool ID identifying the pool that the problem
set resides in |
status |
int(1) |
No |
0 |
Status of problem (0=pending approval,
1=approved) |
This
table stores the most recent attempt for each student at solving a problem in
the system.
solutionAttempt |
||||
|
|
|
|
|
Field |
Type |
Null |
Default |
Comments |
assignmentId |
int(9) |
No |
0 |
Assignment ID that soluition attempt belongs
to. |
problemId |
int(9) |
No |
0 |
Problem ID that is being solved |
student |
varchar(30) |
No |
|
Username of student attempting a solution |
timestamp |
int(20) |
Yes |
NULL |
Timestamp of last submission |
code |
varchar(1000) |
Yes |
NULL |
Java Source that student used |
numAttempts |
int(9) |
Yes |
NULL |
Number of attempts student has used for this
particular solution |
score |
int(9) |
Yes |
NULL |
Grade that student received (NULL indicates
unsucessful attempt) |
comment |
varchar(100) |
Yes |
NULL |
Comment field for faculty to explain a grade
change. |
This
table stores a single test case for a problem in the system.
testCase |
||||
Field |
Type |
Null |
Default |
Comments |
problemId |
int(9) |
No |
0 |
Id of problem that test case belongs to |
testCaseNumber |
int(2) |
No |
0 |
The test case number (1 – 25) |
param1 |
varchar(100) |
Yes |
NULL |
Data for first parameter of test case. |
param2 |
varchar(100) |
Yes |
NULL |
Data for second parameter of test case. |
param3 |
varchar(100) |
Yes |
NULL |
Data for third parameter of test case. |
param4 |
varchar(100) |
Yes |
NULL |
Data for fourth parameter of test case. |
param5 |
varchar(100) |
Yes |
NULL |
Data for fifth parameter of test case. |
result |
varchar(100) |
Yes |
NULL |
Data for result of test case. |
hidden |
int(1) |
Yes |
NULL |
Indicates that this is a hidden test case. |
This
table stores the information for all users in the system.
user |
||||
|
|
|
|
|
Field |
Type |
Null |
Default |
Comments |
username |
varchar(30) |
No |
|
username of user |
password |
varchar(32) |
No |
|
md5 hash of user password |
firstname |
varchar(30) |
No |
|
user first name |
lastname |
varchar(30) |
No |
|
user last name |
email |
varchar(30) |
No |
|
user email address |
squestion |
varchar(50) |
No |
|
security question for password reset |
sanswer |
varchar(100) |
No |
|
security answer for password reset |
gradSemester |
varchar(6) |
Yes |
NULL |
Graduation Semester (Spring/Fall) - Only used
for students |
gradYear |
int(4) |
Yes |
NULL |
Graduation year (20XX) - Only used for
students |
loginAttempts |
int(1) |
No |
0 |
number of incorrect login attempts |
userType |
int(1) |
No |
0 |
type of user (0=student, 1=faculty, 2=course
coordinator, 3=administrator) |
confirmed |
varchar(32) |
No |
|
This is a md5 hash of the username field
concatenated with the email field. When user successfully registers, the
field changes to "true" |
bornOn |
varchar(20) |
No |
|
timestamp of when the account was registered. |
active |
int(1) |
No |
1 |
field indicating status of account (1=active,
0=inactive). |
|
|
|
|
|
518 Interactive will provide all required source files and setup scripts (such as database create table statements) to the client, Dr. Lim, on a portable media device, such as a CD or DVD. Instructions on installation, setup, and configuration will also be provided.
·
Appendix
1: Sources of Information
·
Appendix
2: Glossary of Terms
·
Appendix
3: Current Timeline
·
Appendix
4: Data Flow Diagrams
·
Appendix
5: Activity Diagrams
·
Appendix
6: Data Dictionary
·
Appendix
7: Test Plan
Information
found within this Requirement Specification document has been obtained through
meetings with our client, Dr. Darren Lim. Information was also obtained through
Dr. Lederman’s Software Engineering lectures. Information has also been
collected from various internet resources, as well as requirement specification
documents from previous years.
The following are a list of technical terms
used within the document. This section
is provided to clarify their meaning.
Actor: An entity in UML Use Case
Diagrams and UML Activity Diagrams. It
represents the human and non-human external entities (outside the system boundary)
that interact with the system.
Activity Diagram: A diagram based on the Unified
Model Language (UML). This represents
the processes that comprise a certain activity within the system. These diagrams are generally created with the
perspective of an actor in mind.
Client: Used to refer to Dr. Darren Lim,
the client of 518 Interactive who
requested J.O.L.T.
Compiler: A program that reads in source
code and generates an executable.
CSS: Cascading Style Sheets – Used
within HTML documents in order to control the presentation of web pages.
DFD: Data Flow Diagrams are used to
show how data moves and is processed within a system. There are various levels to DFDs, with each
subsequent level providing more detail than the previous.
Hardware: The tangible components of a
computer and server. Examples include
monitors, disk drives, printers, keyboard, processor, and memory.
HTML: Hypertext Markup Language is
the scripting language used to describe the information contained on a
website. HTML utilizes Cascading Style
Sheets (CSS) to generate the style of the page.
HTML and CSS are parsed by web browsers, such as Internet Explorer and
Firefox, to render the websites for users.
Java: A programming language which
the System will be able to compile and execute.
This language will be used by the students to solve the assigned
problems.
Java Byte Code: The output of the Java™ compiler
upon successful compilation of Java™ source code. Java Byte Code is read by the Java™ runtime
environment, which in turn executes the proper machine-level commands.
Java SDK: Software Development Kit for
Java – a collection of tools used by developers to aid in the creation of
programs. The Java SDK includes the
Java™ (V. 1.6) compiler. The Java™ SDK
also includes the Java™ (V. 1.6) runtime environment, which allows for Java™
Byte Code to be executed.
J.O.L.T: Java
Online Learning Tool
is the name of the system being developed for Dr. Lim, the client of 518 Interactive.
MySQL: A free implementation of a
Relational Database Management System.
Used to store and retrieve information relevant to the website, such as
usernames, passwords, problems, solutions, and scores. Accessing information within the database is
achieved by submitting a “query” in the Structured Query Language (SQL) form.
PHP: PHP Hypertext Processor is a
programming language used to create dynamic web sites. Has the ability to interact with a database.
Software: The intangible components of a
computer and server. It is a set of
machine-level instructions that is run from within the memory, and is used to
perform a specific set of functions.
Examples include Microsoft Word, Adobe Photoshop, and Mozilla Firefox.
Source Code: A document that a compiler parses
to generate machine code (which the computer can run directly), or code that
gets interpreted by a third-party application, which then gets executed.
Source/Sink: This is a term used within Data
Flow Diagrams to represent an entity that either provides (source) or receives
(sink) data.
System: Used within this document to
describe the Java Online Learning Tool (J.O.L.T).
UML: Unified Modeling Language is
the industry-standard language for the specification, visualization,
construction, and documentation of the components of software systems.
Use Case Diagram: Represents the high-level
functions of the system. It also depicts how actors interact with each of those
functions.
The Data
Flow Diagrams (DFDs) are used for structure analysis and design. DFDs show the flow of data from external
entities into the system. DFDs also show
how the data moves and is transformed from one process to another, as well as
its logical storage.
Data
Flow Diagrams are in an accompanied document titled “Data Flow Diagrams”, which
can be found under the “Documents” link of the 518 Interactive Website.
Activity
Diagrams are a UML (Unified Modeling Language) specified diagram which shows
workflows of stepwise activities and actions, with support for choice,
iteration, and concurrency. It outlines
the process that Actors (both human and non-human) go through while interacting
with the System to accomplish a specific task.
Activity
Diagrams are in an accompanied document titled “Activity Diagrams”, which can
be found under the “Documents” link of the 518 Interactive Website.
The Data
Dictionary lists all data entities within J.O.L.T.
The Data
Dictionary is in an accompanied document titled “Data Dictionary”, which can be
found under the “Documents” link of the 518 Interactive Website.
The Test
Plan describes the testing that will take place to verify that all the
functional requirements have been met.
The Test
Plan is in an accompanied document titled “Test Plan”, which can be found under
the “Documents” link of the 518 Interactive Website.