Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Contents 1. Introduction ........................................................................................2 1.1 Purpose and Scope ...............................................................2
1.2 Scope ......................................................................................2 1.3 Definitions, Acronyms, Abbreviations and Notation ........2 1.4 Overview ................................................................................4 2. References ............................................................................................5 3. Decomposition Description .................................................................5 3.1 Module Decomposition .........................................................5 3.2 Concurrent Process Decomposition ...................................13 3.3 Data Decomposition .............................................................18 4. Dependency Description ...................................................................28
4.1 Module Dependencies ..........................................................28 4.2 Concurrent Process Dependencies .....................................29 4.3 Data Dependencies ...............................................................30 5. Interface Description ..........................................................................31
5.1 Module Interfaces .................................................................315.2 Process Interfaces .................................................................51
Appendix – Requirements Traceability Matrix ....................................51
1. Introduction
1.1 Purpose
The purpose of this document is to describe in detail the software design for the Themis automated online programming contest system being developed as part of the CS312 Software Engineering course.
1.2 Scope
This document intends to elaborate the various design entities of the software such as the modules, concurrent processes and data entities. It also describes their interdependencies and interfaces. It is an exposition of how the various requirements in the SRS document will be attained through the software design. The intended audience of this document is by all developers, programmers and testers of the product.
1.3 Definitions, Abbreviations, Acronyms
1.3.1 Definitions
Concurrent Processes
Two or more independent, interacting programs executing over the same period of time; their execution can be interleaved or even simultaneous.
Coupling
A metric that characterizes the interdependence of a module with other modules.
Database
A logical collection of interrelated information, managed and stored as a unit, usually on a disk, that can easily be accessed, managed and updated.
Decomposition
A technique by which a problem is broken up into several independent tasks, or functions, each of which can be solved separately.
Dependency
A state where one function depends on another function for its execution and completion.
Form
A section of a document containing modifiable elements called input elements or fields, and labels on those fields.
Identification
A name or abbreviation assigned to an entity that simplifies referencing and tracking in the future.
Module
A separate and distinct unit of software that may be used as a component in a system.
Session
A lasting connection between a user (or client) and a peer, typically a server, usually involving the exchange of information between the client and the server.
1.3.2 Abbreviations
SRS Software Requirements Document
1.3.3 Acronyms
HTTP Hyper Text Transfer Protocol
PHP PHP Hypertext Processor
SMTP Secure Mail Transfer Protocol
SQL Structured Query Language
1.4 Overview
This document is organized as follows :
Section 2 provides additional reference material for this document.
Section 3 lays out a detailed description of the various entities in the design. It describes the different data entities in the design first, followed by the concurrent processes and modules that compose the software.
Section 4 lists the various interdependencies between the design entities described in Section 3. First, module dependencies are listed, following which process dependencies and data interactions are described.
Section 5 is a description of the interfaces of various entities in the design. Module interfaces are listed with a short description of the function of each module. A subsection on process dependencies looks at how the concurrent process running in the system interact with each other.
2. References
1. IEEE Recommended Practice for Software Design Descriptions (IEEE Standard 10161998)
2. Themis – An Automated Online Programming Contest System : Software Requirements Specification, Version 1.0.1
3. Decomposition Description
In this section, we describe the design from three angles :
First, we look at the data decomposition of the design. This, in our case, consists of the database schema containing all information about the programming contest, users, judges, problems, etc. Then, we decompose the design in terms of the concurrent processes that run in the system. Finally, we describe the modular decomposition of the design, looking at the individual modules and their subcomponents.
3.1 Module Decomposition
3.1.1 Session module
Identification: (SM)
This module facilitates login, logout and registration of teams. It also maintains information for each session of the user through his Web Browser. This information includes the last activity of the user along with the duration of the session which helps timing out teams inactive for a prespecified duration. It also stores data on the Web Browser in the form of cookies to enable frequent users to login without going through the authentication process each time. A random Session ID is created for each session of the contestant and the same is used for authenticating the contestant for all transactions in that session.
3.1.2 Form module
Identification: (FM)
All data from the user is obtained through forms. The Form module simplifies the task of keeping track of errors in user submitted forms and helps in generating dynamic pages informing the user about any incorrect information entered that needs to be resubmitted.
3.1.3 Process module
Identification: (PM)
All forms submitted by the user have to be processed. This module takes care of the same. Every form the user fills out is directed to this module and this figures out the action to be taken (whether it be login, register, forgot password, etc.) and calls the appropriate functions to handle the request.
This module is also in charge of redirecting the user to the correct page after the form has been processed, whether it be to the team status info, or some other specified page. When errors have been found with the submitted form, the default action is to redirect to the page where the user filled out the form in order to let them know about the error and fix it.
This module also handles logout procedures (like deleting the set cookies, etc).
3.1.4 Admin Process module
Identification: (APM)
The administrator can monitor and change the contest preferences from a remote computer (those which do not run the contest server) which can access the Web Server. All such changes are submitted as forms by the administrator which need to be processed. This module processes the forms and takes the corresponding actions.
3.1.5 Mailer module
Identification: (MM)
The contestants need to be mailed their team information after registering successfully. In case of contestants losing team information, they have to be mailed new passwords for participating in the contest. These two functions are accomplished by this module. However, this module requires that the web server be setup to send mails i.e., the SMTP needs to be running on the web server.
3.1.6 File Upload module
Identification: (FUM)
The source files that the contestant submits as solutions for the problems must be uploaded to the Web Server and the information about the submission should be updated in the database. This module facilitates the same.
3.1.7 MySQL Database module
Identification: (MDM)
This module forms the interface between the web server and the database server. It is a cohesive unit that combines various functions like adding new teams to the database, verifying team name and password, retrieving team info/status, etc. Data submissions and other requests from the contestants form the inputs to this module. These are transformed into database specific MySQL queries. The resulting output if any, on execution of these queries are the outputs for this module.
3.1.8 DatabaseAccess
Identification: (DBA)
This module provides the only interface for all our other modules, excepting the web server, to access the mysql database. It opens a connection to the database, and services all our other modules, through an interface that has functions specific to our application, like editJudge and so on. Any change to the database format, the database, etc. will affect only this module.
3.1.9 Server
Identification: (SVR)
This is the module that handles most of the core server side functionality, like performing judge requests, assigning judges to submissions, selecting queries to be sent to the judges, authentication of judges, identifying inactive judges and sending the submissions whose answers have not yet been received from that judge to other judges, etc. All the corresponding database access will be done through a DatabaseAccess object. The threads that service the judge from the server side, directly communicate with this module to get what the judge wants done.
3.1.10 SocketServerTh
Identification: (SST)
This module is a small one, that just listens on a specified port, to see whether new judges are trying to connect to the server or not.
3.1.11 ServerJCommThread
Identification: (SJCT)
This is the module that will basically handle communication with a judge. Is not being used directly, but serves as the base class for 2 derived classes.
3.1.12 ServerJSend extends ServerJCommThread
Identification: (SJS)
This module basically handles all the communication with the judge, where the server wants to send some data. The server, sends all the data to this module, which in turn transmits it across the network to the judge. An instance of this thread is created for each judge, to service him.
3.1.13 ServerJRecv extends ServerJCommThread
Identification: (SJR)
Like ServerJSend, this too handles communication with the judge, but acts as a receiver of information the judge wishes to send to the server. After receiving the data, this sends it to the main server, for processing the judge request.
3.1.14 ServerJDetails
Identification: (SJD)
This module encapsulates all the details about each judge, like his personal information, the 2 threads that service him, the current workload, the languages he has on his local machine, etc. It provides accessors and mutators to obtain and set the data.
3.1.15 Judge
Identification: (JDG)
This is the primary module on the judge side. By interacting with the judge GUI, this does the basic functionalities of the judge like authentication, evaluation of received submissions, query management, reconnection in cases of failure, etc. This is the analog of the Server in the server side.
3.1.16 JudgeSCommThread
Identification: (JSCT)
This is the module that will basically handle communication with the server. Is not being used directly, but serves as the base class for 2 derived classes.
3.1.17 JudgeSSend extends JudgeSCommThread
Identification: (JSS)
This module basically handles all the communication with the server, where the judge wants to send some data. The judge module, sends all the data to this module, which in turn transmits it across the network to the server. An instance of this thread is created for each judge, to service him.
3.1.18 JudgeSRecv extends JudgeSCommThread
Identification: (JSR)
Like JudgeSSend, this too handles communication with the server, but acts as a receiver of information the server wishes to send to the judge. After receiving the data, this sends it to the judge module, for processing the server request.
3.1.19 Admin
Identification: (ADM)
This is the administrator module, where an admin can authenticate himself, create contests, edit contests, add/edit judges, monitor any contest he created, override any of the judges’ solutions, etc. all through a GUI, using the AdminUI Module. He edits contest databases, using the Contest Module, which contains a database connection.
3.1.20 Contest
Identification: (CON)
The contest module allows an administrator to edit the details of a particular contest, the judge details and/or the contestant details for that contest, etc. through its interface. This is the only module that provides access to that contest details for the administrator.
3.1.21 Language
Identification: (LNG)
This encapsulates all the aspects of a programming language, enabling editing of default language commands, language names, etc. This will be the data format in which the language information is sent across the network.
3.1.22 Problem
Identification: (PRO)
Like language, this encapsulates all the information about a single problem of the programming contest, including its source file, all the test cases, points, etc providing accessors and mutators.
3.1.23 JudgeUI extends javax.swing.JFrame
Identification : (JG)
This handles the graphical user interface for the judge. This interacts with the judge, to perform certain functions of the judge when events occur.
3.1.24 AdminUI extends javax.swing.JFrame
Identification: (AG)
This handles the graphical user interface for the admin to monitor the contest. This has an object of Admin and performs the required actions by calling the functions of Admin when there are events.
3.2 Concurrent Process Decomposition
As per [1], we present an alternative design view of the system in this section by presenting the Concurrent Process decomposition. Here we deal with all the independent processes and threads that are executing during the running of the system. Since we have already described the various functions and members in the Module dependencies we shall only look at the basic function of the threads and their interdependence.
3.2.1 The Database ServerType: Process
The functions handled by the database server are as follows:
• Acts as a source of information for the administrator, the contestants, and the judges.
• Enables insertion/modification of information about the contests, the contestants and the judges based on authentication.
• Entertains various administrator requests for configuring the contest.• Maintains the rankings and the current status of each team.
MySQL V5.0 is used to implement the Database Server.
3.2.2 Web ServerType: Process
The Web Server acts as an interface between the contestant and the Database Server. This enables contestants from all over the world to participate in the contest without having to download/install/run any code on their machine. It services the various requests from the contestants based on authentication of passwords provided by them during the registration. It also enables contestants to submit source codes for the problems in the contest.
The Apache HTTP Server V2.0 is used to implement the web server for the following reasons:
• It is an opensource HTTP server for modern operating systems.• It is a secure, efficient and extensible server that provides HTTP services in sync
with the current HTTP standards.• It is capable of handling concurrent requests robustly.
PHP (PHP Hypertext Processor) is used to host pages on the web server and process dynamic data provided by the contestants. The contestants interact with the database server of the contest through these pages.
3.2.3 Web BrowserType: Process
The pages hosted on the Web Server are displayed to the contestant through a Web Browser. It also facilitates transfer of data supplied by the contestant to the Web Server. Themis shall not deal with the design and implementation of the Web Browser. The contestant can use any standard Web Browser that supports PHP.
3.2.4 The Admin Process:Type: Process
The administrator runs a separate process during which he creates, modifies and starts Contests and monitors their execution. This includes a Graphical User Interface (GUI) which is event driven in which actions are initiated through an interaction with the GUI.This process also interacts with most of the databases that are used in the system to modify various settings and create new entities required by the system.
Functions: • Waits for events from the Administrator and perform these operations in an event
driven manner.
• The first process to be run on the Server end, it interacts with the Admin and performs configuration tasks and also initiates creation and running of a Contest.
3.2.5 The Server process:Type: Process
This process is run at the server end and this process handles all the interaction with the Judges in a clientserver model. This process constitutes a major part of the back end of the system .It spawns a number of individual threads to service Judges (Client) on a network through a ClientServer framework and also interacts with the databases used in the system.
Functions:• Backend process• Interacts with all the Judges over a network in a ClientServer model.• Performs all operations based on the Judge interactions.
3.2.6 The Server Sockets:Type: Thread
The server process spawns two threads which accept connections from Judges over a network through sockets. The sockets serve the function of establishing connections in different ports for independent communication in both directions. On receiving a connection request from a client each of these two threads spawn another new thread to communicate with that particular Judge(client).
Initiator: The Server ProcessFunctions:
• Used to implement the ClientServer model.• Waits for connections from the Judges (clients) and establishes connections.• Creates individual threads to communicate with each of the judges.
3.2.7 Server to Judge CommunicatorsType: Thread
For every judge we have two threads (Sender and Receiver) for providing communication in both directions independently.
Initiator: Server Sockets
Sender:
Functions:• Establishes connection and authorizes the judges.• Communicate initial information including some handshake information.• Sends data (Server requests) to the Judges (independently).
Receiver
Functions:• Establishes connection and authorizes the judges.• Receiver data (Judge Responses/Requests) to the Server (independently).
3.2.8 The Judge Process:Type: Process
This is an independent process which interacts with the judge on his machine viz. a GUI and performs various actions chosen by him. The judge system spawns two threads to communicate with the Server for communication in both directions independently.
Functions:• Performs all the processing of the judges like judging different runs, answering
queries and communicating with the server.
3.2.9 Judge to Server Communicators:Type: Thread
The judge process creates two threads to communicate with the Server during the running of the Programming contest.
Initiator: Judge Process
Sender:
Functions:1. Tries to establish connection with the server and tries to authorize itself.• Sends data (Judge Responses/ Requests) to the Server (independently).
Receiver:
Functions:• Tries to establish connection with the server and tries to authorize itself.• Communicate initial information including some handshake information.• Receive data(requests) from the Judges and put them on a queue for processing.
3.2.10 The Judge GUI Process:Type: Thread
The GUI process acts on an event and calls the corresponding Judge method.
Functions:• Interacts with the Judge on his machine through a GUI.• Performs actions through an eventdriven mechanism based on input from the
judge.
3.2.11 The Admin GUI Process:Type: Thread
The GUI process acts on an event and calls the corresponding Admin method. Functions:
• Interacts with the Admin on his machine through a GUI.• Performs actions through an eventdriven mechanism based on input from the
Admin.
3.3 Data Decomposition
This section contains information about all the various data entities that are being used by the software. We first describe the databases that will be in use, then the log file, and finally the software configuration file(s).
3.3.1. Databases
Databases located in the server machine, referred to henceforth as the global tables.
Admin Database
Admin ID Name Password Age Sex
This table contains information about the administrators on that system, which will be used for admin authentication, etc. A new administrator can only be created by any existing administrator. The Admin GUI shall be the only application to read from and write to this database.
Contest Database
Contest ID
Owner Admin
Name Date Start Time
Duration Website Max Contestants per Team
Details of all the contests that have been and will be conducted are recorded in this table. Contest Settings and Details such as Name, Owner (should be an administrator on the server machine), Date of Contest, Start Time, Duration, etc. are stored here. The Admin GUI shall be the only application to interact with database as well.
Databases on a percontest basis, referred to as the local tables. They will be stored in a subfolder, say the “contest nameyear” folder.
Team Info Database
Team ID Team Name Password F1 F2 F3 … Fn Status
This table has information about the teams that have registered to take part in a particular contest. F1, F2, …, Fn are fields created by the administrator to contain additional information needed about the teams for each contest. These fields shall be referred as the “Admin chosen fields” in the future. The domain type of each field is specified in another table. Status field contains the disqualification status of the team.
Admin Specified Field Database
Field Name Domain Optional/Mandatory
Details about the “Admin chosen fields” are stored in this table. The field name, the domain of the field (like an integer, a string, etc), and whether or not that
particular field information is mandatory or optional are stored and will be retrieved and used whenever a team registers for the contest.
Judge Info Database
Judge ID Name Password
This table records essential details about the judges who will be evaluating the submissions for that contest.
Judge Evaluation Preferences Database
Judge ID Problem No.
Preferences about which judge will evaluate which problem are stored in this table.As per the SRS, this permits one judge evaluating many problems, and many judges correcting the same problem.
Problem Info Database
Problem No. Problem File Max. No. of Submissions
Contest Problem details like the problem no, problem statement source file, and maximum allowed submissions for that problem are stored in this database.
Test Case Info Database
Problem No.
Test Set File
Answer Set File
Time Limit
Memory Limit
Points
For each problem, the test set files, corresponding answer set files, time limits, memory limits and points to be awarded are stored in this table.
Evaluated Submissions’ Status Database
Problem No. Team ID Time of Submission Submission No ScoreSource File
LngId Judge ID Error Report File Mode of Evaluation Status
Once a submission has been evaluated by the judge and the submission status received by the server, the details are added to this database.Status has the evaluation status – whether the solution was accepted, or had a compilation error, or a run time error, etc.If Status is an error, the error report file field has the link to the file containing the error output of the compilation/execution.
Ranking and Result Database
Team ID Team Name Rank Q1 Q2 … Qn Total Points
This table is used to obtain dynamically, the rankings of each team, and the final results ad well. Q1, Q2, …, Qn are fields that contain the points obtained by the team in problems 1,2,…,n respectively.
This database is actually a view derived from the EVALUATED SUBMISSIONS’ STATUS DATABASE and the TEAM INFO DATABASE. This database shall be used for directly reading off the rankings during the contest and obtaining the final results after the contest.
Unsent Submissions Database
Team ID Problem No LangId Submission No Source File Path
This database will have the submissions that have just arrived. The server will retrieve submissions from this, assign a judge to evaluate the submission, and transfer the submission data (like the source file, problem No. etc.) to the chosen judge. Once the server sends the file across, it shall also delete the corresponding row from this database and add it to the one described below.
Sent but unevaluated Submissions Database
Team ID
Problem No
LangId Submission No
Source File
Assigned Judge
Send Time
This database holds entries of all submissions that have been sent to the judge but whose evaluation results haven’t reached the server yet. This comes in handy whenever a judge machine fails (and/or the application crashes) during evaluation of a submission. The server will identify submissions that have remained uncorrected for a long time by polling this database, and try to resend the data across.
Answered Queries Database
Query No Query Team ID Reply Status Judge IDBroadcast/Direct Query Time Query
Priority Reply Text Question No
Information about all the queries posted by the teams, the replies given by the judge(s), etc. is stored in this database. The web server shall use this database, to display all queries on the contest pages.
Unsent Queries Database
Team ID Problem No Query No Query File Path
Just like the unsent submissions database, this one is for queries that have not yet been sent to any judge.
Sent but unanswered queries database
Query No
Team ID
Problem No
Assigned Judge
Query File Path
Send Time
This database is for storing those queries that have been sent to some judge but not yet answered, like the corresponding database for submissions.
3.3.2 Log File
In addition to the above mentioned databases, a log file of contest proceedings shall also be maintained to detect malicious events that go unnoticed by the software during the contest. The log file will be created once the contest starts and will constantly record the following events, noting down the time of occurrence too.
• Admin Signing In/Out• Team/Judge Signing In• Team/Judge Signing Out• Submission• Evaluation Results for submissions• Message broadcast by the judge• Admin Overrule – this happens when an admin overrules a judge’s evaluation of a
submission
3.3.3 Data Structures
JudgeReq – Stores the request of a judge, at the server side.
Member Prototype Member Descriptionint judgeId; Stores the judge Id to uniquely
identifying him.int reqType; Has the type of Request stored in itEvalSubData esd; A reference to EvalSubDataEditJDetails ejd; A reference to EvalSubDataQueryResp qres; A reference to EvalSubData
EvalSubData – Evaluated Submission Data sent back.
Member Prototype Member Descriptionint prNo; The problem number of the
evaluated problemint subNo; The submission number of the
solution evaluatedint score The score for the problemint status The status of the result
(WA,TLE,CA)char modeOfEval Whether manual/automatedint judgeId The judgeId who evaluated itString errorRepFile The error Report File
QueryResp – Query Response.
Member Prototype Member Descriptionint prNo; The problem number of the queryint queryNo; The query number of the queryint priority The priority as rated by the judgeint status Whether answered/notint judgeId The judgeId who answered itString responseFile The response File NameInt broadcastOrNot Whether the answer is to be
broadcasted or not
JudgeInfo – Information about a judge.
Member Prototype Member Descriptionint jId; Stores the judge Id to uniquely
identify him.String passwd Stores the modified password String uName Stores the user nameint[] ProbNos List of problems that he can
evaluate
AdminInfo Information about an admin.
Member Prototype Member Descriptionint AdminId; Stores the admin Id to uniquely
identify him.String passwd Stores the modified password String uName Stores the user nameint[] contests List of all contest IDS for the
contests he owns
ContestantInfo – Information about a contestant/team.
Member Prototype Member Descriptionint cId; Stores the Contestant Id to uniquely
identify him.String passwd Stores the modified password String uName Stores the user name
ContestInfo – Contest Information.
Member Prototype Member Descriptionint coId; Contest IDInt AdminID AdminID of ownerString Name Name of the contestDate occursOn Date of occurrence of contestTime startTime Starting TimeTime Duration Duration of the contestString website The Hosting website addressint MaxContestants The maximum no. of contestants
ServerReq – Request by a server to the judge. (Common Request)
Member Prototype Member Descriptionint type The type of the request –
query/submissionint ID Corresponding request type Id No.int timeOfArrival Time of arrival of the requestint prNo The problem number of the
submission/queryString filename The file name of the code/query
text
SubmissionRequest – Specific Submission Request.
Member Prototype Member Descriptionint prNo; The problem number of the
evaluated problemint subNo; The submission number of the
solution evaluatedint modeOfEval Whether manual/automatedString sourceFile The Source Program FileInt LanguageNo ID of the language of submission
QueryRequest – Query Request from server.
Member Prototype Member Descriptionint prNo; The problem number of the queryint queryNo; The query number of the queryString queryFile The query File Name
TestCase – Test Case Information about a problem.
Member Prototype Member Descriptionint tcNo; Test Case number(within the
problem)String tcInput; The input file name for that test
caseString solFile The expected solution fileint marks Marks for getting the test case right
4 Dependency Description
This section describes the various interactions and relationships among entities. It identifies the dependent entities, describes their coupling, and identifies the required resources. It specifies the type of relationships that exist among the entities such as shared information, prescribed order of execution, or welldefined parameter interfaces.
4.1 Module Dependencies
Here we look at the interdependencies between the modules we described in Section 3. We represent these using the dependency matrix. We refer to the modules by the identifications assigned to them in Section 3.
MDM SM FM PM APM MM FUMMDM NIL X X X X X X
SM SC NIL SC CC CC X X
FM X X NIL X X X X
PM SC SC, CC SC NIL CC SC SC
APM SC SC, CC SC CC NIL X X
MM X X X X X NIL X
FUM SC SC, CC SC X X X NIL
DBA SVR SST SJCT SJS SJR SJD JDG JSCT JSS JSR ADM CON LNG PRO JG AGDBASVR SC SC DCSST EC ECSJCTSJS ECSJR SC ECSJDJDG SC SC
JSCTJSS EC ECJSR EC EC SCADM DC SCCON SC DC DCLNGPRO
JG SC
AG SC
Legend
SC Stamp Coupling CC Content Coupling EC External Coupling DC Data Coupling
4.2 Concurrent Process Dependencies
Here, we describe the dependencies between the various concurrent processes running in the system. Since these are threads that run simultaneously, we must ensure that they interact in a manner that avoids data inconsistencies and equitable request handling.
The Web Browser displays data that is generated dynamically by the Web Server. The Web Browser can interact with the Database Server only through the Web Server. Therefore, the functionality of the Browser depends on the Web Server.
The requests serviced by the Web Server are typically accessing and updating the data present in the database. For this reason, the Web Server interacts with the Database Server. Thus, in order to generate / update data correctly and handle requests efficiently, the Web Server depends on the Data Server – this constitutes a dependency between these two processes.
The Database Server is an independent process that runs and functions independent of any of the other processes. It only services requests from all of its clients and does not depend on any other process for its own functioning.
For the judge, admin, server modules, the process dependency is in fact, very similar to the module dependency, as the main processes are themselves modules.
4.3 Data Dependencies
As such, there is no data dependency found in our design, as the databases are all independent, and the data structures too are not dependent on each other.
5 Interface Description
This section describes the interfaces of all the modules and other design entities described in Section 3 of this document. This helps the designers, programmers and testers to correctly use or develop the functions provided by an entity.
5.1 Module Interface
Here, we tabulate the interfaces to each of the functions in the modules described in Section 3. We mention both the signature of the function along with a brief description of what it does. Additionally we have also mentioned the data members and other private functions.
5.1.1 Session module
Method Prototype Method Descriptionfunction startSession() Performs all actions to start a
session. Checks if team has already logged in.
function checkLogin() Checks if a session with the team has already been established. Checks if team has been remembered. If so, the database is queried to make sure of the team’s authenticity.
function login($subteam, $subpass, $subremember)
Verifies password and team name from the database and checks for all possible errors. Called by Process.
function logout() Logs team out of the session – deletes cookies, unsets session variables, etc. Called by Process.
function register($subteam, $subpass, Checks if team name, password
$subemail) and email satisfy all conditions – registers if so, returns if not. Called by Process.
function editAccount($subcurpass, $subnewpass, $subemail)
Verifies current password and if right, sets new password and email after checking for conditions. Called by Process.
function isAdmin() Check if the current user is the Administrator.
function generateRandID() Generates a random alphanumeric string and hashes it using MD5.
function generateRandStr($length) Generates random alphanumeric string of specified length. Called by Process.
5.1.2 Form module
Method Prototype Method Descriptionfunction setValue($field, $value) Records the value typed into the
given form field by the contestant.
function setError($field, $errmsg) Records new form error given the form field name and the error message attached to it.
function value($field) Returns the value attached to the given field.
function error($field) Returns the error message attached to the given field.
function getErrorArray() Returns the array of error messages.
5.1.3 Process Module
Method Prototype Method Descriptionfunction procLogin() Processes the submitted login form
if errors are found, the team is redirected to correct the information,if not, the team is logged in to the system.
function procLogout() Attempts to log the user out of the system.
function procRegister() Processes the user submitted registration form, if errors are found, the team is redirected to correct theinformation, else, the team is registered with the system. Sends email to the team.
function procForgotPass() Validates the team name, generates a new password and mails it to the team’s email id.
function procEditAccount() Edit’s team information after verifying password.
5.1.4 Admin Process module
Method Prototype Method Descriptionfunction procUpdateLevel() Updates team’s privilege level
according to admin’s request.function procDeleteTeam() Deletes registered team name from
the database.function procDeleteInactive() Deletes all inactive teams from the
database.function procBanTeam() Bans specified team i.e deletes
from database, adds to banned teams table.
function procDeleteBannedTeam() Removes team from banned teams list.
function checkTeamname($tname, $ban=false) Verifies if team name is allowed string.
5.1.5 Mailer module
Method Prototype Method Descriptionfunction confirmRegister($team, $email, $pass) Sends a mail – with team name &
password to the team confirming registration.
function sendNewPass($team, $email, $pass) Mails a newly generated password to the team.
5.1.6 File Upload module
Method Prototype Method Descriptionfunction file_upload() Sets parameters for file upload.function show_error_string() Displays any error message produced.function set_file_name($new_name = "")
Changes uploaded file name.
function upload($to_name = "") Uploads file from contestant to the server.function get_extension($from_file) Gets extension of the file.function validateExtension() Validates file extension against allowed
extensions.function show_extensions() Shows all allowed file types.function move_upload($tmp_file, $new_file)
Moves uploaded file from temp directory to new directory.
function check_dir($directory) Checks if specified directory already exists.function get_uploaded_file_info($name)
Obtains info about the uploaded file.
function del_temp_file($file) Deletes temporary file uploaded on server.function error_text($err_num) Maps error messages to error numbers.
5.1.7 MySQL Database module
Method Prototype Method Descriptionfunction confirmTeamPass($teamname, $password)
Validates team name and password from the database. Called by Session.
function confirmTeamID($teamname, $teamid) Validates session ID for the team. Called by Session.
function teamnameTaken($teamname) Checks if a team name already exists in the database. Called by Session, Process.
function teamnameBanned($teamname) Checks if a team has been banned. Called by Session.
function addNewTeam($teamname, $password, $email)
Adds a new team to the team info database. Called by Session.
function updateTeamField($teamname, $field, $value)
Updates info for a particular team. Called by Session and Process.
function getTeamInfo($teamname) Obtains info for a given team from the database. Called by Session and Process.
function getNumTeams() Counts number of registered teams. Called by Admin Process.
function calcNumActiveTeams() Calculates number of teams active currently.
function addActiveTeam($teamname, $time) Adds info about an active team to the database. Called by Session.
function removeInactiveTeams() Deletes info about inactive teams from the database. Called by Session.
function query($query) Performs the given query on the database and returns the result.
5.1.8 Class DatabaseAccess
Method Prototype Method DescriptionDatabaseAccess() Constructor – Opens the connection to
the databaseJudgeInfo getJudgeDetails(String name)
Obtain all details of a judge
JudgeInfo getJudgeDetails(int JID) Obtain all details of a judge, given his ID
Int setJudgeInfo(JudgeInfo j) Sets the judge information of a judge(edits/adds to the table)
ContestantInfo getJudgeDetails(String name)
Obtain all details of a contestant
ContestantInfo getJudgeDetails(int CID)
Obtain details of a contestant, given his ID
Int setContestantInfo(ContestantInfo j) Sets the contestant information of a contestant(edits/adds to the table)
AdminInfo getAdminDetails(String name)
Obtain all details of an admin
AdminInfo getAdminDetails(int CID) Obtain all details of an admin, given his ID
Int setAdminInfo(AdminInfo j) Sets the admin information of an admin(edits/adds to the table)
ContestInfo getContestDetails(String name)
Obtain contest details
ContestInfo getContestDetails(int CoID)
Obtain contest details, given its ID
Int setContestDetails(ContestInfo c) Set the contest Information(edit/add)Int DeleteJudge(int JID) Delete a JudgeInt DeleteContest(int CID) Delete a contestInt DeleteAdmin(int AID) Deletes an AdminSubmissionRequest GetUnevaluatedSubmission()
Returns an unevaluated submission from the corresponding table
Int deleteSubmissionFromUnsentTable(int sid)
Deletes from the UNSENT DATABASE
Int addSubmissionToSentTable ( SubmissionRequest s, int time)
Adds the submission to the SENT DATABASE
Int addResultToSubmissionDatabase ( EvalSubData x)
Adds the results of an evaluation to the main submission database
QueryRequest GetUnAnsweredQuery() Returns an unanswered query from the corresponding table
Int deleteQueryFromUnsentTable(int qid)
Deletes from the UNSENT DATABASE
Int addQueryToSentTable( QueryRequest q, int time)
Adds the query to the SENT DATABASE
Int addResponseToQueryDatabase( QueryResp x)
Adds the response of a query to the main query database
Int[] getJudgesProblems(int JID) Gets the problems that the judge can evaluate
Int[] getJudgesProblems(String name) Does the same as the above, given nameProblem getProblemInfo(int pid) Returns all information pertaining to the
problem specified.
5.1.9 Class Server
Member Prototype Member DescriptionDatabaseAccess database Reference to the object through
which all database access is done.SocketServerTh servSock1; Has an object called servSock
which receives all the client connections and spawns threads to service each Judge client.
SocketServerTh servSock2; This is used to reference the Socket that receives the second connection from judges
LinkedBlockingQueue<JudgeReq> jUpdations; Maintains a queue to service all Judge requests and results. This includes mainly updating database entries.
ServerJDetails[] details Stores all the required information about the judges.
Method Prototype Method DescriptionServer() Constructor for the classint authenticate(String username, String passwd); This authenticates judges who
attempts to login to the server by validating their user name and password and returns the judge ID if successful of authentication.
void addJudge(int judgeId,ServerJSend s); void polling(); Keeps polling/searching the
database to check if any new Submission or Query is to be processed.
int scheduleJudge(int type,int prNo); Allocates a judge for servicing a current request(query/submission based on type) and based on the problem Number.
int sendToJudge(int type,int id); Invokes a call to send a submission/query (id identifies it) to a particular judge.
int addJudgeRequest(JSReq); Add the Judge Requests to the queue. The calling method should not have multiple instances(threads) calling it simultaneously.
int editJudgeRequest(JDetails jd); Stores the changes a judge makes to his profile.
int processEvalSub(EvalData e); Stores the result of an evaluation from a judge and update it to the database.
int processQuerySub(QueryResp q) Stores the response from a judge in the database and act accordingly.
int processJudgeReq(); Picks few entries from the Queue and processes them. It will call editJudgeReuest , processEvalSub or processQueryResp according to the type.
void setJudgeThreads(int judgeNo,ServerJSend sjsend,ServerJRecv sjrecv)
It will set the objects corresponding to the two connections that handles the particlar judge.
Void timeOutSched(); It will check the database for all those submissions that have timed out and service them again.
5.1.10 Class SocketServerTh extends Thread
Member Prototype Member DescriptionServerSocket servSock; This has an object of the java.net
class ServerSocketServer serv; Stores a reference to the Server for
which it is processing(needed for some updation).
int portNo; Stores the port number that will receive this communication.
Method Prototype Method Descriptionrun() This instantiates the thread.This
will contain the basic functionality of the class
SocketServerTh(Server serv); The constructor that instantiates the objects of this class.
5.1.11 Class ServerJCommTh extends Thread
Member Prototype Member DescriptionSocket socket; This has an object of the java.net
class SocketServer serv; Stores a reference to the Server for
which it is processing(needed for some updation).
Int judgeId Stores the Judge ID this thread refers to
String username Stores the userName of the corresponding thread
int portNo; Stores the port number that will receive this communication
Method Prototype Method DescriptionServerJCommTh() Constructor for this classrun() This instantiates the thread.This
will contain the basic functionality of the class
ServerJCommTh(Server serv); The constructor that instantiates the objects of this class.
int authenticate(String username,String passwd) Authenticates the user by using the Server’s function.
5.1.12 Class ServerJSend extends ServerJCommTh
Member Prototype Member DescriptionLinkedBlockingQueue<ServerReq> This stores a Queue for sending
Server requests to the judges.
Method Prototype Method DescriptionServerJSend() Constructorrun() This instantiates the thread.This
will contain the basic functionality of the class
int sendInitialInfo() Sends the intial Information after Judge Logs in
addReqToQ(ServerReq) Adds a Request to the QueuesendServReq(ServerReq) Sends this request to the Judge
5.1.13 Class ServerJRecv extends ServerJCommTh
Member Prototype Member Description
Method Prototype Method Descriptionrun() This instantiates the thread.This
will contain the basic functionality of the class
synchronized int addToServerQ(JSReq) Adds this task to the Server processes. Only one of the many thread must be allowed to access this function because this will modify the Server Database.
ServerJRecv() Constructor for the classInt receiveInitialData() Receive initial data from the judge
5.1.14 Class ServerJDetails
Member Prototype Member DescriptionJudgeInfo judge Basic Information about the judgeServerJSend sjSend Identifies the thread to use for
sendingServerJRecv sjRecv Identifies the thread to use for
receivingint status; Status of the connection is storedint noSubReqs Stores the no. of Submission
evaluation requests being processed by the judge (for choosing the judge for next processing).
int noQueries Stores the number of Query requests being processed by the judge.
List<int> subReqs Stores the Submission Request Numbers
List<int> queryReqs Stores the Query Request Numbersint lastConnTime Stores the last Connection timeint[] langs The languages that the judge has .int modeOfEvaluation The mode of evaluation that the
judge wants to use(either manual/automatic). If manual it will ask him how to evaluate each of the problems.
Method Prototype Method DescriptionServerJDetails(int jId) Constructor for the classServerJDetails(StringStream) To convert data from another
format to this. ServerJDetails(StringStream) To convert data from another
format to this.checkTimeout() Checks whether this process can get
timed out.
5.1.15 Class Judge
Member Prototype Member DescriptionJudgeInfo judge Basic Information about the judgeint connStatus Stores the status of the connectionint TimeOfLoggingIn Stores the time it logged into the
systemLinkedBlockingQueue<SubmissionRequest> subReqs
This stores a Queue for receiving submission evaluates requests from the Server.
LinkedBlockingQueue<QueryRequest> queryReqs
This stores a Queue for receiving query from the Server.
JudgeSSend sSend Reference to the thread used for sending data
JudgeSSend sRecv Reference to the thread used for receiving data
Languages[] langs Stores details of all Languages that
can run on this machineMethod Prototype Method DescriptionJudge() Constructor for the classint login(String username, String passwd); Sends data for logging in to the
systemvoid changeDetails(String username,String passwd,int[] languages);
Sends the profile changes by adding it to the Sender Queue
void changePasswd(String passwd) Changes the password by verifying the the old password.
int Evaluate(Submission s) Evaluates a particular submissionint autoEvaluate(Submission s) Automatic Evaluation Modeint manualEvaluate(Submission s) Manual Evaluation Modeint answerQuery(Query s) Sends the query with answer to the
serverint addReqToQ(ServerReq) Adds a Request to the Queueint reconnect() Reconnects the judge, on accidental
connection cutsint validateLangs() Validates all the language compiler
paths provided by the jugde on his machine.
5.1.16 Class JudgeSCommTh extends Thread
Member Prototype Member DescriptionSocket socket; This has an object of the java.net
class SocketJudge judge Stores a reference to the Judge for
which it is processing(needed for some updation).
Method Prototype Method DescriptionJudgeSCommTh() Constructor for this classrun() This instantiates the thread. This
will contain the basic functionality of the class
JudgeSCommTh(Judge jud); The constructor that instantiates the objects of this class.
int authenticate(String username, String passwd) Authenticates the user with the judge.
5.1.17 Class JudgeSSend extends JudgeSCommTh
Member Prototype Member DescriptionLinkedBlockingQueue<JudgeReq> This stores a Queue for sending
Judge requests to the server.
Method Prototype Method DescriptionJudgeSSend() Constructorrun() This instantiates the thread.This
will contain the basic functionality of the class
int sendInitialInfo() Sends the intial Information after Judge Logs in
addReqToQ(JudgeReq) Adds a Request to the QueuesendServReq(JudgeReq) Sends this request to the Server
5.1.18 Class JudgeSRecv extends JudgeSCommTh
Member Prototype Member Description
Method Prototype Method Descriptionrun() This instantiates the thread.This
will contain the basic functionality of the class
synchronized int addToJudgeQ(ServerReq) Adds this request to the judge processing queue.
JudgeSRecv() Constructor for the classInt receiveInitialData() Receive initial data from the Server
5.1.19 Class Language
Member Prototype Member Descriptionint langId Unique keyString nameOfLang Name of the Languageint type Kind of Language Eg. whether it is
only Compilation based like C or like JAVA using a JVM
String usualCLinuxPath The usual Path name of Compiler/command in Linux
String usualCWindowsPath The usual Path name of Compiler/command in Windows
String usualCMacPath The usual Path name of Compiler/command in Mac
String usualRLinuxPath The usual Path name of running command in Linux
String usualRWindowsPath The usual Path name of run command in Linux
String usualRMacPath The usual Path name of run command in Linux
Method Prototype Method DescriptionLanguage(String name) ConstructoreditLanguage(String name,int type) To change the setting of the
Language(by admin)
5.1.20 Class Problem
Member Prototype Member Descriptionint prNo; The problem number of the
evaluated problemString probTextFile File name having the problem textint noOfTestFiles No. of test files that have to be runTestCases[] testcase Details of the test cases for that
problemint maxScore Total Score for that problemint type Type/category of the problemMethod Prototype Method DescriptionProblem(String name) ConstructoreditProblem() To change the settings/content of
the Problem (by admin)
5.1.21 Class Admin
AdminInfo admin Stores Information about adminint contested The contest that the Admin is
currently viewingint[] contestIds The IDs of the contests that this
admin has control overContest[] contests The contests that the admin is
currently controllingDataBaseAccess dba To access the global databaseMethod Prototype Method DescriptionAdmin() Constructor for the classvoid getAdminDetails(); Gets the Admin detailsVoid editAdminDetails(String username,String passwd,String name,int age,char sex);
To change the Admin details in the database
void changePasswd(String passwd) Changes the password by verifying the the old password.
void createContest() Creates a contest that will be owned
by himint selectContest(int cNo) Chooses one of the contests
controlled by him as the current Contest
void editContest() Edit the contest detailsint runContest(Contest c) Start running a particular contestint editSubmissionDetails() Marks a problem for reevaluationint authenticate(String usrName, String passwd) Authenticates the login
5.1.22 Class Contest
ContestInfo contest Basic contest informationString dbName The name of the database DatabaseAccess db The database class which it
interacts with.Method Prototype Method DescriptionContest() Constructor for the classvoid editContest() Change the contest detailsvoid createJudge() Creates a new judge and his
corresponding loginvoid editJudge() Change the judge detailsvoid createContestant() Create a new Contestant and a
corresponding loginvoid editContestant() Edits the contestant detailsvoid addQuestion() Creates a problem/question in the
contestvoid editQuestion() Edit the problem detailsvoid addLanguages() Adds a Language to be supported
by the contestvoid editLanguages() Edit a Language detailsgetSubmissionDetails(int n) Gets the last n submission detailsvoid editSubmission() Marks the submission for
reevaluation /reevaluates it himselfint reEvaluation(int subNo) Reevaluates a submission
5.1.23 GUI (class JudgeUI, class AdminUI)
Since the layout of the GUI for the judge and admin is not fully understood at this level, we only give a brief description of the Java classes that will be used and a few screenshots of how the GUI might look.
The JudgeUI class will have an object of Judge, and viceversa. The need for the former dependency is that depending on what is selected in the GUI, the corresponding function of the Judge class need to be called. The latter dependency is to handle a situation when a query is sent to a Judge class. This should open a window in GUI displaying the query to the judge. The AdminUI class will have an object of Admin to invoke the functions of the Admin class when an action event occurs.
JButton is used for creating buttons to which ActionListener(s) are added to perform a function when there is an ActionEvent on the the button by calling the actionPerformed(ActionEvent evt) function. The GUI classes will also use JTabbedPane for implementing various functionalities of the Admin and Judge by means of tabbed windows.
For a judge, there will be separate tabs for viewing unjudged runs, changing the settings for the judge, answered and unanswered queries. For an admin, there will be tabs for setting the time fields (start time, remaining time), viewing the team status for all the teams, managing accounts, problems, language options and the queries that have been posted. Each of these tabs may have buttons (JButton), radio buttons (JRadioButton), fields for entering text (JTextField), fields for entering password (JPasswordField), tables (JTable).
The prototype user interface screenshots of the GUI built using NetBeans IDE 5.0 are given below. These prototypes are only meant to be guidelines for the GUI design and changes could be made to the current layout.
Prototype GUI Screenshot 1 (Judge):
Prototype GUI Screenshot 2 (Admin):
5.2 Process Description
Of all the processes listed, the Web Server, Database Server and Web Browser are implemented using external software – Apache HTTP Server, MySQL V5.0 and any web browser software respectively. The interfaces to these processes therefore, are the same as are provided by the corresponding vendors.
Regarding the judge, admin, server, all the processes are basically modules. Hence the interface between processes can be deduced from the Module Description with focus only on those modules that are listed in the processes section.
Appendix: Requirements Traceability Matrix
Here we describe the mapping of the functional requirements specified in SRS[2] to the corresponding sections describing the design modules and processes.
SRS Specific Requirements
Section/Subsection
Corresponding section numbers in SDD
3.2.1 Registration Phase 3.1.2, 3.1.3, 3.1.5, 3.1.7, 3.2.1, 3.2.2, 3.2.3, 5.1.2, 5.1.3, 5.1.5, 5.1.7
3.2.2 Administrator mode 3.1.4, 3.1.19, 3.1.20, 3.1.21, 3.1.22, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 5.1.4, 5.1.19, 5.1.20, 5.1.21, 5.1.22,
3.2.3 Judge mode 3.1.15, 3.1.16, 3.1.17, 3.1.18, 3.2.8, 3.2.9, 5.1.15, 5.1.16, 5.1.17, 5.1.18
3.2.4 Contestant mode 3.1.1, 3.1.2, 3.1.3, 3.1.6, 3.1.7, 3.2.1, 3.2.2, 3.2.3, 5.1.1, 5.1.2, 5.1.3, 5.1.6, 5.1.7
3.2.5 Result mode 3.1.7, 3.2.1, 5.1.7