Universitatea Tehnică a Moldovei

PLATFORMĂ ONLINE PENTRU DEZVOLTAREA

CAPACITĂȚII DE REZOLVARE A
PROBLEMELOR

ONLINE PLATFORM FOR PROBLEM-SOLVING

SKILL TRAINING

Student: Dodon Ion

gr. FAF-172

Coordonator: Drumea Vasile

asist. univ.

Chișinău, 2021
 Universitatea Tehnică a Moldovei
Facultatea Calculatoare, Informatică şi Microelectronică
Departamentul Ingineria Software și Automatică
Programul de studii Ingineria Software

Aprob
şef de departament
Fiodorov Ion, dr.conf.univ.
___________________
„06” octombrie 2020

CAIET DE SARCINI
pentru proiectul de licenţă al studentului

Dodon Ion
(numele şi prenumele studentului)

1. Tema proiectului de licenţă Platformă online pentru dezvoltarea capacității de

rezolvare a problemelor

confirmată prin hotărârea Consiliului facultăţii nr. 2 din „06” octombrie 2020

2. Termenul limită de prezentare a proiectului de licență 21.05.2021

3. Date iniţiale pentru elaborarea proiectului de licență Sarcina pentru elaborarea

proiectului de diplomă

4. Conţinutul memoriului explicativ

Introducere
1 Analiza domeniului de studiu
2 Definirea cerințelor
3 Modelarea și proiectarea sistemului
4 Managementul proiectului
5 Implimentarea sistemului
Concluzii
5. Conţinutul părţii grafice a proiectului de licență
Diagrame structurale și comportamentale ale sistemului
REZUMAT

Există multe platforme care oferă posibilitatea de a rezolva mai multe tipuri de probleme ı̂n scopul
antrenării gândirii. Un exemplu bun este brilliant.org. [7] Dar acest website nu ofeară o posibilitate de a crea
probleme (teste) pe orice domeniu, de exemplu filosofie. Majoritatea platformelor existente se focusează
pe un singur domeniu sau pe un set de arii, cum ar fi: matematica, informatica, istorie, fizica s, i altele.
Platformele existente pentru antrenarea capacităt, ii de rezolvare a problemelor au unele neajunsuri, dar s, i le
lipsesc unele functionalităt, i care ar face platforma mai interesantă pentru utilizatori. Unele din slăbiciunile
platformelor exitente, pe lânga faptul că ele t, intesc o singură nis, ă, e că sunt cu plată s, i faptul că le lipsesc
unele functionalităt, i cum a fi crearea concursurilor sau echipelor.
Scopul acestui proiect este de a crea un website alternativ celor existente. Iar acest website pe
lânga faptul că va aduce noi oportunităt, i utilizatorilor, va s, i oferi probleme care se rezolva ı̂ntr-o manieră
diferită. Problemele oferite vor putea fi rezolvate anume ı̂ntr-o manieră de cercetare, analiză s, i deduct, ie.
Noul website va fi totus, i ceva diferit fat, ă de cele existente, dar va avea acelas, i scop: de a oferi oamenilor
posibilitatea să invet, e lucruri noi ı̂ntr-un mod interactiv s, i ı̂n stilul unui joc de intelectualitate.
Ce este, de fapt, această platformă (sau mai exact – noul website)? Noul website va oferi un set de
probleme, care pe website vor fi numite ”puzzles”. Oricare utilizator poate rezolva, dar s, i crea probleme.
O problemă constă dintr-un set de ı̂ntrebări. Fiecare ı̂ntrebare are un cod care trebuie aflat. Acest cod nu
este neapărt răspunsul la ı̂ntrebare dar dacă este aflat, atunci se poate de trecut la următorul nivel, adică
următoarea ı̂ntrebare. Fiecare ı̂ntrebare trebuie să facă ca utilizatorul, sau putem spune chiar – jucătorul, să
exploreze, să caute ı̂n mai multe surse s, i să-s, i folosească intuit, ia pentru a putea găsi codul secret. Scopul
este ca jucatorul să afle codul secret. Este recomandat ca ı̂ntrebările să aibă o legătură ı̂ntre ele. Acest stil
de problemă/joc este inspirat din setul de puzzle-uri create de organizat, ia secretă Cicada 3301 cu scopul de
a recruta oameni inteligent, i (codebrakers) din public. [5]
ABSTRACT

There are many platforms that offer the possibility to solve several types of problems in order to
train human thinking. A good example is brilliang.org. [7] But this website does not offer an opportunity
to create problems/tests in any field, for example philosophy. Most existing platforms focus on a single
field or set of areas, such as math, computer science, history, physics and more. Existing platforms for
problem-solving skill training have some shortcomings, but they also lack some features that would make
the platform more interesting for users. Some of the weaknesses of the existing platforms, in addition to
the fact that they target a single niche, is that they are paid and that they lack some features such as creating
contests or teams.
The purpose of this project is to create an alternative website to the existing ones. And this website,
besides bringing new opportunities to users, will also offer problems that are solved in a different way.
The problems offered will be able to be solved through research, analysis and deduction. The new website
will still be something different from the existing ones, but it will have the same goal: to offer people the
opportunity to learn new things in an interactive way and in the style of an intellectual game.
What exactly is this platform (or more precisely - the new website)? The new website will offer a set
of problems, which on the website will be called ”puzzles”. Any user can solve, but also create problems.
One problem is a set of questions. Each question has a code that needs to be found out. This code is not
necessarily the answer to the question, but if it is found, then the user can pass to the next level, which
means – the next question. Each question must make the user (we can even say – the player) explore, search
in several sources and use his intuition to find the secret code. The goal is for the player to find out the secret
code. It is recommended that the questions be related to each other. This style of problem/game is inspired
by the set of puzzles created and published by the secret organization Cicada 3301 in order to recruit smart
people/codebreakers from the public. [5]
Contents

List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1 DOMAIN ANALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.1 Problem Analysis and Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.2 Solution and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 REQUIREMENTS SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 SYSTEM DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Use Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Activity Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.3 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.4 REST API Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.5 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 PROJECT MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Economic perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.1 SWOT Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 Market analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2.1 Competitive Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.3 Cost analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.3.1 Salary expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Marketing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Customer Avatar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2 Customer Acquisition Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Project perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9
 4.3.1 Success Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Project Management Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.3 Tasks Listing and Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4 Tasks Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.5 Tasks Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 Solution Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.1 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1.1 Version Control System . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1.2 Client Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1.3 Server Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.2 Architectural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.2.1 Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.2.2 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Project Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Server Application Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.1 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.2 The API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.3 JWT Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Database Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.1 Data Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A Complete diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

B Docker configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B.1 Dockerfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.1.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.1.2 Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

10
 B.1.3 NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

C Nginx API Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

D Example of entity class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

11
List of Figures

3.1 4+1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Account related use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Puzzle and team related use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Create contest and check puzzle code use cases . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Create puzzle activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Solve Puzzle activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Relations between Account entities and Puzzle related entities . . . . . . . . . . . . . . . 31
3.8 Class diagram that shows relation between User, Team and PuzzleSession . . . . . . . . . 32
3.9 REST API Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Tasks to configure Nxing, Docker container and database configuration . . . . . . . . . . . 47

4.2 Tasks API implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Scheduled tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.1 Entities class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.2 Database schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

12
List of Tables

4.1 SWOT analysis for the problem-solving platform . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Advantages and Disadvantages of available platforms . . . . . . . . . . . . . . . . . . . . 39
4.3 Salaries for team members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

13
Acronyms

API Application Programming Interface. 12, 26, 29, 30, 33, 40, 41, 43, 51, 52, 53, 54, 55, 56, 57, 58, 60,
61, 62, 63

CLI Command Line Interface. 57

CORS Cross-origin Resource Sharing. 23

CPU Central Processing Unit. 40

CRUD Create, Read, Update, Delete. 48

CSRF Cross-Site Request Forgery. 23

CTR Clickthrough Rate. 38

DNS Domain Name System. 64

GUI Graphical User Interface. 56

HTML HyperText Markup Language. 53

HTTP Hypertext Transfer Protocol. 33, 40, 47, 53

JWT JSON Web Token. 33, 48, 60, 63

KPI Key Performance Indicators. 43, 44, 45

MVC Model View Controller. 26, 32, 33, 40

MVP Minimum Valuable Product. 36, 41, 46, 51

NPM Node Package Manager. 54, 55

OOP Object Oriented Programming. 34

ORM Object Relational Mapping. 32, 54

REST Representational State Transfer. 12, 17, 26, 29, 30, 33, 54, 56, 63

SEO Search Engine Optimization. 47, 48, 53

14
SMART Specific, Measurable, Achievable, Relevant, Time bound. 43

SPA Single Page Application. 17, 52, 53

SQL Structured Query Language. 23, 54

SSL Secure Sockets Layer. 47

SWOT Strengths Weaknesses Opportunities Threats. 36

UI User Interface. 53, 54, 55, 56

UML Unified Modeling Language. 18, 25, 26, 27, 34

VCS Version Control System. 52, 53, 56, 63

WBS Work Breakdown Structure. 48

15
Listings

5.2.1 Start all docker containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.2 Enter into a container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.3 Initialize a basic ReactJS app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.4 Initialize basic Symfony project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 API dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.2 Create puzzle endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.3 Verify token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.4 Identify user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4.1 Database URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.2 Generate schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.3 Mapping team members to the team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.0.1 Environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.1.1 Dockerfile for MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.1.2 Dockerfile for Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.1.3 Dockerfile for nodejs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.0.1 Nginx API configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
D.0.1Puzzle entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

16
INTRODUCTION

Problem solving skills are a good characteristic to poses especially for those who want to have
success in their lives. For example entrepreneurs will always face different kinds of problems in their career
and having a developed technique to solve problems will be the thing that will assure their success. There
are already a few applications or websites that offer puzzles to be solved in order to train people’s thinking,
but some of them are for kids only or they are targeting a single niche such as programming. But those are
not the only shortcomings.
What gave life to project is noticing that the existing problem solving websites do not offer a kind
of problems that would require more time to get solved and which would imply research, general culture
knowledge, deduction and intuition. The motivation is to offer a platform, that inherits best practices from
its competitor and avoids their shortcomings, for those who want to develop their skills of problem solving
and to learn something new while solving the problems.
The idea came out from the puzzles created by an anonymous organization with the name Cicada
3301. [5] The puzzles were meant to recruit code-breakers from the public. A problem on the new platform
represents a set of questions that require research, intuition and deduction in order to be answered. Someone
who solves the problems will have to browser on the internet for example, in order to be able to answer. A
problem is not a quiz like set of questions, but rather questions which cannot be answered without research.
The purpose of this project is to offer an online platform for those who want to better their problem
solving skills. The online platform is supposed to fill the gaps found at its competitors and inherit best
features from them, so that finally to have a more flexible, accessible product for those who want to learn
new things by solving problems.
The project is based on a client-server architecture. The server will be a REST (Representational
State Transfer) API that will server a SPA (Single Page Application) website. The advantage of this archi-
tecture is that the client side and server side are decoupled and this way it is possible to have different types
of clients. For example, besides a SPA website, it is also possible to add in the future a mobile application
as a client without affecting the backend. The back-end will communicate to a relation database.
A problems will also be referred as a puzzle. Each puzzle has a general description and will consist
of a set of free-text questions made up by the author of the puzzle. In order to be able to go to the next
question, the previous one should be solved. Each question has a secret code that must be found out. Users
will be able to create contest based on puzzles and also, they will be able to solve problems in teams.
This paper is a general description of the project. In the first chapter is described in more details the
problem that this project solves, the solution for this problem, what is the scope. Also in the first chapter

17
has the market analysis, the market size, addressable market, serviceable market, the profit and a compar-
ison with the possible competitors. In the second chapter are described the functional and nonfunctional
requirements. In the third chapter is described the system design. The system design chapter contains a
number of UML (Unified Modelling Language) that describe the architecture of this project.

18
1 DOMAIN ANALYSIS

The purpose of this project is to offer an online platform for those who want to better their problem-
solving skills. The online platform is supposed to fill the gaps found at its competitors and inherit the best
features from them so that finally to have a more flexible, accessible product for those who want to learn
new things by solving problems.
A problem on the platform represents a set of questions that require research, intuition, and deduc-
tion in order to be answered. Someone who solves the problems will have to the browser on the internet for
example, in order to be able to answer. A problem is not a quiz-like set of questions, but rather questions
that cannot be answered without research.
The idea came out from the puzzles created by an anonymous organization with the name Cicada
3301. [5] The puzzles were meant to recruit code-breakers from the public.
The motivation is to offer a platform, that inherits best practices from its competitor and avoids their
shortcomings, for those who want to develop their skills of problem solving and to learn something new
while solving the problems.

1.1 Problem Analysis and Definition

As we know, since the internet became so widely used, there are different websites for learning
various topics such as math, physics, programming, etc. All of these platforms differ from one another.
One is focused on a specific topic, for example, history, another one on a different topic, and so on.
Also, we have access to many platforms to train our problem-solving skills. Let’s take as an example
one of the websites for coding contests, be it the well-known codeforce.com. [17] And again, on this kind
of website we solve problems, and at the same time we better our skills in problem-solving, but they are
based on a single subject, which in this case is programming. Competitive programming websites have
features such as creating contests and solving problems in teams and they motivate the users to solve more.
There are platforms with the aim to teach through practice within interactive problems. A kind of such a
website is brilliant.org. [7]
It is clearly seen that all of the platforms mentioned above, or at least the kind, have a common goal
and this is to train skills in problem-solving. But these platforms cannot embrace all the subjects that might
come to our minds. The platforms in case, are limited by the way they are built, they follow protocols. This
might be an issue for a more creative person who wants to create a problem with a unique structure.
Since it was mentioned about the creation of the problems, some of the above-mentioned websites
allow only to solve problems, or, if to create a puzzle they require a different type of account. Considering

19
that, thinking about how to create complicated problems can also train someones problem-solving skills
and better their creativity, it is a good idea to let users be able to create problems for others. And of course
- not requiring a different account or some privileges.
Now, since it has been mentioned about privileges, it is known that online courses, especially those
that have interactive learning, require payments in order to have access to the courses and the prices are not
affordable for all. This is a problem for people from poorer countries. Usually, most known sites, any kind,
not only educational as in the case of the platform described in this paper, are founded in richer countries
such as the USA, and the value of, for example, 5$, is obviously not the same in poorer countries.
Problem definition – Available course oriented and interactive based platforms that help to develop
problem solving skills have the following shortcomings:

– cannot embrace all areas of study;

– are expensive;

– you either use the content with a simple user; account or create content with a special account;

– on some of the platforms we cannot create contests and teams.

1.2 Solution and scope

To develop a platform that will be free, with free text content so that problems to be solved can be
created on any subject and without restrictions/protocols. Also, the platform should inherit main function-
alities from some of its competitors such as contests, solving in teams, etc. A problem will represent a set
of questions which in order to be answered will require research, intuition, and deduction.
The scope is to offer a platform for people who want to solve problems in order to better their
problem-solving skills and to study a subject by research. The platform will have the following character-
istics in relation to the discussed limitations.
It will require a single account that will allow to create as well as to solve problems. The problems
will have a defined structure but the content itself will be free text, such as writing a blog post. This
will allow to create any kind of problems as one can imagine, on any desired topic. The platform will be
completely free and will embrace as many functionalities as possible from its competitors, such as creating
contests, solving in teams, etc. The content on it is grown by the community itself, which doesn’t imply
any specialized group of people that have to create problems.

20
 Domain Analysis Conclusions

In this chapter was discussed that is the purpose of the project and the problem that it solves in
relation to its alternatives which is that problem solving platforms that are already out there miss some
functionality, some of them are paid and other disadvantages. This chapter describes the solution which is to
create a new platform that offers a slightly different problem-solving approach and offers more possibilities
or opportunities.
After that, the scope of the project was defined, which is to offer people an alternative platform
where they can solve intellectual problems that involve knowledge on different areas and required research,
intuition, and deduction in order to be solved, when they want to develop their problem-solving skills.
The project that is described here is a new way, a new approach in which someone can solve prob-
lems. This new approach is inspired by the cryptography puzzles published by the anonymous organization
named Cicada 3301 in order to recruit intellectual people from the public. [5]

21
2 REQUIREMENTS SPECIFICATION

To have a clear vision of what should be done and on what the system is based on, it is needed to
have defined the functional and non-functional requirements. The non-functional requirements show the
reliability of the system and how it performs its functional requirements. The functional requirements show
what the system should do and these requirements usually represent the use cases of it.

2.1 Functional Requirements

These requirements show what the system offers to the end-user and all together are a description
of the system’s behaviour. The problem-solving platform has a set of functional requirements targeted to
bring more possibilities/ and opportunities to the user and this makes the system different from the others.
They are next described in regards to their behavior, how should be used and, their inputs and outputs.
R1 In order to create an account the following information will be required: username, full name,
email, password. After the account is created, the user will have a My Account page from which will be
able to edit the above-mentioned fields.
R2 The core entity of the platform is the problem. The problem should have the following charac-
teristics:

- each problem must have a general description;

- the problem consists of stages and each stage must have a secret code to be found;

- each stage must have a description;

- in order to go to the next stage, the previous stage must be solved.

R3 Anyone who wants to solve problems must have an account on the platform and once a person
owns an account he/she will be able to: create problems, solve problems, create contests, participate in
contests, create teams and be invited in teams.
R4 The contests on the platform will represent an existing problem on the platform, but with a
defined time when it can be solved. Contests must have a start time and end time. On the same contest
can be enrolled solo players as well as teams, therefore contests will have winners that can be either a solo
player or a team. The contest will be won by the first solo player or team who finished the last stage of the
problem on which the contest is based on.
R5 On the platform, users can create teams and when choosing a problem they can solve it either
solo or with a team of whom he/she belongs. Each team must have a name. When the team is created

22
it is required to be specified at least two players (one being the author of the team). There will not be a
restriction of how many members a team can have. The author of the team can leave the team and this does
not mean that the team will be destroyed. Only the author of the team can edit it and editing a team means
changing its name or adding/removing team members. Once a users is part of a team, he/she can enroll the
team at any problem or contests in the name of the team. If a user is enrolled to solve a problem, it is not
restricted that he/she cannot be enrolled at the same problem within a team.
R6 The platform will have a top feature with the help of which top 20 solo players and top 20 teams
will be shown.
R7 Each problem will have a difficulty set by the creator of the problem and it will be named
difficulty by creator.
R8 Players will be able to vote the difficulty of the solved problem (from 1 to 5) and the average
difficulty will be calculated and set for the problem. This difficulty will be named difficulty by statistics.
R9 The platform will have an advanced search engine that will search based on the following enti-
ties: problems by name and tag, contests by name and users by full name and username. There will also be
available a filtering functionality for contests, teams, problems.
R10 A user (player) will be able to see the account of another user. The account of a user will
have the following information: username, email, full name, created problems, created contests, created
teams, teams of which he/she is a member, contests that he/she won, solved problems and all open problem
sessions (solved and unsolved problems).

2.2 Non-Functional Requirements

The non-functional requirements are the type of system characteristic that will tell the strength of
the system. This strength is defined by how secure, available, scalable, maintainable the system is, how well
the system protects the data, and other characteristics related to the quality of the system as one service.
R1 A deleted account should not be deleted from the database, but just disabled.
R2 The system should support at least 500000 user accounts, at least 1000000 puzzles, 500000
teams, and at least 100000 contests.
R3 The system should be available anywhere there is an internet connection.
R4 Each month the new data from the database should be put in a backup.
R5 The system should have protection for CORS (Cross-origin Resource Sharing) attack, CSRF
(Cross-Site Request Forgery) attack, and SQL (Structured Query Language) injection attack.
R6 Any page on the website should not take longer than a second to load.

23
 Requirements Conclusions

In this chapter were defined the functional and non-functional requirements for this project. The
project has a good amount of functional requirements since it focuses on bringing more functionalities in
comparison to its competitor. But this is not the only concern. Regarding non-functional requirements, the
project focuses on being an easy-to-use and not annoying website that runs fast, can hold a decent amount
of users, and is secure.
The defined requirements will help to have a clear vision of the whole system. Usually, requirements
are users’ needs or in other words – what they expect from this platform. Also, especially functional
requirements, are the things that a system unique from its competitors. Having a bigger set of functional
requirements may bring more value to the business and having well-defined non-functional requirements
may be a good assurance for the business.

24
3 SYSTEM DESIGN

The diagrams that will be used to graphically represent the architecture of the platform will be
chosen based on the 4+1 Architecture view model. This model groupers the UML diagrams in five views:
use case view, logical view, process view, physical view, and development view as it can be seen in Figure
3.1. For some of these views there are more types of UML diagrams suitable and for others just one. It is
needed to choose the right UML diagrams that will describe the project better.

Figure 3.1 - 4+1 Architecture

Note: A problem is also referred to as a puzzle in this paper.

The platform to be implemented is actually a business entity wrapper with use cases atop. The en-
tities are mutated through activities on the platform. The system does not have states and one can tell that
state diagrams do not help us describe the system. The activities performed on the system don’t have im-
portance in relation to time, therefore one can say that sequence diagrams aren’t necessary. Instead, activity
diagrams will be used to show what actions can be performed on the platform and in which order. Activity
diagrams will be used to describe in more detail the use cases. It is important to show the relationship
between the entities to have an overview of how the system works internally, for this class diagrams will be
used. It is not needed to describe the whole system including frameworks/libraries since their architecture
can be found on their official website and it is not our goal to describe other projects, but the one we are
implementing. For example, class diagrams of the Symfony framework aren’t a necessity to be described
in this paper. [symfony] But we can show in a general way how our implemented elements interact with
the framework, for example in the case of class diagrams it can be shown what other classes our classes
implement or extend. Or, in the case of a component diagram, we can show what component our unique
components are using from the framework. The platform does not have communication between compo-

25
nents that is really important for the system and it is not important to show how components call each other,
because, there will be calls mostly to setters, getters, service method calls, and other calls that are obvious
in an MVC architecture, therefore communication diagrams are not needed.
To summarise, for the logical view will be used class diagrams, for the process view - activity di-
agrams, for the physical view - deployment diagram, and for the deployment view - component diagrams.
For the back-end side will be used a RESTful (Representational State Transfer) API (Application Program-
ming Interface) based on the MVC (Model View Controller) architecture and on the client side, as a client
to the back-end will be ca single page we app.

3.1 UML Diagrams

UML diagrams are the type of diagrams that are used to represent the structure of a service, how it
behaves and how the system is deployed. This kind of diagrams are used online in the IT sector to describe
software, but they also can be used in business and other areas. UML is a graphical language with the
help of which three categories of diagrams can be created: structural diagrams, behavioral diagrams, and
interaction diagrams. Some of the diagram suit better than the other for a specific project. In the case of the
project described in this paper in order to describe the structure of the system were used Class Diagram,
Component Diagram and Deployment Diagram. In order to describe the behavior of the system were used
Activity Diagram. All UML diagrams were created using Visual Paradigm Community Edition. [20]
The UML represents best practices for the development of an informational system. All developers
understand this graphical language and through it, developers communicate to each other how the system
has to create and how it should behave. The language is important in the process of development because
it helps to keep track of the system through releases. One big advantage of UML is that it is platform
and technology independent. This way, the UML language can be used in a wide variety of use cases, for
different types of informational systems, but also in businesses and other areas. It also supports development
concepts at a high level such as patterns, frameworks, components, and collaborations. UML has a lot of
different diagrams and the reason is that a system can be analyzed from different angles. Different people
that are working on the same project need different types of diagrams to analyze it. There is more version
of UML, but the latest, most used, and most stable one the version 2.
In this paper some diagrams were simplified or splitted up into smaller diagrams to have easier-to-
digest graphical information. For example, the Class Diagram was split up according to the system subjects
into two smaller diagrams. One Class Diagram represents the links between Users, Accounts, Teams and
PuzzleSessions while the other shows the links between Account, Puzzle, Stage and Contest. The other
digrams are shown integrally including the front-end side as well the back-end side to have a clearer view
on how the two sides interact.

26
 3.1.1 Use Case Diagrams

Use case diagrams are just a graphical way to tell what functionalities the system should support.
The functional requirements of the platform are written in Section 2.1. Bellow will be represented the most
important functionalities using UML diagrams. The website would not make sense without users. Users
should have accounts registered where their progress can be recorded, and this is just one of the reasons.
The use cases related to the account will be to create the account, to log in to the system, after the account
is created we can change the password, username, or delete it as shown in Figure 3.2.

Figure 3.2 - Account related use cases

Some of the main features are to create puzzles, teams, and contests. Puzzles and contests which are
actually puzzles as well but on time, can be solved either solo or with a team. As it is shown in Figure 3.3,
when someone wants to enroll in a contest/puzzle he has the option to select to solve it solo or with a team.
The Create team use case is part of the more general use case named Manage teams that has other two use
cases: Leave team and Delete team. A team ca be deleted only by the user who created this team. Anyone
who is a member of the team can leat it, even the author of this team. Further, in Figure 3.4 are shown the
use cases related to puzzles and contests.

27
 Figure 3.3 - Puzzle and team related use cases

When someone wants to create a contest he/she has the option to create a new puzzle if the new
contest will not be based on one of the existing puzzles. It is needed to choose a puzzle on which the
contest will be based on. The use case Check stage code is the use case when a user is enrolled in a puzzle
and solves it by checking a secret code that has to be found for each unlocked stage.

Figure 3.4 - Create contest and check puzzle code use cases

28
 3.1.2 Activity Diagrams

As it is shown in Figure 3.5, in order to create a puzzle, a set of fields should be filled in, which are:
puzzle name, general description, tags, difficulty, a set of stages each with its description and code. After
all these fields are filled in the puzzle is sent to the back-end server to be persisted in the database. The user
is notified if the puzzle was saved successfully or not.

Figure 3.5 - Create puzzle activity diagram

This activity diagram includes all possible flows that a user can perform. It shows the actions that
can be made on the front-end side and on the back-end side as well. When the user saves a puzzle, a puzzle
object is sent to the REST API. The REST API will create a new puzzle object, then, if the object sent
comes with non-existing tags, the tags will be created and finally, if the puzzle and tags are successfully
persisted in the database then the puzzle will be returned back to the Client web app.

29
 The activities involved to solve puzzles and their order are shown in the Figure 3.6. As mentioned,
in the beginning, the user decides if he wants to solve solo or with a team. A session is an entire process
starting with the time when the user enrolled for the puzzles until he removes the session. The session takes
care of the progress on the puzzle and holds other information about how the user solves the puzzle. A user
can have more sessions on the same puzzle because he can be enrolled for a puzzle solo – one session, with
a team – the second session, with another team – another session, and so on. When solving a puzzle, it is
needed to select for what session you want to solve at the current time. Solving puzzles means reading the
stage description, then a secret code should be found, and the player checks if the found code is correct or
not and repeats this process until the last stage is reached and solved.
From Figure 3.6 one can notice that there is a tight communication between the Client web app nad
the REST API. This diagram also shows the actions needed to remove a session and the actions needed to
enroll in a puzzle.

Figure 3.6 - Solve Puzzle activity diagram

30
 3.1.3 Class Diagrams

The following two class diagrams show which entities are connected to which. We opted for an
approach with more connection between the entities in order to simplify at some level the complexity of
the code in the services and to be easier to add new functionality. The idea is to do just one query to the
database to get an entity and also more of its connections with other entities. But one of the disadvantages
of this approach is that sometimes we do not need that much information that comes from the database. We
can improve it with lazy fetch types for aggregate/composed entities.
In Figure 3.7 is shown the relation between an account and puzzle, contests and notification. In
this system, notifications are being represented as an entity. This diagram has described the relationship
between a puzzle and its stages, and also the relation between a puzzle and a set of tags. A puzzle can have
multiple tags that describe what is this puzzle about. A puzzle is composed of a set of stages also referred
to as levels.

Figure 3.7 - Relations between Account entities and Puzzle related entities

In Figure A.1 can be found the complete class diagram for the entities used for this project. In that
figure, it is easier to see all the connections between all entities, which entities use which. These class
diagram shows not only the relations between entities but they also show what field each entity has and of
which type.

31
 In Figure 3.8 is shown another side of the system that includes the following entities: Account,
User, Team and PuzzleSession. A team can have 0 or more puzzle sessions and that means that a team can
or cannot be enrolled to solve a puzzle. A user has a single account. If the user is deleted, then the account
is also deleted. A team has a user that is the author of this team. A team has 1 or more accounts, one account
is the account of the user who created this team. The last relation explained is also vice versa.

Figure 3.8 - Class diagram that shows relation between User, Team and PuzzleSession

Figure A.2 shows the same thing as the entity class diagram but from the perspective of a database.
The schema was modeled with MySQL Workbench. [12] This schema describes how the system’s entities
are being mapped into the database. The many to many relations from entities are represented using join
tables and the one to many relations are implemented at the database level using foreign keys in the owner
table. The process of mapping the entities from the back-end to the database and vice versa is done by an
ORM (Object Relational Mapping) framework.

3.1.4 REST API Component Diagram

Figure 3.9 includes the framework components and the components specifically written for this
project following the MVC approach: Controller, Entities, Services, Repositories. But there is an exception.
In our case there is no V (View) since it is going to be an API that will be used by a single page web
app application. The services will implement the business logic, the repositories will fetch data from the

32
database, the controller will open endpoints. The security component will take care of authentication and
authorization and this will be based on JWT. This diagram is suitable for any MVC framework since all
these frameworks have the same architecture and principle to function.

Figure 3.9 - REST API Component Diagram

In Figure 3.9 is shown which component communicate to which and what interface they are using
for communication. The process of communication can also be referred to as usage since one component
uses another in order to get a task done. The most important component are the controller, the service, and
the repository. The controller acts ad HTTP request receiver. The controller sends the HTTP requests to
the service and the service implements the business logic. The service uses repositories to work with the
database.

3.1.5 Deployment Diagram

The website will be deployed on a static server or a virtual machine. The client app server which
has the role to serve web pages will run on a Docker container, as well as the REST API, will run on its
container and the database on its own container. In front of them, as a gateway, will be used Nginx running
on its container. Nginx will open the ports for the API and client app communication. Only the API server
will communicate with the database, therefore it is not needed to open a public port for the database on the
virtual machine.

33
The physical components and how they interact are described graphically in Figure 3.10.

Figure 3.10 - Deployment Diagram

System Design Conclusions

In this chapter is explained why UML diagrams are important in the process of system architecture
planning. Chapter 3 tries to show an agnostic architecture of the platform, because framework and OOP
programming languages generally rely on the same principles. In this chapter were used only a subset of
the UML diagrams which are the most suitable for the kind of this project and these diagrams are: Use
Case diagrams, Activity diagrams, Class Diagrams, Component diagram, and Deployment diagram. In
the appendices can be found two more complete diagrams related to entities class diagram and database

34
schema.
By having the architecture of a system represented graphically in diagrams before starting imple-
menting it is a step forward towards having a clean architecture that later can be extended into a more
complex system with more capabilities. It also helps in the implementation phase and to understand the
internal structure of it, ass well.

35
4 PROJECT MANAGEMENT

This chapter explains how the project will be managed in regards to competitiveness, marketing
strategy, and the process of developing it. In the Economic Perspective 4.1.1 section are presented the
SWOT analysis that shows the strengths, weaknesses, opportunities, and threats that the project might have.
Moreover, in the Competitive Analysis 4.1.2.1 section are being described the competitors and how this
system is different from its competitors. Later, in the Cost analysis 4.1.3 section it is described how much
money the project takes to be brought to life in regards to utilities and workforces. The Marketing Strategy
4.1.2 section describes how the product will be popularized, how it will be presented to the customer. In the
Project perspective, 4.3 section are shown the success metrics, the project management approach in regards
to development, how the project will be decomposed into tasks, task prioritization, and scheduling.

4.1 Economic perspective

In this section is argued how this project with its slightly new idea is going to gain its users and the
cost to bring the project to life. As it can be seen in Table 4.1, the project has some weaknesses and threats,
but at the same time, it also has some strengths that make it different from its competitors and opportunities.
The project doesn’t take too much time to implements its MVP (Minimum Valuable Product) since it does
not require sophisticated technologies or any special programming skills. The system is mostly a form-
based web application. At the same time, it does not require a big number of developers.

4.1.1 SWOT Analysis

SWOT analysis (or SWOT matrix) is a technique used to identify what weak and strong points a
product, organization, or anything else has in relation to their business competition or project planning.
SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. It is a tool is used to make decisions
in an organization and is also used to make strategic position evaluations for an organization of any kind. It
is one of the most used strategic tools for managers. [8]
In the Table 4.1 bellow represents the SWOT traits of the application that is described in this paper.
These characteristics can be used when it is needed to make a comparison with competitors.

36
Table 4.1 - SWOT analysis for the problem-solving platform

Strengths
1. A platform the will inherit the most important
functionality from its alternatives;
2. The problem definition will not follow
a defined structure, therefore creativeness can be
involved in the composition of the problem;
3. Users can solve, as well as create problems;
4. The platform will be completely free;
5. Easier to implement since it is a free text structure;
6. Self-growing content (problems are being added;
by the same users), which means that it is
not required to have a specialized group of people
to add content on the website;
Opportunities
1. The opportunity to develop skills of
problem-solving;
2. The opportunity to be a creator by
creating problems for others;
3. The opportunity to organize contests
and to make teams;
4. The opportunity to find highly
intellectual individuals;
Weaknesses
1. Those who create problems can create
malicious problems, that can affect
the solvers;
2. A user can create spam-like problems
and by doing so, he/she will deteriorate
the quality of the platform content;
3. Not having a mobile app at the
beginning;
Threats
1. The platform won’t be attractive until it
gains a good amount of problems available;
2. Since it is going to be completely free, a
way of income should be found. I might
be either through donations or by showing
ads on the pages of the platform;

As it has been explained in Section 1.1, there are many online platforms that offer problems for
problem-solving skill training and they are all different between them. In the following table are shown
some of them with their advantages and disadvantages.

4.1.2 Market analysis

The problem-solving skill training platform will be created for those who want to become better
at problem-solving and also for those who want to learn by solving problems because by having free text
problem definitions, problems can be composed in such a way that it will require research in order to be
able to solve it. The platform also can be used in schools or universities for taking tests online. The teacher
will create problems which in this case will represent tests, and students will enroll. As mentioned above,
a problem will have a defined structure and the structure will be explained in the following chapters. But,
shortly, a problem will consist of stages and each stage will have a secret code/key. In the case of online
tests, stages can be the subject of the test.

37
 The platform will be affordable for all since it will be free. It can be used in global contests, similar
to those organized by Google for example wherein the scope is to find highly intelligent people. The
platform can be used worldwide, by any gender and age. As initially said, the target audience is the group
of people who want to improve their knowledge and develop the skills of problem-solving.
As the total market size of our project, it can be considered that those users which already use a
similar app for problem-solving like, leetcode.com, and want to try something else besides coding, students
interested in problem-solving are also in this category as well as those from the lyceum, or even those who
work and want to improve their problem-solving skill. After a short research, it has been summed up all the
users from top platforms like leetcode.com and has got about 45 mln users only from existing platforms,
54 mln people who are working as programmers-devs plus the number of pupils-students interested in
problem-solving. [2] [4]
Now, in regards to the addressable market, for this category, those who already used such a plat-
form were included. As in this area are many platforms, there isn’t present a monopoly, it will be easy to
attract users from other platforms, and more likely, the users will come from those which have an old design,
poor features, or even which are based on one topic, for example, you can take an instance the difference
between codility.com were are about 20.000 users and leetcode.com which, in 2 years, from 2015 till 2017,
gathered more than 1 million. Also, according to another research, it was found out that in the world 59
percents of the population have access to the internet, so from the whole total size, 1/4 should be subtracted,
not 1/2 because almost every student-pupil have access to the internet, and they do represent a big part
of the world’s population, it means from the total of 100 mln + a number of students-pupils interested in
problem-solving in the world, 1/4 should be subtracted from total market size. [14]
The problem-solving skill training platform will attract those who want to become better at problem-
solving and also for those who want to learn by solving problems, and most likely it will be easier to attract
students and pupils which didn’t use before such a platform, so, it means that here we will have an only
number of students-pupils interested in problem-solving, but not all of them will have access to the internet,
so we should subtract a small part from them, and most likely there will be users which got tired solving only
programming problems that will want to try something new. Finally, someone can say that the serviceable
market will be represented by the number of students interested in problem-solving.
Initially, the profit wasn’t a priority, the goal was to develop a non-profit platform that would help a
lot of people to improve their skills, and would bring competitiveness among users, but even if it is needed
to get a bonus from our platform, we would get profit only from the advertisements or from promoting
some specific products/industries in our problems. Advertisements will bring low income, because this
income depends on many factors, such as Click-through Rate (CTR), CPC - Cost-per-click, and Clicks. For
example, if the system holds 10,000 users and only 1,000 users clicked on the ad, then the CTR is equal to

38
10 percents, the average CPS is 0.58 USD dollars, and say only 25 users accessed the ad, the total income
will be equal to 14,8 USD dollars, so it won’t bring much income while the system doesn’t hold at least one
million users.

4.1.2.1 Competitive Analysis

In Table 4.2 are presented the advantages and disadvantages of the available platforms that have
the same goal which is to offer problems (or exercises) and courses for those who want to better their
problem-solving skills.

Table 4.2 - Advantages and Disadvantages of available platforms

Website Self Description Advantages Disadvantages

brilliant.org “Build quantitative skills
in math, science, and
computer science with
fun and challenging
interactive explorations.
Brilliant helps you see
concepts visually and
interact with them,
and poses questions
that get you to think.”
skillshare.com “Explore new skills,
deepen existing passions,
and get lost in creativity.
What you find just might
surprise and inspire you.”
1. Interactive problems
2. Helps you see concepts
visually and interact
with them
1. Video online courses
2. A wide variety of high
quality courses
3. Courses on almost
any topic
4. Classes taught by
real creators
1. Contests cannot be
created, therefore not
competitive solving
can be made
2. Teams cannot
be created,
therefore it doesn’t
facilitate collaborative
problem-solving
3. We can not create
problems. In order to
do this it is needed
to have some privileges
4. It requires payments
in order to be used
1. It is paid
2. It does not offer
problems to be solved,
therefore, there are
no contests and teams

The advantages and disadvantages shown above bring to light the importance of the system that is
described in this paper. the problem-solving platform that is described here offers those things that are not
offered by the two examples shown in Table 4.2. For specific use cases, the platforms show above are better.
This comparison and the disadvantages presented don’t have the goal to tell that the two alternatives aren’t

39
good. They are used in this case to present a clear comparison between the system that is described in this
paper and its competitors.

4.1.3 Cost analysis

The project is not a complex one and does not require sophisticated architectures doesn’t require
special algorithmic skills from developers and since it is not a complex system with many microservices it
can be developed by a small number of people. But still, there is a number of things that require money to
use them. Hardware stuff needed for development such as computers – it is not needed to buy new ones and
developers will work on their laptops, because the project does not require a set of security rules that would
make the teams use specific computers. Regarding technologies used in development and production, all of
them are free and satisfy the needs. For example, a MySQL free edition database is more than enough for
the start of this project. Regarding backend, most MVC frameworks are free for any programming language.
In regards to HTTP server, there are two most popular choices that are Nginx and Apache HTTP server.
Bot of them are free and satisfy the needs for this project. Regarding the software needed for development,
all of them that are needed are free and those are MySQL Workbench and Visual Studio Code.
The only thing that it is needed to pay for is the hosting server. The hosting server is also needed
in the development phase for testing purposes, for example, to test the performance through the network.
Later, in production, it will be needed to pay the hosting each month. If the project will have success the
number of users will grow and this means that the hosting server will have to be more powerful which
means that it will be more expensive per month. Making the hosting more powerful is also referred as to
vertical scaling. But there is also another approach – horizontal scaling, which means to replicate API on
more hosting servers in order to be able to serve more users in a short time. This approach is also more
expensive when more virtual machines are being taken as hosting servers.
There are many services that offer hosting servers such as Amazon EC2 - AWS, DigitalOcean,
Google Cloud, etc. To make a prediction on how much money will be spent per month in the process of
development, prices from DigitalOcean will be taken as examples. DigitalOcean offers three CPU (Central
Processing Unit) options: Regular Intel with SSD, Premium Intel with NVMe SSD, and Premium AMD
with NVMe SSD. The cheapest and most suitable for testing is the first option. The thirst option itself has
more sub-options. For testing purposes, it is enough to have a server with just 1 CPU, 1 GB RAM, 25GB
SSD, and 1000 GB data transfer. This option is the cheapest one that costs 5$ per month. The project is
estimated to be developed in about three months, which means that for the testing host it will be needed to
pay 15$ in total. But this is the maximum of the price because DigitalOcean charges perused hours, which
means it is possible to pay only for what is used and how much is used.

40
 4.1.3.1 Salary expenses

Since the project is categorized as a small one that might be implemented as a MVP in about three
months, it does not require many developers. It is not needed to have a specialist for each role in the project,
but rather one person can have more roles. It is needed to have three people that are working on the project.
One of them will be the API developer. The API developer will be the one who best knows the bossiness
and will also be the Project Manager and the System Architect. The client web app developer will have
one single role that is to create a user-friendly interface. The third person will be the integration tester.
The integration tester will also have the role of DevOps. Depending on how many responsibilities the team
members have, their salaries will vary from one to another as shown in Table 4.3:

Table 4.3 - Salaries for team members

Team member Work hours Per hour, $ Costs, $

Client Web app developer 150 25 3750
API developer (+Project Manager, +Software Architect) 150 35 5250
Integration tester (+DevOps) 70 30 2100
11100

As shown in Table 4.3, the amount of money that would be needed to pay the salaries during three
months is 11000$. That means that per month it would be needed to pay 3700$, for salaries.

4.2 Marketing Strategy

In this subsection is explained how the platform is going to be marketed. It is important to have
a customer avatar overview because it helps to understand better who is this platform targeting. In this
subsection, it is described the strategy of making the platform more popular.

4.2.1 Customer Avatar

Any business should have a vision of its ideal customer. The ideal customer is also known as the
Customer Avatar and can be described in a form of a spreadsheet of characteristics that refer to the customer.
The customer Avatar describes in detail and without abstractions an example of a persona that would be the
ideal client. It is needed to have a customer avatar for any kind of business because it helps to understand
who is this business targeting. The Customer Avatar is better than an abstract description of the customer
because it shows concrete characteristics of the customer that can be compared to a specific person and
then predict if that person is a good possible client or not. Next is described the Customer Avatar for the
problem-solving platform that is presented in this paper. The Customer avatar will be described in regards

41
to Demographics, Goals and Values, Sources of Information, Challenges and Pain Points, and Objections
Role in the Purchasing Process. [21]
Demographics: His name is Stefan and is 22 years old. He does not lack money. He is not married
and does not have children. Lives in the USA and is a Computer Science student. His favorite quote is ”Life
is mean to be discovered.”.
Goals and Values: Stefan wants to be better at problem-solving of any kind so that when he will
face a problem in life, he will be able to solve it. Stefan is committed to personal development. He whats
to make something revolutionary in the world and change it in a better way. Stefan likes intellectual and
mystery games. Stefan thinks that people should never stop learning.
Sources of Information: Stefan reads books about how to be better in life, about how to have
success in life. He also reads books about history, cryptography, life problems. Stefan sometimes watches
YouTube videos about the problems in the world, entrepreneurship, and other related.
Challenges and Pain Points: Stefan is afraid that he will not be able to make a change in the world.
He thinks that his personality is not good for a person who can handle a business and solve its problems.
Objections and Role when using the platform: Stefan wants to have sharp thinking. He wants to
learn new things by solving problems. Stefan wants to meet new people who also want to learn new things
maybe of the same topics.

4.2.2 Customer Acquisition Strategy

In order to get to the desired customers it is needed to have a plan on how to make them aware of
the platform. But making them aware is not enough. It is also needed to convince that it is worth using the
platform. For this project the checks that will be needed to gather the customers are the following:

a) the Web app uses a call to action strategy;

b) a video that explains the idea of the platform should be prepared and promoted on social networks;

c) a video that explains how the platform is used should be available o the Web app;

d) the video that explains the idea should be promoted and set to reach a people of the following cate-
gories on social networks;

1) age between 16-25;

2) students or pupils;

3) those who are interested in intellectual games, based on their social network behavior.

42
 e) the web app should have social network links with which users can share puzzles and the platform
itself;

4.3 Project perspective

In this section is being explained the success metrics of this project, how the project is going to be
managed in the development phase. Also, here are listed the tasks needed to implement the API and the
schedule for these tasks alongside the tasks needed to implement the User Interface. The tasks are also
prioritized by their importance.

4.3.1 Success Metrics

After there are analyzed the most important KPIs (Key Performance Indicators) that bring success
to a project, the conclusion is that next KPIs will help to achieve the goals and most importantly to finish
the project without any problems or errors that usually appears when KPIs are not defined correctly and
make them as SMART as possible and use the M.E.C.E principle. [10] [15] [9]
In order to assure that our product will attract users and more importantly, keep them longer on the
web app, one of the metrics is Customer Satisfaction. Through this metric, the goal is to be sure that there
will be a present good atmosphere when users are navigating through our web app. This can be identified
in 2 stages, before deployment, and after deployment, and measured with multiple variables, like customer
survey results, revenue generated from clients, repeat or lost clients, and complaints. Before the deployment
stage, will be used different kinds of surveys in order to find out different opinions about our app features,
design, what is missing in order to achieve better results and it can be measured as follows:

CustomerSatis f actionScore = (TotalSurveyPointScore/TotalQuestions) ∗ 100 (4.3.1)

Of course we can use it and after deployment, but it won’t be as effective method as before. After
deployment, the easiest method to find customer satisfaction percentage is simply be monitoring the number
of active users in previous month vs the current month, it will be something like:

CustomerSatis f actionScore = (ActiveUsersOnMonth/ActiveUsersPastMonth) (4.3.2)

Here some limits can be defined, like between 0 and 0.8, very bad, between 0.80 and 1 – good score,
between 1 and 1.2 – great, and between 1.2 and above – greatest, or it can be divided into 2 parts simply,
passed score (greater or equal to 0.8) or failed score (from 0 to 0.8), but as we think it’s realistic to get 100
newly users per month, so there will be the only ratio above 0.8. This metric is one of the most important,

43
because as was mentioned before, it is wanted to get as many users as possible, and by monitoring customer
satisfaction – it’s possible to do that.
Another important KPI for our project is Earned Value, this will help to track how well we have
done the task prioritization and created the schedule. This can be measured according to the next formula:

EarnedValue(EV ) = CompletedWork/BudgetAtCompletion(BAC) ∗ 100 (4.3.3)

where completed work means both functional and non-functional requirements achieved at some
point. It can be trackable thanks to the product backlog and to the documents where all requirements were
defined. As there are many functional requirements it’s a very relevant KPI for the project. Thanks to it,
it’s possible to re-prioritize the tasks if some low earned value percentage is met, it will mean that we were
not focusing on the main goals that’s why we should take it into account as many times as possible till our
product reach the maintenance phase. This KPI will help accomplish some goals like maintain or improve
the schedule based on the project plan.
As it is wanted to use the feedback from customers in order to create a perfect web app, of course,
some key functional requirements that some of the customers would like to be present can be missed, that’s
why it is needed to know the percentage of work that needs to be completed, or in other words, how much
ahead or behind of the planned budget the project is. Thanks to Schedule Variance metric it will be able
to do that. This is a key metric when during a project there may appear some new requirements that are not
initially described in the documentation phase. Of course, this is not the only goal that can be achieved with
it, there are other goals, like meeting project milestones, manipulating project scope, and of course getting
high-quality project outputs. It can be simply calculated according to this formula:

ScheduleVariance(SV ) = BudgetedCosto fWorkPer f ormed–BudgetedCosto fWorkScheduled (4.3.4)

This indicator can be measured both at the end, but in this case, it will be measured during the project
execution for tracking the status of the project in different stages. And according to the result, if the result
is a positive number, it means that it was underestimated the amount of time that is needed to complete
the project/tasks or even that workforce was insufficient, but fortunately, it can be minimized, for example
setting realistic expectations from the beginning for the team and of course setting accurate deadlines for
the project.
Another KPI which will also be taken into account is Resource Utilization, thanks to it, will be
able to track the planning and resources in such a way to not overload some of them, and another key factor
why we have chosen it is the fact that it’s a foundation for other metrics that were used, even for schedule

44
variance. We can analyze used time which will tell the effectiveness of our planning and how correctly we
have estimated the task duration for example after the assignments were completed. This metric will be
used while we will do the scheduling part and prioritization and will take it into account while adding new
features. The actual utilization of a resource can be calculated according to the following formula:

ActualUtilization = ReportedTime/ResourceCapacity ∗ 100 (4.3.5)

And as it is said that resource utilization is optimal if the result is between 90 – 100 %, but in this
case, the resource utilization may reach constantly 100 % which is an unhealthy environment, because as
was mentioned, new requirements, features may appear after the customer’s complete surveys, but also,
thanks to this KPI can be sorted the resources and we will allocate correctly tasks to those who have more
free time, or even find a resource by filtering a specific skill which is needed for a specific task, that’s why
it will be used during the whole project lifecycle.
Besides taking care of the project stages, plan, budget, the satisfaction of the team’s members will
also be monitored, that’s why was included Employee Satisfaction Score, because it plays a vital role in
the project lifecycle, if the employees are happy with the company, they are engaged with it, they are likely
to leave it during a project. It can be measured using the formula:

EmployeeSatis f actionScore = (TotalSurveyPointScore/TotalQuestions)x100 (4.3.6)

This is the easiest way to find out how happy is an employee in a company, also be measuring its
activity, a motivated person is a happy person, but a happy person is a satisfied one. Then it is possible
to divide them into 3 groups for example: very satisfied, somehow satisfied, unsatisfied and thanks to this
categorizing process we will know whom should we motivate, whom should we give extra tasks and be sure
that they will be completed at the given time.

4.3.2 Project Management Approach

After were analyzed most of the project management philosophies [19], their strengths and weak-
nesses, the conclusion is that the perfect suit for the project will be Agile philosophy. First of all, Agile
fits perfectly in this project, because it is wanted to be used the feedback of the customer, potential users
in order to create a web application that will attract users more, that’s why Waterfall has not been chosen
because with that philosophy customer will see the product at the end, there is present lack of customer
interaction-feedback. Of course, the Iterative Model is also a solution in this case, as it has similarity to
Agile, it gives a working version early in the process and as it is known, it will be less expensive to im-
plement some changes, but too many resources by repeating the process again and again can be lost. The

45
same goes with Spiral Model, there is preset both customer feedback, a working MVP, but the risk is that a
never-ending spiral can be obtained.
As for method choosing, here some difficulties are met, we were choosing between Lean Develop-
ment and Scrum, because other methodologies, like XP, Kanban, or even Crystal, don’t provide the needs
for this project, like fast project starting the process, as it’s said, Crystal methodology, planning and de-
velopment are not dependent on requirements, this is the main disadvantage and another one which is also
related to the fast project starting a project is the fact that it includes more variants like Crystal Clear (8-10
members), Crystal Yellow (10-20 members) and this feature of choosing the right variant also takes a lot
of time, moreover bad estimations for resources means failed definition of the budget. As for XP, this is
not the optimal solution, architectural design is more important than coding, as it stands, good architectural
design implies good coding structure, but not vice versa, and another disadvantage of XP, is the fact that
a registry of errors is not always maintained, which implies that in the next stages we will meet a lot of
potential bugs. Why not Kanban? Kanban does not provide time frames, which implies that we will meet
delays in every stage, but the strongest argument why Kanban Methodology is not chosen is the fact that it
does not have a prioritization system for tasks and very often information from Kanban Board, especially
when it is revealed outdated is misinterpreted by the team. [18]
In the end the conclusion is that Scrum is relevant for the project, and here are some key points
which shows this. Both methods are scalable when it comes to adding new tasks, but Scrum besides that
provides prioritization of tasks in later stages, meaning they can reorganize, in this way it can be ensured
that sprints that have not been completed yet to get more attention. The focus of quality is increased,
the transparency is present both in Scrum and Kanban, but not in the Lean Development, and this gives
extra motivation and even clearance who needs some help, who can take more tasks on his shoulders,
this improves resource management process. It also has Stand-Ups, which provides the effectiveness of
each member, by answering 3 questions, each member relates its dedication, misunderstandings, obstacles
they met during a project daily, and of course in this way the collaboration and motivation between the
development team are increased. There are also present Sprint Retrospective, the perfect way to find what
went wrong during the specific sprint, what can be improved. Also, there are different roles like Scrum
Master, Product Owner, and Scrum Development Team, which means that there are no persons that are
over-working, each member has its own responsibilities which are clearly defined.

4.3.3 Tasks Listing and Decomposition

All the tasks involved to implement the whole platform are grouped into five groups: The configura-
tion of Nginx, Database preparation, Docker container configuration, implementation of Front-End, and the
implementation of Back-End. One of the non-functional requirements is to have a decent level of security

46
and for this in addition SSL (Secure Sockets Layer) for HTTP communication. For this, it is needed to get
an SSL certificate and use it in the Nginx configuration. SSL certificates we can obtain from free providers,
for example, Let’s Encrypt is a popular choice. In the Nginx configuration will be specified how to process
the incoming requests, the ports to be used for communication between the client and the back-end, and
others. [16]
The database will not be accessible from outside the server (which may be a virtual machine). It
will be accessible only by the back-end that will be deployed on the same server. As a database engine,
MySQL will be used, because it is a mature relational database that has all the features needed to fulfill
our requirements for the project. The first step will be to install MySQL and for this, a Docker image will
be used. As it was shown in the deployment diagram all the parts of the system that are communicating
information will be running in Docker containers. The container’s images will be configured each with
its Docker file and, also, a docker-compose.yml, will be used to manage the containers. After MySQL is
installed, it is needed to prepare the database and this means to set up a database user, the actual database,
and the schema. The schema is tightly related to the entity class diagram.

Figure 4.1 - Tasks to configure Nxing, Docker container and database configuration

The Back-End and Front-End are the two components of this system that require most of the work.
Each one is a separate project. The tasks for the front-end can be implemented in parallel with one developer
on each side. But first, the environments have to be prepared for the front-end as well for the back-end. The
tasks are prioritized in such a way that it will be possible to go from the base tasks to more complex ones
that rely on the previous ones. The tasks are being divided based on the functionality of the system and this
functionality can be synchronized on the front-end and the back-end at the same time in development.
The Front-End will be a NextJS server that will serve the client with a ReactJS app. We are going to
use NextJS and not React only because of the SEO (Search Engine Optimization) reasons. When developing

47
the ReactJS app wrapped by NextJS, will be kept in mind the SEO optimization principles. Before the
development starts a mock-up will be made. The overall architecture of the ReactJS components has to be
prepared. After having the idea of how to implement the front-end, as shown in the WBS (Work Breakdown
Structure), pages for the front-end are implemented in sequence.

Figure 4.2 - Tasks API implementation

The Back-End will be an API implemented on the Symfony framework. The approach to implement
the back-end is to first setup the project to prepare the JWT based security, entities definition, and finally
the logic implementation per entity. For each entity CRUD (Create, Read, Update, Delete) operations will
be implemented and the additional logic. After each new feature/new logic added in the back-end will be
created unit tests.
At each development iteration will be used integration testing that will include all the components of
the system: Nginx, the Front-End, the Back-end, and the database. For this to be possible, first Docker con-
tainers should be configured and the Nginx server, while the Front-End and the Back-End can be developed
in parallel. This will be explained in more detail in the next two sections.

4.3.4 Tasks Prioritization

In order to prioritize the tasks the MoSCoW method [11] will be used because as we can see from
the section where functional requirements are defined, we can state that the system has many features and
not all of them can be implemented at once. From the functional requirements, it is clear that many stated
features are not as important as others, therefore we have to prioritize the tasks to implement those features

48
based on how important they are in relation to each other. If we would strive to implement all the features
at once we risk not only passing the deadline but also failing the project implementation.
MoSCoW method also helps us get at first a product that has the main features implemented and can
be already used by the client. The remaining features can be implemented within the budget and if they are
still needed.
Task prioritization using MoSCoW method:

a) Must have;

1) SignUp/Login (Account support);

2) Puzzle (create/update puzzle, explore puzzles, search puzzle);

3) Enroll and solve puzzle;

b) Should have;

1) Contest (create/update contest, explore contests, search contest).

c) Could have;

1) Teams (create/update team, includes to remove/invite a member, enroll as a team, my teams

page);

2) Search user;

3) Notifications support.

d) Won’t have (this time).

1) Top 20 solo players/teams.

4.3.5 Tasks Scheduling

Gantt Chart is used to schedule the tasks. In the following Gantt chart [3] the tasks are being
scheduled based on the task prioritization. Front-End and Back-End tasks were merged according to the
functionality because the back-end and front-end developer would work in parallel.

49
 FE - Front-End (User Interface)
BE - Back-End (API)

Figure 4.3 - Scheduled tasks

Project Management Conclusions

In this chapter was analyzed the market in order to see if the project might bring a benefit if it
reaches a good amount of users. Regarding that, it was analyzed the potential client, or in other words –
the addressable target. The SWOT analysis is used to have a clearer view of the strengths, weaknesses,
opportunities, and threats the system has. All these come in handy when it is needed to compare it with its
competitors.
Also here were discussed the prediction about how much would it cost the project in regards to
employee payment and technology acquisition. The estimates show that the project can be listed as a cheap
one since for development it would cost around 11000$ and for production per month, at the beginning, it
would cost about 15$. Besides that, in the Marketing strategy section, 4.2 were discussed the strategies used
to popularize the platform and also shown the customer avatar, which is the ideal client for this platform.
The niche to make the platform more know is Social Networks.
This chapter describes in detail how the project is going to be implemented. The desired methodol-
ogy to be used in the development process is Agile because this project depends on the customer’s needs

50
and it has many features where some are very important and others a less important. The development
framework is Scrum.
Also, in this chapter the project was divided into tasks. These tasks were prioritized by their impor-
tance. The most important tasks are those that are part of the MVP. To prioritize the functionalities of this
platform the MoSCoW method was used. After task definition, a Gantt chart was used to schedule them.
In the Gatt chart, the tasks for the front end are present along with the tasks for the back-end, because they
can be implemented in parallel and this allows integration testing from client app to API, even to database.

51
5 IMPLEMENTATION

This chapter focuses mainly on the back-end side which later will be described as an API (with some
characteristics of REST) running in a Docker container on a virtual or physical server. But, this chapter will
also be described parts of the client app that later will be described as being a SPA (Single Page Application)
client and what’s its role in the whole system.
This chapter describes the processes, architecture, and technologies used in the implementation
phase. Comparing to Chapter 3, this chapter talks about architecture regarding what technologies are being
used, because sometimes technologies also have an influence on the system’s architecture. Next will be
listed what technologies were used, for what purposes. Also, it will be argued why those technologies were
chosen instead of other alternatives.
In this chapter are shown parts of the implementation that are most important in understanding how
components are communicating to each other. Here are described the high-level architectural patterns used.
It will show how to initialize the project and parts of code from the server-side that are most important when
someone wants to understand what approach has been chosen to solve the problem.
Also, this chapter describes the tools used in the development process, and here are shown parts of
their configuration and how to use them to initialize the project.

5.1 Solution Strategy

This section describes the technologies used for the API and argues why those technologies were
chosen. Besides that, in this section will be shown the chosen architectural pattern used for the whole
project including the SPA client.

5.1.1 Technologies

Most of the time technologies depend on the kind of system that is being implemented. Since
service-oriented and microservice-oriented architecture became more and more used, in some cases for a
system we can have more technology candidates. For example in the case of the API that is described in
this chapter, it can be implemented using Java, PHP, C, and so on. In this section are presented the language
used to implement the back-end and the tools used in the development and deployment phase.

5.1.1.1 Version Control System

Nowadays almost any project, not necessarily an IT project, uses a VCS (Version Control System).
A VCS helps teams to work on the same project without having code synchronization issues. It helps to

52
manage the versions of a system. A VCS helps developers to maintain a common workflow for all team
members and to have a structured process of work on the project. There are some standard workflows
that most teams use and one of them is GIT Workflow. This workflow was used in the process of API
implementation. [1]
There are a few VCS tools such as CVS, Mercurial, Git, and others. In this project was used Git since
it is fast, is easy to use, and in general, it satisfies all necessities in the project implementation phase. VCS
work with remote hosting services. Some of the code hosting systems are GitHub, GitLab, and BitBiucket.
For this project was used GitHub because it offers all the needed features. The project was hosted publicly
and two developers worked on it, one front-end developer and one back-end developer.

5.1.1.2 Client Application

The client application is the part of the system that offers a user-friendly interface for the user to
interact with the system. In order to offer more portable and easy access to the app, from any device, it
has been decided to implement a SPA. Therefore, the website will be accessible from computers as well as
from mobile phones through web browsers.
Being a SPA the client app runs on the users’ machine and so it does not overload the server with
payload and request just to render something on the interface. SPA a more composable, that means that
this kind of interface can be easily extended with more featured because they have a clear component-based
architecture.
There are out there a few front-end frameworks or libraries with the help of which SPA application
can be implemented, such as VueJS, AngularJS, or ReactJS. All of them are similar and follow the same
principle that is to divide UI (User Interface) part into components in code. For this project was used
ReactJS since it runs fast and has a big number of libraries with which it can be integrated.
Single page applications run only on the users’ machine and those kinds of applications do not
transfer HTML content over the network. This fact is bad for SEO (Search Engine Optimization). SEO
is needed for search engines like Google or Bing. These search engines try to index websites by making
requests to them and seeing what has been returned. In the case of a single page application, if it is not
prepared for SEO, it will be returned to the user only a JS file that contains all the applications. The data
that is being sent back and forth between the client app and the API is only the data needed, for example, a
list of puzzles, without HTTP.
To solve the problem of SEO for SPA, there are libraries that make these applications behave like
the HTTP content was dynamically rendered on the server-side. For this project was use NextJS because it
was made to work specifically with ReactJS.
ReactJs applications run on Node servers. For this project, a Node server will run inside a Docker

53
container. The package manager that was used to manage the dependencies of the client app is NPM (Node
Package Manager).
The client app has a unique and authentic UI design. This design uses warm colors. The idea is to
be simple and focused o actions.

5.1.1.3 Server Application

Single page applications usually communicate to APIs. Nowadays, REST is one of the best choices
when designing an architecture for a system because of a number of advantages. In the case of the system
described in this paper, the advantage is that in the future if it is needed to replicate the back-end in order
to be able to handle more requests, it will be easy to replicate a REST API since the state of a session for
a user in not being hold on the server-side but on the client-side. Also, if later it is needed to add more
modules of the system, it will be possible to create another REST API for the client, since the client does
not depend on the APIs it uses.
For this project was selected PHP programming language because it is one that is solid, has good
documentation and code examples that would help to solve a problem quicker. As a framework, it was
selected Symfony framework, because it has a rich ecosystem of components that would satisfy all the
needs for the project and it also has good online documentation. The package manager that is used with
projects implemented with Symfony framework is Composer. Composer is a package manager uses in most
PHP-based projects.

5.1.1.4 Database

For this project a relational database is most suitable because there are many entities that are tightly
linked to each other. It does not need to use a document-based database or a column-based one, because
big data handling or speed are not a concern for the project. As a SQL based database engine was chosen
MySQL, because it is used in many projects, even in big systems like Tweeter, and it is known as a reliable
one.
On the API side, as an ORM has been used DoctrineORM since it integrates well with Symfony
framework, has good documentation, and a wide community that ensured stability. Doctrine ORM is a tool
that maps entities from the database to objects in PHP.

5.1.1.5 Docker

Docker is a tool that created and manages containers. These containers are like virtual machines, but
something lighter. By being light, they are easy to start and do not use much memory and computing power.
Docker is a tool that can be used in the development phase as well as in production. For this project, it was

54
used in the development phase, which helped us to be sure that all developers have the same development
environment in order to avoid issues. There are predefined configurations for development environments
and one of them that is a project name Laradock was used for this project. [6] Docker will also be used in
the production of the same configuration that was used in the development phase.
For this project five containers have been: node, workspace, php-fpm, nginx and mysql. These
containers have instead the environment already prepared depending on its purpose. The node container
is used to run the client app on it. The php-fpm is used to run the API. The nginx container is used to
run an Nginx container that will receive the request from the client from the exterior and will send these
requests further. Nginx is used as an intermediate server between the client app and server. The mysql
container is used to run the MySQL database on it. And, finally, the workspace container is used only in
the development phase and is has inside a number of tools used for development such as NPM, Composer,
and others.
The Docker configurations for the containers can be found in the annex B of this paper. In annex B
can be found the versions used for the technologies used for the project, what ports have been choosing for
communication, the container names, and what other tools have been used in the development process.

5.1.2 Architectural Patterns

After having the design done based on the functional and non-functional requirements it is needed
to select a high-level architectural model. Nowadays system architects chose the architectural style based
on the application that is being developed, on the number of the targeted users, on availability zones, and so
on. Generally speaking, most systems that are complex and are aimed to target a big number of users, have
a microservice-based architecture. and is scaled vertically, horizontally ad in depth. This is done when the
system has to grow in order to be able to serve more users. In the case of a new project, it is not needed to
overengineer, therefore the problem-solving platform will have the design shown in Figure 3.10.
Most IT systems rely on Client-Server Model where there there is a client (ex: ReacJS app) that
makes requests to an API that is the Server. In this case, the client is considered the app running in a
browser, or it can be a mobile app. In the past when high-level architectural patterns weren’t a big concern,
the client part was prepared and delivered by the server to the user, and in this last case, the client can be
considered the browser itself.

5.1.2.1 Client-Server Model

One of the most important principles in an IT system is to have components with a single respon-
sibility. The Client-Server architectural model follows this principle. The client has the responsibility the
offer a user-friendly UI to the user and the Server has the responsibility to serve the client with data. The

55
client is independent of the server. The server can serve more clients and in the case of a REST API, the
server should not know anything about the client.

5.1.2.2 REST

The API to be implemented will not be REST API, but will take some benefits from it, for example
– being stateless. REST stands for Representational State Transfer. This is a way to create APIs that do not
store information about their clients. These kinds of APIs only take data from the requests without taking
care of the sender client, processes it, and then returns a response that is client agnostic as well. According
to Wikipedia, a back-end server has to follow a number of architectural constraints in order to be REST.
These constraints are listed and described below. [13]

- Client–server architecture: separation of UI from the back-end site as described above;

- Statelessness: the resource state is being stored on the server and consists of information that is
independent of the client’s context;

- Cacheability: responses must define themselves as being cachable or non-chaceable;

- Layered system: the client shouldn’t know if it calls directly the server or it uses intermediate servers;

- Code on demand (optional): server can mutate the functionalities of the client by sending code
portions;

- Uniform interface: the interface depends on the system’s constraints.

REST rest is one of the most used standards for API, because it offers the possibility to scale up and
down the number of APIs. It should be taken into account that nowadays big companies relly of having a
scalable system if they want to serve a big number of users.

5.2 Project Initialization

As mentioned above, most IT projects are hosts on a VCS hosting provider. To host a project on a
hosting provider like GitHub, it is needed to have an account a git tool installed on the local machine. Git
has command-line tools and GUI tools available. The first step is to create a remote repository on GitHub.
After having the repository create it is needed to clone it using git with the following command:

$ g i t c l o n e <r e m o t e r e p o s i t o r y u r l >

where <remote repository url> is the URL that points to the remote repository provided by GitHub. This
command will create a local folder and in it will be the project files.

56
 The project consists of three folders: reactjs folder, symfony folder and docker folder. In reactjs
folder is located the front-end subproject and in symfony folder is located the back-end subproject. The
docker folder holds the configuration files for docker containers in which will run the parts of the project.
These configuration files are presented in annex B. In annex C is presented the Nginx configuration for the
API.
As mentioned earlier, Docker containers will be used for development and as well for production.
First of all, it is needed to build the images from which the containers will be created. Since all configuration
files are located in the docker folder, including docker-compose.yml the commands related to docker should
be run from the respective folder. With the following command Docker CLI will build the images and then
run the containers for those images:

$ s u d o d o c k e r −compose up

Listing 5.2.1: Start all docker containers

After having the containers running, it is possible to shell into them with the following command:

$ s u d o d o c k e r −compose e x e c < c o n t a i n e r name> b a s h

Listing 5.2.2: Enter into a container

The following command should be run from node container and will create a basic NextJS project
on which the client app will be based on:

$ npx < c l i e n t app name>

# or
$ y a r n < c l i e n t app name>

Listing 5.2.3: Initialize a basic ReactJS app

This command will create the needed folder (ex: components folder) and most important, it will
create a package.json file where are defined the scrips needed in the development phase and the dependen-
cies. These dependencies will be presented in one of the next sections. The API is developed in a separate
folder. The project can be initialized with the following command:

$ c o m p o s e r c r e a t e − p r o j e c t symfony / s k e l e t o n <p r o j e c t n a m e >

Listing 5.2.4: Initialize basic Symfony project

This command crate ca composer.json file where can be found information about the project such as
required dependencies. The dependencies will be presented in one of the next sections.

57
 5.3 Server Application Structure

The API besides the components from Symfony framework, is composed mainly of components,
services, repositories, and security components. The controller use services for business logic and services
use repositories as a data persistence layer. The Component diagram for the API shows well the components
used and their interaction.

5.3.1 Dependencies

The package manager used in Symfony projects is Composer. Composer creates a file name com-
poser.json where can be found information about the project and most important – information about de-
pendencies. The dependencies used for the back-end project are the following:

” require ”: {
” php ” : ” 7 . 1 . 3 ” ,
...
” friendsofsymfony / rest −bundle ”: ” 2 . 5 . 0 ” ,
” jms / s e r i a l i z e r − b u n d l e ” : ” ˆ 2 . 0 @dev ” ,
” l e x i k / jwt − a u t h e n t i c a t i o n − bundle ” : ” ˆ 2 . 4 ” ,
” nelmio / cors −bundle ” : ”1.5” ,
...
” symfony / f l e x ” : ” ˆ 1 . 1 ” ,
” symfony / form ” : ” 4 . 2 . * ” ,
” symfony / framework − b u n d l e ” : ” 4 . 2 . * ” ,
” symfony / h t t p − f o u n d a t i o n ” : ” 4 . 2 . * ” ,
” symfony / p h p u n i t − b r i d g e ” : ” 4 . 2 . * ” ,
” symfony / r o u t i n g ” : ” 4 . 2 . * ” ,
” symfony / s e c u r i t y ” : ” 4 . 2 . * ” ,
” symfony / s e c u r i t y − b u n d l e ” : ” 4 . 2 . * ” ,
” symfony / s e c u r i t y − c o r e ” : ” 4 . 2 . * ” ,
” symfony / s e c u r i t y − h t t p ” : ” 4 . 2 . * ” ,
...
” symfony / s w i f t m a i l e r − b u n d l e ” : ” ˆ 3 . 1 ” ,
” symfony / t e m p l a t i n g ” : ” 4 . 2 . * ” ,
” symfony / t w i g − b u n d l e ” : ” 4 . 2 . * ” ,
” symfony / yaml ” : ” 4 . 2 . * ” ,

58
 ” d o c t r i n e / d o c t r i n e − m i g r a t i o n s − bundle ” : ”2”
}
...

Listing 5.3.1: API dependencies

5.3.2 The API

The requests from the client are first received by the framework’s core components and then they
are being sent to the controllers. For example, one of the controllers is PuzzleControler which has to role
to catch requests related to the puzzle and then call the PuzzleService that has the role to do puzzle related
business logic. A code snippet example is shown below:

/* *

* @Route ( ” / a p i / p u z z l e s / c r e a t e ” , name=” p u z z l e s . c r e a t e ” , m e t h o d s ={”

POST ” } )

* @param R e q u e s t $ r e q u e s t
* @param P u z z l e S e r v i c e $ p u z z l e S e r v i c e
* @return R e s p o n s e
*/
public f u n c t i o n c r e a t e ( Request $request , PuzzleService
$ p u z z l e S e r v i c e ) : Response
{
$ d a t a = j s o n d e c o d e ( $ r e q u e s t −> g e t C o n t e n t ( ) , t r u e ) ;
$ s u c c e s s = $ p u z z l e S e r v i c e −> c r e a t e P u z z l e A n d S a v e ( $ d a t a , $ t h i s −>
getUser ( ) ) ;

i f (! $success ){
r e t u r n new R e s p o n s e (
’ P u z z l e wasn \ ’ t s a v e d ’ ,
R e s p o n s e : : HTTP INTERNAL SERVER ERROR ,
[ ’ c o n t e n t − t y p e ’ => ’ t e x t / h t m l ’ ]
);
}

r e t u r n new R e s p o n s e (

59
 ’ Puzzle s u c c e s s f u l l y saved . ’ ,
R e s p o n s e : : HTTP CREATED ,
[ ’ c o n t e n t − t y p e ’ => ’ t e x t / h t m l ’ ]
);
}

Listing 5.3.2: Create puzzle endpoint

5.3.3 JWT Security

There are different ways to assure security in an API. In the past, the most used approach was to use
session identification which means that the API kept information about the client in identified it with the
session identification. This approach is not good when it is needed to build an API, because this one should
not know anything about the client. More than that, it would be a problem for scaling. Another approach
is to us JWT (JSON Web Token). This approach relies on the fact that session data is hashed in a string of
characters name a token and this token is kept by the client not the server. The client with each request sent
to the server will also send the token and in this way, the server will know who the client is, but the idea is
that the information about the client isn’t stored on the server.
In a Symfony-based project, JWT can be implemented with a class that is responsible for checking
the token for each request that comes in. The class in this project is named JwtAuthenticator.php. This class
extracts the user credentials from the token that is located in the cookies

/* *

* @param R e q u e s t $ r e q u e s t
* @return f a l s e | m i x e d | s t r i n g | v o i d
* @throws J W T D e c o d e F a i l u r e E x c e p t i o n
*/
public f u n c t i o n g e t C r e d e n t i a l s ( Request $request )
{
i f ( ! $ r e q u e s t −>c o o k i e s −>h a s ( ’BEARER ’ ) ) {
return false ;
}

$ e x t r a c t o r = new C o o k i e T o k e n E x t r a c t o r ( ’BEARER ’ ) ;
$ t o k e n = $ e x t r a c t o r −> e x t r a c t ( $ r e q u e s t ) ;

60
 i f ( ! $token ) {
return false ;
}

r e t u r n $token ;
}

Listing 5.3.3: Verify token

In case the API needs to know who is the user, there is a method in JwtAuthenticator.php that extracts
the user information from the token

/* *

* @param m i x e d $ c r e d e n t i a l s
* @param U s e r P r o v i d e r I n t e r f a c e $ u s e r P r o v i d e r
* @return o b j e c t | U s e r I n t e r f a c e | n u l l
* @throws J W T D e c o d e F a i l u r e E x c e p t i o n
*/
public function getUser ( $credentials , UserProviderInterface
$userProvider )
{
$ d a t a = $ t h i s −>j w t E n c o d e r −>d e c o d e ( $ c r e d e n t i a l s ) ;

i f ( $ d a t a === f a l s e ) {
t h r o w new C u s t o m U s e r M e s s a g e A u t h e n t i c a t i o n E x c e p t i o n ( ’ I n v a l i d
Token ’ ) ;
}

$username = $ d a t a [ ’ username ’ ] ;
$ u s e r = $ t h i s −>em−> g e t R e p o s i t o r y ( U s e r : : c l a s s )
−>findOneBy ( [ ’ u s e r n a m e ’ => $ u s e r n a m e ] ) ;

i f (! $user ) {
t h r o w new A u t h e n t i c a t i o n C r e d e n t i a l s N o t F o u n d E x c e p t i o n ( ) ;
}

61
 return $user ;
}

Listing 5.3.4: Identify user

5.4 Database Interaction

The API uses DoctrineORM to map entities from the relational database to entity classes. For this,
the Symfony framework should be configured to know where the database is located and what schema to
use. This configuration is located in .env file along with other configurations

DATABASE URL= mysql : / / c i c a d a a d m i n : password@mysql : 3 3 0 6 / c i c a d a d b

Listing 5.4.1: Database URL

If it is needed to generate the tables in the database schema based on the entities defied in the
Symfony project, there is a useful command to do this and this command should be run from inside the root
of the Symfony project

$ php b i n / c o n s o l e d o c t r i n e : schema : u p d a t e −− f o r c e

Listing 5.4.2: Generate schema

5.4.1 Data Persistence

As it was mentioned, business entities in the relational database are represented with tables and in
the Symfony project, they are classes. These classes should be annotated with @ORM in order to be treated
as entities by the framework. Entity classes show the relations between business entities, for example the
Account entity has a $teamsMemberOf variable that is the ManyToMany relation with Team entity

/* *

* @var C o l l e c t i o n
*
* @ORM\ManyToMany ( t a r g e t E n t i t y =”Team ” , mappedBy=”members ” )
*/
p r i v a t e $teamsMemberOf ;

Listing 5.4.3: Mapping team members to the team

This variable will hold the teams of which the user that has this account is a member. More complete entity
classes are presented in annex D.

62
 Implementation Conclusions

In this chapter, it has been described how the platform was implemented. This chapter shows the
architectural pattern used, that is client-server where the client is a single page application build with Reac-
tJS wrapped by NextJS and the server is an API. The API is not a full REST, but takes some characteristics
from it, for example one of the most important REST characteristic for this platform is that the API should
be stateless. Also, this chapter is shown how the API is configured to communicate with the relational
database. Talking about technologies, each technology is argued why it has been chosen. The project relies
a lot on the Docker containers. Any component of this platform runs on a Docker container. The containers
bring many advantages when it comes to maintaining a stable and agnostic environment for the platform.
In the Server Application Structure section 5.3 are shown the dependencies used to implement the
API. Each of those dependencies has a well-defied purpose, for example swiftmailer is used to send emails,
the jwt-authenticator-bundle is used to create JWT tokens and use them for authentication. JWT authenti-
cation is a good choince when it is needed to have a stateless API.
The chapter shows some important potions of code (or as examples purpose) cut from the actual
implemented project and describes them. Also, the chapter refers to the appendices of this pater where can
be found some more complete parts of code from the project that was implemented. There are also some
code snippets in the chapter that tells how to set up the project on a local machine. The VCS used is Git
and as a hosting server for the project, GitHub was used.

63
CONCLUSIONS

This license project describes a system that offers to the client the possibility to train their problems
solving skills. The idea is that by solving more problems, anyone gets better at it. The platform also offers
the possibility to compose our own problems for other to solving and this process also helps to develop
our skills. A problem is a set of questions that are free in the way how they are created and this gives the
opportunity to create unique problems that test the players in different ways.
This platform is different when comparing to its competitors in the way that it offers a new idea – a
new type of problem. Besides that, this system brings a set of useful functionalities like solving in teams,
creating contests, and on the most important ones – the ability to create your own problems. The goal is to
offer to the client a new type of problem to solve that a based on a new idea. The project is inspired by an
event named Cicada 3301. [5]
The platform is useful for anyone who wants to play by solving problems, by anyone who likes to
put to the test their agility of mind. The system targets mostly teenagers and since it is flexible in the way
how problems are created because they are free-text, the system can be used in schools and universities for
testing purposes or even to create contests for the students.
At the moment the platform is implemented with all the features listed in the Requirements Spec-
ification chapter 2. Now, it is possible to create problems (puzzles), to solve them, to create contests and
teams, and other useful functionalities. All the technologies used to implement it are free and gives the
system all it needs, even more. To have a project that can be easily developed further and expanded, were
used most recent versions for the technologies in development. The system was developed with clean code
principles in mind.
As a further perspective, the system can be internationalized which means to support more languages
for the interface. At the moment it offers an interface only in English. An internationalized interface where
the user can select the languages of his preference would be more user-friendly and would bring more
clients. Also, the platform can be distributed by DNS (Domain Name System) per country or region in
order to bring together users that are closer to each other according to their location.

64
Bibliography

1. A successful Git branching model.

Available: https://nvie.com/posts/a-successful-git-branching-model/.

2. About LeetCode and the Recruiting Process in Silicon Valley.

Available: https : / / medium . com / @teamblind / about - leetcode - and - the - recruiting -
process-in-silicon-valley-d91eab67106.

3. Gantt Chart.
Available: https://en.wikipedia.org/wiki/Gantt_chart.

4. How Many Software Developers Are There In The World?

5. David Kushner. Cicada: Solving the Web’s Deepest Mystery.

Available: https://www.rollingstone.com/culture/culture-news/cicada-solving-the-
webs-deepest-mystery-84394. January 15, 2015.

6. Laradock – a full PHP development environment for Docker.

Available: https://laradock.io/.

7. Learn to think – brilliant.org.

Available: https://en.wikipedia.org/wiki/Brilliant_(website).

8. Dag Øivind Madsen. “SWOT Analysis: A Management Fashion Perspective”. In: International Journal
of Business Research 16.1 (2016), pp. 39–56.

9. MECE.
Available: https://en.wikipedia.org/wiki/MECE_principle.

10. Metrics/KPIs.
Available: https://www.workfront.com/project-management/metrics.

11. MoSCoW.
Available: https://en.wikipedia.org/wiki/MoSCoW_method.

12. MySQL Workbench.

Available: https://www.mysql.com/products/workbench.

13. Representational state transfer.

Available: https://en.wikipedia.org/wiki/Representational_state_transfer.

65
14. Tiago Silva. 23 Platforms to Monetize Your Skills by Solving Problems.
Available: https : / / medium . com / the - innovation / 23 - platforms - to - monetize - your -
skills-by-solving-problems-d9be203cca5f. 2020.

15. SMART.
Available: https://www.klipfolio.com/resources/articles/what-is-a-key-performance-
indicator.

16. SSL (Secure Sockets Layer).

Available: https://en.wikipedia.org/wiki/Transport_Layer_Security.

17. The only programming contests Web 2.0 platform – codeforces.com.

Available: https://codeforces.com/blog/entry/1336#q1.

18. Top 5 methodologies.

Available: https://www.xpand-it.com/2018/10/11/top-5-agile-methodologies.

19. Top 6 basic SDLC philosophies.

Available: https : / / www . roberthalf . com / blog / salaries - and - skills / 6 - basic - sdlc -
methodologies-which-one-is-best.

20. Visual Paradigm Tutorials.

Available: https://www.visual-paradigm.com/tutorials/.

21. What Is a Customer Avatar?

Available: https://viralsolutions.net/customer-avatar/#.YHWEDHVfjMU.

66
 Appendix A

Complete diagrams

Figure A.1 - Entities class diagram

67
Figure A.2 - Database schema

68
 Appendix B

Docker configuration

###########################################################
###################### G e n e r a l S e t u p ######################
###########################################################

### P a t h s #################################################

# P o i n t t o t h e p a t h o f y o u r a p p l i c a t i o n s c o d e on y o u r h o s t
SYMFONY CODE PATH HOST = . . / symfony
FULLAPP CODE PATH HOST = . . /

# Choose s t o r a g e p a t h on y o u r m a c h i n e . F o r a l l s t o r a g e s y s t e m s
DATA PATH HOST = ˜ / d a t a

### Docker compose f i l e s ##################################

# D e f i n e t h e p r e f i x o f c o n t a i n e r names . T h i s i s u s e f u l i f you h a v e
m u l t i p l e p r o j e c t s t h a t use docker t o have s e p e r a t e c o n t a i n e r s per
project .
COMPOSE PROJECT NAME= c i c a d a

### PHP V e r s i o n ###########################################

# S e l e c t a PHP v e r s i o n o f t h e Workspace and PHP−FPM c o n t a i n e r s ( Does

n o t a p p l y t o HHVM) . A c c e p t e d v a l u e s : 7 . 3 − 7 . 2 − 7 . 1 − 7 . 0 − 5 . 6
PHP VERSION = 7 . 2

### PHP I n t e r p r e t e r #######################################

# S e l e c t t h e PHP I n t e r p r e t e r . A c c e p t e d v a l u e s : hhvm − php −fpm

PHP INTERPRETER=php −fpm

69
###########################################################
################ C o n t a i n e r s C u s t o m i z a t i o n #################
###########################################################

### WORKSPACE #############################################

WORKSPACE COMPOSER GLOBAL INSTALL= t r u e

WORKSPACE INSTALL NODE= t r u e
WORKSPACE INSTALL YARN= t r u e
WORKSPACE TIMEZONE=UTC
WORKSPACE SSH PORT=2222

### PHP FPM ###############################################

PHP FPM BASE IMAGE TAG PREFIX= l a t e s t

PHP FPM INSTALL MYSQLI= t r u e
PHP FPM INSTALL INTL= t r u e
PHP FPM ADDITIONAL LOCALES=” e s E S . UTF−8 f r F R . UTF−8”

### NGINX #################################################

NGINX HOST HTTP PORT=80

NGINX HOST HTTPS PORT=443
NGINX HOST LOG PATH = . / l o g s / n g i n x /
NGINX SITES PATH = . / n g i n x / s i t e s /
NGINX PHP UPSTREAM CONTAINER=php −fpm
NGINX PHP UPSTREAM PORT=9000
NGINX SSL PATH = . / n g i n x / s s l /

### MYSQL #################################################

MYSQL VERSION= 5 . 7
MYSQL DATABASE= c i c a d a d b

70
MYSQL USER= c i c a d a a d m i n
MYSQL PASSWORD= p a s s w o r d
MYSQL PORT=3306
MYSQL ROOT PASSWORD= p a s s w o r d
MYSQL ENTRYPOINT INITDB = . / mysql / d o c k e r − e n t r y p o i n t − i n i t d b . d

Listing B.0.1: Environment variables

B.1 Dockerfiles

B.1.1 MySQL

FROM mysql : ${MYSQL VERSION}

ARG TZ=UTC
ENV TZ ${TZ}
RUN l n − s n f / u s r / s h a r e / z o n e i n f o / $TZ / e t c / l o c a l t i m e && e c h o $TZ > / e t c /
t i m e z o n e && chown −R mysql : r o o t / v a r / l i b / mysql /

COPY my . c n f / e t c / mysql / c o n f . d / my . c n f

RUN chmod 0444 / e t c / mysql / c o n f . d / my . c n f

CMD [ ” mysqld ” ]

EXPOSE 3306

Listing B.1.1: Dockerfile for MySQL

B.1.2 Nginx

FROM n g i n x : a l p i n e

COPY n g i n x . c o n f / e t c / n g i n x /

ARG PHP UPSTREAM CONTAINER=php −fpm

ARG PHP UPSTREAM PORT=9000

71
# S e t u p s t r e a m c o n f and remove t h e d e f a u l t c o n f
RUN e c h o ” u p s t r e a m php − u p s t r e a m { s e r v e r ${PHP UPSTREAM CONTAINER } : ${
PHP UPSTREAM PORT } ; }” > / e t c / n g i n x / c o n f . d / u p s t r e a m . c o n f \
&& rm / e t c / n g i n x / c o n f . d / d e f a u l t . c o n f

ADD . / s t a r t u p . s h / o p t / s t a r t u p . s h
RUN s e d − i ’ s / \ r / / g ’ / o p t / s t a r t u p . s h
CMD [ ” / b i n / b a s h ” , ” / o p t / s t a r t u p . s h ” ]

EXPOSE 80 443 9000

Listing B.1.2: Dockerfile for Nginx

B.1.3 NodeJS

FROM node : 8

WORKDIR / v a r /www

RUN npm i n s t a l l

EXPOSE 3000

Listing B.1.3: Dockerfile for nodejs

72
 Appendix C

Nginx API Configuration

server {
l i s t e n 9000;

r o o t / v a r /www/ p u b l i c ;
i n d e x i n d e x . php i n d e x . h t m l i n d e x . htm ;

location / {
t r y f i l e s $ u r i @rewriteapp ;
}

# F o r Symfony 4 c o n f i g
l o c a t i o n @rewriteapp {
r e w r i t e ˆ ( . * ) $ / i n d e x . php / $1 l a s t ;
}

l o c a t i o n ˜ ˆ / ( app | a p p d e v | c o n f i g | i n d e x ) \ . php ( / | $ ) {
f a s t c g i p a s s php − u p s t r e a m ;
fastcgi split path info ˆ ( . + \ . php ) ( / . * ) $ ;
include fastcgi params ;
f a s t c g i p a r a m SCRIPT FILENAME
$document root$fastcgi script name ;
}

e r r o r l o g / var / log / nginx / symfony error . log ;

a c c e s s l o g / var / log / nginx / symfony access . log symfony log ;
}

Listing C.0.1: Nginx API configuration

73
 Appendix D

Example of entity class

The class presented here shows only the class members, but it also has setters and getters in the project.

/**

* Puzzle
* @ORM\ E n t i t y
* @ORM\ T a b l e ( name =” p u z z l e s ” )
*/
c l a s s Puzzle
{
public function construct ()
{
$ t h i s −> t a g s = new A r r a y C o l l e c t i o n ( ) ;
}

/**

* @ORM\ I d
* @ORM\ G e n e r a t e d V a l u e ( s t r a t e g y =”AUTO” )
* @ORM\ Column ( t y p e =” i n t e g e r ” )
*/
p r i v a t e $id ;

/**

* @var s t r i n g
*
* @ORM\ Column ( u n i q u e = t r u e , n u l l a b l e = f a l s e )
*/
p r i v a t e $name ;

/**

* @var C o l l e c t i o n
*

74
 * @ORM\OneToMany ( t a r g e t E n t i t y =” C o n t e s t ” , mappedBy =” p u z z l e ” )
*/
private $contestsPartOf ;

/**

* @var C o l l e c t i o n
*
* @ORM\OneToMany ( t a r g e t E n t i t y =” S t a g e ” , mappedBy =” p u z z l e P a r e n t ” )
*/
private $stages ;

/**

* @var C o l l e c t i o n
*
* @ORM\ManyToMany ( t a r g e t E n t i t y =” Tag ” , i n v e r s e d B y =” p u z z l e s ” )
* @ORM\ J o i n T a b l e ( name =” p u z z l e s t a g s ” )
*/
private $tags ;

/**

* @var A c c o u n t
*
* @ORM\ManyToOne ( t a r g e t E n t i t y =” A c c o u n t ” , i n v e r s e d B y =”
createdPuzzles ”)

* @ORM\ J o i n C ol u m n ( name =” a c c o u n t i d ” , r e f e r e n c e d C o l u m n N a m e =” i d ” )
*/
p r i v a t e $createdBy ;

/**

* @var DateTime
*
* @ORM\ Column ( t y p e =” d a t e t i m e ” , n u l l a b l e = f a l s e )
*/
private $createdAt ;

75
/**

* @var DateTime
*
* @ORM\ Column ( t y p e =” d a t e t i m e ” , n u l l a b l e = t r u e )
*/
p r i v a t e $updatedAt ;

/**

* @var b o o l
*
* @ORM\ Column ( t y p e =” i n t e g e r ” , n u l l a b l e = f a l s e )
*/
private $isPrivate ;

/**

* @var i n t e g e r
*
* @ORM\ Column ( n u l l a b l e = f a l s e )
*/
private $stagesCount ;

/**

* @var i n t e g e r
*
* @ORM\ Column ( t y p e =” i n t e g e r ” , n u l l a b l e = t r u e )
*/
private $difficultyByStatistics ;

/**

* @var i n t e g e r
*
* @ORM\ Column ( t y p e =” i n t e g e r ” , n u l l a b l e = t r u e )
*/

76
private $difficultyByCreator ;

/**

* @var C o l l e c t i o n
*
* @ORM\OneToMany ( t a r g e t E n t i t y =” P u z z l e S e s s i o n ” , mappedBy =” p u z z l e ” )
*/
p r i v a t e $openSessions ;

/**

* @var s t r i n g
*
* @ORM\ Column ( t y p e =” t e x t ” , n u l l a b l e = f a l s e )
*/
private $description ;

Listing D.0.1: Puzzle entity

77