System Architecture

X5QGEN system consists of several components. There is the web app, the API and the database. In terms of architecture, the web app adopts the Model-View-Controller (MVC) pattern and all sequences of actions are triggered by the user's interaction with the web app. The web app receives the text input from the user through the frontend and sends a post or a get request to the X5QGEN API through the controller. The web app is deployed on an Azure virtual machine and so is the question generation (QG) API. The API will generate the question by either using the multiple-choice (MC) question generation model or the true or false (T/F) question generation model depending on the request parameters. Then, the generated questions will be sent back to the controller in the web app as a JSON file. The controller processes and sends the data to view which displays the questions and after the user interacts with the questions web app sends the data to the database through the model. The web app can also retrieve data from the database when user wants to check their progress on the profile page. So, that is a basic summary of how our system works and what each component do.

To be able to show the basic architecture of the whole system, we drew up a C4 model diagram which is a lean graphical notation technique for modelling the architecture of software systems. The C4 model diagram clearly shows that the users (teachers and students) only interact with the system through the web application. It also illustrates the question generation logic is handled in the API and all the user information is stored in the database.

Site Map

We tried to make our website as simple and intuitive as possible so the user would be able to navigate around easily. The website provides all the essential functionality in only a few pages. The basic functionality of each page is explained below:

Passage input is the main page where the user can enter their text.

The display questions page is for users to interact with the questions and click on their answer.

The profile page is for the users to track their progress.

Sign up page is so the users can sign up and give us permission to track their progress.

Sequence Diagram

We drew up a sequence diagram that represents how a typical user would interact with our X5QGEN system.

Design Patterns

Model-View-Controller (MVC)

MVC design pattern is used in the web app part of the project and it allowed us to separate the app into three interconnected parts so that it helps with reusing of code and parallel development. On top of that MVC design pattern gives the opportunity to modify one part of the app without affecting the other parts. This independent structure is almost an industry standard and is commonly used.

Blueprints

Blueprints record operations to execute when registered on an application [1]. We used blueprints to provide templates and static files for view functions. We created the routes and assigned functionality to each subdomain using blueprints. It was optional for us to use but it gave our app a more organized structure which is why we chose to use blueprints.

Application Factories

Factories in Flask allows us to have instances of the same application with different settings to test every case. This was crucial for us when it comes to testing and it made it easy for us to conduct testing. We did this by setting up the application in a function and that way we can create multiple instances of the app. Using this design pattern, no application-specific state is stored on the extension object, so one extension object can be used for multiple apps [2].

Data Storage

We drew up an Entity Relationship Diagram to show the structure of our database. Our database has two entities one of them being the users and the other one being questions. The users table stores any information about the users including the statistics about the questions they have answered. Users table is used for authentication and it is useful for progress tracking. The primary key for users is the userId but that is not how it is related to the questions entity. Questions stores data on everything about the questions such as the context, options, answer... The primary key of the questions is the questionId. In users, attemptedQuestion field is the questionId of the attempted question and that is how we can access the details of the questions attempted by every user. This proves to be very useful on the profile page where we can display the questions attempted by the user thanks to the connection between the two entities.

System Design