3-Tier网络的开发

原文地址：3-Tier网络的开发

开发一个基于3-Tier Network的系统，通过回答多选题以及编程题来测试学生对编程语言的理解能力。

Requirement

The aim of the project is to develop a 3-tier network-based system which tests students' ability to demonstrate their understanding of contemporary programming languages by correctly answering multi-choice questions and short programming challenges.

By successfully completing the project, you will have a greater understanding of the standard TCP and IP protocols, know how to use programming languages' interfaces to internet protocols, and have developed a simple application-layer protocol for the exchange of queries, responses, and files.

Students undertake a test using a standard web-browser. Their web-browser will communicate with a software application termed a Test-Manager (TM), which first authenticates a student's session and then navigates the student through a sequence of multi-choice questions and programming challenges, receiving the student's attempts, and totalling marks awarded for correct attempts.

The TM, in turn, will communicate with software applications termed Question-Banks (QBs) which generate a sequence of multi-choice questions and programming challenges for each student (communicated via the TM), and executes and marks students' attempts.

Students will be undertaking a single test, via their browser, but the questions they receive will be drawn from questions about two different programming languages.

The web-browser, TM, and QBs, all execute on different computers (hardware) and, thus, must communicate using network protocols. Because students interact with the testing system using a web-browser, communication between the web-browser and TM will require the HTTP and HTML protocols, while the design and implementation of a protocol between your TM and QBs is up to you.

Pre-registered students must first login to the TM using a text-based name and password. They may then navigate, forwards and backwards, through a sequence of, say, 10 questions which are either multi-choice questions, or ones setting a short programming challenge (see Clarifications for some examples).

If the student's first attempt at any question is correct, they receive 3 marks, 2 marks if their second attempt is correct, and so on. Once they have attempted all questions (either correctly or after 3 attempts each) they may no longer submit answers.

After 3 incorrect attempts at any question, the TM should report the 3rd attempt's incorrect output, and the correct output, to be displayed side-by-side in the browser.

At any time, a student may login, attempt questions, see their progress, their mark to-date, or logout.

The TM only manages the testing of students, and has no 'understanding' of the questions or how they are marked. Similarly, the QBs have no 'understanding' of the students and their marks. In an effort to reduce collusion amongst students, the QBs should choose questions randomly from their bank of questions (simple approach), or generate repeatably randomized questions (more complex approach). If a student logs out, and later logs back in, they should see the exact same sequence of questions.

The marking of multi-choice questions hopefully requires no explanation. The marking of the programming challenges will require the QBs to execute the student's attempt, and to compare any output against the anticipated answer (which may, itself, have to be generated by executing a standard solution). Answers do not have to be plain text.

Important dates and project submission

The project contributes 40% of your mark in CITS3002 this year, and has a number of important dates and deadlines.

Complete the project demonstration booking sheet, which will be pinned up outside of CSSE Lab 2.3. When the demonstration times are known, they'll be announced on our help forum.

Constraints

The constraints of the project require that:

1. your TM and QB software must execute on different computers (hardware), and must not assume access to any shared (networked) files.
2. your TM and QB must be written in two different programming languages (selected from Java, C, and Python).
3. your QBs must support the generation and marking of questions assessing two of Java, C, and Python.
4. your system will execute two distinct QB instances, with each QB supporting (generating and assessing) questions from a single programming language. However, you should develop only a single QB application, able to support multiple languages.
5. your system must support two or more students simultaneously attempting questions.
6. your TM does not need to produce a fancy web-interface - basic HTML involving forms, a textarea, radio-buttons, and checkboxes will be sufficient.
7. the answer (output) for any question does not have to be plain-text. A valid output (answer) could, for example, be a GIF or PNG image. Keep this in mind when assessing answers, and when reporting them to be displayed on the user's browser.
8. your TM does not need to support full user or password management - just logging in and out. Assume that all pre-registered students and their unchangeable passwords are just stored in a file (there is no need to use UWA student numbers or attempt Pheme authentication).
9. neither the TM nor QBs require a sophisticated database to manage the students, marks, and questions - simple text files will be sufficient.
10. your system must be developed for Linux, or macOS (or a combination).
11. you should employ the core networking functions (classes, methods, libraries,...) of your chosen programming languages and not employ 3rd-party frameworks or resources to complete large parts of the project. If in doubt, please ask.

Project demonstration

Your team must also arrange a demonstration of your software, of up to 30 minutes, in week 12 (possibly overflowing into week 13). The role of the demonstration is for you to demonstrate how much of the project's goals you have met, and to answer questions to demonstrate your understanding. It is not essential for all team members to be at your demonstration, but ensure that those attending will be able to represent the team.

During the demonstration, you'll be logging into your account on your chosen operating systems. A booking sheet will be provided closer to the deadline. During the demonstration, your team should:

• briefly describe design decisions and assumptions that you have made in your project. You must clearly explain how it works, and identify any known weaknesses with your approach or its implementation.
• re-compile your programs, and initialize and invoke the two server programs. Describe the contents of necessary directories and files.
• demonstrate, through a small number of examples, how someone may use your software system.
• do not prepare a PowerPoint-style presentation.

Working in teams of up to 4

The project may to be undertaken in teams of up to 4 students (no, not 5). The motivation for working in small teams is to enhance communication skills amongst students, and to enable you to attempt a project considered of greater difficulty than would normally be reasonable for the time available. It is anticipated that this project will require 20-30 hours of study by each member of the 4-person teams.

The project is worth 40% of your mark in CITS3002 this year, and the distribution of marks within your team, typically one-quarter each, must be agreed to by all members of your team (and verified at the demonstration).

Only one team member needs submit files using cssubmit. Ensure that all students' names and student numbers appear in all submitted materials.

Anyone needing to find a project partner should read Students seeking project partners as soon as possible.

Clarifications

Please post requests for clarification about any aspect of the project to help3002 so that all students may remain equally informed.

Clarifications will be also added to the project clarifications webpage.

Good luck.

(本文出自csprojectedu.com，转载请注明出处)