F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTOMobile application for online
monitoring and collaboration of a
sporting event
João Pedro Sousa e Castro
Mestrado Integrado em Engenharia Informática e Computação Supervisor: Prof. João Correia Lopes
Mobile application for online monitoring and
collaboration of a sporting event
João Pedro Sousa e Castro
Mestrado Integrado em Engenharia Informática e Computação
Approved in oral examination by the committee:
Chair: Prof. António Pimenta MonteiroExternal Examiner: Prof. Benedita Malheiro Supervisor: Prof. João Correia Lopes
Abstract
Live information on mobile phones has become a trend around the world. Push notifications about sport events has become a common feature to keep the user up-to-date about what is going on in the subjects that matters. Even though that is the trending nowadays, on sports environment it is still almost impossible to track live events that a smaller collection of people cares and for which there is not much liable data.
Despite the fact that there are hundreds of mobile applications that a user can choose to fol-low live sport events that professional companies handle, there is still work to do to create an application that can also allow the user to make his data input live for less documented events. This problem requires an appropriated and intuitive graphical design to make the input as fast as possible, which is an obvious requirement for a live application.
The main challenge of this work focuses on solving the problems mentioned in order to be able to collect more information about more sporting events, concentrating and producing more attention to more institutions, clubs and athletes until now little valued.
By collecting information and analyzing the state of the art, it became possible to architect a solution to the dilemmas encountered. The challenge of obtaining a responsive platform that allows users to interact and contribute can be solved through the creation of a Progressive Web App, and the validation of the information offered by each one can be validated through the im-plementation of a Reputation System. The final product of this work is an interactive platform supported by an implemented mathematical model that helps the system to make decisions about the reliability of the information it is receiving.
In order to test the work done, and given the complete impossibility of testing it with real users and events due to the suspension of competitions at the date of the work, a system of multi-agents was implemented that aim to simulate some standard behaviors of interaction with the platform simulation the repetition of events that have already occurred in order to assess the accuracy of the information obtained.
The results achieved were satisfactory and open the door to a new way of collecting informa-tion on sporting events that until now was not possible.
Resumo
A informação em direto nos telemóveis tornou-se uma tendência em todo o mundo. As noti-ficações sobre eventos desportivos tornaram-se numa funcionalidade comum que mantém o uti-lizador atualizado em relação ao que está a acontecer nos temas que lhe interessam. Ainda que seja uma tendência hoje em dia, no ambiente desportivo ainda é impossível seguir eventos em direto que possuam um menor grupo de pessoas interessadas para os quais não existe muita informação viável.
Apesar de existirem centenas de aplicações móveis que um utilizador pode escolher para seguir eventos desportivos relevantes onde empresas profissionais gerem a informação, ainda existe tra-balho por realizar para poder criar uma aplicação que permite também ao utilizador inserir in-formação em direto para eventos menos documentados. Este problema requer um design gráfico apropriado e instintivo para tornar a contribuição do utilizador o mais rápida possível, o que é um requisito óbvio para uma aplicação em direto.
O principal desafio deste trabalho centra-se na resolução dos problemas mencionados de forma a poder recolher mais informação sobre mais eventos desportivos, concentrando e produzindo mais atenção a instituições, clubes e atletas até aqui pouco valorizados.
Ao recolher informação e analisando-a no estado da arte tornou-se possível arquitetar e atin-gir uma solução para os dilemas encontrados. O desafio de obter uma plataforma responsiva que permita aos utilizadores interagirem e contribuírem pode ser resolvido através da criação de uma Progressive Web App, sendo que a validação da informação oferecida por cada um é validada através da implementação de um Sistema de Reputação. O produto final deste trabalho é uma plataforma interativa suportada através de um modelo matemático implementado que ajuda o sis-tema a tomar decisões sobre a fiabilidade da informação que está a receber.
De forma a testar o trabalho efetuado, e dada a impossibilidade de o testar com utilizadores e eventos reais dada a suspensão das competições à data do mesmo, foi implementado um sistema de multi-agentes que pretende simular alguns comportamentos padrão da interação com a plataforma através da repetição de eventos já ocorridos de forma a avaliar a precisão da informação obtida.
Os resultados obtidos foram satisfatórios e abrem portas a um novo caminho de recolha de informação sobre acontecimentos desportivos que até aqui não era possível.
Palavras-chave: Coleção de Dados, Sistema de Reputação, Evento Desportivo, Sistema Mul-tiagente
Acknowledgements
I would like to say a big thanks to my supervisor Prof. João Correia Lopes for the time spent, as well as for the constant and tireless support, suggestions and critical spirit that contributed a lot to the elaboration of this work.
A special thank you also the company ZOS Lda, especially Eng. Marco Sousa but also the whole team, for accepting and welcoming me in the best possible way, giving me all conditions to complete my work.
I would also like to thank my family, specially my mom, my father and my grandfather for helping me achieving my goals and for always being supportive when I most needed. I have to mention my girlfriend that was an essential key on all of this process and always made me believe that everything is possible.
Finally I have to give a word for my friends that made this journey way more special and made me realize how much better everything is with them on my side.
“Great things don’t come from comfort zones”
Contents
1 Introduction 1
1.1 Scope . . . 1
1.2 Problem Statement and Motivation . . . 1
1.3 Aim and Goals . . . 2
1.4 Document Structure . . . 2
2 Literature Review and Related Work 3 2.1 Progressive Web Apps . . . 3
2.1.1 Main characteristics . . . 4
2.1.2 Advantages over other technologies . . . 5
2.1.3 Frameworks . . . 6
2.2 Reputation Systems . . . 6
2.2.1 Decentralized reputation system . . . 7
2.2.2 CONFIDANT protocol . . . 8
2.3 Multi-Agent Systems . . . 9
2.3.1 JavaScript Framework . . . 9
2.4 Summary . . . 10
3 Problem Statement and Solution Proposal 11 3.1 Problem Statement . . . 11 3.2 Usage Scenario . . . 12 3.2.1 Actors . . . 12 3.2.2 User Stories . . . 12 3.3 Solution Requirements . . . 13 3.4 Architecture . . . 14 3.4.1 Technologies . . . 15 3.5 Summary . . . 15 4 Reputation System 17 4.1 Description . . . 17 4.2 Adversities . . . 17 4.3 Problem Formulation . . . 18 4.4 Algorithm Application . . . 18
4.4.1 Thresholds and assumptions . . . 19
4.4.2 Consistency of information . . . 20
4.5 Business Layer . . . 20
4.6 Database . . . 20
x CONTENTS
4.7 Summary . . . 25
5 Web App 27 5.1 User Interface . . . 27
5.1.1 Open the application . . . 27
5.1.2 Live contribution . . . 28 5.1.3 Chat . . . 30 5.1.4 Events occurred . . . 30 5.1.5 All matches . . . 30 5.1.6 Customization . . . 32 5.2 Performance . . . 32 5.3 Summary . . . 34 6 Test Scenarios 35 6.1 Agents . . . 35
6.2 Simulation of a live event . . . 37
6.2.1 Event with collaborators . . . 38
6.2.2 Event with clean users . . . 39
6.2.3 Event with malicious users . . . 41
6.2.4 Event with malicious and unhappy supporters . . . 43
6.3 Summary . . . 45
7 Conclusions and Future Work 47 7.1 Overview . . . 47
7.2 Contributions . . . 47
7.3 Further Work . . . 48
A API Routes 49 A.1 User . . . 49
A.1.1 Create an user . . . 49
A.1.2 Update user’s reputation . . . 50
A.1.3 Login . . . 50
A.1.4 Verify email . . . 51
A.1.5 Delete user . . . 52
A.2 Match . . . 52
A.2.1 Get matches by date . . . 52
A.2.2 Update match event . . . 53
A.2.3 Get match’s referee . . . 53
A.3 Player . . . 54
A.3.1 Get team players . . . 54
A.3.2 Get player’s photo . . . 55
A.4 Team . . . 55
A.4.1 Get team’s information . . . 55
A.4.2 Get team’s coach . . . 56
A.5 Competition . . . 57
A.5.1 Get competition’s information . . . 57
A.6 Stadium . . . 57
CONTENTS xi
List of Figures
2.1 CONFIDANT systems . . . 8
2.2 Agent center . . . 10
3.1 System architecture . . . 14
4.1 Communication between nodes . . . 19
4.2 API route to update an user . . . 21
4.3 API route to create an user . . . 21
4.4 Database architecture . . . 22
5.1 Registration . . . 28
5.2 Live match . . . 29
5.3 Live input during a match . . . 29
5.4 Live chat during a match . . . 30
5.5 Events occurred during a match . . . 31
5.6 Matches available to select . . . 31
5.7 Side menu for customization . . . 32
5.8 Time to open an application . . . 33
List of Tables
3.1 User stories . . . 12
6.1 Technical sheet used for simulation . . . 37
6.2 Game technical sheet obtained with 100 users . . . 38
6.3 Game technical sheet obtained with 100 users . . . 39
6.4 Game technical sheet obtained with 1000 users . . . 40
6.5 Game technical sheet obtained with 2000 users . . . 40
6.6 Game technical sheet obtained with 100 users . . . 41
6.7 Game technical sheet obtained with 1000 users . . . 42
6.8 Game technical sheet obtained with 2000 users . . . 42
6.9 Game technical sheet obtained with 100 users . . . 43
6.10 Game technical sheet obtained with 1000 users . . . 44
Abbreviations
PWA Progressive Web App P2P Peer-to-PeerAPI Application Programming Interface REST Representational State Transfer HTML HyperText Markup Language GPS Global Positioning System
Chapter 1
Introduction
Nowadays, live time information is present in every possible way in our society. Even more when focusing on sports events. Multiple companies work to give as quick and as viable as possible information about thousands of events from multiple sports.
1.1
Scope
Even though society is reaching a time where almost gets information on their mobile phones earlier than witnessing on the television, there’s still an huge amount of events without enough information that is still relevant and deserves attention.
The first problem is how to get information fast and to verify that it is correct. These are three big challenges that need to be solved quickly. This solution provides an opportunity, for example, to lower league football fans be able to follow in more detail his own team or even other rivals.
Every sports fan, like a football fan, that supports smaller teams most probably struggles to know how is his team doing on a match if he doesn’t attend the event. That’s where this work makes the difference and will create an impact on the society.
On football events the main information that a user wants to know live is the score, how many goals each team scored, when did it scored, who scored, who got yellow cards or also who got sent off by a red card. This work will provide the opportunity for its users to achieve that.
1.2
Problem Statement and Motivation
Creating a platform that is able to provide live information from sport events with the collaboration from its own users is the main goal on this work. In this scenario there is a need to create a network to provide the communication needed, but also to implement a validation of the information that each user offers.
The user has the possibility to register in the platform, which will be associated with the database already existing from ZOS Lda., and will be rewarded depending on how much he col-laborates with it.
2 Introduction
In this scope we are proposing being able to collect and deliver live information, that is not yet available, about sports events. That’s obviously the big challenge of this problem. The possibility to overturn this lack of information and to create a platform that is able to answer to sport fans needs is a big motivation to complete the goal and present the final work.
Besides that there is already a lot of information being given by ZOS Lda., the company that supports this work. With them, it will be possible to collect the live information available from official events which will facilitate the integration with the big problem that lies ahead: to create the final product with every data aggregated.
1.3
Aim and Goals
To be able to answer to the problems described above, the main goal is to create a platform that is reliable to help its users to get the information they want and, more specifically, that they can’t get on other live score applications.
The fundamental goal on this platform is the validation of the user input on any event. The platform should be able to learn when the user is telling the truth or not about its collaboration and it should get in the end a big success rate to avoid creating a platform that i s a stage for spreading false information.
In view of this objective, it is necessary to achieve good results in the validation of the imple-mented model, obtaining equal or approximate simulations to the correct information.
The work done must also be interactive in order to offer the user the ideal conditions to con-tinue using the system and provide information.
1.4
Document Structure
This document contains six more chapters besides the Introduction. On Chapter2it will be pre-sented a review of the literature, a resume of what has already been done in the topics where this work will be focused. In Chapter3it’s possible to observe the methodology and the architecture of the work with its explanation. Chapter4 presents all the backend development of the work. It contains the structure of the database, but also addresses and details the implementation of the Reputation System applied, justifying the decisions taken. Chapter5demonstrates the visual as-pect of the work, as well as its interaction for the application of the necessary requirements. Then, in Chapter6, the evaluation of the work carried out, with the performance of several test scenarios and the respective discussion of the results obtained. Finally, on Chapter7there’s a evaluation of the work with its conclusions and the main contributions that it provides and an overview of what has been done and could also be implemented in the future.
Chapter 2
Literature Review and Related Work
In this chapter it will be presented the state of art around the areas that this work focus. It will be described the articles and conclusions that were made until now about work related topics. The main topics that are in correlation to the problem will be described here.
The first section presents more information about Progressive Web Apps. It still is a new concept and firstly it contains its main definitions, how it appeared and why it worked. After that it is presented its advantages against other options available with effective comparisons that were already made.
The second topic covers are the Reputation Systems. It is important to understand what a Reputation System can give to exemplify the usefulness and differentiation of this work. In this context it will firstly be defined a Reputation System and after that define how it behaves and how successful it can be.
The last topic addresses Multi-Agent Systems, what they are, how they work and how they can be applied in different contexts. A framework will be presented that fits the work developed and useful for its validation.
2.1
Progressive Web Apps
Progressive Web Apps (PWA) are a trending theme in the industry and with that comes a lack of published research content. Companies are now getting used to it when the first case uses are proving to be a success in many different ways.
Over the years, since the introduction of the iPhone, there is a lot of effort spent on develop-ment methods. Those have been struggling due to the incredibly fast mobile industry that keeps creating new challenges in a pace that programmers almost can not follow to keep the development stable, unified and efficient.
By now, the amount of different platforms that are dominating the market has decreased and that’s a big factor to the emerge of more efficient tools. Even so we’re still facing a market with a
4 Literature Review and Related Work
lot of brands with their own teams and their own specifications that oblige developers to be able to answer too many different questions.
It all started in 2005 when “web development has moved from static multi-page documents to single-page applications”[19] but the initial hype that the implementation on Smartphones created become a struggle for the reasons explained earlier.
In the most recent years it was created a Web App Manifesto[6] that unifies the implementation and allows the user to download the application to his Home Screen. This was made by a group of editors from big companies such like Google, Intel or Microsoft and its a key piece for the developers be able to create an experience similar to a native application.
The Manifesto is JSON-based and provides key metadata. This is a simple example from a possible manifesto:
1 {
2 "name": "Donate App",
3 "description": "This app helps you donate to worthy causes.", 4 "icons": [{ 5 "src": "images/icon.png", 6 "sizes": "192x192" 7 }] 8 } 2.1.1 Main characteristics
Progressive Web Apps become possible only in 2014 when Service Workers were added in Chromium browsers. Their main characteristics focus specially on the following technical features:
• Progressive — Works continuously on the background for the user even when not appearing on the screen.
• Responsive — Has the ability to answer to each use case, such as any type of mobile phone, tablet, computer or other.
• Shortcut — A PWA can be used as a normal application in a mobile device. • Connectivity-independent — Can still work offline and handle the connectivity. • Security — Allows the implementation of more secure certificates.
• Push Notifications — Powerful tool that was one of the main reasons for the strength of the native developments, but now PWA are also able to implement.
2.1 Progressive Web Apps 5
Service Workers represent one break through that Web development got since they were in-troduced. They allow the developed apps to run the needed jobs in background, even when the application is closed. This created the opportunity to implement push notifications, work offline when needed and synchronize data without the user needing to open the application. Even though they were introduced in Android operating systems in 2014, they were only available on iOs after version 11.3 being released [19].
This major step was crucial to reduce the differences between a native mobile implementation and a Web app. The application with Service Workers gets much more control in the network, since all requests made are now intercepted and controlled by them.
Besides this, Service Workers also provide an opportunity to different caching scenarios on the implementation. These scenarios were analysed by Pavel Bˇroušek in 2017 [3] and can be summarized in the following characteristics:
• Cache First — More efficient and is more useful on stable data, but never updates. • Network First — It’s fresh but can face scenarios of timeout.
• Cache Only — It’s never loaded and should be focused on cache data. • Network Only — Provides the pattern behaviour as normal.
This adaptability gives developers more chances to create efficient systems according to their application needs. Cache is a key piece of an application considering its speed comparing to other hardware resources.
2.1.2 Advantages over other technologies
The industry is investing resources into Progressive Web Apps and the development of learning material. The lack of academic involvement denotes a significant knowledge gap, but, at the same time, provides research potential [2]. Many big companies are already making the transition to PWA for the multiple advantages.
Native applications have to be certified by operating system stores. Apple store is very specific in its requirements and it is very common to see apps being temporarily removed because of company’ demands. With PWA there is a viable path to avoid the negotiation with those companies [14].
Another main advantage is the performance. PWA got significantly faster with the implemen-tation of the Service Workers. It even gets notably quicker when loading than a normal Web page and the differences for a native application are very small [22]. Native is still a little bit quicker but it already makes almost no difference for a common user.
Progressive Web Apps are also much smaller than native applications. A common Android application with a size of 30 megabytes represents around 3 megabytes on a PWA version [22] which can make a pretty big difference considering that mobile data is still a big limitation in most
6 Literature Review and Related Work
Finally, it is also important to note the unified development that it requires. Native applications development requires multiple efforts and almost independent projects for each operating system, but PWA offer the possibility of unifying the development and avoid wasting more resources.
2.1.3 Frameworks
The biggest proof that Progressive Web Apps are the trend of the future is that the biggest ref-erences of Web development currently on the market have already incorporated them in their functionalities. React[16], Angular[12] and Vue[9] are the three major market leaders in today’s Web development[8] and currently support PWA, each in a different way, but always incorporating scripts for the implementation of Service Workers.
Another option that emerged is the Svelte framework. This tool is totally disruptive in Web development and, consequently, creates a learning curve that is much more difficult and prolonged in the initial part, a condition that does not fall within the scope of this dissertation.
Finally, there is the Ionic framework[11]. Created in 2013, it initially worked only on Angular, but has also incorporated development using React. This framework allows hybrid development for all types of platforms in a unified way. Through this tool it is possible with the same devel-opment to compile natively for Android and iOS operating systems, but also to build a responsive Web platform for all devices. Consequently, it also allows the creation of a PWA.
Naturally, this tool carries costs [13]. The performance for the native version of the develop-ment does not have the same capacity as an original native developdevelop-ment, but, on the other hand, it does not require jobs for different operating systems.
Over the years, the efficiency of this framework has improved significantly and today it is within acceptable standards for the response times of native applications developed with Ionic.
2.2
Reputation Systems
In this work one of the main challenges proposed is the validation of each user. It requires an implementation on the application that can recognize if the new information is correct or incorrect. Since the context of the problem does not provide any official information in some scenarios to verify its veracity, a Reputation System is the best solution to achieve the best possible result.
Reputation Systems are able to define the reputation that a participant should have for a better understanding of its value [23]. On its first steps, P2P systems were insecure and weak for dan-gerous members that could joined the network and multiple companies struggled around the years with it.
That is when Reputation Systems appeared to start avoiding false positives and learning how to deal with intruders in the networks. Nowadays we can see this type of solutions in a big variety of applications, such as P2P Networks, Mobile Ad-Hoc [5].
2.2 Reputation Systems 7
2.2.1 Decentralized reputation system
The implementation of a P2P Network requires also a matching decentralized reputation system. In 2003, Sonja Buchegger and Jean-Yves Le Boudec have published a “Robust Reputation System for Mobile Ad-hoc Networks”[5].
Even though it was not created for the specific purpose of a P2P architecture as it was devel-oped for a Mobile Ad Hoc Network, it works exactly on the same design with some main concepts that provided good results. This system defines that each node i has two ratings about all the others nodes j of its interest. One of them its the reputation rating (Ri, j) that represents its opinion on its behavior. The other variable defined is the trust rating (Ti, j) that confines how honest, as it’ll be demonstrated below, is the node j on the opinion of the node i.
Considering that this algorithm is based on a Bayesian approach, the reputation rating and trust rating are represented by:
Ri, j := Ri, j + wFk, j (2.1)
γ := vγ + s (2.2)
δ := vδ + (1 − s) (2.3)
There is a variable w that represents a small and positive number that keeps constant along the time. The trust rating is represented in a common Bayesian approach where Ti, j is shown as T(γ, δ ).
Initially it starts at T (1, 1) and variable s is binary being positive or negative if the member is trustworthy or not. A decision is then taken after a deviation test is made by comparing to a predefined constant r for behavior, and t for trustworthiness.
It is also important to note that the nodes must keep the past record of the ratings when a modification happens called first hand information represented by Fi, j. The evaluation of the trends that can possible be noted are also taking in account for a better decision.
When a node i gets an information Fk, j and node k is already considered trustworthy or has a first hand information value close to Ri, j than the message will be accepted and the reputation will be slightly upgraded. If the reputation value is close to the first hand information, the trust rating is also slightly upgraded. If it isn’t there, trust rating should suffer a slight decrease.
The decision making of each node about the reputation and the trust it has in relation to an-other is then decided based on deviations from the previously defined thresholds. The reputation threshold r will always be close to 0.5 and the confidence threshold t should not exceed 0.75.
We can conclude that this algorithm is focused on the regular/misbehaved criteria, but also takes into consideration the trustworthy of each member. It is important to note that both ratings are defined by the Bayesian approach.
This system proposes that the actual cause of a misbehaviour shouldn’t be taken into consid-eration as it is not viable to create an algorithm that can judge an action. So if a bad collaboration
8 Literature Review and Related Work
Figure 2.1: CONFIDANT systems
Another key point of this algorithm logic is on how to punish the liars. These authors defend that these liars should not be punished, but instead the system should only reduce the visualizations that the public will receive from them. With this perception it is possible to keep members engaged to the main goal and give them the opportunity of redemption. This is possibly the game changer on this algorithm. With periodic re-evaluation of each member, everyone will have the chance of redemption and will always be in time to be useful for the community.
2.2.2 CONFIDANT protocol
The Figure2.1represents the components of the CONFIDANT protocol [4], created by the same authors of the reputation system described above. This protocol is based on selective altruism and utilitarianism. The main objective, of course, is to be able to find nodes with standard behaviors to isolate them and avoid the damage they may cause in the network.
This protocol consists of four components: Monitor, Reputation System, Path Manager and Trust Manager. Any of these components is always present on all nodes in the network.
The Monitor actually corresponds to the surveillance of neighboring nodes. All nodes are responsible for watching their neighbors and will always be the first to try to detect intruders. The Trust Manager is responsible for managing messages for all alert nodes to inform when the system has the information that a given node has malicious behavior. The Reputation System component corresponds to the formulas presented above that allow measuring the degree of trust and reputation of each node. Finally, Path Manager is responsible for managing the rankings of the nodes and, if necessary, eliminating networks of malicious nodes that are harmful to the network.
2.3 Multi-Agent Systems 9
2.3
Multi-Agent Systems
Multi-Agents System are a architectural paradigm of Artificial Intelligence where each agent acts independently of the behavior of all others [20]. When defining an agent, a set of capabilities is always associated that portrays the objectives that the agent intends to represent.
Since their coming out in the 80’s, multi-agent systems have been considered as “societies of agents” that interact together to coordinate their behavior and often cooperate to achieve some collective goal [10]. It is clear, from this conception, that the body of multi-agent researches should be concerned by both agents and societies. However, an important emphasis has been put on the agent side.
Multi-agent systems can be seen as open systems where agents can enter and leave freely. The concept of open multi-agent systems seems to be of special interest in situations where a common platform exists on which different multi-agent systems are built and agents migrate from one multi-agent system to another to perform activities that can not be performed in the multi-agent system where they were originally placed. Such migrations of agents among open multi-agent systems pose problems that are also common to systems whose organizations vary dynamically during their functionings.
2.3.1 JavaScript Framework
Use of JavaScript, and HTML as an agent platform is not very common. The Radigost [17] system uses both as an implementation platform for multiagent systems. It has many interesting features like support for standard agent communication and yellow-pages service for agent directories. However, it does not support running agents outside the browser. Because of that, Radigost has been merged with the JavaEE-based agent framework into one system named Siebog[18]. Siebog allows execution of JavaScript agents on the server side with the use of adapters, but only one-way mobility is currently supported. Agents can only migrate from a browser to a server.
Therefore, in 2017, Aleksandar Lukic, Nikola Luburic, Milan Vidakovic and Marko Holbl developed a multi-agent JavaScript framework [15]. This framework provides from the outset the set predefined interfaces for the creation of agents.
In its architecture there is always at least one Agent Center, which is actually the Master responsible for managing the agents. In Figure2.2obtained from [15], it is possible to verify the Agent Center architecture, concluding that both the lifecycle and the messages are managed by this entity. This, as the authors explain, is due to the single-threaded nature of JavaScript operation, thus avoiding possible blockages.
The limitation of this work is due to the low efficiency in scalability. The model is, as ex-pected, quite fast and responsive for a small number of agents, but the response time increases exponentially and it becomes very difficult to make it feasible in a context with more than 3000 agents who are very active in their communications.
10 Literature Review and Related Work
Figure 2.2: Agent center
2.4
Summary
The literature review and related work presented shows an opportunity to encompass multiple models on a new topic to create a different solution. It is presented that the appearance of PWA focused on how it was possible and why it is being succeeded and catching the attention of the market. It is introduced what a Reputation System is and then is shown the Decentralized Reputa-tion System, explaining its algorithm. Finally, a brief resumé of Multi-Agent Systems is presented together with a a JavaScript Framework that suits the problem.
Chapter 3
Problem Statement and Solution
Proposal
This chapter describes the problem presented, the motivation for its resolution and the solution adopted to achieve it.
For this, the Problem Statement is initially presented, which frames its appearance, followed by the description of the Usage Scenario with the necessary actors for the solution, as well as the respective user stories.
Subsequently, the Solution Requirements are described, in which the different layers that the solution will be presented and how the connection between them should work.
Then, Architecture will be demonstrated, with special attention to the technologies applied, with its description and explanation.
3.1
Problem Statement
Live information on mobile phones has become a trend around the world. Push notifications about sport events have become a common feature to keep the user up-to-date with what is going on in the subjects that matters. Even though that is the trending way, on sports environment it is still almost impossible to track live events that a smaller number of people cares and for which there is not much liable data.
Despite the fact that there are hundreds of mobile applications to follow live sport events, there is still to be created an application that allows the user to share his input regarding less documented events. This problem requires an appropriated and intuitive graphical design to share the input as fast as possible, which is an obvious requirement for a live application.
Being able to unify the live data about professional events that are already collected with the outlier events it’s the main challenge and for which multiple solutions will be developed and tested. To gather all the information it will be necessary to join official information from a live Application Programming Interface (API) with the inputs collected from the mobile application.
12 Problem Statement and Solution Proposal
The challenge of validating live inputs will require an implementation of a Reputation System that needs to be integrated with the appropriated tools to ensure the most reliable answer for each event. This mechanism allows the creation of a robust model that is accurate in the information provided in real time, regardless of the type of event (First Division or an amateur Lower League). In this scope, we are proposing to collect and deliver live information about sports events that are not yet available. That is obviously the biggest challenge of this problem. The possibility to overturn this lack of information and to create a platform that is able to answer to sport fans needs is a big motivation that can provide the answer to a current difficulty.
3.2
Usage Scenario
A usage scenario describes the actions that can be performed by the system with the needed re-quirements, specifying also the actors involved. This description was required to specify the work in coordination with ZOS, Lda.
3.2.1 Actors
The system has three special actors. Even though all of them can perform the main actions of the application, each one have different permissions associated to their degree of importance for the operation of the application.
This scenario allows the work fulfill all usage needs. The user can have three levels, the last of which can only be assigned via administrative level through direct intervention of the person responsible for maintaining the application.
The actor User has access to the live events available, to their information and can contribute with information.
The Authenticated User has the same permissions as the User but is not anonymous in the live events chat and can personalize his profile.
The Collaborator is an important actor of the application. It is a Registered User with special permissions because is considered a trusted user with reliable information.
3.2.2 User Stories
Table 3.1: User stories Identifier Name Description
US01 Register As a User, I want to register a new account so that I can person-alize my profile
US02 Login As a User, I want to login so that I can participate in the live events’ chat
3.3 Solution Requirements 13
Table 3.1 – continued from previous page Identifier Name Description
US11 View Event As a User, I want to enter a match so that I can see the details from any live event
US12 Input in Event
As a User, I want to contribute information about an event so that I can update it
US13 Watch Input
As a User, I want to conclude my contribution so that I can see my contribution applied
US21 View chat As a User, I want to be able to access the chat menu so that I can see the live chat
US22 Use chat As a Authenticated User, I want to be able to enter in the live chat so that I can participate
US31 View teams in the event
As a User, I want to be able to have a lineups menu so that I can see the lineups from each team in the event
US32 View livescore of the event
As a User, I want to see the livescore from a live event so I can know the actual score
US33 Select my favorite teams
As a Authenticated User, I want to be able to select my favorite teams so that I can have my favourite teams in the platform
US34 View live events of my favorite teams
As a Authenticated User, I want to see any live event happening from my favorite teams so that I can filter live events
3.3
Solution Requirements
In view of the problem presented, the solution obtained necessarily has several steps along the way besides the user stories obtained from the front-end implemented. The work requires the creation of a responsive platform, which adapts to several different types of devices and which manages to fulfill the various functionalities required that will be necessary both for the possibility of execution from the user’s perspective as well as on the information management side.
Mainly, the solution is a platform capable of showing the data of a sporting event live and al-lowing interactivity to the user to contribute and provide live information about that same sporting event. This functionality requires the validation of the information that is offered, which is not always possible to perform automatically. Although there are more and more licensed sources of
14 Problem Statement and Solution Proposal
Figure 3.1: System architecture
To validate the information that the system collects through its users, a reputation system will be used. These systems are quite common in several areas and can really offer an interesting and useful solution to the problem. A reputation system requires that it be modeled and adapted to the problem and existing database and is able to offer an indicator about each user, that will guide the decision making about accepting the shared inputs.
Considering that this development was carried out at a time when the interruption of sporting activity occurred at a global level, it became necessary to seek ways of validating and evaluating the results obtained without the existence of human interactivity. In that sense, it was necessary to define agents that stimulate and approach the behavior of a normal user of the application.
The platform will be able to register users to track their participation along the way and get the necessary information about the person. When a user is considered as trustworthy by the administration after a given time, it will be marked manually as Collaborator. This achievement will allow the user to become a credible and important source of information.
3.4
Architecture
As presented in the previous section, the required solution requires overcoming some inherent challenges. The solution will have to go through the agglomeration of the trust and reputation information about each user, the ability to manage the information collected and also the capacity for interactivity that the platform can generate to attract its use.
In Figure3.1it is possible to see the architecture of the developed system. This solution is based on a traditional Client/Server architecture, where user interaction is carried out through the PWA platform and the information that is produced is maintained through the open source database MongoDB, one of the most powerful tools available with regard to scalability of the information maintained [7].
3.5 Summary 15
3.4.1 Technologies
The project is focused in developing a product that can be presented also as a Progressive Web App. In that purpose the application was developed using the framework Ionic [11], a cross-platform tool. This framework allows an unifying development that can be presented in the final output as a native application, which is a positive option considering the commercial aspect of this dissertation.
This framework is focused on mobile development and has plugins that allow the use of avail-able hardware features, such as Camera, GPS and other options that native development offers.
Given the architecture, which has already been presented previously, following the Clien-t/Server paradigm, the server side was developed using Node.js technology [21]. This framework is widely used in current Web development mainly for the use of the features it offers for the definition of RESTful API components. This option is especially effective in the development of server-side applications and, although the Web code developed is in TypeScript and this option is in JavaScript language, the similarities are high and facilitate the unification between both.
3.5
Summary
This chapter presents the description of the problem and the architecture of the solution developed, together with the technologies that provide the means to achieve it, as well as all the requirements
Chapter 4
Reputation System
In this chapter, a Description of the development model is initially made and what are the bases used for the implementation of the Reputation System.
Next, the Adversities found are presented, as well as, after the decisions made, the Problem Formulation.
After the presentation of this information, the Algorithm Application is demonstrated, which summarizes the operation of the system and how it interacts with the backend.
Throughout the work, decisions about Thresholds and assumptions were necessary, which are explained and argued. These decisions are connected with the Consistency of information, where it is discussed and explained how the model manages information.
Finally, the Business Layer is presented, as well as the Database to better visualize how the management of all information works.
4.1
Description
In the spectrum of this dissertation the reputation system is applied to a novel situation. A Rep-utation System is a challenge that requires key understanding of human behaviour as it will be explained later.
The algorithm applied, detailed in a previous Chapter2, was initially defined for a Mobile Ad-Hoc Network. The modified Bayesian approach proved to be the best approach available to validate the contributions provided by the application designed in this work.
This work is based on the development of an application which means that the members of the network involved in this system will, ideally, be also users. For definition, a user will be considered as a node of the same.
4.2
Adversities
Identifying and modeling a Reputation System is a challenge in a human context. It is crucial to take on some concepts with regard to the degree of penalty applied to the different adversities that
18 Reputation System
users may create.
The model applied in this Dissertation does not differ in the assumptions used in the origi-nal model. The work done is intended to be attractive and to induce users to feel motivated to contribute to the events and, in this scenario, it is essential to decide not to permanently penalize unreliable nodes in the information network.
Imagining a scenario where the assumption made at the beginning was contrary, that is, punish the node, we could lose a user who may be useful in the future. In this context, the possibility of massification of information will always be a focus, as this will always mean greater ease in obtaining true information.
4.3
Problem Formulation
The behavior of each node is presented as an independent entity whose actions are carried out on his initiative. Node thinks that there is a parameter, such that node misbehaves with probability, and that the outcome is drawn independently from observation to observation (Node considers that there is a different parameter for every different node).
The first-hand information is described as Fi,j. In summary, this is the mathematical repre-sentation of the data structure that represents the aggregation between reputation and trust that each node i, in this case user of the platform, has over node j. Over time, the nodes update their neighbors with the information and data they have about other members of the network. This in-formation management allows to correct and fine-tune the degree of reliability that the system can collect on each user while exchanging information. The higher the level of information exchange, the greater the robustness of the decision making about each user.
In a scenario where an event is transmitted by one of the nodes and the information is trans-mitted to another, there are two first steps for it to be assumed. The receiving node can only accept this information if the data it has about the sender node is that it is reliable and has a reputation within the defined threshold. If this happens, the information is saved and the reputation score receives a slight increase.
4.4
Algorithm Application
After modeling and understanding the algorithm, it was necessary to fit it in the development context. The State of the Art does not have any tool already created for its implementation in JavaScript, as was necessary in this work.
Throughout the description, each node must be understood as a user of the application. In the simulation scenario that will be presented later on, the same entity will also be considered an agent, so the three keywords refer to the same in the elaborated framework, varying the use depending on the most appropriate context.
4.4 Algorithm Application 19
Figure 4.1: Communication between nodes
Naturally, the development of this model was directly implemented on the backend, maintain-ing volatile information when possible and preservmaintain-ing consistent information through the API that will be presented in the next section.
The original algorithm focused on a decentralized model, which is not the case, but in parts there was some adaptation. Figure4.1represents an example of the communication to be achieved. In a decentralized system, nodes communicate directly, and in this work they initially communi-cate with the server that is responsible for forwarding information.
In Figure4.1, node 1 had received information from node 4 and made the decision to transmit it to neighboring nodes. For this, the user communicates with his closest neighbors and, initially, sends his reputation on node 4, then sends the message he had received, which in this work will always be an event. This action leads nodes 2, 3 and 4 to calculate a new weighted average of the opinion they had of node 5 and, if these nodes have indicators above the defined thresholds, they accept the information.
4.4.1 Thresholds and assumptions
After the definition and implementation of the system, the quality of the results will always depend on the default values and in predefined limitations on the network.
These decisions were be made with several simulations, since only the execution of the model over time will contribute to its tuning. Therefore, the work developed on this topic is also a consequence of the results presented later in Chapter6.
Since this is not a decentralized system, the first decision made was to limit the number of nodes that are considered neighbors. Considering the results that were obtained, the maximum number of neighbors that a node can have is 3. This maximum value offered the most positive results in reducing the spreading of malicious nodes.
Subsequently, it was also necessary to establish the Reputation and Trust thresholds. After several simulations, the best results obtained did not vary much from the indications of the original model. In this work, the threshold r, referring to reputation, presented slightly better results with
20 Reputation System
4.4.2 Consistency of information
One of the difficulties to start with in a centralized system is to maintain the information in a consistent way over multiple matches. The demand that each node keeps the historical information about the nodes it has communicated which results in a high database cost.
In this way, information management was also modified. The communication history between nodes is volatile, being preserved only for the duration of the match. At the end of each match the system collects all the opinions formed about each node and performs a weighted average. This average becomes persistent information and is updated in the database for each user.
When information about a given node is required for a new match, a request is made to the server’s API to provide that information again, so the nodes become aware.
4.5
Business Layer
This component deals with how the information obtained is created, saved and maintained. In this sense, it is necessary to define the application programming interface (API) for the interaction between the software and the database.
Briefly, this component is the interface that establishes the routes and communication patterns between the server and the database. The API was developed in this work using the technologies NodeJS and ExpressJS[1], a framework that works on the first and whose simplicity of develop-ment has made it a reference.
All Database definitions, changes and updates go through this component. When some func-tionality is executed in the developed application, it is the API that is responsible for transforming it into a database. For this, the API has previously defined routes responsible for making direct changes to the database.
Below are some of the most important and relevant routes in this work, all of which are avail-able in AppendixA.
1. Update user’s reputation: In Figure4.2, it is possible to see the route architecture to update the user’s reputation invoked at the end of each event he participates.
2. Create User: In Figure4.3it is possible to see the architecture of the route to update the creation of a user that is used when registers on the platform.
4.6
Database
This is the component responsible for the large volumes of data storage and retrieval related with the System, is here that all the data format is defined stored, retrieved and filtered and intercon-nected. This Component was built using PostgreSQL.
4.6 Database 21
22 Reputation System
4.6 Database 23
4.6.1 Data Structure
Figure4.4depicts the Data Structure, which was designed to manage the information that is needed for the platform. In addition to the information shared with the system by the users, there is also a long data storage that the collaboration with ZOS Lda makes available at the outset.
However, the scheme applied to this work was synthesized given the brevity of time when compared to the level of date abstraction that the company has. It was filtered to obtain the neces-sary information for the execution of the required functionalities and for the platform to respond to the necessary parameters. In total there are 12 classes whose respective abstractions define their characteristics. Certain classes defined here could be generalized in this context, but this system has been simplified for this specific purposes.
1. User
This Class is in charge of maintaining all the information of each user of the platform. In addition to preserving the most important data that identifies him, such as name, email and password, the reputation associated with it is also preserved in this same object.
As it can be seen, each user can be associated with several teams, which are his favorite teams, as well as the meetings he saw live.
2. Player
This Class is in charge of managing all the information that can be obtained about a player. From the name, personal data, data related to his sports performance such as position, which is his favorite foot and also regarding his business aspect, such as who is his agent, what is the duration of his current contract.
3. Team
This Class defines the concept of team in the collective sports group, where there are al-ways necessarily two teams present. There is a variety of necessary information, from their historical data, their nicknames, their location or even, if any, their hymn.
This definition is one of the essential points in the structuring of the database. It is to him that most of the remaining existing classes are associated.
4. Coach
This Class defines a relevant identity in the sports world that is the Coach. His personal data, his possible family members also in the world of football and his current status (active or inactive) are some of the examples of preserved information.
A Coach is directly associated with several teams, which together make up their career history. It also necessarily represents his country.
24 Reputation System
This Class represents a central entity of a sporting event, which is precisely the Referee. This definition preserves some specific data, such as the category to which it belongs at the arbitration level, the international level it may or may not have and the sports association in which it is registered, in addition to personal data.
Naturally, it is associated with any match he may be part of, as well as the country that represents.
6. Stadium
This Class represents the infrastructure that hosts sporting events and preserves important data such as the opening date, its location, size, capacity and even the architect who planned it.
These data allow us to obtain very valuable information for the details of a sporting event, as well as to know what infrastructure each team has, because generally the two classes are directly linked.
7. Country
This Class defines, in addition to the Country entity naturally associated, the National Se-lection. It is a special entity distinct from the team for its definitions and characteristics. A player, for example, naturally always belongs to both a team and his country because he can represent both.
8. Competition
This Class defines the various competitions that exist in the sporting panorama of the sport. From friendly, professional, amateur, club or national team competitions. In addition, infor-mation is also preserved about the division in which it fits in the competitive context. This definition is closely linked to any and all matches that take place, as well as linked to the country to which the competition belongs.
9. Match
This Class defines the sporting event that takes place. Among multiple information col-lected, there is necessarily a date for the event, the technical sheet that is essential for defin-ing the work of this Dissertation and even the television channel of transmission if it exists. Naturally, as expected, it is directly associated with several other entities that actively par-ticipate in the course of a game.
10. Administrator
This Class represents the leaders that each team has. Each one naturally has his position and his status of exercising functions in each specific club.
4.7 Summary 25
This Class exists to define the individual prizes that are directly associated around each modality. There are multiple attributes that are preserved and that may or may not be specific to a certain prize and whose respective are linked to the player who wins it.
4.7
Summary
This Chapter has demonstrated in depth the development carried out specifically in the application back-end. Focused on the modeling of the Reputation System, it has inherently implied a Database model, as well as the API that was presented and that allows the definition of services to be used
Chapter 5
Web App
For the visual realization of the work that was described in the previous Chapter, it is necessary to develop the front-end that allows the interaction and visualization of the product. This work is also the visible part that a common user will have access to enjoy the platform created.
The main focus of this Chapter is on explaining and demonstrating the platform and how the previously described features can be implemented in practice. This development is covered in the User Interface.
It is also crucial to understand the behavior of the Web App and how efficient it is. For this purpose, a description and analysis of the platform’s Performance is carried out..
Finally, a short Summary of the work described in all sections is presented with the main conclusions to be drawn from it.
5.1
User Interface
In addition to the model developed, it was also necessary to develop the frontend. This component demonstrates some of the main features of the platform.
As previously mentioned, this development was carried out using the Ionic framework, a new tool that has been appearing and being used more and more as the community grows. This frame-work uses and compiles native methods, but provides Web tools that facilitate its use. It also has an aspect mostly similar to the most common visuals of the iOS operating system, since the Web tools it offers are always closer to it.
In this part of the work, the aim is to achieve the connection between the user and the system that processes all the information, being the bridge between the two parts through its visual part and the features inherent to it.
5.1.1 Open the application
The first step the user takes when opening the job for the first time is to register. However, as shown in Figure5.1and previously planned in the user stories defined in Chapter 3, this action is not mandatory. From the moment the user is using it, the system can obtain a unique token for
28 Web App
Figure 5.1: Registration
each user. Thus, to facilitate navigation and avoid dropouts, there is always the possibility of the registration being closed and proceeding to other screens.
Even so, initially the development try to demand as little information as possible, to keep the user engaged. You are offered the option of associating your Facebook or Google account to quickly set up registration, or else you simply need to define your email and password.
If the user already has a registered account, the screen for the login is practically the same, but the data is not new and there is only a check in the system if it definitely already exists.
5.1.2 Live contribution
One of the most important points in the frontend development focuses on offering the user the possibility to contribute information to the system and to have more knowledge about the event. This functionality is shown in Figures5.2and5.3.
In Figure5.2, it is possible to see what the user can see when choosing an event that is taking place live. The contribution can be made in the sub-menu that always opens first by default with the name "Teams", for which the players playing from both teams are shown.
When an event occurs and the user wants to contribute, just clicks on the player and a modal will appear, as shown in Figure5.3. There the user has the option to indicate that the player scored a goal, saw a yellow card, saw a red card or can simply go back and close again.
If the user enters the event, it is readily assumed to motivate and keep him using the sys-tem. However, this does not mean that other users receive this information, as explained in the reputation system model.
5.1 User Interface 29
30 Web App
Figure 5.4: Live chat during a match
5.1.3 Chat
One of the important features to make this work more attractive and appealing to the user is the implementation of a chat. The screen in Figure5.4presents an example of a conversation within the event, as each has their own independent comments. In this way, the conversation becomes more fluid, without noise and confusion due to multiple matches that may be taking place, and motivates users to exchange views on what is happening on the field.
To use it the user just has to click on the Comentários sub-menu and enter the conversation directly. As highlighted above, the use of this functionality is limited to users registered in the system.
5.1.4 Events occurred
When the system processes and takes over events the frontend offers the user the possibility to check them in the sub-menu Events. Figure 5.5 shows an example screen of a technical sheet made available to the user during the meeting.
The screen itself is quite representative, using icons to represent goals, substitutions (in case of official information about it), yellow or red cards.
5.1.5 All matches
One of the necessary features to be implemented was the development of a screen where events that occur during a certain day were agglomerated. This screen is shown in Figure 5.6 where each card corresponds to a clickable encounter. When the user interacts with him, navigates to the
5.1 User Interface 31
32 Web App
Figure 5.7: Side menu for customization
screen shown in Figure5.2. The user can scroll across the screen to view all games and get better usability.
5.1.6 Customization
In Figure 5.7, it is possible to check the open side menu, where there are several options for interaction. The user can edit his profile photo by clicking on the current photo, can access his profile to change or complete information, or navigate to a screen of his favorite teams.
The functionality of the favorite teams is always present throughout the frontend. In any match that the user has opened, there is always an icon next to each of the teams where, when clicked, it will appear in their favorite teams. This screen is similar to the one shown in Figure5.6, but only with filtered teams.
5.2
Performance
The success of an application in today’s competitive market also depends on its responsiveness and efficiency. Since they appeared in 2016, Progressive Web Apps have enjoyed rapid growth and are increasingly attracting the attention of private investment due to their characteristics.
With the purpose of validation of this development, it is important to understand how the application performs compared to other alternatives. In this context it is key to measure the time of opening an application and also how much time it takes to change screen. The iOS Standard and Android Standardvalues are considered the benchmark values to achieve in a native development for each scenario.
5.2 Performance 33
Figure 5.8: Time to open an application
In assessing the application’s behavior, two main metrics were considered: the time required to open the application for the first time (Figure5.8) and the response time for changing between each screen in the application (Figure5.9).
In the third column, it is possible to analyze the indicators obtained from PWA’s performance. Also, it was used the tool that the development carried out in the Ionic framework allows. This tool offers the possibility of normal development carried out being compiled for native code. Due to the limited material available, the possibility was used to create a native Android version.
The graph of Figure5.8 shows that the results obtained from the developed PWA are quite satisfactory. Considering the easiness that this tool offers in the quality and feasibility in the de-velopment, the approach to the native values of the two great leaders of mobile operating systems in the market is a clear indicator of the viability of this area in the business future. However, the compilation of the code into native Android code showed significantly slower results, proving that there is still work to be done in the existing frameworks regarding the efficiency of the compo-nents it makes available. However, it should be emphasized that a value close to 250 ms is still not considered a deal breaker by specialists, and there are other development tools in this area with worse results.
These results allow above all to realize that the tools considered and used for the execution are quite feasible and considering the short life span and the strong growing community around the area, the private sector must bet on this possibility because it allows a cost reduction. The development is unified for multiple operating systems and for Web operation, which reduces the
34 Web App
Figure 5.9: Time to change from screen inside the application
5.3
Summary
This Chapter presents the validation of the solution developed in this work. For this purpose, the reason for using agents in the validation is initially described, followed by their explanation and how they were defined and shaped. Then, all the results obtained for the various scenarios created are shown.
Chapter 6
Test Scenarios
The development of test scenarios proved to be one of the biggest challenges of this work and whose work has always been necessarily linked to improvements and corrections of the work described previously in the Chapter4.
Under normal conditions, it would be easier to validate the work done through the use of real events that happen almost daily with people invited in the most random way possible to analyze the results. Unfortunately, during the period in which the work was carried out, there was an unexpected sporting suspension at a global level that, right from the start, forced the search for other possibilities.
In view of these conditions the implementation with Agents is presented to help and validate the work carried out in the Reputation System model.
The Simulation of a live event is presented below, which consists of the execution of various scenarios, with various types of agents and various combinations that intend to approach a real scenario, with the results obtained and their analysis.
6.1
Agents
Given the limitations for the validation of the work, simulations were promoted to cover scenarios the system may encounter and to evaluate the results. Within this framework, the multi-agent framework discussed in Chapter2was specifically developed to be used in JavaScript.
The framework developed by Aleksandar Lukic, Nikola Luburic, Milan Vidakovic and Marko Holbl builds a generalized template for the definition of agents following a SiebogJS Architecture. This architecture was adapted to this work, as it is designed for communication with customers, something that does not occur in this scenario.
In short, each agent created corresponds to a new child process in Node.js, the tool used for backend development. Subsequently, each new process communicates with the Manager who is responsible for acting as a communication bridge for all other processes.
