A PRELIMINARY PROJECT REPORT ON

Programming Contest Tool

SUBMITTED TO SAVITRIBAI PHULE PUNE UNIVERSITY, PUNE IN

PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE AWARD OF
DEGREE
OF

BACHELOR OF ENGINEERING (COMPUTER

ENGINEERING)

SUBMITTED BY

Prajkta Patil Exam No:59

Arzoo Barmate Exam No:60
Apurva Bhadage Exam No:61
Ankita Morankar Exam No:75

DEPARTMENT OF COMPUTER ENGINEERING

K. K. Wagh Institute Of Engineering Education &
Research

Hirabai Haridas Vidyanagari, Amrutdham, Panchavati, Nashik-422003

SAVITRIBAI PHULE PUNE UNIVERSITY

2018-19
 SAVITRIBAI PHULE PUNE UNIVERSITY
2018-19

K. K. Wagh Institute Of Engineering Education & Research

CERTIFICATE
This is to certify that the Project Entitled

”Programming Contest Tool”

Submitted by

Prajkta Patil Exam No:59

Arzoo Barmate Exam No:60
Apurva Bhadage Exam No:61
Ankita Morankar Exam No:75

is a bonafide work carried out by Students under the supervision of Prof. R.H.Jadhav
and it is approved for the partial fulfilment of the requirement of Savitribai Phule
Pune University, for the award of Bachelor of Engineering (Computer Engineering).

Prof. R.H.Jadhav Prof.S.S.Sane

Internal Guide H.O.D
Dept. of Computer Engg. Dept. of Computer Engg.
Dr. K. N. Nandurkar
Principal

Place: Nashik
Date:
 ACKNOWLEDGEMENT

It gives us great pleasure in presenting the preliminary project report on ‘System

for Programming Contest’.

We would like to take this opportunity to thank our internal guide Prof. R.H.Jadhav
for giving us all the help and guidance we needed. We are really grateful to them for
their kind support. Their valuable suggestions were very helpful.

We are also grateful to Prof.S.S.Sane, Head of Computer Engineering Department,

CollegeName for his indispensable support, suggestions.

In the end our special thanks to Prof. R.H.Jadhav for providing various resources
such as laboratory with all needed software platforms, continuous Internet connec-
tion, for our Project.

Prajkta Patil
Arzoo Barmate
Apurva Bhadage
Ankita Morankar
(B.E. Computer Engg.)

KKWIEER, Department of Computer Engineering 2018-19 I

 ABSTRACT

Nowadays, in this competitive world it is necessary to use time wisely. There

are many systems for programming contest but not every system provides test cases
and is not institute specific. The aim of this system is to minimize the time consump-
tion required for checking codes and result online. These days when competitions
are held where human intervention is involved, the chances of genuine results are
less. This is a system which can be specially used for institute level for conducting
programming contests. This system helps both the faculty and students by automat-
ing evaluation of codes and immediate result. This system emphasizes on giving
customized access to admin and students. This system enables admin to specify the
problem statement, test cases and timer. Students will be provided online editor and
compiler. After submitting the test, results are evaluated by checking each test case.

KKWIEER, Department of Computer Engineering 2018-19 II

 INDEX

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Definition And Objectives . . . . . . . . . . . . . . . . . . 2
1.3 Project Scope and Limitation . . . . . . . . . . . . . . . . . . . . . 2
1.4 Methodologies of Problem Solving . . . . . . . . . . . . . . . . . . 2

2 Literature Survey 3

3 Software Requirement Specification 5

3.1 Assumption and Dependencies . . . . . . . . . . . . . . . . . . . . 6
3.2 Functional Requirement . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Authentication and Schedules . . . . . . . . . . . . . . . . 6
3.2.2 Submission of files and Timelimit . . . . . . . . . . . . . . 6
3.2.3 Test Cases and Grades . . . . . . . . . . . . . . . . . . . . 6
3.2.4 Visualization and Manual grading . . . . . . . . . . . . . . 7
3.3 External Interface Requirements (If Any) . . . . . . . . . . . . . . 7
3.3.1 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . 7
3.3.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . 7
3.4.1 Performance Requirements . . . . . . . . . . . . . . . . . . 7
3.4.2 Security Requirements . . . . . . . . . . . . . . . . . . . . 7
3.4.3 Software Quality Attributes . . . . . . . . . . . . . . . . . 8
3.5 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
 3.5.1 Database Requirements . . . . . . . . . . . . . . . . . . . . 8
3.5.2 Software Requirements (Platform Choice) . . . . . . . . . . 8
3.5.3 Hardware Requirements . . . . . . . . . . . . . . . . . . . 8
3.6 Analysis Models : SDLC Model to be applied . . . . . . . . . . . . 9

4 System Design 10
4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Mathematical Model . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . 14
4.5 UML Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Project Plan 18
5.1 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1 Risk Identification . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.3 Overview of Risk Mitigation, Monitoring, Management . . 19
5.2 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1 Project Task Set . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.2 Task Network . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.3 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Team Organization . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.1 Team Structure . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.2 Management Reporting and Communication . . . . . . . . 20

6 Project Implementation 21
6.1 Overview of Project Modules . . . . . . . . . . . . . . . . . . . . . 22
6.2 Tools and Technology used . . . . . . . . . . . . . . . . . . . . . . 22

7 Software Testing 23
7.1 Testing Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8 Results 25
8.1 Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

KKWIEER, Department of Computer Engineering 2018-19 IV

 8.2 Screen Shots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

9 Conclusions 27
9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Annexure A 29

Annexure B 32

Annexure C Plagiarism Report 34

Annexure D References 37

KKWIEER, Department of Computer Engineering 2018-19 V

List of Figures

4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2 Layered Architecture used in the System . . . . . . . . . . . . . . . 12
4.3 Venn Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1 System Implementation Plan . . . . . . . . . . . . . . . . . . . . . 19

A.1 Venn Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

List of Tables

7.1 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

 CHAPTER 1

INTRODUCTION
1.1 MOTIVATION

Contest in which new problems and tasks are given to participants often in-
clude a practical component so that participants can show there knowledge and skills.
Usually, this practical part often involves creating a program in order to solve a given
problem. The programs made by each participant (or group of participants) have to
be evaluated by the Examiners of the course. These programs can be evaluated ac-
cordingly to two parameters:
i) whether the program executes as required and
ii) whether participants have implemented the program applying the concepts and
constructs which gives optimized.

1.2 PROBLEM DEFINITION AND OBJECTIVES

To create a system to assist participants and Examiners of programming Con-

test by automating most of the tasks related to evaluating programming tasks and the
evaluation system should help to automate the evaluation process offloading most
of the evaluation work from Examiners also handle participants management help-
ing on all the grouping and schedule issues, managing program reception inside the
Time limit and also managing program grades.

1.3 PROJECT SCOPE AND LIMITATION

System is designed to write, compile and submit c program from participants side
for Contest.
From perspective of Examiners this system allow to submit problem statements and
test cases and grades which will be useful for evaluating prograsms and giving grades
automatically

1.4 METHODOLOGIES OF PROBLEM SOLVING

KKWIEER, Department of Computer Engineering 2018-19 2

 CHAPTER 2

LITERATURE SURVEY
 • Review of the papers, Description , Mathematical Terms

This chapter presents an overview of the some existing automatic program evalua-
tion systems. Automatic Evaluation Systems are systems able to receive the source
code of programs created as solution for given problem, compile and execute them
with a set of test cases and assert the amount of cases passed by the users solution.
This kind of systems are used to support the realization of programming contests and
in several programming contests throughout the world. Some contest systems and
an academic evaluation system are Mooshak UVa Judge,PC 2 and PO Eval. A good
way to better compare the capabilities of the automatic evaluation systems mentioned
above . There are some capabilities of the systems that are not publicly available or
hard to classify in the non-functional requirements field. Being the PC 2 system
composed of a group of desktop application intended to run on a small network with
very few clients, it may not comply by design with many of the requirements. All
the applications mentioned on this section are at their core client-server applications.
All except PC 2 offer a web interface. By going through above systems we can con-
clude there does not exist any system that satisfies all the requirements, though some
comply with several of them. As noted in their respective sections, Some complies
with great part of the management requirements and PCT does a good job concern-
ing the automated evaluation of test cases theoretically.
System Description:
Input: All possible Test cases for given problem and Problem Statement.
Output: Evaluated result of all students with their score.
Functions : Authentication,Security,Editor,Compilation,Submission,Grading.

KKWIEER, Department of Computer Engineering 2018-19 4

 CHAPTER 3

SOFTWARE REQUIREMENT
SPECIFICATION
This section describes in detail the requirements that programming Contest system
should meet. First,This present the Project Scope,functional requirements and then
the non-functional requirements. The desired system should have a set of function-
alities that goes from authentication to the ability of automatically grading a pro-
grams.s

3.1 ASSUMPTION AND DEPENDENCIES

1.Test cases and program should be in given format only

2.Server should not crash in between contest.
3.Registration should be done from system portal only for participants.

3.2 FUNCTIONAL REQUIREMENT

The functional requirements of programming Contest system are:

3.2.1 Authentication and Schedules

The system should allow a participants to authenticate himself unambiguous with

the system since the system is used to evaluate part of his grade in a Contest and
schedule a problem statement to participants.

3.2.2 Submission of files and Timelimit

Participants should be able to upload his source code solution remotely to the sys-
tem.Each submission must be timestamped. the system should allow a Examiners to
submit a participants program after the deadline has reached as some problem arises.
Each system has a deadline. The deadline can be static (a specific date and hour) or
variable.

3.2.3 Test Cases and Grades

The system must be aware of the concept of grades. The Examiners of the Contest
must be able to specify how are the programs criteria and should give Test Cases and

KKWIEER, Department of Computer Engineering 2018-19 6

Grades for same.

3.2.4 Visualization and Manual grading

Apart from the features previously introduced which already impose some user in-
terface requirements, there are some other UI requirements that do not fit any of the
requirements previously listed. Examiners should be able to view and sort partici-
pants submissions and Examiners must also be allowed to download the programs
of the participants in order to be able to do the manual evaluation of the code.

3.3 EXTERNAL INTERFACE REQUIREMENTS (IF ANY)

3.3.1 User Interfaces

GUI

3.3.2 Hardware Interfaces

LAN

3.3.3 Software Interfaces

Browser

3.4 NON FUNCTIONAL REQUIREMENTS

In order to support the functionalities described in Section 3.2, the following non-
functional requirements are desirable:

3.4.1 Performance Requirements

Under normal load the system should be able to run participant programs without
any performance hit and give grades properly

3.4.2 Security Requirements

The system must have secure authentication. The system cannot allow a participant
to see another participant source code.

KKWIEER, Department of Computer Engineering 2018-19 7

3.4.3 Software Quality Attributes

Accessibility: The system should be accessible from a wide variety of locations, be-
ing desirable to have a web interface for both participant and Examiners interaction.
Adaptability: The system must be adaptable. It should be easy to integrate the sys-
tem with other systems.
Auditability: The system, being used in official contests, must be auditable. For
that end the system must log all user interactions with it like for example: date and
time of the submission along with what files were submitted and by whom it was
submitted.
Availability: The system must be able to accept program submissions even if under
heavy load.This may lead to a variation of the Quality of Service taking into account
the load of the system.
Extensibility: The system must be easily extended for new functionalities. It should
be easy to add a new evaluation strategy for when the system is under heavy load or
New language.
Scalability: It is desirable that the system can scale to support a situation where the
number of submissions grows more than it was intended in the first place.

3.5 SYSTEM REQUIREMENTS

3.5.1 Database Requirements

Oracle Database

3.5.2 Software Requirements (Platform Choice)

Tomcat,Java IDE,Browsesr

3.5.3 Hardware Requirements

8 Gb ram

KKWIEER, Department of Computer Engineering 2018-19 8

3.6 ANALYSIS MODELS : SDLC MODEL TO BE APPLIED

Requirement gathering and analysis.

Design.
Implementation or coding.
Testing.
Deployment.
Maintenance.

KKWIEER, Department of Computer Engineering 2018-19 9

 CHAPTER 4

SYSTEM DESIGN
4.1 SYSTEM ARCHITECTURE

The requirement of the system to have high availability in order for the students to
be able to submit their projects, made us choose to decentralize the two main func-
tions of the system evaluation,submission.This way even if the evaluation subsystem
has some issue or is under load, the submission subsystem is unaffected and vice
versa, allowing participants to submit their solutions without problems which from
the point of view of both participants and judges is the crucial activity. If partici-
pants are not able to submit their programs they will not be evaluated. If the files
have been submitted in due time to the Submission Subsystem, they will eventually
be evaluated.
The main component of evaluation subsystem is represented by the evaluation Man-
ager Component. It is responsible for managing all activities and data con- cerning
evaluation of programs and managing the results of those evaluations. Basically it
implements the domain logic of this project and coordinates access to other compo-
nents of the system.

Figure 4.1: System Architecture

This Manager subsystem presents a layered architecture which will have three
layers: the presentation, the business logic and the domain. Layered Architecture

KKWIEER, Department of Computer Engineering 2018-19 11

 Figure 4.2: Layered Architecture used in the System
where the Business Logic and Domain Layers are located in a server and the Pre-
sentation Layer is located wherever the client is accessing the server to get and send
information through Connection. This type of architecture was chosen because this
system had the need to save persistent data , provide ways to manipulate that same
data and then present the results of said manipulations or the data itself to the end
user of the system who is not on the same machine where the system is running

4.2 MATHEMATICAL MODEL

The system takes input from the set IN and gives output as assessment of programs
and grading result to user for ranking or check correct programs, provides a good
way to reduce the required time and human error factor with improving the effi-
ciency. It can efficiently deal with large-scale contest. The proposed system S is
defined as follows:

S= {I, F, O}

I= Set of output obtain from programs of contestants.

KKWIEER, Department of Computer Engineering 2018-19 12

 I= {I1, I2...In}

F= Automation testing done to generate the o/p for grading.

F= {F1, F2, F3}

F1: Preprocessing on the storage obtained after the test.

F2: Time required to test each program.

F3: Detection of the overall test quality.

O= Module for score board set.

Figure 4.3: Venn Diagram

4.3 DATA FLOW DIAGRAM

In above diagram flow of the system is there.It is very simplified as user will give
some input via browser then it will be send to the servers where it will get processed.
and stored or retrived according to user control and results will be shown on front.
It is a 3-tier web-application with the middle tier being the application server and

KKWIEER, Department of Computer Engineering 2018-19 13

 Figure 4.4: Data Flow Diagram
the final tier being a relational database.Web application is comprised of many web
pages which can be accessed using a browser. Users have to be authenticated and
authorized by the application for have access of web application. It is is achieved
by password comparison and verified by comparing the role assigned to the user
with the role required to access the resource. This security mechanism prevents par-
ticipants from accessing web pages allowed to judges. The server application is a
Java Servlet implementing the Remote interface. A single Servlet services all client
requests. The server is responsible for logging contest activity, storing uploaded
participants submissions for subsequent grade assignment by a judge and refresh-
ing client scoreboards with the latest standings. Contest activity is maintained as
records in a oracle database table. JDBC APIs allow the server to access and update
the tables. Additionally, creation of reports in the future will be easy. Only one
participants can be used from a machine at a time because of resource constraints.

4.4 ENTITY RELATIONSHIP DIAGRAM

KKWIEER, Department of Computer Engineering 2018-19 14

4.5 UML DIAGRAM

Figure 4.5: Use Case Diagram

KKWIEER, Department of Computer Engineering 2018-19 15

 Figure 4.6: Activity Diagram

KKWIEER, Department of Computer Engineering 2018-19 16

 Figure 4.7: Class Diagram

KKWIEER, Department of Computer Engineering 2018-19 17

 CHAPTER 5

PROJECT PLAN
5.1 RISK MANAGEMENT

5.1.1 Risk Identification

5.1.2 Risk Analysis

5.1.3 Overview of Risk Mitigation, Monitoring, Management

5.2 PROJECT SCHEDULE

5.2.1 Project Task Set

1. Requirement Analysis and Research.

2. GUI Design
3. Coding
4. Testing and Deployment

5.2.2 Task Network

5.2.3 Timeline Chart

Figure 5.1: System Implementation Plan

5.3 TEAM ORGANIZATION

5.3.1 Team Structure

xyz: Requirement Analysis

xyz: GUI Design
xyz: Coding

KKWIEER, Department of Computer Engineering 2018-19 19

xyz: Testing and Deployment

5.3.2 Management Reporting and Communication

KKWIEER, Department of Computer Engineering 2018-19 20

 CHAPTER 6

PROJECT IMPLEMENTATION
6.1 OVERVIEW OF PROJECT MODULES

6.2 TOOLS AND TECHNOLOGY USED

1.Netbeans IDE
2.Apache Tomcat
3.Oracle DB,JSP and Java
4.Browser
5.Gcc Compiler

KKWIEER, Department of Computer Engineering 2018-19 22

 CHAPTER 7

SOFTWARE TESTING
 Table 7.1: Test Cases

Id Test Case Expected Output Actual Output Status Priority Severity

1 Current tab’s url Url of current tab Urls are handled ef- Pass High Blocker
must be handled handled ficiently
2 Authentication Authentication Authentication done Pass Medium Blocker
should be done Properly for Admin
Properly for admin and Student
and student
3 Problem Statement Problem Statement Problem Statement Pass Medium Blocker
assign Operation should assigned assigned randomly.
randomly.
4 CRUD Operations Programs should Programs Pass High Major
for Student save,compile and save,compile and
run. run.
5 CRUD Operations Admin should be Admin can able to Pass Medium Trivial
for Admin able to add and add and remove
remove Problem Problem Statements
Statements and and Details.
Details.
6 Submission After time limit au- Automatic Submis- Pass Medium Blocker
tomatic submission sion Done
should be done.

7.1 TESTING STRATEGIES

• The methods used during the software testing phase directly affect the products
final quality.

• Manual and unplanned testing usually implies doubtful reliability in terms of

software production, not meeting the desired requirements.

• Automated testing is a process that seeks to minimize the subjectivity of man-

ual testing and optimize the available resources.

• To create mechanisms that exploit software requirements with the least possi-
ble computational effort represents a major challenge, and in this scenario the
tools for test case selection are vital to determine the test strategies.

KKWIEER, Department of Computer Engineering 2018-19 24

CHAPTER 8

RESULTS
8.1 OUTCOMES

8.2 SCREEN SHOTS

KKWIEER, Department of Computer Engineering 2018-19 26

 CHAPTER 9

CONCLUSIONS
9.1 CONCLUSION

Shown detailed design and implementation of System for Programming Con-

test, The system has been heavily tested with practice and official contests,
and has shown so far to be very flexible in managing contests with customised
requirements, quite robust as it supported successfully high transactions load
and its automated judging capabilities showed to be very accurate.
A system aiming to become a full Programming Contest System. Further-
more, the system does not require a large number of judge persons to assist in
the management during the contest. PCT distinguishes itself from other sys-
tems by allowing interaction with the system to be web-based and by having
a easy,simple and scalable architecture that enables support for multiple-site
contests and simultaneous online contests.

9.2 FUTURE WORK

For the near future envisage further system development, specially concern-
ing the following issues: 1.Evaluation and Classification of different program-
ming languages(C++,Java).and import export problem statements and solu-
tions. 2.Notifications will be sent using Email and SMS to Participants .

9.3 APPLICATIONS

1.Arrange Programming Contest

2.Platform for practice for Students
3.Exam Conductions

KKWIEER, Department of Computer Engineering 2018-19 28

ANNEXURE A
Problem statement feasibility assessment using, satisfiability analysis and NP
Hard, NP-Complete or P type using modern algebra and relevant mathemati-
cal models

NP-Hard: (Non-deterministic polynomial time hard) in computational the-

ory, is a class of problems that are informally, at least as hard as the hardest
problems in NP*. More precisely, a problem H. As a consequence finding a
polynomial algorithm to solve an NP-Hard problem would give polynomial
algorithms for all problems in NP which is unlikely as many of them are con-
sidered hard. Class of problems which are at least as hard as the hardest prob-
lems in NP, each element of NP, indeed they may not be decision problems.

NP Complete: Class of problem which contains hardest problems in NP,

each element of NP complete has to be element of NP.

Mathematical model: The system takes input from the set IN and gives out-
put as assessment of programs and grading result to user for ranking or check
correct programs, provides a good way to reduce the required time and human
error factor with improving the efficiency. It can efficiently deal with large-
scale contest. The proposed system S is defined as follows:

S= {I, F, O}

I= Set of output obtain from programs of contestants.

I= {I1, I2...In}

F= Automation testing done to generate the o/p for grading.

F= {F1, F2, F3}

KKWIEER, Department of Computer Engineering 2018-19 30

F1: Preprocessing on the storage obtained after the test.

F2: Time required to test each program.

F3: Detection of the overall test quality.

O= Module for score board set.

Figure A.1: Venn Diagram

Conclusion: This system comes in NP Hard convention.This system will be

finding out the time required to search and categorization for given data set.
The correlations among the images label are detected from process. Each
detected possible correlation is processed to see the improvement. This system
is only aiming to improve the categorization of large or small dataset.

KKWIEER, Department of Computer Engineering 2018-19 31

ANNEXURE B
Details of paper publications: name of the conference/journal, comments of
reviewers, certificate, paper.

KKWIEER, Department of Computer Engineering 2018-19 33

 ANNEXURE C

PLAGIARISM REPORT
 PLAGIARISM SCAN REPORT

Words 944 Date April 07,2019

Characters 6347 Exclude Url

100 0
0% 45
Plagiarism % Plagiarized
Sentences
Unique Sentences
Unique

Content Checked For Plagiarism

CHAPTER 1 INTRODUCTION 1.1 MOTIVATION Contest in which new problems and tasks are given to participants
often in- cludeapracticalcomponentsothatparticipantscanshowthereknowledgeandskills. Usually, this practical part
often involves creating a program in order to solve a given problem. The programs made by each participant (or
group of participants) have to be evaluated by the Examiners of the course. These programs can be evaluated
accordingly to two parameters: i) whether the program executes as required and ii) whether participants have
implemented the program applying the concepts and constructs which gives optimized. Depending on the course
and on the Examiners, the evaluation can be just based on the first parameter or on the combination of both of
them. When the con- test has more than a hundred students, evaluating all the submissions is a big effort for the
judges. For the first parameter described, it is possible to define automatic tests that verify the correct behavior of
participants programs but this is not possible for the second parameter that still requires manual verification. The
two main problems that make these systems are hard to create are to ensure the system can always receive
participants programs (availability) and the ability to gracefully endure high load peaks. 1.2 PROBLEM DEFINITION
The purpose of this paper is to create a new system or adapt an existing system in order to assist participants and
Examiners of programming Contest by automating most of the tasks related to evaluating programming tasks. For
Examiners, the evaluation system should help to automate the evaluation process offloading most of the evaluation
work from them. This includes aspects like being easy to create automatic tests and automating the grade
publishing. The system should also handle participants management helping on all the grouping and schedule
issues, managing program reception inside the Time limit and also managing program grades. CHAPTER 2
LITERATURE SURVEY This chapter presents an overview of the some existing automatic program evaluation
systems. Automatic Evaluation Systems are systems able to receive the source code of programs created as
solution for given problem, compile and execute them with a set of test cases and assert the amount of cases
passed by the users solution. This kind of systems are used to support the realization of programming contests and
in several programming contests throughout the world. Some contest systems and an academic evaluation system
are Mooshak UVa Judge,PC 2 and PO Eval. A good way to better compare the capabilities of the automatic
evaluation systems mentioned above . There are some capabilities of the systems that are not publicly available or
hard to classify in the non-functional requirements field. Being the PC 2 system composed of a group of desktop
application intended to run on a small network with very few clients, it may not comply by design with many of the
requirements. All the applications mentionedon this section are at their core client-server applications. System
Description: Input: All possible Test cases for given problem and Problem Statement. Output: Evaluated result of all
students with their score. Functions : GetResult, ShowResult ,GetProblemStatement, AddStudent, SetTimer.
CHAPTER 3 SOFTWARE REQUIREMENT SPECIFICATION 3.1 INTRODUCTION This section describes in detail the
requirements that programming Contest system should meet. First, we present the Project Scope,functional
requirements and then the non-functional requirements. The desired system should have a set of functionalities
that goes from authentication to the ability of automatically grading a programs. 3.1.1 Project Scope System is
designed to write, compile and submit c++ program from participants side for Contest.
FromperspectiveofExaminersweallowtosubmitproblemstatementsandtestcases and grades which will be useful for
evaluating programs and giving grades automatically 3.1.2 User Classes and Characteristics 3.1.3 Assumptions and
Dependencies Test cases and program should be in given format only Server should not crash in between contest.
Registration should be done from this portal only for participants. 3.2 FUNCTIONAL REQUIREMENT The functional
requirements of programming Contest system are: 3.2.1 Authentication and Schedules The system should allow a
participants to authenticate himself uni vocally with the
systemsincethesystemisusedtoevaluatepartofhisgradeinaContestandschedule a problem statement to participants.
3.2.2 Submission of files and Time limit The source code of the participants solution has to be able to be uploaded
remotely to the system.Each submission must be timestamped. the system should allow a Examiners to submit a
participants program after the deadline has ended as some problem arises. Each system has a deadline. The
deadline can be static (a specific date and hour) or variable. 3.2.3 Test Cases and Grades The system must be
aware of the concept of grades. The Examiners of the Contest must be able to specify how are the programs graded
and should give Test Cases and Grades for same. 3.2.4 Visualization and Manual grading Apart from the features
previously introduced which already impose some user interface requirements, there are some other UI
requirements that do not fit any of the requirements previously listed. Examiners should be able to view and sort
participants submissions and Examiners must also be allowed to download the programs of the participants that
belong to their section in order to be able to do the non automatic evaluation of the code. 3.4 NON FUNCTIONAL
REQUIREMENTS In order to support the functionalities described in Section 3.2, the following non- functional
requirements are desirable: 3.4.1 Performance Requirements Under normal load the system should be able to run
participant programs without any performance hit and give grades properly 3.4.2 Security Requirements The
system must have secure authentication. The system cannot allow a participant to see another participant source
code. In order to protect the execution of the system
andthecontentofthetestsaparticipantprogrammustbeexecutedinasandbox. This way, if the submitted code has
malicious instructions it should not be able to affect the normal behavior of the system or corrupt data.
Sources Similarity
ANNEXURE D

REFERENCES
1. Design of Online Runtime and Testing Environment for Instant Pro-
gramming Assessment1
2. Online Judging System for Programming Contest using UM Frame-
work
3. An Analysis Tool for a Programming Contest for High-school Students
4. Programming Contest and Training Platform Based On STM
5. Structural Analysis of Source Code Collected from Programming Con-
tests
6. Online Interactive Educational System for Submission and Evaluation
of Programming Assignments
7. Programming contests in academic environments

KKWIEER, Department of Computer Engineering 2018-19 38