Criação de plataforma para gestão de torneios online

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunicações e Informática,

2016

Daniel

Gomes

Oliveira

Cria¸

c˜

ao de Plataforma para Gest˜

ao de Torneios

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunicações e Informática,

2016

Daniel

Luis Gomes de

Oliveira

Cria¸

c˜

ao de Plataforma para Gest˜

ao de Torneios

Online

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orientação cient´ıfica do Doutor Joaquim Manuel Henriques de Sousa Pinto, Professor do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro.

(4)

(5)

Dedico todo o trabalho realizado ao longo do curso à minha mãe, que estará sempre no meu pensamento. Ao meu pai, pela paciência e pelo apoio incondicional. Ao meu irmão, por estar sempre presente quando foi preciso. A todos as amizades que fiz durante o curso que influenciaram o meu trajeto e o melhoraram. À Tatiana pela motivação dada nos momentos em que foi mais preciso e pela paciência nos momentos menos bons.

(6)

(7)

o j´uri / the jury

presidente / president Professor Doutor Joaquim Arnaldo Carvalho Martins

Professor Catedr´atico da Universidade de Aveiro

vogais / examiners committee Professor Doutor Andr´e Frederico Guilhoto Monteiro

Professor Auxiliar Convidado Instituto Superior Miguel Torga

Professor Doutor Joaquim Manuel Henriques de Sousa Pinto

Prof. Auxiliar do Dep. Eletrónica, Telecomunicações e Informática da Universidade de Aveiro

(8)

(9)

agradecimentos Agradeço toda a ajuda disponibilizada pelo meu orientador, Professor Dou-tor Joaquim Manuel Henriques de Sousa Pinto que se mostrou dispon´ıvel sempre que precisei. Queria também agradecer ao Francisco Oliveira e ao André, da empresa Digitalmente, que também foram uma importante ajuda no desenvolvimento deste trabalho.

(10)

(11)

Resumo Todos os anos existem centenas de torneios organizados por clubes, princi-palmente nos escalões de formação. Para cada torneio é necessário realizar um conjunto de ações no que toca à organização desde a parte inicial em que é necessário contactar as equipas, até à entrega dos prémios aos ven-cedores, passando por toda a estruturação necessária. Inicialmente foram testados vários sistemas já existentes, no entanto nenhum era especifico o suficiente para o pretendido, sendo grande parte destinado a utilizadores in-dependentes e não tanto a clubes. O objetivo desta dissertação é a criação de um sistema que agilize todo este processo e que permita a reutilização de informação relativa a equipas e jogadores entre diferentes torneios. Adicio-nalmente, existirá uma área pública que irá permitir o seguimento online do torneio pelos potenciais interessados.

(12)

(13)

Abstract Every year there are hundreds of tournaments organized by clubs, mainly at the training levels. For each tournament it is necessary to carry out a set of actions regarding the organization from the initial part in which it is necessary to contact the teams, until the delivery of the prizes to the winners, going through all the necessary structuring. In a first stage, several existing systems were tested, however none were specific enough for the intended, being almost all intended for independent users and not so much for clubs. The purpose of this thesis is to create a system that will streamline this process and allow the reuse of information regarding teams and players between different tournaments. In addition, there will also be a public area that will allow online tournament tracking by potential contenders.

(14)

(15)

Conte´

udo

Conte´udo i

Lista de Figuras iii

Lista de Listagens vii

Lista de Tabelas ix Acrónimos xi 1 Introdução 1 1.1 Motiva¸cão . . . 1 1.2 Objetivos . . . 1 1.3 Estrutura . . . 2 2 Estado de Arte 3 2.1 Sistemas existentes relacionados . . . 3

2.1.1 Tipos de estruturas organizacionais . . . 3

2.1.2 Tournament Software . . . 5 2.1.3 Konkuri . . . 7 2.1.4 Enjore . . . 8 2.1.5 Leverade . . . 12 2.1.6 Challonge! . . . 17 2.1.7 Tournament Scheduler . . . 19 2.2 Compara¸c˜ao . . . 21 2.3 Standards de desenvolvimento . . . 24 2.3.1 MVC . . . 24 2.3.2 MVP . . . 25 2.3.3 MVVM . . . 25 2.4 Tecnologias utilizadas . . . 27 2.4.1 PHP . . . 27 2.4.2 Bootstrap . . . 27 2.4.3 MySQL . . . 27 2.4.4 Laravel Framework . . . 27

Intera¸c˜ao com a Base de Dados . . . 27

(16)

3 Requisitos e Arquitetura do Sistema 37

3.1 Organiza¸c˜ao do sistema . . . 37

3.2 Casos de uso . . . 40

3.3 Estrutura da Base de Dados . . . 46

3.3.1 Primeira fase . . . 46 3.3.2 Segunda fase . . . 47 3.3.3 Terceira fase . . . 49 3.3.4 Quarta fase . . . 51 3.3.5 Fase final . . . 52 3.4 Arquitectura . . . 54 3.4.1 Estrutura . . . 54 3.4.2 Models . . . 56 3.4.3 Views . . . 58 3.4.4 Controllers . . . 63 3.4.5 Mapa da aplica¸c˜ao . . . 64

3.4.6 Sorteio das equipas pelos grupos . . . 70

3.4.7 Distribui¸c˜ao dos jogos . . . 76

4 Resultados 81 4.1 Resultados . . . 81

4.1.1 Opera¸c˜oes comuns . . . 81

4.1.2 Organizador do torneio . . . 89

4.1.3 Diretor de um clube . . . 94

4.1.4 Coordenador de uma equipa . . . 96

4.1.5 Extras . . . 96

Calend´ario de jogos edit´avel . . . 96

Caixa de pesquisa . . . 97

Edi¸c˜ao do regulamento e do convite . . . 97

Upload de ficheiros extra . . . 98

Barra informativa . . . 99

Pr´emios personalizados . . . 100

Ordena¸c˜ao personalizada de grupos . . . 100

Identifica¸c˜ao dos campos com recurso ao Google Maps . . . 101

5 Conclus˜ao 103 5.1 Conclus˜ao . . . 103

5.2 Trabalho Futuro . . . 104

(17)

Lista de Figuras

2.1 Exemplo de estrutura baseada em eliminat´orias simples para 8 equipas . . . . 4

2.2 Exemplo de estrutura baseada em eliminat´orias duplas para 4 equipas . . . . 4

2.3 Exemplo de estrutura baseada em grupos seguido de eliminat´orias para 16 equipas . . . 5

2.4 P´agina inicial Tournaments Software . . . 6

2.5 Apresenta¸c˜ao dos torneios existentes . . . 7

2.6 P´agina inicial Konkuri . . . 7

2.7 P´agina de apresenta¸c˜ao de torneio Konkuri . . . 8

2.8 P´agina inicial Enjore sem log in efetuado . . . 9

2.9 P´agina inicial Enjore com log in efetuado . . . 9

2.10 P´agina de adi¸c˜ao de equipas Enjore . . . 10

2.11 P´agina de escalonamento do torneio onde ´e poss´ıvel sortear as equipas pelos jogos Enjore . . . 11

2.12 P´agina de detalhes de jogo Enjore . . . 11

2.13 P´agina inicial Leverade . . . 12

2.14 P´agina de utilizador p´ublica Leverade . . . 13

2.15 P´agina de administrador Leverade . . . 13

2.16 Formul´ario de adi¸c˜ao de torneio Leverade . . . 14

2.17 P´agina de apresenta¸c˜ao de torneio Leverade . . . 14

2.18 ´Area de submiss˜ao de ficheiros Leverade . . . 15

2.19 ´Area de registo de equipas Leverade . . . 15

2.20 ´Area de convite Leverade . . . 16

2.21 ´Area de escalonamento dos jogos Leverade . . . 17

2.22 P´agina inicial Challonge! . . . 18

2.23 P´agina de cria¸c˜ao de um torneio Challonge! . . . 18

2.24 P´agina de apresenta¸c˜ao de um torneio Challonge! . . . 19

2.25 P´agina inicial Tournament Scheduler! . . . 19

2.26 P´agina de apresenta¸c˜ao de um torneio Tournament Scheduler! . . . 20

2.27 Diagrama MVC . . . 24

2.28 Diagrama MVP . . . 25

2.29 Diagrama MVVM . . . 26

2.30 Resultado de Club::where(’created by’, Auth::user()->id) . . . 29

2.31 Resultado de Club::where(’created by’, Auth::user()->id)->get() . . . . 29

2.32 Exemplo da organiza¸c˜ao de uma aplica¸c˜ao . . . 34

(18)

3.2 Diagrama dos casos de uso . . . 42

3.3 Estrutura inicial . . . 46

3.4 Estrutura segunda fase . . . 48

3.5 Estrutura terceira fase . . . 50

3.6 Estrutura quarta fase . . . 51

3.7 Estrutura final . . . 52 3.8 Estrutura simplificada . . . 55 3.9 Estrutura simplificada . . . 55 3.10 Modelos . . . 56 3.11 Views . . . 58 3.12 Diagrama simplificado . . . 61 3.13 Controladores . . . 63 3.14 Diagrama demonstrativo . . . 69

3.15 Escolha do tipo de estrutura . . . 70

3.16 Exemplo de estrutura¸c˜ao por elimina¸c˜ao para 8 equipas . . . 71

3.20 Escolha do n´umero de grupos . . . 73

3.21 Escolha da estrutura para a pr´oxima fase . . . 74

3.22 Escolha das equipas qualificadas . . . 74

3.23 Estrutura de fase de grupos seguida de fases de elimina¸c˜ao . . . 75

3.24 Esrutura de fase de grupos seguida de jogos para apurar a qualifica¸cão final . 76 3.25 Modo como é percorrido o grupo para a cria¸cão dos jogos . . . 77

3.26 Modo como s˜ao percorridos os grupos para a cria¸c˜ao dos jogos . . . 77

3.27 Exemplo de atribui¸cão de códigos para fase de grupos seguida de elimina¸cão . 78 3.28 Exemplo de atribui¸cão de códigos para estruturas baseadas em elimina¸cão . . 79

4.1 P´agina principal . . . 82

4.2 P´agina de descri¸c˜ao de Torneio . . . 83

4.3 Separador categorias . . . 83

4.4 Separador com os grupos . . . 84

4.5 Separador com os jogos . . . 84

4.6 Separador com os pr´emios . . . 85

4.7 Separador com a localiza¸c˜ao do torneio . . . 85

4.8 P´agina de descri¸c˜ao de Clube . . . 86

4.9 P´agina de descri¸c˜ao de Equipa . . . 86

4.10 P´agina de descri¸c˜ao de Jogador . . . 87

4.11 P´agina de descri¸c˜ao de Utilizador . . . 87

4.12 P´agina de Log In . . . 87

4.13 P´agina de Registo . . . 88

4.14 P´agina de Perfil . . . 88

4.15 P´agina de Administra¸c˜ao . . . 89

4.16 P´agina de Cria¸c˜ao de um torneio . . . 89

4.17 P´agina de Adi¸c˜ao de Categoria . . . 90

4.18 P´agina de Gest˜ao de Convites . . . 90

(19)

4.20 P´agina de grupos . . . 91

4.21 P´agina de jogos . . . 92

4.22 P´agina de calend´ario de jogos . . . 92

4.23 Altera¸c˜ao de campo ou submiss˜ao de resultado . . . 93

4.24 P´agina de edi¸c˜ao dos convites . . . 93

4.25 P´agina de edi¸c˜ao do regulamento . . . 94

4.26 P´agina de cria¸c˜ao de um Clube . . . 95

4.27 P´agina de edi¸c˜ao de campos f´ısicos do clube . . . 95

4.28 P´agina de cria¸c˜ao de uma equipa . . . 96

4.29 P´agina de cria¸c˜ao de um jogador . . . 96

4.30 Distribui¸c˜ao dos jogos no calend´ario . . . 97

4.31 Exemplo de pesquisa . . . 97

4.32 Regulamento edit´avel . . . 98

4.33 Upload de ficheiros . . . 99

4.34 Convites recebidos apresentados na barra informativa . . . 99

4.35 Estado dos torneios . . . 99

4.36 Alertas recebidos . . . 100

4.37 Upload de ficheiros . . . 100

4.38 Factores de desempate para ordena¸c˜ao dos grupos . . . 101

(20)

(21)

Lista de Listagens

1 Exemplo de Query 1 . . . 28

2 Exemplo de Query 2 . . . 28

3 Exemplo do m´etodo de uma rela¸c˜ao 1-1 . . . 29

4 Exemplo do uso de uma rela¸c˜ao 1-1 . . . 29

5 Exemplo do m´etodo de uma rela¸c˜ao 1-1(Inverso) . . . 30

6 Exemplo do uso de uma rela¸c˜ao 1-1(Inverso) . . . 30

7 Exemplo do m´etodo de uma rela¸c˜ao 1-Muitos . . . 30

8 Exemplo do uso de uma rela¸c˜ao 1-Muitos . . . 30

9 Exemplo do m´etodo de uma rela¸c˜ao 1-Muitos (Inverso) . . . 30

10 Exemplo do uso de uma rela¸c˜ao 1-Muitos (Inverso) . . . 31

11 Exemplo de m´etodo de uma rela¸c˜ao Muitos-Muitos . . . 31

12 Exemplo de m´etodo de uma rela¸c˜ao Muitos-Muitos . . . 31

13 Exemplo do uso do m´etodo definido . . . 31

14 Exemplo do uso do m´etodo definido . . . 32

15 Exemplo de uma Migration . . . 32

16 View base para a parte p´ublica . . . 59

17 View base para a parte administrativa . . . 60

18 home.blade.php/welcome.blade.php . . . 60

19 dashboard.blade.php . . . 61

(22)

(23)

Lista de Tabelas

2.1 Tabela comparativa 1 . . . 21 2.2 Tabela comparativa 2 . . . 22 2.3 Tabela comparativa 3 . . . 22 2.4 Tabela comparativa 4 . . . 23 2.5 Tabela comparativa 5 . . . 23 2.6 Alguns m´etodos disponiveis para a manipula¸c˜ao de Collections . . . 28 2.7 Tabela de comandos . . . 33 3.1 Rotas resource resultantes . . . 64

3.2 Rotas definidas para o controlador HomeController . . . 65

3.3 Rotas definidas para o controlador UserController . . . 65

3.4 Rotas definidas para o controlador MainTournamentController . . . 65

3.5 Rotas definidas para o controlador TournController . . . 66

3.6 Rotas definidas para o controlador ClubController . . . 66

3.7 Rotas definidas para o controlador TeamController . . . 66

3.8 Rotas definidas pelo controlador PlayerController . . . 66

3.9 Rotas definidas para o controlador AwardController . . . 67

3.10 Rotas definidas para o controlador InviteController . . . 67

3.11 Rotas definidas para o controlador FieldController . . . 67

3.12 Rotas definidas para o controlador FixtureController . . . 68

(24)

(25)

Acr´

onimos

CRUD Create, Read, Update and Delete

JSON JavaScript Object Notation

PHP PHP: Hypertext Preprocessor

HTML HyperText Markup Language

MVC Model-View-Controller

MVVM Model-View-ModelView

MVP Model-View-Presenter

(26)

(27)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Motiva¸

c˜

ao

A prática desportiva, seja qual for a idade do praticante, tem uma contribui¸cão signifi-cativa na sua saúde e bem-estar. Mais especificamente os desportos coletivos, são bastante importantes durante a fase de adolescência, funcionando muitas vezes como uma ”fuga”para os problemas que surgem nestas idades. Outros fatores bastante importantes que os desportos coletivos podem oferecer, neste caso o futebol de forma¸cão, é o sentido de responsabilidade, de disciplina e conv´ıvio, bastante importantes na forma¸cão e educa¸cão de uma pessoa. No futebol de forma¸cão, principalmente nos escalões iniciais, como não existem campeonatos en-tre os diferentes clubes, são organizados torneios. Adicionalmente, também é costume serem realizados torneios durante a pré-época, onde as equipas de escalões que participem em cam-peonatos, se preparam para a competi¸cão. Existem, portanto, centenas de torneios realizados anualmente por todo pais pelos clubes com equipas de forma¸cão, porém, para cada torneio a equipa organizadora tem de realizar um conjunto de tarefas, nomeadamente escolher as equipas, convidar as equipas, escolher a estrutura do torneio, realizar o sorteio, organizar um

calend´ario, escrever um regulamento, entre muitas outras. Todas estas tarefas podem ser

uniformizadas de forma a ajudar não só o clube organizador, como também os clubes parti-cipantes. Para além de tudo, nem sempre é fácil oferecer às pessoas que querem acompanhar os torneios acesso a horários de jogos, resultados de jogos realizados, localiza¸cão dos jogos, constitui¸cão das equipas e toda a informa¸cão referente ao torneio. Assim sendo, este sistema pretende não só oferecer uma plataforma que facilite o trabalho das equipas, mas, também, permitir que qualquer pessoa interessada tenha acesso a toda a informa¸cão do torneio.

1.2 Objetivos

Esta disserta¸cão tem como objetivo final o desenvolvimento de uma plataforma que per-mita aos clubes, inicialmente clubes de forma¸cão de futebol presentes em Portugal, uma forma de facilitar e uniformizar todo o processo de prepara¸cão e realiza¸cão de um torneio de futebol, desde o envio de convites até à atribui¸cão de prémios. É também pretendido que a aplica¸cão disponibilize a possibilidade de partilha de informa¸cão relativa aos diferentes clubes entre torneios diferentes, assim como suporte para armazenamento de ficheiros relativos aos clu-bes e utiliza¸cão de Google Maps na localiza¸cão dos clubes e dos seus campos. Pretende-se, também, que exista uma área de acesso público para que qualquer pessoa possa consultar

(28)

informa¸c˜oes sobre os torneios existentes.

1.3 Estrutura

A disserta¸cão está organizada em 5 cap´ıtulos. O primeiro cap´ıtulo contém uma introdu¸cão ao projeto, expondo a motiva¸cão e os objetivos. No segundo cap´ıtulo são comparados os sistemas já existentes, real¸cando as suas vantagens e o que os diferencia. Ainda neste cap´ıtulo são analisados os diferentes standards de desenvolvimento existentes e é feita, também, uma breve descri¸cão das tecnologias utilizadas. No cap´ıtulo três são apresentados os requisitos para o desenvolvimento da aplica¸cão, onde consta também uma descri¸cão da base de dados. No quarto cap´ıtulo é explicada toda a arquitetura que está por detrás do sistema, sendo ainda explicada a sua implementa¸cão e organiza¸cão. No cap´ıtulo quatro, são apresentados os resultados alcan¸cados. Finalmente, no ponto 5, é conclu´ıda a tese com referência, também, para o trabalho futuro.

(29)

Cap´ıtulo 2

Estado de Arte

Este cap´ıtulo tem como objetivo a apresenta¸cão e compara¸cão de trabalhos com fun¸cões semelhantes às pretendidas, destacando as diferen¸cas que potenciam a realiza¸cão deste projeto.

Posteriormente ser˜ao comparados os diferentes standards de desenvolvimento web e, por

´

ultimo, ser˜ao descritas as tecnologias utilizadas.

2.1 Sistemas existentes relacionados

Neste momento estão já dispon´ıveis um conjunto de software destinados ao suporte de atividade desportiva, em particular a cria¸cão de torneios. Nesta seçcão serão descritos os sistemas encontrados durante a fase de pesquisa e recolha de informa¸cão para a fase de desenvolvimento. De modo a facilitar a perce¸cão das diferentes estruturas de torneio referidas nos sistemas testados, foi feita previamente uma breve explica¸cão dos tipos de estrutura organizacional que um torneio pode tomar.

2.1.1 Tipos de estruturas organizacionais

Nesta seçcão serão contemplados os seguintes tipos:

• Eliminat´orias simples; • Eliminat´orias duplas;

• Grupos seguidos de eliminat´orias; • Round Robin;

O primeiro tipo de estrutura, eliminatórias simples, é bastante intuitivo, as equipas são sorteadas de modo a jogarem entre si passando à eliminatória seguinte a equipa que ganhar (Figura 2.1).

(30)

Figura 2.1: Exemplo de estrutura baseada em eliminatórias simples para 8 equipas O segundo tipo, eliminatórias duplas, consiste numa versão mais complexa das elimi-natórias simples. Neste caso, as equipas que perdem têm ainda uma hipótese de ganhar o torneio tendo de jogar na chamada Losing bracket. A figura 2.2 demonstra como seria feita a divisão para um torneio com 4 equipas.

Figura 2.2: Exemplo de estrutura baseada em eliminat´orias duplas para 4 equipas O terceiro tipo, grupos seguidos de eliminat´orias, consiste primeiramente no sorteio das

(31)

equipas pelo número de grupos definido pelo utilizador, sendo que depois de realizados os jogos da chamada fase de grupos, irão ser apuradas equipas para jogar a seguinte fase, que será de elimina¸cão. Na figura 2.3 está representado um exemplo de uma estrutura deste tipo, em que 16 equipas são distribu´ıdas por 4 grupos, qualificando-se as duas primeiras equipas de cada grupo.

Figura 2.3: Exemplo de estrutura baseada em grupos seguido de eliminatórias para 16 equipas Quanto ao quarto tipo, Round Robin consiste basicamente num grupo em que todas as equipas pertencentes a esse grupo se têm de defrontar, até que cada equipa tenha defrontado todas as outras. Este tipo pode ser conciliado com uma qualifica¸cão prévia.

2.1.2 Tournament Software

O primeiro website encontrado foi o Tournament Software [1] cuja p´agina inicial ´e apre-sentada na figura 2.4.

(32)

Figura 2.4: P´agina inicial Tournaments Software

os torneios e campeonatos existentes. Após a cria¸cão de uma conta, é permitida a inscri¸cão em torneios classificados como abertos, no entanto, não é poss´ıvel a cria¸cão de torneios mesmo com conta criada. A página que apresenta os torneios existentes e permite a sua pesquisa está representada na figura 2.5, onde são mostrados os torneios referentes à modalidade futebol. Em adi¸cão à disponibiliza¸cão dos torneios existentes, há por todo o website referência ao software que permite a cria¸cão e organiza¸cão de torneios e ligas, tendo, no entanto, um custo para quem pretender utilizar.

O website permite, contudo, fazer a descarga de um demo do que seria a versão final do software, com algumas fun¸cões bloqueadas. Após a utiliza¸cão do demo do software e da leitura do manual disponibilizado [2] foi poss´ıvel perceber as funcionalidades oferecidas, assim como o funcionamento do software.

O software revelou-se bastante completo, contendo cinco tipos de estrutura¸cão(Elimina¸cão simples e dupla, Round Robin, Elimina¸cão com qualifica¸cão prévia e Round Robin com qua-lifica¸cão prévia), suporte para sorteio de grupos e jogos sendo que é necessário definir, pos-teriormente, a localiza¸cão e data destes, permitindo ainda ao utilizador fazer um controlo de custos do torneio. Depois de criado o torneio é poss´ıvel publicá-lo online na página do software onde pode ser consultado pelos interessados. Todas as fun¸cões referidas requerem um pagamento prévio.

O sistema apresentado não permite, no entanto, o armazenamento de clubes, equipas ou jogadores para partilha entre os vários torneios utilizados na plataforma. Também em falta, está o suporte para armazenamento de ficheiros relacionados com o torneio e a possibilidade de adicionar prémios para além dos atribu´ıdos às equipas vencedoras.

Concluindo, apesar do sistema ser bastante completo, tem um custo elevado e requer a descarga de uma aplica¸cão e instala¸cão no computador pessoal do utilizador. Foi, porém, bastante útil para perceber que informa¸cões são necessárias para a organiza¸cão de um torneio.

(33)

Figura 2.5: Apresenta¸c˜ao dos torneios existentes

2.1.3 Konkuri

Outro sistema que tem como fun¸cão base a cria¸cão de um torneio é o Konkuri [3]. A página inicial permite a cria¸cão de um torneio sem que seja necessário fazer log in (Figura 2.6).

Figura 2.6: P´agina inicial Konkuri

(34)

a necessidade de descarregar qualquer tipo de programa. Embora seja gratuito, obriga à utiliza¸cão de créditos para algumas fun¸cões poderem ser utilizadas. Estes créditos devem ser previamente comprados pelo utilizador.

Quanto à utiliza¸cão, é bastante intuitiva e o utilizador não é obrigado a criar uma conta para proceder à cria¸cão de um torneio, sendo, no entanto, necessário registar-se caso pretenda guardar o torneio. A figura 2.7 apresenta a página que é mostrada após a cria¸cão de um torneio, que é por omissão criado para oito equipas.

Figura 2.7: P´agina de apresenta¸c˜ao de torneio Konkuri

São oferecidas três possibilidades de estrutura(Elimina¸cão simples, um grupo com todas as equipas ou grupos seguidos de elimina¸cão) e a possibilidade de adicionar até oito compe-tidores gratuitamente. Caso o utilizador pretenda adicionar mais do que oito compecompe-tidores ou pretenda adicionar equipas com vários jogadores, terá de usar créditos sendo esta uma das fun¸cões pagas. Mesmo que sejam adicionados competidores ou equipas, estes não são armazenados e não podem ser reutilizados em outros torneios. Também não está presente o suporte para convites entre clubes/equipas criadas, nem a possibilidade de armazenar ficheiros relativos ao torneio.

´

E poss´ıvel fazer o sorteio das equipas pelos grupos/jogos, sendo necessário definir poste-riormente a data do jogo. Não existe a possibilidade de adicionar o local onde se realizará cada encontro.

Apesar de não ter suporte para convites, o que será crucial no projeto que será desen-volvido, a aplica¸cão disponibiliza uma interface interessante no que toca à apresenta¸cão dos torneios e acompanhamento do processo de execu¸cão dos mesmos.

2.1.4 Enjore

O Enjore [4], tal como os outros websites apresentados, ´e uma plataforma que se destina `

(35)

registar uma conta ou efetuar log in com o facebook e ver as informa¸cões disponibilizadas referentes ao sistema. Ainda que o botão para criar torneios esteja vis´ıvel, após pressionar o botão o utilizador é reencaminhado para a página de log in.

Figura 2.8: P´agina inicial Enjore sem log in efetuado

Depois de efetuado o log in, o utilizador é reencaminhado para a página 2.9 onde pode gerir toda a sua informa¸cão.

(36)

Qualquer utilizador pode consultar os torneios existentes, no entanto, é obrigatório registar-se para conregistar-seguir criar o registar-seu torneio. Depois do registo é solicitada a cria¸cão de uma ’orga-niza¸cão’ que será a entidade a que o utilizador e todos os seus torneios/campeonatos estarão associados.

Como estruturas dispon´ıveis, estão presentes elimina¸cão simples, Round Robin e elimina¸cão seguida de grupos. Depois de criado o torneio, é poss´ıvel adicionar equipas e, a cada equipa, é poss´ıvel adicionar jogadores. Estes dados são guardados apenas para a organiza¸cão em questão, não sendo poss´ıvel fazer a sua reutiliza¸cão para outros torneios que não perten¸cam `

a organiza¸c˜ao do utilizador, como ´e explicito na figura 2.10.

Figura 2.10: P´agina de adi¸c˜ao de equipas Enjore

O sistema suporta, também, o sorteio das equipas pelos jogos (Figura 2.11), sendo, no entanto, necessário definir manualmente a data e o campo para cada jogo depois destes terem sido gerados, como é demonstrado na figura 2.12 que mostra os detalhes de um jogo. Apesar de ser poss´ıvel definir uma morada para os campos, não existe suporte do Google Maps.

(37)

Figura 2.11: P´agina de escalonamento do torneio onde ´e poss´ıvel sortear as equipas pelos jogos Enjore

Figura 2.12: P´agina de detalhes de jogo Enjore

Não está implementado um sistema de convites entre organiza¸cões/equipas e os torneios e os utilizadores não podem solicitar a sua presen¸ca nos torneios apresentados. Estes são vis´ıveis publicamente apenas para consulta de informa¸cão.

Por último, apenas existe a atribui¸cão de prémios para as equipas vencedoras não havendo a possibilidade de definir prémios personalizados. O armazenamento de ficheiros associados

(38)

a cada torneio também não é poss´ıvel.

2.1.5 Leverade

De todos os sistemas testados o que mais se aproxima dos objetivos do projeto é o Leverade [5], cuja página inicial é apresentada na figura 2.13.

Figura 2.13: P´agina inicial Leverade

´

E um sistema que requer o registo e o pagamento por parte do utilizador para a sua utiliza¸cão, disponibilizando, no entanto, quinze dias de utiliza¸cão grátis, o que permitiu test´ a-lo.

Depois de ter sido criada uma conta e efetuado o log in, o utilizador é reencaminhado para a página representada na figura 2.14, que funciona como um tipo de dashboard, dispo-nibilizando toda a informa¸cão relativa ao utilizador.

(39)

Figura 2.14: P´agina de utilizador p´ublica Leverade

Usando o botão localizado no canto superior direito da página da figura 2.14 o utilizador pode alterar para a vista de administrador (Figura 2.15). Aqui, épode-se pesquisar todos os torneios criados pelo utilizador, sendo, ainda, poss´ıvel criar um novo, ou competi¸cão como é chamado na plataforma, surgindo durante este processo um formulário com alguns dados para preencher 2.16.

(40)

Figura 2.16: Formul´ario de adi¸c˜ao de torneio Leverade

Após a cria¸cão do torneio o utilizador é reencaminhado para a página de administra¸cão do mesmo (Figura 2.17), onde são apresentados sete separadores cada um com fun¸cões especificas.

(41)

O primeiro separador (Configuration) destina-se à configura¸cão do torneio, onde podem ser alteradas informa¸cões como o nome, a localiza¸cão da sede do torneio com recurso ao Google Maps, entre outros. E tamb´´ em aqui que se encontra a área onde é poss´ıvel fazer upload de ficheiros relativos ao torneio, como é demonstrado na figura 2.18.

Figura 2.18: ´Area de submiss˜ao de ficheiros Leverade

O segundo separador (Registration) destina-se à personaliza¸cão das op¸cões de registo, no caso do organizador pretender utilizar o modo de registo público.

No terceiro separador é tratada a informa¸cão referente às equipas participantes, sendo

poss´ıvel efetuar o registo de equipas, que ser´a guardado na base de dados. No entanto,

apenas ´e permitida a partilha de equipas entre competi¸c˜oes criadas pelo mesmo utilizador (Figura 2.19).

Figura 2.19: ´Area de registo de equipas Leverade

(42)

equipas, uma op¸cão de convite em que é gerado um Link que será enviado para o email da equipa que o organizador pretende convidar, podendo esta, potencialmente, fazer o registo no torneio (Figura 2.20).

Figura 2.20: ´Area de convite Leverade

Apesar de suportar convites, a sua troca não é estritamente feita através do website, pois o convite não é direcionado a nenhum utilizador em particular, mas apenas a um email que o organizador assume como sendo da equipa. A cada equipa é poss´ıvel, ainda, associar jogadores.

Quanto às estruturas organizativas, estão dispon´ıveis quatro (Liga, elimina¸cão simples, grupos e grupos seguidos de elimina¸cão), sendo poss´ıvel realizar em todas o sorteio de grupos e de jogos (Figura 2.21), embora seja necessário definir a data e o campo onde se vão realizar os encontros depois do sorteio. Estas a¸cões podem ser realizadas no quarto separador (Standings and calendar). A localiza¸cão dos campos é feita com ajuda do Google Maps.

(43)

Figura 2.21: ´Area de escalonamento dos jogos Leverade

O quinto separador (Stats) apresenta as estat´ısticas dos jogadores e o sexto (Sanctions) permite sancionar jogadores. O ´ultimo separador (Economic control) destina-se somente ao controlo de custos do torneio.

Como referi anteriormente, este foi o sistema mais completo e aproximado do que seriam os objetivos finais do projeto que vai ser desenvolvido. No entanto, o projeto final terá como objetivo dar suporte total a todos os passos do torneio e possibilitar a comunica¸cão entre os diferentes intervenientes das diferentes equipas, sendo destinado mais a organiza¸cões reais e não tanto a qualquer utilizador que pretenda organizar um torneio.

2.1.6 Challonge!

O Challonge! [6] trata-se de uma sistema bastante mais simples destinado principalmente a torneios de jogos de computador online. A página inicial sem log in(Figura 2.22) permite pesquisar os torneios existentes através da caixa de procura, utilizar um Bracket Generator para escalonar um torneio com base no número de equipas ou então proceder ao registo na página por forma a poder criar um torneio e partilhá-lo.

Depois de efetuado o log in é poss´ıvel proceder à cria¸cão de um torneio, surgindo a página destinada a este fim (Figura 2.23). Aqui é necessário inserir os dados relativos ao torneio, assim como escolher, também, a estrutura pretendida. E poss´ıvel escolher entre´ quatro estruturas(Elimina¸cão simples, elimina¸cão dupla ,Round Robin e grupos seguido de elimina¸cão). Quanto à escolha das equipas que irão participar no torneio, o organizador pode optar entre duas possibilidades, designadamente ser ele a escolher as equipas que vão participar, ou criar uma página de registo a que cada equipa terá de aceder para se registar no torneio.

(44)

Figura 2.22: P´agina inicial Challonge!

Figura 2.23: P´agina de cria¸c˜ao de um torneio Challonge!

Depois de criado e de serem adicionadas as equipas necessárias, é poss´ıvel realizar o sorteio das equipas pelos jogos (Figura 2.24). Não é permitido adicionar nem a data dos jogos nem a sua localiza¸cão.

Concluindo, é um sistema muito simples que apenas contém uma parte do que será o objetivo final do projeto.

(45)

Figura 2.24: P´agina de apresenta¸c˜ao de um torneio Challonge!

2.1.7 Tournament Scheduler

Também bastante simples e com a fun¸cão apenas de gerar e sortear os jogos necessários

para determinado n´umero de equipas, existe o Tournament Scheduler [7]. A sua p´agina

inicial serve, igualmente de p´agina de cria¸c˜ao de um torneio, como se pode verificar na figura 2.25.

(46)

Após a inser¸cão do número de equipas, a estrutura(Round Robin ou double Round Robin) e as localiza¸cões dos jogos é poss´ıvel gerar os encontros que serão necessários para apurar o vencedor do torneio. Tanto nas equipas como nas localiza¸cões dos campos, apenas é permitido definir o seu nome.

Depois de gerado, é fornecido um Link para uma página somente para consulta de in-forma¸cão do torneio, e um Link de administrador para atualizar os resultados. Tanto a página pública como a de administrador têm o mesmo aspeto, apresentado na figura 2.26, sendo que na página de administrador é poss´ıvel inserir e modificar os resultados dos jogos. O primeiro pode ser partilhado entre os interessados que queiram seguir a evolu¸cão do torneio; o segundo serve apenas para realizar altera¸cões ou inserir resultados. Nenhum torneio pode ser visto publicamente sem o Link público, que apenas o organizador tem em posse inicialmente.

(47)

2.2 Compara¸

c˜

ao

Esta seçcão pretende clarificar as diferen¸cas existentes entre os diferentes sistemas testados e o que é pretendido alcan¸car com este projeto, real¸cando a necessidade da sua cria¸cão.

Como suporte foram criadas cinco tabelas comparativas, cada uma referente a pontos de compara¸c˜ao distintos.

Na tabela 2.1 foram contemplados os pontos relativos à cria¸cão de torneios, à possibilidade de participa¸cão em torneios criados por outros utilizadores e aos tipos de estrutura disponi-bilizados por cada sistema. Constata-se que, embora todos os sistemas permitam a cria¸cão de torneios, apenas o Enjore permite realiza-lo gratuitamente. Quanto à participa¸cão em torneios criados por outros utilizadores, apenas é poss´ıvel fazê-lo no Tournament Software, onde os torneios são disponibilizados online, e no Leverade através do convite por email.

No que toca aos tipos de estrutura apresentados, todas as aplica¸cões contêm elimina¸cão simples e grupos seguidos de elimina¸cão, divergindo apenas em algumas estruturas adicionais apresentadas pelos diferentes sistemas.

Website Criação de torneios Participação em torneios Tipos de estrutura

Tournament Software Mediante pagamento Gratuita

Elimina¸c˜ao simples e dupla,

Round Robin, Elimina¸cão com qualifica¸cão prévia e Round Robin com

qualifica¸c˜ao pr´evia

Konkuri Gratuita at´e 4 equipas ou

8 participantes individuais

O organizador define as equipas, n˜ao sendo poss´ıvel a uma equipa de fora solicitar a sua participa¸c˜ao

Elimina¸c˜ao simples,

grupos seguidos de elimina¸c˜ao e todos contra todos

Enjore Gratuita

O organizador define as equipas, n˜ao sendo poss´ıvel a uma equipa de fora solicitar a sua participa¸c˜ao

Elimina¸c˜ao simples,

Round Robin e elimina¸c˜ao seguida de grupos

Leverade Mediante pagamento

Mediante pagamento ´e poss´ıvel participar em torneios criados por outros utilizadores, atrav´es de um Link enviado por email

Liga, elimina¸c˜ao simples, grupos e grupos seguidos de elimina¸c˜ao

Tabela 2.1: Tabela comparativa 1

Na tabela 2.2 foram comparadas as várias formas como é efetuado o registo de clubes, equipas e jogadores para utiliza¸cão no torneio. Em nenhuma das aplica¸cões testadas é poss´ıvel guardar clubes, equipas ou jogadores para serem utilizados por outros torneios criados por uti-lizadores diferentes, sendo poss´ıvel, no entanto, em alguns casos a partilha dentro de torneios do mesmo utilizador(Leverade). Apenas no Konkuri não é permitida a cria¸cão de clubes ou adi¸cão de jogadores às equipas.

(48)

Website Registo de clubes Registo de equipas Registo de jogadores Tournament Software

´

E poss´ıvel registar clubes, no entanto n˜ao ´e feita a partilha entre torneios

´

E poss´ıvel registar equipas, no entanto n˜ao ´e feita a partilha entre torneios

´

E poss´ıvel registar jogadores, no entanto n˜ao ´e feita a partilha entre torneios

Konkuri N˜ao suportado

´

N˜ao suportado

Enjore

´

E poss´ıvel registar jogadores, no entanto n˜ao ´e feita a partilha entre torneios

Leverade

´

E poss´ıvel registar clubes,

no entanto, a partilha entre torneios ´e feita apenas entre torneios

do mesmo organizador

´

E poss´ıvel registar clubes, no entanto a partilha entre torneios ´e feita apenas entre torneios do mesmo organizador

Na tabela 2.3 foi analisado o suporte para o sorteio de grupos e para o sorteio de jogos. Todos cumpriram este requisito, embora tanto o Tournament Software como o Leverade

apenas o permitam mediante pagamento. Em nenhum dos sistemas testados ´e feito o sorteio

em rela¸cão aos campos ou às datas, sendo sempre necessária a sua defini¸cão posterior.

Website Sorteio de grupos Sorteio de jogos

Tournament Software Mediante pagamento

Mediante pagamento os jogos são sorteados, no entanto é necessário definir manualmente a data e o campo onde cada

jogo se ir´a realizar

Konkuri Suportado

Jogos são sorteados, no entanto é necessário definir manualmente a data e o campo onde cada jogo se irá realizar

Enjore Suportado

Jogos são sorteados, no entanto é necessário definir manualmente a data e o campo onde cada jogo se irá realizar

Leverade Mediante pagamento

Mediante pagamento os jogos são sorteados, no entanto é necessário definir manualmente a data onde cada

jogo se ir´a realizar Tabela 2.3: Tabela comparativa 3

No que concerne à localiza¸cão dos campos, datas de jogos e ao modo como são definidos os prémios foram contemplados na tabela 2.4. Em rela¸cão à localiza¸cão dos campos, apenas o Konkuri não permite definir em que campo se realizará cada jogo. Embora todos os restantes possibilitem a localiza¸cão, apenas o Leverade a viabiliza com recurso ao Google Maps.

Todos os sistemas testados suportam a defini¸cão da data de cada jogo e todos atribuem prémios às equipas vencedores, não permitindo ,no entanto, adicionar prémios personalizados, como por exemplo prémios para as equipas com menos cartões amarelos/vermelhos.

(49)

Website Localização dos campos Datas de jogos Prémios Tournament Software

Mediante pagamento permite a utiliza¸c˜ao de localiza¸c˜ao de campos sem suporte do Google Maps

Mediante pagamento Apenas prémios para as equipas vencedoras. Não suporta prémios personalizaveis

Konkuri N˜ao Suportado Suportado Apenas pr´emios para as equipas vencedoras.

N˜ao suporta pr´emios personalizaveis

Enjore

Mediante pagamento permite a utiliza¸c˜ao de localiza¸c˜ao de campos sem suporte do Google Maps

Suportado Apenas prémios para as equipas vencedoras. Não suporta prémios personalizaveis

Leverade Mediante pagamento Mediante

pagamento

Apenas prémios para as equipas vencedoras. Não suporta prémios personalizaveis

A tabela 2.5 evidencia as diferen¸cas existentes em rela¸c˜ao ao suporte para troca de convites entre os organizadores e as equipas participantes e o suporte para armazenamento de ficheiros. Apenas o Leverade permite realizar ambas as fun¸c˜oes.

Website Suporte para troca de convites Suporte para ficheiros

Tournament Software N˜ao suportado N˜ao suportado

Konkuri N˜ao Suportado N˜ao suportado

Enjore N˜ao suportado N˜ao suportado

Leverade Mediante pagamento e atrav´es de link de convite Mediante pagamento

Após a análise das diferentes aplica¸cões encontradas, embora houvesse à partida uma es-pecifica¸cão e um conjunto de objetivos pré-definidos, foi poss´ıvel recolher alguma informa¸cão sobre como estruturar e o que deve ser inclu´ıdo no projeto final. Assinala-se, porém, que, enquanto que os sistemas testados se destinam mais a utilizadores independentes que preten-dem organizar um torneio, o pretendido no sistema a ser desenvolvido é o suporte para clubes de forma¸cão. Como tal, é fundamental que exista uma base de dados com informa¸cão dos clubes, equipas e jogadores, atualizada constantemente, e que possa ser partilhada entre os diferentes torneios, seja qual for o organizador do torneio. Esta fun¸cão, como demonstrado anteriormente, não está dispon´ıvel em nenhum dos sistemas testados.

O sistema de convites também não está presente em nenhum dos sistemas, em que o mais próximo foi o Leverade, que disponibiliza a possibilidade de convidar equipas através do email. No entanto, é necessário registar a equipa no ato de inscri¸cão não sendo reutilizados dados de equipas existentes. O sistema de convites que se pretende construir tem por objetivo que os utilizadores consigam tratar de toda a log´ıstica associada ao convite e respetiva aceita¸cão e confirma¸cão de presen¸ca através do website.

(50)

2.3 Standards de desenvolvimento

Nesta seçcão irão ser expostos alguns dos standards de desenvolvimento web existentes.

2.3.1 MVC

O modelo MVC tem por base trˆes entidades:

• Model - Representa a informa¸cão que está presente na base de dados. A manipula¸cão dos dados presentes na base de dados é feita através destes modelos, independentemente do tipo de base de dados, desde MySQL até um simples ficheiro XML. A configura¸cão da base de dados é feita no ficheiro .env gerado automaticamente aquando da cria¸cão do projeto.

• View - Representa as páginas que contêm a parte visual de modo a permitir ao utilizador interagir com a aplica¸cão.

• Controller - Intermediário entre o Model e a View, aqui é tratada a informa¸cão, quer seja apenas para apresentar em uma página(View) informa¸cão presente na base de dados(Model), quer seja para guardar na base de dados informa¸cão que o utilizador introduziu.

Como é evidenciado na figura 2.27, neste modelo, depois de ser recebido o pedido, é o controlador que interage com o modelo para recolher os dados necessários disponibilizando-os depois na view respetiva.

´

E usado atualmente por muitas frameworks incluindo Ruby on Rails, Spring Framework e Laravel Framework utilizada neste projeto.

(51)

2.3.2 MVP

O modelo MVP (Figura 2.28 adaptada de [8]) ´e um modelo derivado do modelo MVC,

em que o controller existente no modelo MVC ´e substitu´ıdo pelo presenter [8].

Figura 2.28: Diagrama MVP

Tal como o modelo MVC, este modelo tem por base trˆes aspetos, sendo os dois primeiros (Model e View) semelhantes ao modelo descrito no ponto anterior:

• Presenter - ´E respons´avel pelo tratamento de todos os eventos provenientes da interface

apresentada pela view. Recebe o input dos utilizadores atrav´es das views e depois

processa os dados com a ajuda do model, passando-os depois novamente para a view. O presenter tem o trabalho de servir de suporte à view, sendo a comunica¸cão entre eles feita através de uma interface.

O presenter e as views têm uma rela¸cão de um para um, sendo que a cada view está associado um presenter.

2.3.3 MVVM

O modelo MVVM (Figura 2.29 adaptada de [8]) ´e, tamb´em, um modelo derivado do

(52)

Figura 2.29: Diagrama MVVM

Tal como o modelo MVC, este modelo tem por base trˆes aspetos, sendo os dois primeiros (Model e View) semelhantes ao modelo descrito no ponto anterior:

• View Model - Implementa m´etodos e comandos que ajudam a manter o estado da view

e a manipular o modelo como resultado de a¸cões realizadas na view. A comunica¸cão entre a view e o view model é feita através de um mecanismo de binding.

(53)

2.4 Tecnologias utilizadas

A escolha destas foi motivada pelo facto de terem sido recomendadas pela empresa, que, desta forma, pˆode oferecer uma melhor ajuda sempre que foi necess´ario.

2.4.1 PHP

PHP ´e uma linguagem de programa¸c˜ao destinada a desenvolvimento web e pode ser

em-butida em HTML. O seu código é interpretado do lado do servidor pelo módulo PHP[9],

que tamb´em gera a p´agina web a ser visualizada no lado do cliente. O principal objetivo da

linguagem ´e permitir que programadores web desenvolvam paginas geradas automaticamente

com rapidez[10] [11]. A programa¸cão em PHP é muito parecida com a programa¸cão em C, Java ou Perl e a estrutura¸cão do código é muito simples e intuitiva. O PHP é um software gratuito, com o código disponibilizado sob a PHP License, e pode ser instalado gratuitamente.

2.4.2 Bootstrap

O Bootstrap é uma web framework gratuita destinada ao desenvolvimento da parte visual de websites e aplica¸cões web. Como tal, foca-se apenas na parte de front-end, e para além de templates, contém uma vasta variedade de botões, formulários, barras de navega¸cão e

outros elementos que podem ser utilizados[12]. Apresenta tamb´em como vantagens o facto

de ser otimizado para o desenvolvimento de layouts responsivos e de funcionar em todos os navegadores atuais.

2.4.3 MySQL

MySQL ´e uma das base de dados mais popular no mundo, sendo neste momento

desen-volvida, distribu´ıda e suportada pela empresa Oracle. ´E gratuita e uma garantia de boa

performance, confiável e de fácil utiliza¸cão, ideal tanto para pequenas aplica¸cões como para aplica¸cões mais compostas.[13] [11] [14]

2.4.4 Laravel Framework

Para o desenvolvimento da aplica¸cão foi utilizado o framework Laravel [15] [16], que se baseia no modelo de arquitetura MVC, explicado no próximo ponto. Para além de melhorar a eficiência na elabora¸cão do código, a framework é escalável e robusta [17]. É chamada de uma framework ’full stack’, pois lida com todas as tarefas da aplica¸cão desde a gera¸cão da base de dados até à gera¸cão do HTML. Outra vantagem consiste na facilidade oferecida para configurar o projeto aquando da sua cria¸cão, sendo bastante fácil criar e colocar uma aplica¸cão a funcionar, tendo apenas de se editar um ou outro ficheiro de configura¸cão.

Interac¸˜ao com a Base de Dados

A intera¸cão com a base de dados é feita através do Eloquent ORM[18] inclu´ıdo na

framework, que consiste numa implementa¸c˜ao PHP ActiveRecord[18] em que cada tabela

presente na base de dados tem um ’Model’ correspondente [19]. O modo como s˜ao feitos os

pedidos à base de dados(Querys) são facilitados, substituindo a escrita de código SQL por métodos, como apresentado no exemplo 1, em que é pedido à tabela correspondente ao mo-delo ’Fixture’ presente na base de dados que retorne o elemento com o id passado ao método

(54)

’find’ como argumento. É igualmente poss´ıvel sobrepor métodos para pedidos mais elabora-dos, como é demonstrado no exemplo 2, em que para além de ser usado o método ’where’ para filtrar, é, também usado o método ’orderBy’ para ordenar os elementos e, finalmente, o método first para retornar o primeiro elemento do resultado dos dois métodos anteriores.

$ f i x t u r e = F i x t u r e : : f i n d ( $ f i x t u r e i d ) ;

Listagem 1: Exemplo de Query 1

$ m a i n t o u r n a m e n t = MainTournament : : where (’ c r e a t e d _ b y ’, Auth : : u s e r ( )−>i d ) −>orderBy (’ n a m e ’,’ ASC ’)

−> f i r s t ( ) ;

Listagem 2: Exemplo de Query 2

Qualquer conjunto de resultados retornado pelo Eloquent constitui uma instˆancia da

classe Collection, a partir da qual ´e poss´ıvel usar um conjunto vasto de m´etodos que

per-mitem manipular essa Collection. A tabela 2.6 apresenta alguns dos m´etodos dispon´ıveis

adaptados da documenta¸cão disponibilizada [20], assim como uma breve descri¸cão da sua fun¸cão.

Método Descrição Utilização

contains Avalia se a cole¸cão contém um elemento $collection− > contains(0Desk0); count Retorna o número total de elementos da cole¸cão $collection− > count();

isEmpty Avalia se a cole¸cão tem elementos $collection− > isEmpty(); random Retorna um elemento aleatório da cole¸cão $collection− > random(); sort Ordena por ordem crescente a cole¸cão $sorted = $collection− > sort(); sortBy Ordena por ordem crescente a cole¸cão com base

na {key} passada como argumento $sorted = $collection− > sortBy(

0_price0_);

toJson Converte a cole¸c˜ao em JSON $collection− > toJ son(); toArray Converte a cole¸c˜ao em um array PHP $collection− > toArray(); where

Filtra a cole¸c˜ao, obtendo os elementos em que a {key} passada como argumento 1 ´e igual ao valor passado como argumento 2

$f iltered = $collection− > where(0price0, 100);

Tabela 2.6: Alguns m´etodos disponiveis para a manipula¸c˜ao de Collections

No entanto, para poder usar estes métodos, é necessário, como foi dito, que o objeto seja uma instância de Collection. Para isso é preciso usar o método get sobre o resultado

retornado pela base de dados. Na figura 2.30 ´e apresentado o objeto resultante da Query

sem recurso ao método get. Sendo da classe Builder, não é possivel utilizar os métodos de manipula¸cão de Collection.

(55)

Figura 2.30: Resultado de Club::where(’created by’, Auth::user()->id)

Recorrendo ao m´etodo get, figura 2.31, o resultado obtido ´e agora uma Collection,

tornando-se poss´ıvel a sua manipula¸cão através dos métodos dispon´ıveis.

Figura 2.31: Resultado de Club::where(’created by’, Auth::user()->id)->get()

Por último, é também muito intuitivo o modo como são tratadas as rela¸cões na base de dados. Se o modelo estiver devidamente constru´ıdo é poss´ıvel obter, facilmente, dados de tabelas relacionadas, seja qual for o tipo de rela¸cão [21].

Para demonstrar como é replicada uma rela¸cão do tipo um para um (One-to-One), é utilizado como exemplo a rela¸cão entre um utilizador e o seu número de telefone, sendo

que um utilizador apenas pode estar associado a um n´umero de telefone. Na Listagem 3,

está o método phone, que teria de ser definido no modelo correspondente ao Utilizador. Através dele é poss´ıvel obter o número de telefone correspondente ao utilizador que invoca o método(Listagem 4).

p u b l i c f u n c t i o n phone ( ) {

r e t u r n $ t h i s −>hasOne (’ App \ P h o n e ’) ; }

Listagem 3: Exemplo do m´etodo de uma rela¸c˜ao 1-1

$phone = $ u s e r −>phone ;

Listagem 4: Exemplo do uso de uma rela¸c˜ao 1-1

Por outro lado, e de modo a poder realizar a opera¸cão inversa, isto é, ter acesso ao utilizador a partir do seu número de telefone, teria de ser definido o método inverso no modelo correspondente ao Telefone (Listagem 5). O modo como é utilizada é semelhante ao anterior (Listagem 6).

(56)

p u b l i c f u n c t i o n u s e r ( ) {

r e t u r n $ t h i s −>b e l o n g s T o (’ App \ U s e r ’) ; }

Listagem 5: Exemplo do m´etodo de uma rela¸c˜ao 1-1(Inverso)

$ u s e r = $phone−>u s e r ;

Listagem 6: Exemplo do uso de uma rela¸c˜ao 1-1(Inverso)

Esta rela¸cão é estabelecida através da chave estrangeira, que o Laravel assume por omissão que seja o nome do modelo seguido de _id. Neste caso irá existir uma chave es-trangeira na tabela Phones com o nome user_id de modo a associar um telefone a um utilizador. É também poss´ıvel especificar o nome da chave estrangeira no segundo argumento do método hasOne caso este seja diferente.

Para uma rela¸cão do tipo um para muitos (One-to-Many), é tido agora como exemplo a rela¸cão entre um Post online e os comentários associados a esse Post, sendo que um Post pode ter vários comentários (One-to-Many). Na Listagem 7, é vis´ıvel o método comments, que seria definido no Model Post e devolve todos os comments associados ao Post que invoca o método(Listagem 8).

p u b l i c f u n c t i o n comments ( ) {

r e t u r n $ t h i s −>hasMany (’ App \ C o m m e n t ’) ; }

Listagem 7: Exemplo do m´etodo de uma rela¸c˜ao 1-Muitos

$comments = $ p o s t −>comments ;

Listagem 8: Exemplo do uso de uma rela¸c˜ao 1-Muitos

Assim como para uma rela¸cão de um para um, numa rela¸cão de um para muitos também é poss´ıvel definir a rela¸cão inversa. Seguindo o exemplo referido, o inverso seria aceder ao Post com base num Comment. Para isso teria de ser definido uma fun¸cão no modelo correspondente

ao Comment semelhante `a apresentada na listagem 9. O modo como este m´etodo pode ser

acedido, retornando o Post ao qual corresponde o Comment que invoca o m´etodo ´e representado na Listagem 10.

p u b l i c f u n c t i o n p o s t ( ) {

r e t u r n $ t h i s −>b e l o n g s T o (’ App \ P o s t ’) ; }

(57)

$ p o s t = $comment−>p o s t ;

Listagem 10: Exemplo do uso de uma rela¸c˜ao 1-Muitos (Inverso)

Assim como no caso das rela¸cões um para um, a tabela comments vai ter uma coluna com a chave estrangeira post_id, que indica qual o Post a que pertence determinado Comment. É igualmente poss´ıvel especificar uma chave estrangeira com nome diferente caso seja necessário. Em rela¸cões do tipo muitos para muitos (Many-to-Many) é necessária a cria¸cão de uma tabela, normalmente chamada de tabela pivot, para guardar a informa¸cão da rela¸cão. Este

tipo de tabelas tˆem habitualmente o nome dos dois modelos relacionados separados por um

’_’.

Na explica¸cão seguinte será usado como exemplo as diferentes fun¸cões que cada utilizador pode desempenhar (Roles), que representa uma rela¸cão muitos para muitos (Many-to-Many). Quanto aos métodos que têm de ser definidos em cada modelo, no modelo User existiria o método roles (Listagem 11), que retornará todas os roles associados a um utilizador, e no modelo Role existiria o método users (Listagem 12), que retornará todos os utilizadores associados a determinado role. O uso do método withPivot permite adicionar aos resultados retornados as colunas cujos nomes são passados como argumento .

p u b l i c f u n c t i o n r o l e s ( ) {

r e t u r n $ t h i s −>belongsToMany (’ App \ R o l e ’)−>w i t h P i v o t (’ d a t e ’) ; }

Listagem 11: Exemplo de m´etodo de uma rela¸c˜ao Muitos-Muitos

p u b l i c f u n c t i o n u s e r s ( ) {

r e t u r n $ t h i s −>belongsToMany (’ App \ U s e r ’)−>w i t h P i v o t (’ d a t e ’) ; }

Listagem 12: Exemplo de m´etodo de uma rela¸c˜ao Muitos-Muitos

Nas Listagens 13 e 14 estão dois exemplos de como se pode tirar proveito destas rela¸cões no desenvolvimento do código. No primeiro exemplo (Listagem 13) é realizada uma query para obter todas as roles pertencentes ao utilizador definido anteriormente. É, depois, encadeado

o m´etodo orderBy, por forma a ordenar os resultados retornados pela ordem passada como

argumento (name). Deste modo o resultado obtido neste exemplo ser´a o conjunto das roles do

utilizador que invocou o m´etodo, ordenadas crescentemente pelo nome. No segundo exemplo

(Listagem 14) ´e utilizada a rela¸c˜ao no sentido inverso, obtendo todos os utilizadores associados a determinada role.

$ r o l e s = $ u s e r −>r o l e s ( )−>o r d e r B y (’ n a m e ’)−>g e t ( ) ;

(58)

$ u s e r s = $ r o l e −>u s e r s ;

Listagem 14: Exemplo do uso do m´etodo definido

A manuten¸c˜ao da base de dados pode ser feita atrav´es de Migrations, que permitem gerir

facilmente a estrutura da base de dados, registando as mudan¸cas realizadas e permitindo

anulá-las. Estas estão diretamente relacionadas com a classe Schema, que é usada para a cria¸cão e manipula¸cão das tabelas [22]. A Listagem 15 demonstra a cria¸cão de uma Migration.

´

E composta por dois métodos: um para quando a migration é executada(up), que neste caso resulta na cria¸cão da tabela fields; e outro para quando a migration é anulada (down) que resulta na elimina¸cão da tabela fields. É poss´ıvel ver o uso da classe Schema na cria¸cão e elimina¸cão da tabela na Listagem 15.

<?php u s e I l l u m i n a t e \ D a t a b as e \ Schema \ B l u e p r i n t ; u s e I l l u m i n a t e \ D a t a b as e \ M i g r a t i o n s \ M i g r a t i o n ; c l a s s C r e a t e F i e l d s T a b l e e x t e n d s M i g r a t i o n { /* * * Run the m i g r a t i o n s . * * @ r e t u r n v o id */ p u b l i c f u n c t i o n up ( ) { Schema : : c r e a t e (’ f i e l d s ’, f u n c t i o n ( B l u e p r i n t $ t a b l e ) { $ t a b l e −>i n c r e m e n t s (’ id ’) ; $ t a b l e −>i n t e g e r (’ c l u b _ i d ’)−>u n s i g n e d ( ) ; $ t a b l e −>i n t e g e r (’ n u m b e r ’) ; $ t a b l e −>s t r i n g (’ n a m e ’) ; $ t a b l e −>d o u b l e (’ l a t i t u d e ’, 1 5 , 1 1 ) ; $ t a b l e −>d o u b l e (’ l o n g i t u d e ’, 1 5 , 1 1 ) ; $ t a b l e −>t i m e s t a m p s ( ) ; } ) ; // F o r e i g n K ey s Schema : : t a b l e (’ f i e l d s ’, f u n c t i o n ( $ t a b l e ) { $ t a b l e −>f o r e i g n (’ c l u b _ i d ’)−> r e f e r e n c e s (’ id ’)−>on (’ c l u b s ’)−>o n D e l e t e (’ c a s c a d e ’) ; } ) ; } /* * * R e v e r s e the m i g r a t i o n s . * * @ r e t u r n v oi d */ p u b l i c f u n c t i o n down ( ) { Schema : : drop (’ f i e l d s ’) ; } }

Listagem 15: Exemplo de uma Migration

(59)

permitem gerir as Migrations, e consequentemente, a base de dados. Estes comandos e uma breve descri¸cão da fun¸cão de cada um são apresentados na tabela 2.7.

Comando Descric¸˜ao

php artisan migrate Executa todas as migrations da aplica¸c˜ao

php artisan migrate:rollback Desfaz as altera¸cões realizadas até à última opera¸cão php artisan migrate:reset Desfaz todas as migrations da aplica¸cão

php artisan migrate:refresh Desfaz todas as migrations da aplica¸c˜ao e executa-as novamente Tabela 2.7: Tabela de comandos

Existe ainda a possibilidade de inicializar a base de dados através de Seeders [23]. A utiliza¸cão de Seeders facilita bastante quando é necessário inserir uma grande quantidade de dados na base de dados, para realizar testes por exemplo. Para isso é preciso inserir no ficheiro DatabaseSeeder.php, que é gerado automaticamente na cria¸cão da aplica¸cão, qual a tabela e os dados que se pretende inserir. Para popular a base de dados deste modo, é necessário após

a modifica¸c˜ao do ficheiro DatabaseSeeder.php, executar o comando php artisan db:seed

na linha de comandos.

Quanto à organiza¸cão da aplica¸cão, todos os projetos, depois de criados, são organizados da forma apresentada na figura 2.32.

(60)

Figura 2.32: Exemplo da organiza¸c˜ao de uma aplica¸c˜ao

Nesta estrutura é poss´ıvel identificar os diferentes elementos da organiza¸cão MVC expli-cada anteriormente. O ficheiro responsável pelo tratamento do Routing é o ficheiro

app\Http\routes.php. Este cont´em toda a informa¸c˜ao para que cada Request recebido seja

reencaminhado para o respetivo Controller. Todos os Controllers s˜ao colocados na pasta

app\Http\Controllers, são estes que vão interagir com a base de dados através dos Models, que são tipicamente colocados na raiz da pasta app.

Os ficheiros associados à base de dados estão presentes na pasta database, e é aqui que vão estar definidas as migrations e as seeds, nas pastas correspondentes.

Todos os ficheiros relativos às Views, responsáveis pela parte visual da aplica¸cão, serão

colocados na pasta resources\views, onde ´e criada normalmente uma sub pasta por modelo,

em que cada sub pasta cont´em as views relativas a esse modelo.

2.4.5 Extras

Para além das tecnologias anteriormente referidas, foram utilizados diferentes packages, entre os quais Full Calendar[24], para apresentar a distribui¸cão dos jogos com suporte de um calendário; Datatables[25] para apresentar as tabelas; DOMPDF[26] para conversão de

(61)

pretendido descarrega-los; Intervention Image[27] para tratamento das imagens referentes ao logo dos clubes, fotos dos jogadores e utilizadores .

(62)

(63)

Cap´ıtulo 3

Requisitos e Arquitetura do Sistema

Neste cap´ıtulo serão descritos os requisitos do sistema, que resultaram de uma série de reuniões não só com a empresa, como, também com outras pessoas do meio, familiarizadas com todo o processo e passos necessários para a organiza¸cão de um torneio.

Primeiro será explicada a organiza¸cão do sistema, como está estruturado e os seus dife-rentes elementos.

Numa segunda parte vão ser expostos os requisitos que o sistema deverá cumprir. Para o efeito vai ser apresentado um diagrama de casos de uso, onde vão ser evidenciados os diferentes tipos de utilizadores da plataforma e as a¸cões que cada um pode realizar na mesma.

Na terceira parte irá constar a evolu¸cão da base de dados desde o esbo¸co inicial até ao resultado final.

Finalmente, ser´a, depois, descrita a arquitetura de sistema concebida para alcan¸car os resultados finais pretendidos.

3.1 Organiza¸

c˜

ao do sistema

A plataforma deverá suportar um sistema de utilizadores que poderão ser diretores de clubes, coordenadores de equipas ou somente organizadores de torneios. Deverá, igualmente, ter suporte para armazenar informa¸cão de clubes, equipas e jogadores, por forma a ser par-tilhada entre os diferentes torneios sem que seja necessário introduzir a mesma informa¸cão cada vez que é criado um torneio.

O sistema tem de ser capaz de acompanhar todos os passos necessários desde a cria¸cão do torneio até à sua conclusão:

1. Cria¸c˜ao do torneio principal;

2. Adicionar ao torneio principal uma categoria/escal˜ao de idade;

3. Convidar equipas para participarem no torneio, em uma categoria especifica;

4. Depois de estarem confirmadas as equipas necessárias para a realiza¸cão do torneio, será preciso definir a sua estrutura;

5. Ser´a agora poss´ıvel realizar o sorteio dos grupos e posteriormente dos jogos;

6. À medida que os jogos vão sendo realizados, será necessário que vão sendo inseridos os seus resultados;

(64)

7. Depois de serem inseridos os resultados de todos os jogos, os pr´emios devem ser auto-maticamente calculados e associados aos vencedores;

Relativamente à cria¸cão do torneio principal, é necessário que o utilizador defina o seu nome, a sua data de inicio, o intervalo de horas a que pretende que os jogos sejam realizados e, ainda, escolher o clube que será o anfitrião do torneio. Depois de criado o torneio, o organi-zador pode adicionar uma categoria ao torneio principal. Para cada categoria irá ser definido o número de equipas participantes, o escalão de idade, a dura¸cão de cada jogo, o intervalo entre jogos e, finalmente, a ordem pela qual pretende que os grupos sejam ordenados(Pontos, Golos Marcados, Golos Sofridos e Diferen¸ca de Golos).

Depois de adicionada a categoria, o utilizador deve conseguir convidar as equipas que pretende que participem no seu torneio. O processo de convites deverá consistir em três passos: primeiramente o organizador envia o convite para o clube, convidando determinada equipa desse clube para o seu torneio; depois, o responsável pelo clube convidado após receber o convite, pode aceitá-lo ou rejeitá-lo. No caso de aceitar o convite, tem, ainda, de aguardar que o organizador do torneio confirme a sua presen¸ca. Este terceiro passo de confirma¸cão por parte do organizador foi adicionado para que no caso de mais equipas do que as necessárias terem aceite o convite, o organizador possa escolher as equipas que pretende ter no torneio.

Logo que o número de equipas que confirmaram a presen¸ca alcance as equipas que o orga-nizador definiu, este pode escolher a estrutura pretendida. Quanto às estruturas dispon´ıveis, variam consoante o número de equipas participantes, estando no geral dispon´ıveis:

• Eliminat´orias

• Grupos seguidos de eliminat´orias

• Grupos seguidos de jogos para apurar posi¸c˜oes finais

Os dois primeiros tipos, foram j´a explicados anteriormente no ponto 2.1.

Como a maior parte dos torneios organizados pelos clubes se destinam a escalões mais jovens, foi proposto outro tipo de estrutura em que todas as equipas realizavam o mesmo número de jogos para justificar a desloca¸cão, muitas vezes longa, para a localiza¸cão do tor-neio. Como tal, o terceiro tipo de torneios tem por base uma fase de grupos, idêntica à referida anteriormente, mas agora seguida de jogos para apurar as posi¸cões no torneio. Desta forma, para apurar o 1o e 2o lugar defrontar-se-ão as equipas que acabaram em primeiro em

cada grupo, para o 3o e 4o as equipas que terminaram em 2o lugar em cada grupo e assim

(65)

Figura 3.1: Exemplo de estrutura baseada em grupos seguido de um jogo para 16 equipas Depois de escolhida a estrutura, é poss´ıvel sortear as equipas pelos grupos (grupos de 2 caso seja a estrutura por eliminatórias) e, posteriormente, gerar os jogos que serão divididos pelo intervalo de tempo definido pelo organizador e pelos campos existentes no clube anfitrião do torneio. Tanto a data de realiza¸cão como o campo em que é realizado o jogo deve poder ser alterado posteriormente consoante as preferências do organizador.

Chegando à data da realiza¸cão do torneio, o organizador deverá poder inserir os resultados `

a medida que os jogos se v˜ao realizando.

Finalmente, depois de todos os jogos serem realizados, os prémios são distribu´ıdos. Deverá ser poss´ıvel para além dos prémios de equipas inserir prémios personalizados.