开发一个基于 [ 3-Tier Network ](https://www.geeksforgeeks.org/2-tier-and-3-tier-
architecture-in-networking/ “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:
- your TM and QB software must execute on different computers (hardware), and must not assume access to any shared (networked) files.
- your TM and QB must be written in two different programming languages (selected from Java, C, and Python).
- your QBs must support the generation and marking of questions assessing two of Java, C, and Python.
- 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.
- your system must support two or more students simultaneously attempting questions.
- your TM does not need to produce a fancy web-interface - basic HTML involving forms, a textarea, radio-buttons, and checkboxes will be sufficient.
- 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.
- 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).
- neither the TM nor QBs require a sophisticated database to manage the students, marks, and questions - simple text files will be sufficient.
- your system must be developed for Linux, or macOS (or a combination).
- 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.
