1. Systemspecification

1.1. Initial situation

The HTL Leonding is an HTL in Upper Austria. Central room with around 1400 students and the specialist departments Media technology, IT, electronics and medical technology.In the scope of the IT departments and media technology, the subject of databases (DBI / INSY) is taught. An essential part of this course is the practical training in the database query language SQL.

1.2. Present situation

At the HTL Leonding an Oracle database is available to the students in order to be able to work with a database. The teacher provides exercises for the students to perform. There are already various exercise tools that can be found on the Internet. However, these are mostly static and you can only learn the existing exercises. In addition, the overview of the level of knowledge is not very clear. Also, you often have to pay for these tools to use them.

1.3. Problem

In addition to the tasks provided by the teachers, it is advantageous for the students to be able to prepare for the exams with additional tasks. The teachers often provide additional examples, but sometimes without solutions.

1.4. Task

Creation of a software product for students and teachers at the HTL Leonding. The system consists of 4 functions:

  • Practice mode

  • Learning mode (according to the learning card system, the incorrect examples are repeated from a set of tasks)

  • Exam mode - student (simulated exam)

  • Exam mode - teacher (assessed performance assessment)

The exam tasks can be created by teachers using the system. The tasks are then evaluated.

The GUI is basically divided into 3 areas:

  • Text / information (graphic representation of the data model)

  • SQL statement to be entered by the student

  • Feedback

The learning progress should be documented graphically.

1.4.1. Functional requirements

diag 1a71ea43356de24a2ece5298653cb392

  • practice SQL

  • take simulated exam

  • take exam

  • view knowledge level

  • upload exercises/tests

  • execute exam

  • view knowledge of students

1.5. Use case 1: practice tasks

1.5.1. Characterizing information Use case 1:

Superordinate elementary business process:

Practice tasks

Aim of the use case:

The student learns to use database commands through exercises.

Precondition:

Tasks must already have been created. The user needs his own account.

Description:

  • Task is displayed

  • Student enters the command

  • The program checks the correctness of the command

    • If the command is correct → next task

1.6. Use case 2: taking a simulated exam

1.6.1. Characterizing information use case 2

Superordinate elementary business process:

take a simulated exam

Aim of the use case:

The student can check his level of knowledge

Precondition:

The student must have already completed the previous exercises. The test must have already been created.

Description:

  • Task is displayed

  • Student enters the command

  • The program checks the correctness of the command

    • If the command is correct → next task

  • He cannot access previous exercises during the exam

1.7. Use case 3: Take the exam

1.7.1. Characterizing information use case 3

Superordinate elementary business process:

Take the exam

Aim of the use case:

The teacher can check the student’s level of knowledge

Precondition:

A test must already have been created

Description:

  • Task is displayed

  • Student enters the command

  • The program checks the correctness of the command

    • If the command is correct → next task

    • If the command is wrong 3 times → possibility to skip this task (no points)

  • He cannot access previous exercises during the exam

1.8. Use case 4: View the state of knowledge

1.8.1. Characterizing information use case 4

Superordinate elementary business process:

View knowledge level

Aim of the use case:

Students have an overview of the material they have already learned.

Precondition:

The student must have created his own account.

Description:

  • The current level of knowledge is shown graphically.

1.9. Use case 5: Upload exercises / tests

1.9.1. Characterizing information use case 5

Superordinate elementary business process:

Upload exercises / tests

Aim of the use case:

The exercises are made available in the database for students to complete.

Precondition:

The exercises must first have been created locally.

Description:

  • The teacher types in the task and the corresponding command.

  • This process is repeated until it has reached the number of tasks that the teacher would like to include in this exercise set.

1.10. Use Case 6: Approve Exam

1.10.1. Characterizing information use case 6

Superordinate elementary business process:

Approve examination

Precondition:

The test must already have been created.

Description:

  • Exams that have already been created are initially not visible to anyone other than the creator. They have to be released separately.

1.11. Use case 7: View the students' level of knowledge

1.11.1. Characterizing information use case 7

Superordinate elementary business process:

View the students' level of knowledge

Aim of the use case:

Teachers can call up the respective level of knowledge of the individual students in order to be able to keep an overview

Precondition:

The teacher must be given access to his students.

Description:

  • The level of knowledge of the students is shown graphically.

1.11.2. Non-functional requirements (NFA)

  • Robustness of the application against user errors (Example: Refusal of SQL injections by the user)

  • quick feedback from the system

  • no check for e.g. JDBC so for project connections in Java, C ++, C

1.12. Goals

  • Improve learning success because the student receives immediate feedback as to whether the example is correct

  • There are many tasks available to students

    • The teachers do not need to prepare extra examples

    • Students do not need to ask teachers for new assignments

  • You can concentrate on learning SQL, bureaucratic tasks are eliminated

  • Practice examples for the test are already known

1.13. project phases

  • Learn quarkus

  • Learn Angular

  • Program the backend → build the basic architecture

  • program backend → save data (tasks / commands)

  • Program the backend → check commands

  • Program the backend → save knowledge

  • Program the backend → call up / evaluate knowledge

  • Implement frontend

1.14. Quantity structure

  • There are currently around 1400 students attending the HTL Leonding, with around 450 students actively learn SQL.

  • To implement this we need one database

1.15. Framework conditions

  • Everything has to be docker

  • Quarkus as a backend

  • Angular as a front end

2. System architecture

2.1. Team

  • 15PV

  • 19SM

  • 22TI

2.2. GANTT-Diagramm

gantt protoype

GANTT-Diagramm