Themis An Automated Online Programming Contest System

Transcription

1 Themis An Automated Online Programming Contest System Software Requirement Specification SRS version Aravindan V (CS03B002) Ravi Shankar K (CS03B018) Sriram Kalyanaraman (CS03B024) Karthekeyan C (CS03B038) Kaushik K L (CS03B039)

2 Contents 1. Introduction Purpose Scope Definitions, Acronyms and Abbreviations References Overview Overall Description Product Perspective System Interface User Interface Software Interfaces Communications Interfaces Operations Site Adaptation Requirements Product Functions User Characteristics Constraints Assumptions and Dependencies Apportioning of Requirements Specific Requirements External Interface Registration Interface Login Interface Admin Interface Judge Interface Contestant Interface Result Interface Functions Registration Phase Administrator Mode Judge Mode Contestant Mode Rankings and Standings 14 2

3 3.3 Performance Requirements Efficiency Fairness Logical Database Requirements Design Constraints Standards Compliance Software System Attributes Reliability Security Portability Change History About 16 3

4 1. Introduction 1.6 Purpose The purpose of this Software Requirements Specifications document is to specify the requirements of Themis, an automated online programming contest engine which is designed as a part of the course CS312 Software Engineering. This document is intended to serve as a formal reference for programming contest coordinators to understand the functionalities of the software. 1.7 Scope Themis is an automated online programming contest engine. This project will cater completely to the needs of educational institutions and organizations, which conduct online programming contests. The system will allow the judges (with secure authorization for judges) to specify the problems, the solution (test cases) and some evaluation criteria or a scoring system for the contest. The system will allow contestants (teams) to register for the contest and submit programs over a network to contest judges. The judges can optionally recompile the submitted program, execute it, view the source code and/or execution results, and send a response back to the team. The system will perform a number of configurable tasks like time stamping and archiving submitted runs, maintaining and displaying current contest standings, and allowing the judges to retrieve and re-execute archived runs. It will also provide a mechanism for contestants to submit clarification requests and queries to the judges, and for the judges to reply to queries and to issue broadcast bulletins to teams. 1.8 Definitions, Acronyms and Abbreviations DBMS: Database Management System. SQL: Structured Query Language, a language for querying a database. MySQL: It is an implementation of the SQL 92 standard. HTTPS: Hypertext Transfer Protocol Secure. HTML: Hypertext Markup Language, a language in which the World Wide Web pages are written. 4

5 TCP/IP: Transmission Control Protocol / Internet Protocol. SSL: Secure Socket Layer. JSP: Java Server Pages. 1.9 References 1. Software Engineering A Practitioner s Approach by Rogers Pressman, 5/e McGraw Hill Publications. 2. PC 2 - the Programming Contest Control System developed at California State University, Sacramento (CSUS) in support of Computer Programming Contest activities of the ACM Overview The rest of the document is organized as follows: Section 2 of the document lists the overall requirements of the software. This section gives a description of the user interface, software interface and the communication interfaces that will be part of the product. The different modes of operation as well as the functionalities, constraints and dependencies of the software are sketched out. Section 3 of the document talks about the specific requirements of the software, at length. Here, the external interfaces along with the different modes available are explained in detail. Other issues like performance and logical database requirements, design constraints and software system attributes like security and reliability are also discussed. Section 4 of the document describes the Change History of the document. Section 5 gives the tools used to write the document. 5

6 2. Overall Description 2.1 Product Perspective This product is independent and self-contained. It is not a part of any larger software and can be used as a standalone product System Interface As this is not a part of any larger system, there are no system interfaces User Interface The product shall offer both a web-based interface and a Window based client interface, which can be operated in the following modes: a. Judge Mode b. Admin Mode c. Contestant Mode Further details on these modes can be obtained in section 3.2 of this document. Both interfaces will be intuitive and easy-to-understand. The interfaces shall contain drop down menus and radio buttons to choose one of many options (e.g. choosing a programming language for program submission). Text boxes shall be provided for input purposes like logging in, posting queries, choosing files for submission, etc. The contestant can submit data by clicking on buttons. The output shall be displayed using message boxes, tables, etc. Since the users of this software are assumed to have prior knowledge of online programming contests and their functioning, the interface will be designed keeping in mind their technical background Software Interfaces This product will be designed and tested to work on the following operating systems: 1. Microsoft Windows 95/98/2000/ME/XP 2. All flavors of Linux (like Debian, Fedora etc) 6

7 It also requires a DBMS to store data related to the contest. The server will use MySQL DBMS software supporting SQL 92 standards. To interface the application program with the database server, jdbc-mysql driver shall be used. To host the contest on the web, we shall use the Apache web server. This server is preferred since it satisfies most of our requirements such as supporting Java Server Pages, dynamic and concurrent page views, standard network security protocols, etc Communications Interfaces The web interface shall use the HTTPS protocol for secure communication with the server. The Window based client shall use the TCP/IP protocol for the same Operations There are three modes of user operations: 1. Judge Mode 2. Admin Mode 3. Contestant Mode The functionalities of the various modes are described in section 3.2. The software will be an interactive operation between the judge and the contestant, with the admin playing a role only in setting up the contest and hosting the server. Interaction between admin and judge / contestant occurs when irregularities are detected. The judge also has an option of enabling correction automatically this is a period of unattended operation. The system also makes logs of all events and backs up data regularly to ensure fast recovery in case of system failure. Logs can also be used to monitor possible foul play during or after the contest Site Adaptation Requirements The default settings shall be made based on standard configurations commonly used in most online programming contests. 2.2 Product Functions The major functionalities that the software shall provide are:- 7

8 Enabling hosts to customize contest settings Enabling participants to test and submit solutions Forum where queries can be posted and answered Manual and automatic evaluation of solutions by judges Dynamic display of contest status including rankings, etc. Web Interface and Window based client interface 2.3 User Characteristics The average user of this product is assumed to be familiar with online programming contests and their functioning. He/she is also expected to know standard terminology like judge, TLE, test runs, submissions etc. We have optimized our interface to suit the needs of such a user. 2.4 Constraints The client side web interface should be browser independent this imposes the constraint of having to use HTML and JSPs as a front-end as opposed to using JavaScript for example. Since many teams are likely to submit solutions and view results simultaneously, our web server must support parallel and concurrent operations, ensuring integrity of data. Also, the server must ensure safety and security of data and authentication of user logins and passwords. This constrains our choice of the web server used. 2.5 Assumptions and Dependencies The following assumptions are made about the hardware and software on the underlying machine running the software. The supported operating systems for this product are Windows and Linux. We also assume that the users running the Window based client interface have the Java Runtime Environment package installed. Users running the web interface require a browser that supports Java Server Pages and complies with the latest HTML standards. In addition, the programming contest host machine (server) which also runs the admin program needs to have the following softwares installed: 1. Windows / Linux operating system 2. Java Runtime Environment 8

9 3. MySQL database server 4. Apache Web Server 2.6 Apportioning of Requirements The following requirements may not be part of the current release but will be included in the future releases. 1. A plug-in for the judge program to detect code plagiarism and other foul practices. 2. A means for contestants to share problems amongst themselves by submitting new problems to an online repository running on a server. 3. Facilitate customized searches for problems based on category, difficulty, date etc. 4. Facility for the judge to choose from one among various heuristics to decide acceptance of a solution. 9

10 3. Specific Requirements 3.1 External Interface The external interface shall provide a GUI system to interact with different categories of users in the system. The GUI system shall include both web-based and independent application client interfaces as described below Registration Interface The system shall provide a web-based interface by which contestants can register for an online programming contest managed by the software system. The registration page shall collect personal information regarding the contestants and the password for authenticating the team during the contest Login Interface The Login Interface shall allow a user (admin/judge/contestant) of the system to login to the system securely. Additionally, a contestant can also login to the system by a web-based system which can be configured by the admin Admin Interface A GUI shall be provided by the system to allow the administrator to control and organize the programming contest. It shall also provide him with features to set and modify configurable contest options Judge Interface The Judge interface shall enable the judges of the programming contest to validate (automatic/manual) the submissions by the contestants. The judge shall also be provided with the result of the test input on the submissions Contestant Interface The contestant interface shall be realized in two forms a web-based and an independent client interface. This interface shall allow authenticated contestants to view problems, submit solutions, view results of these submissions, check the team status, post queries regarding the problems and refer to the clarifications given by the organizers. 10

11 3.1.6 Result Interface The result interface will consist of a web-based interface enabling any interested party to view the current standings of all the contestants participating in the programming contest. 3.2 Functions The software system shall include three basic modes of operation viz. an Admin mode, a Judge mode and a Contestant mode. Further a Registration phase for the contestants in the programming contest shall also be provided. The remainder of this section is devoted to providing a detailed description of the above-mentioned modes Registration Phase Every contestant who wishes to participate in the programming contest shall first register for the contest by providing the necessary details. 1. The contestant shall fill in data in the fields, requested by the Admin during the set up phase of the system as described in section (3.2.2) 2. The contestant shall choose a password which he/she shall use for authentication during login 3. The system shall allow only unique team names/ids to be chosen by the contestants 4. The system shall also forbid individuals from registering in more than one team (validation through address) 5. The system shall also prevent computerized registration by employing Turing tests Administrator Mode The programming contest is almost entirely defined and organized in the Admin mode of operation. The organizers or administrators are the only people who can operate in this mode of operation. The administrator specifies the various features of the programming contest, thus conceiving the system. 1. The Admin system shall allow the Administrator to create the programming contest by creating an admin account, and then specifying the contest name, time and duration. 2. The Admin system shall allow the organizer of the contest to set the Admin password which is used for authenticating users into the Admin mode later. 11

12 3. The Admin mode shall also be used to specify the Web server and other communication settings for the contest 4. The Admin shall be allowed to create accounts for the Judges (and contestants) of the contest 5. The Admin can also specify the necessary and mandatory fields for registration. 6. The Admin mode shall allow the administrator to specify the languages allowed in the contest. 7. The Admin shall specify the problems in the contest along with the time and memory limits before the commencement of the contest. Further he shall also specify the test inputs and the corresponding expected outputs for the problem 8. The Admin shall also specify the evaluation pattern, the total number of allowed submissions for a problem and the scoring system for each of the problems 9. The Admin mode shall provide a host of reconfigurable options including the messages for the communication of run-results to the contestants and allowing compiling and testing with user-specified inputs 10. The Admin shall be allowed to view the logs maintained during the duration of the contest and recover from crashes. 11. The Admin mode allows the Administrator to reset the duration of the contest and reset the status/submissions of the contestants. 12. The Administrator has higher privilege than the judges and hence, he shall be allowed to overrule judges decisions Judge Mode The judges who will evaluate the contestant entries shall first login to the judge mode by using his/her login information as specified by the administrator. The front end of the judge system is a user-friendly system, which aids the judge in evaluating the submissions, as described below. 1. The judge can choose the mode of evaluation of entries automatic or manual 2. In the Manual mode, the judge system shall allow the judge to specify the input for the particular problem in question. The judge system shall compile and run the program with the judge-specified input (as standard input) and output the result to the judge. The judge can evaluate the submission based on the output 3. In the Manual Judging mode, the judge can manually choose to terminate the program upon his/her discretion 4. In the Automatic mode, the judge system shall automatically compile and run the input program with the default test cases (given by the administrator). The judge system will compare the results with the output specified by the administrator and thereby evaluate the submission 12

13 5. In the Automatic Judging mode, the judging system shall terminate the program if it exceeds the run-time or memory limit specified by the problem setter. 6. The judge system shall provide the source code (program text) to the judge upon request. 7. The judge system shall further forbid system calls to be used by the program. 8. The judge system shall inform the judge about the queries posted by the contestants. The judge could choose to answer these queries with a valid text message, in which case it will be communicated to the specific team or all teams, according to the judge s choice. The System shall mark the query as answered/unanswered depending on the choice of the judge or in case the clarification is not communicated due to technical problems. 9. The judge system shall archive the submitted run along with time-stamps (which could be used for scoring). 10. The judge system shall also allow the judge to retrieve, recompile and reexecute archived runs. 11. The judge system shall provide a configurable (by the Admin) feature through which the result of the run can be communicated to the contestant Contestant Mode Every authenticated contestant shall have access only to the Contestant mode of operation of the system. The system will ensure that the contestants cannot gain unauthorized entry into the judge/admin system. The features of the system extended to the contestants are described below. 1. The contestants shall be provided with a facility to view the problems of the programming contest 2. The system shall allow the contestant to specify the language of coding (among the ones specified by the Admin) 3. The contestant shall be provided with an option (configurable by the Admin) to compile his program using the compiler used by the organizer (at the server end) to avoid version conflicts in the compilation process 4. The contestant shall be provided with an option (configurable by the Admin) to specify his own test inputs and run his program and display the result 5. The system shall facilitate the contestants to submit the source code for evaluation, return the result of the evaluation and further update the status of the contestant. However, the system shall forbid the contestant from submitting more number of solutions than specified by the administrator (Section 3.2.2). 6. The contestant shall also be allowed to post and search for queries and clarifications regarding the problems. 13

14 7. The contestant shall also be allowed to modify his/her registration details and password. 8. The system shall also inform the contestant in case of any connectivity problems. 9. The system shall also keep the contestant informed of the time left in the contest. Further, the contestant shall not be allowed to compile, test or submit beyond the duration of the contest Rankings and Standings This feature shall dynamically update the scores of the contestants in the programming contest based on the evaluation of the submissions and thereby tabulate the standings in the contest. 3.3 Performance Requirements Efficiency The standings for the programming contest should update within 5 seconds from the last change to the scores unless specified otherwise Fairness The system should ensure that the evaluation of a contestant submission should not be delayed indefinitely due to entries submitted later by other contestants. 3.4 Logical Database Requirements The system shall maintain a database of the problems, submissions, queries and clarifications, details of the contestants, and login information of the judges, contestants and the administrator. This information management system shall facilitate easy access to the data stored through the various interfaces mentioned above. 3.5 Design Constraints Standards Compliance The software shall follow the International Collegiate Programming Contest Validator (Judge) Interface Standard between programming Contest Control Systems and Validator (Judge) programs intended to be used in conjunction with such systems. 14

15 3.6 Software System Attributes Reliability A high degree of reliability is necessary for this software product since this is to be used for judging Programming contests on the national and international scale. System crashes are to be handled by regular backups of the contest data Security The users of this system including the Administrator, the Judges and the Contestants need to be authorized and authenticated by cryptographic primitives (including applications like SSL) before using the system. A log of the various activities or actions performed by the users is to be maintained and is to be accessible only by the Administrator Portability This software is meant to be platform independent and can be used on any Operating System. 15

16 4. Change History Version Release Date Changes March 2, 2006 Initial release of the SRS March 6, 2006 Added Change history, unified all fonts and font sizes 5. About This Software Requirements Statement was written for Phase 1 of the CS312 Software Engineering course project at IIT Madras. The document was written using Microsoft Word 2003 and MS Word