System Design

High-Level Design

The following diagram shows a high-level overview of three iOS clients, the Core Module containing shared components, and the Artemis Server.

High-Level Component Diagram

Themis Subsystem Decomposition

The following UML component diagram shows internal details of Themis and its dependencies on ArtemisCore components. To ensure that the diagram remains comprehensible and uncluttered, we’ve excluded the view models.

Subsystem Decomposition of Themis

The Authentication subsystem helps the user authenticate using the Login subsystem. Once a user successfully logs in, the Course subsystem takes over, responsible for displaying courses where the user is as a tutor. Additionally, this subsystem manages the retrieval and presentation of exercises and exams associated with these courses. When the system needs to present more detail about a particular exam or an exercise, the Exercise and Exam subsystems come into play. The Exam subsystem primarily focuses on presenting the exercises within an exam context and leverages the Exercise subsystem when the user selects a particular exercise. When the user initiates an assessment on a submission, the Assessment subsystem.

Deployment

The following UML deployment diagram shows a typical deployment of Themis, Artemis application server and Athena server. The Artemis server communicates with Athena to fetch feedback suggestions.

Deployment Diagram

Persistent Data Management

The app stores the authentication cookie in the HTTPCookieStorage, which is described in the Access Control and Security Chapter.

UserDefaults

The app stores the selected Course ID (which are the ones provided by Artemis) in the UserDefaults at “shownCourseIDKey” in order to always show the last selected course. The Artemis server URL is also stored in the UserDefaults at “serverURL”.

ThemisML Server

Note

This section will be removed once feedback suggestions are completely integrated into Artemis.

ThemisML has a Postgres database separate from the Artemis database to store existing feedbacks for given submissions. The choice of the database follows a related project to ThemisML, Athene. In principle, ThemisML could use the Artemis database directly, but the development team decided to use a separate database for a faster development cycle and more flexibility. The database might be merged in the future.

Currently, ThemisML fetches submissions from Artemis only when it is notified from the app using the /feedback_suggestions/notify endpoint. Then, the feedbacks are fetched and the following data is stored in the database for each feedback:

• a unique id within ThemisML

• the exercise_id of the submission

• the participation_id of the submission

• the method_name of the method belonging to the feedback (ThemisML currently does not work for feedbacks outside of methods, so those are not stored)

• the code of the method belonging to the feedback

• the src_file of the method belonging to the feedback

• from_line and to_line of the feedback within the src_file

• the text of the feedback

• the credits given by the tutor

Access Control and Security

In order to make requests to the Artemis server the user has to be authenticated, i.e. has to have a cookie which contains a jwt token. The corresponding cookie is set by the Artemis server when calling the /authenticate route. In iOS cookies are stored and managed in the HTTPCookieStorage, which means no further management of the token is done by Themis.

ThemisML Server

Note

This section will be removed once feedback suggestions are completely integrated into Artemis.

When notifying or requesting feedback suggestions from ThemisML, the request has to contain the jwt token for Artemis of the requesting user. ThemisML only uses the token to make requests to the Artemis server and does not store the token.

Global Software Control

Note

This section will be removed once feedback suggestions are completely integrated into Artemis.

The feedback suggestions that are generated by ThemisML are based on previous assessments. Because of this, ThemisML stores assessed submissions with their respective feedbacks. Therefore, ThemisML should always be notified whenever a new assessment is submitted, so that it can pull and store the new assessment in its own database. For this Themis uses the /notify route after an assessment was submitted, so that ThemisML can request the new assessment from the Artemis server. The alternative of checking for new assessments in a time interval was considered but decided against to reduce the strain on the Artemis server.