Scientific Progress Report

of BSc students of 4 year 6B06101 Information Systems

Amangeldiuly Ravil, Ulykbekov Arsen, Kuanyshbekov Yermakhan,
Zhuandyk Sultan and Alikhan Adilov

Introduction

Football tournaments are held in SDU every year. A tournament is primarily a

competition, in football it is a competition between teams and players within a team. In
order to determine the winner in tournaments, we must count, save and compare data
about these tournaments themselves. This is necessary for both the organizers and the
fans.
At the moment, information about the events of football tournaments in SDU is published
on instagram and telegram. The method can be said to be not very convenient, since you
have to constantly move around different platforms, where other data can be mixed with
tournament data. Also, the speed of publishing data is very far behind the conduct of the
tournaments themselves, for example, information about a match can be released a few
days after the match itself.
Our team decided to solve this problem by making one single application for recording,
saving and publishing data about football tournaments.

Aim and objectives of research

User part: Understand the needs and preferences of football fans and football tournament
organizers. Design the application for these needs and add the appropriate functionality.
Technical part: Design a database for our application, properly set up normalization and
relationships between entities. Design the REST API of our application using best
practices and based on the official thesis of the creator of REST and HTTP, Roy Fielding.

Literature Review
Data collection
Since our first task is to find out about the "mood" of our future users about our ideas and
solutions, we need to conduct research in this regard, and conduct it correctly. For this,
articles on the above topics were selected from the beginning.

Article 1:
https://www.researchgate.net/publication/11842651_Data_Collection_Techniques
What was understood and applied:
There are many data collection methods such as direct observation, standardized tests,
content analysis, surveys, interviews, and detailed information about each method has
been obtained. For example, participants' behavior was recorded through direct
observation rather than relying on other people's reports.
From this article, one of the methods, namely surveys, was chosen, and the data in the
study were collected by this method.

Article 2:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4601897/
What was understood and applied:
Polling can lead to many sources of error such as
+ coverage error - unknown or zero probability of including individuals in the population
in the sample
+ measurement error - questions do not accurately reflect the topic of interest
+ non-response error - no response
But there are several strategies to reduce the chance of errors. Strategies:
creating a multimode design
creation of preliminary questions, convenient graphics
creating a user-friendly survey design
From this article, a "sampling strategy" was applied in the survey, which means that a
sufficient sample was selected, in our case students, that is representative of the
population of interest.

After making sure that the idea finds support and is relevant at the moment, we moved on
to designing the system. The first step was the database.

Database
For the implementation of our database, we were helped by an article from Mike Hillyer,
Technical Writer for MySQL about Database normalization. This article provides
information about the first three normal (all we need) forms from six existing ones.
Let's start with the fact that normalization is a method of organizing data in a database.
Based on the article, we have brought our created tables to the first, second, and third
normal forms.
 (ER-diagram of LiveScore Database)
As you can see above, each table contains no repeating groups and all attributes have a
unique value (1NF), all attributes depend on the primary key (2NF) and there are no
transitive functional dependencies of non-key attributes on key attributes (3NF).

After the issue with the databases was resolved, we set about designing the backend part
of our application. We had to determine on the basis of what style to build our web
service.
Types of web services
https://www.researchgate.net/publication/317604322_ANALYSIS_AND_SELECTION_
OF_WEB_SERVICE_TECHNOLOGIES

The article provides a brief description of what a web service is, what types of web
services exist, what their capabilities and limitations are, and what technologies they are
associated with.
Based on the data obtained from the article, we began an additional study of which web
services are currently relevant. This filter filtered out almost all options, leaving only
SOAP and REST.
Then we started looking at programming forums and articles to choose between these two
kinds of web service design. Here are simplified description of difference between REST
and SOAP based web application
Web service types: SOAP REST
Data format XML (only) XML, JSON, .txt (no
restrictions)
Security Secure No security
Speed Slow Fast
Service calling method RPC Simple call via URL
path
Returning format Does not return human Returns readable plain
readable format JSON or XML
JavaScript calling Available, but hard to Easy call
implement

Based on these data, we realized that SOAP is not suitable for our system, since our
application will publish data in real time (publication of match events at the time of their
occurrence, for example, a goal or a player receiving a red card). Therefore, the REST
architectural style was chosen.

REST architectural style and it’s best practices

The architectural style has been chosen, now the task is to implement it correctly. To do
this, let's turn to the dissertation of the creator of this style, Roy Fielding, written in 2000.
From the fifth paragraph of the dissertation, in which REST is just described, it becomes
known six main principles that any API implementing this architectural style should
follow.
 Client-server architecture
 Stateless
 Caching
 Interface uniformity
 Layered system
 Code on demand
Now we know the requirements for our application from a technical point of view. It
remains to find the right framework that will have sufficient functionality to build the
backend of a web application and implement these principles.
The architectural style is important not only to implement correctly, but also to use the
best practices based on time and experience in implementing this very architecture. Their
descriptions were obtained from open sources on the Internet, and taken into account for
implementation during direct coding.

Spring framework
Of the many possible technologies for building the logic of our web application, Spring
was chosen. The choice was made based on its functionality, a separate subframework
specifically for working with REST, and also because of the scarcity of alternatives (only
J2EE).

Mobile application design

Based on an article I read about colors. First of all, it was important to find out who will
use our mobile application. Mostly they are boys over 16 years old. The report also
mentions that, according to the study, the male half of the population likes bright colors.
In our design, we used shades such as purple-pink and green-yellow. Instead, a dark color
scheme was used, with one bright color used to draw attention to key elements. Also,
using too many colors will distract and annoy the user. Thus, the colors were matched to a
maximum of six. This completes the selection of colors.

The application should be intuitive and user-friendly when used. To achieve these goals,
it was decided to use the ten general principles of interaction design by Jakob Nielsen:
Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose, and recover from errors
Help and documentation

Based on these principles and the above points about colors, templates for our future
mobile application were created.

References
Hillyer, M. (2005) An Introduction to Database Normalization [Preprint].

Morgan, G.A. and J. Harmon, R. (2001) “Data Collection Techniques” Journal of the
American Academy of Child and Adolescent Psychiatry [Preprint].

Ponto, J. (2015) “Understanding and Evaluating Survey Research” J Adv Pract Oncol
[Preprint].

Jakob, N. (1993) “Usability Heuristics” in Usability engineering. Mountain View,

California: SunSoft, pp. 139–177.