Software Architecture

As explained and showed in Section 4.2.1, the system architecture consists of a database, a REST API, and the web application itself. Furthermore, the requirements were gathered and divided into three features: the visu-alization of the news articles, the sharing of the items, and the login or registration process. In discussions with the entire developer team, it is determined how the logic should be implemented. In some cases, specific logic models are already available, as these had already been defined for the implementation of the native applications. In other cases, new logic models have to be defined. The logic is recorded using UML diagrams to illustrate

Figure4.3: The UML Sequence Diagram shows the interaction of the application, the API, and the database when a user wants to see an overview of the latest news.

the process. How the software should interact concerning these features is illustrated in the sequence diagrams in the next few paragraphs.

Figure 4.3, shows the interaction of all components when the user wants to get an overview of the latest news. First of all, the user navigates to this overview. When navigating to the overview, the front-end has to send an HTTP GET request to the API with a parameter that sets a limitation. This limitation is needed that not all database articles get loaded, which could be a vast dataset. Loading all the news entries at once would have several disadvantages. Firstly it would take a long loading time and would have a negative impact on the user experience. The more articles exist, the more time it would need to load them. Secondly, it makes no sense to show the user old news items that are, for example, five months old. Therefore there will be a limitation set by the developers, and if the user wishes, they can also display older news articles and thus more. The application requests the news article data based on the identifier by clicking on a specific news article. After successfully obtaining the object containing the entry, the news detail view should open.

The process when the user wants to log-in on the platform is shown in the

Figure4.4: The UML Sequence Diagram shows the application’s interaction, the API, and the database when a user wants to log in.

second sequence diagram, Figure 4.4. This diagram is explained before the sign-up process because the registration process also needs this logic after the successful creation of the user. The user has to fill in their user information, which is their email address and the password, first. The next step is to validate this data. The front-end should check if the email address is a valid one. When the input data is not valid, the user should get an error message displayed to fix their input. When the input is valid, the front-end sends an HTTP POST request to the corresponding route. The back-end checks if the user exists with this email address in the database and that the password is correct. Again, if this process fails, the user should get corresponding user feedback. If the process is successful, the API-access-token contained in the user object gets sent back to the front-end, which has to store this token for later requests and query the username from the user object to display it for the user.

The next sequence diagram, Figure 4.6, shows the process when a user wants to sign-up on the platform. First of all, they have to fill in their user information and click the submit button afterward. The front-end has to

check if the inputted data is valid. In relation to the username, it has to fulfill some restrictions as mentioned in the non-functional requirements (section 4.1.1). Furthermore, there should be a password confirmation so that the user inputs a password they can recognize without any typos. When the input is not valid, the user should get corresponding user feedback in the form of error messages. Because of the fact that the username is unique, the application has to check if it is available when the user clicks the submit button. The front-end has to send an HTTP POST request with the username to the corresponding endpoint to check the availability. When the username already exists in the database, an error message should be displayed to the user. When the username does not exist in the database, the process continues. A representation of the user gets created and stored in the database with their unique API-access-token. The back-end sends the user object containing the token to the front-end to log in the user, which is the same process as shown and explained before in Figure 4.4.

The sequence diagram 4.5illustrates what messages are sent when the user wants to share the news article on another social platform. The Story Card S1describes the associated requirement. The sharing feature has to include the options to share on Facebook, Twitter, WhatsApp, and copy the article’s link to share it somewhere else. The user clicks on one of the sharing buttons for one of these platforms mentioned before to start the sharing process.

The application sends an HTTP GET request to the back-end, with the news article’s unique ID attached to it, and waits for a response. The response consists of the title, the description, the content URL, and the image URL.

There are two alternatives for the sharing process. One of these alternatives describes the sharing when the user uses a non-mobile device or when the mobile phone browser does not support the Web Sharing API⁶. Therefore, this alternative is also the fallback solution at the same time. In this case, the application should open a new tab with the sharing dialog of the particular platform the user chose. When the user uses a mobile device, and the browser supports the Web Sharing API, the particular system’s sharing screen should open, where the user can select the specific platform.

6https://www.w3.org/TR/web-share/ [accessed on:20.02.2021]

Figure4.5: The UML Sequence Diagram shows the interaction of the application, the API, and the database when a user wants to share a news article on another platform.

Figure4.6: The UML Sequence Diagram shows the interaction of the application, the API, and the database when a user wants to sign up on the soccer platform.