Contentsdos.iitm.ac.in/OOSD_Material/CaseStudies/CaseStudy1/themis-sdd.pdf · Contents 1. ......

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.


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


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


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


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



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


Method Prototype Method DescriptionJudgeSCommTh() Constructor for this classrun() This instantiates the thread. This


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


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



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


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

Contentsdos.iitm.ac.in/OOSD_Material/CaseStudies/CaseStudy1/themis-sdd.pdf · Contents 1. ......

Documents

Transcript of Contentsdos.iitm.ac.in/OOSD_Material/CaseStudies/CaseStudy1/themis-sdd.pdf · Contents 1. ......