UNIVERSIDADE FEDERAL DO PARANÁ ALISSON RAFAEL QUERO DELFINO LUCAS FLECK DE SOUZA CASTRO JACKSON FELIPE DE LIMA SCOUT: UMA ABORDAGEM WEB CURITIBA

UNIVERSIDADE FEDERAL DO PARANÁ ALISSON RAFAEL QUERO DELFINO LUCAS FLECK DE SOUZA CASTRO JACKSON FELIPE DE LIMA SCOUT: UMA ABORDAGEM WEB CURITIBA 2013

ALISSON RAFAEL QUERO DELFINO LUCAS FLECK DE SOUZA CASTRO JACKSON FELIPE DE LIMA SCOUT: UMA ABORDAGEM WEB Trabalho apresentado como requisito parcial a obtenção do grau de Bacharel em Ciência da Computação no curso de graduação em Ciência da Computação, Setor de Exatas da Universidade Federal do Paraná. Orientador: Prof. Bruno Müller Junior CURITIBA 2013

RESUMO Scout é o nome dado ao processo de contagem de determinadas ações em eventos esportivos. Exemplos incluem o número de cestas de três pontos de um jogador a partir de uma localização da quadra ou destino dos ataques de um jogador em uma partida de vôlei. Para agilizar o processo de contagem, é natural utilizar aplicativos computacionais para registrar e contabilizar as ações. O presente texto se propõe a desenvolver uma aplicação WEB para a contagem de ações em partidas de futebol, utilizando tecnologias atuais para captura, armazenamento e síntese das informações obtidas. Palavras-Chave: Aplicação web, scout, bcc, contagem de eventos, esporte, estatística.

ABSTRACT Scout is the name given to the process of counting certain actions at sporting events. Examples include the number of three-pointer goal of a player from a destination location of the court or the attacks of a player in a game of volleyball. To improve the process of counting, it is natural to use computer applications to register and account actions. The main objective is develop a web application for counting actions at soccer games, using current technologies to capture, store and compute the information obtained in a match. Keyword: Web Application, scout, bcc, count of sports, sport, statistics.

LISTA DE ILUSTRAÇÕES Figura 2.1 - Tela de captação de dados, aplicação Mayrhofer [1] Figura 2.2 Arquivo de texto gerado, apartir da captura ilustrada na figura 2.1 [1] Figura 2.3 Tabela com a contagem dos passes por jogador [1] FIgura 2.4 Tela de marcação do Scout Graph [7] Figura 2.5 Documentação da função setjogador Figura 3.1 Casos de uso do usuário em modo scout Figura 3.2 Casos de uso do usuário em modo administrador Figura 3.3 Fluxo da comunicação dos dados Figura 4.1 Tela de Marcação de eventos Figura 4.2 Tela de Marcação de eventos no momento da captura de um evento Figura 4.3 Arquivo XML, que contém a marcação do evento selecionado na figura 4.2 Figura 4.4 Tela inicial do módulo administrador Figura 4.5 Visualisando informações. Figura 4.6 Tela inicial que agrupa informações do jogador específico. Figura 4.7 Indicativo de jogadas para o jogador específico. Figura 4.8 Indicativo de espalhamento e posse de bola para o jogador específico. Figura A.1 Estrutura do HTML5 Figura A.1 2 Página de autênticação do usuário Figura A.1 3 Código a ser interpretado pelo navegador WEB

LISTA DE ABREVIATURAS E/OU SIGLAS CSS Cascading Style Sheets DNS - Domain Name System IBM - International Business Machines IHC Interação Humano-computador MD5 - Message-Digest algorithm 5 MYSQL Sistema de Gerenciamento de Banco de Dados PHP - Hypertext Preprocessor RPC Remote Procedure Call SQL Structured Query Language UFPR Universidade Federal do Paraná WEB Word Wide Web Internet.

SUMÁRIO 1 INTRODUÇÃO... 8 2 TECNOLOGIAS E REVISÃO BIBLIOGRÁFICA... 11 2.1 Solução Existentes... 11 2.1.1 Solução: Aplicação do Mayrhofer... 11 2.1.3 Solução: OptaSports Data Scout... 16 2.2 Ferramentas e Tecnologias... 17 2.2.1 HTML5 (Hyper Text Markup Language)... 17 2.2.2 PHP... 18 2.2.3 Javascript... 18 2.2.4 JQuery... 18 2.2.5 RPC e Web Service... 19 2.2.6 Framework Code Igniter... 21 2.2.7 Servidor Apache... 22 2.2.8 MYSQL, SQL e PHPMYADMIN... 22 3 CONCEITUAÇÃO E IDÉIA GERAL... 24 3.1 Conceitução da Infra-estrutura... 25 3.2 Ideia Geral... 27 4 Implementação da aplicação... 28 4.1 Módulo Scout... 28

4.2 Módulo Administrador... 31 5 Conclusão... 36 5.1 Trabalhos Futuros... 36 6 Referências... 38 Apêndice A Detalhes da Implementação... 39 A.1 O HTML5... 39 A.2 Funcionalidade do módulo Scout... 40 A.2.1 Scripts de Controle... 41 A.3 A interface do sistema... 41 A.3.1 Interface do Módulo Scout e Funcionalidades... 43 A.3.2 Interface do Módulo Administrador e Funcionalidades... 45 A.4 Dados Estatísticos no módulo Administrador... 45 A.5 Comunicação dos Dados... 46 A.5.1 Web Service... 46 A.5.1.2 Criando o Servidor... 47 A.5.1.2 Criando o Cliente... 49 A.5.2 SOAP e NuSOAP... 50 A.5.3 XML... 50 A.6 Segurança... 52

8 1 INTRODUÇÃO Para se obter sucesso em esportes é necessário maximizar as próprias virtudes e minimizar os próprios defeitos(ou anular as virtudes dos adversários). Isto muitas vezes é feito de forma intuitiva, porém este tipo de tarefa tem sido realizada com o uso de computadores para detectar virtudes e defeitos. A classe de aplicativos que executa esta tarefa é chamada de Scout. Scout é basicamente o ato de anotar tudo que o atleta faz, observar e levantar dados para que posteriormente possa ser tomada uma decisão em cima dos dados, ou seja, recolher informações sobre o atleta e também da equipe como um todo. Scout pode ser usado também para analisar novos talentos, verificar se o esportista tem habilidades que podem ser uteis para determinada área. O objetivo geral é aumentar a eficiência do time, apenas trabalhando em pontos que foi possível notar, através do levantamento de dados feito previamente. Uma área que depende fortemente de resultados são os esportes, onde o desempenho de um time influi diretamente em seu orçamento. O sucesso de uma equipe depende na maioria das vezes, do entrosamento entres os jogadores em como cada um joga na sua posição e pode auxiliar a sua equipe na partida. Analisar o comportamento de uma equipe inteira dada uma sequência de ações dos jogadores, não é uma tarefa trivial para o técnico, pois existem muitos fatores a serem incluídos na análise, tais como, condições climáticas, condições do campo, comportamento psicológico do atleta, erros, acertos, habilidades pessoais. Como o técnico tem muitos pontos a focar, a meta do nosso trabalho é pegar alguns pontos e facilitar essa análise. O trabalho de graduação do aluno de matemática industrial Mayrhofer [1], propôs uma solução computacional ao problema, com um programa de marcação de eventos no futebol. Um evento é um lance único que acontece na partida, onde são

9 anotadas as coordenadas do campo onde o lance aconteceu, os jogadores envolvidos e o tempo de ocorrência. Os lances da partida eram marcados em um campo desenhado em uma tela de um computador, os dados coletados eram salvos em um arquivo de texto que servia de entrada para outro programa que realizava a analise dos dados. Foi proposta uma aplicação em linguagem Java, porém bastante limitada. O nosso objetivo é desenvolver uma aplicação mais independente de código aberto onde serão exploradas áreas que foram deixadas em aberto naquele trabalho. A principal diferença em nossa abordagem é o desenvolvimento de uma aplicação web, devido a portabilidade desta plataforma, que permite acesso a partir de dispositivos com diferentes e variadas arquiteturas de hardware e software. Além disso tecnologias mais novas como o HTML5 contém mecanismos que simplificam a captura e a síntese dos eventos detectados, garantindo a independência da nossa aplicação. O objetivo é construir uma aplicação web que permita ao usuário anotar os eventos de uma partida de futebol.entende-se como evento, um acontecimento no campo, como por exemplo o jogador 1 passar a bola para o jogador 2. A marcação dos eventos consiste em o usuário marcar o ponto inicial do passe, ou seja, em que localização do campo o jogador está com bola, e o ponto final assim como a natureza do mesmo (passe certo, perda de bola, cruzamento, etc). A aplicação foi desenvolvida com foco em tablets de 10, devido a facilidade de manuseio e transporte destes dispositivos. Um observador deve marcar os eventos da partida, onde estes eventos são então enviados a um servidor, que é responsável por gerar análises estatísticas. Os dados estatísticos são visualizados em uma página web, que é acessada pela comissão técnica, nesta página estão disponíveis informações em forma de gráficos e tabelas com o desempenho do time adversário e o time da casa, que devem ser interpretadas pelo técnico.

10 O software foi desenvolvido com foco no futebol, mas devido a sua natureza configurável pode ser utilizado em outros esportes, tais como: vôlei, baquete, tênis e handebol.

11 2 TECNOLOGIAS E REVISÃO BIBLIOGRÁFICA O trabalho do aluno Mayrhofer [1], serviu como referência inicial para o desenvolvimento deste. Além disso, foram analisados dois softwares proprietários. As próximas seções descrevem a análise realizada e tecnologias utilizadas no nosso trabalho. As Seções 2.1 apresenta soluções existentes e 2.2, ferramentas e tecnologias utilizadas neste trabalho. Este trabalho se diferencia do trabalho referência[1] por utilizar tecnologias mais eficientes para a captação de dados. O front-end da aplicação foi desenvolvido em HTML5 e o back-end é um web service desenvolvido em PHP. 2.1 Solução Existentes A seguir apresentaremos três soluções de aplicações existentes, 2.1.1 a solução proposta por Mayrhofer, 2.1.2 proposta pelo software Scout Graph[9] e 2.1.3 proposta por OptaSports Data Scout[7]. 2.1.1 Solução: Aplicação do Mayrhofer Nesta aplicação foram desenvolvidos dois módulos independentes: um de captura dos dados e outro de análise, a comunicação entre os módulos era feita através de um arquivo de texto. O módulo de captura consiste na marcação de eventos. O programa possui uma tela onde está desenhado o campo e existem 6 botões: um para iniciar a partida e outro para salvar os dados coletados em arquivo de texto, os outros 4 são eventos pré configurados (passe certo, passe errado, finalização correta, finalização errada).a figura 2.1 representa a tela de captação e a figura 2.2 o arquivo de texto gerado com os dados capturados.

12 A captura é realizada clicando-se com o mouse onde o evento ocorreu no campo, um menu surge e então deve-se escolher o jogador com o teclado e depois deve ser selecionada uma das 4 ações pré-configuradas no canto superior da aplicação. Figura 2.1 Tela de captação de dados, aplicação Mayrhofer [1] Figura 2.2 Arquivo de texto gerado, apartir da captura ilustrada na figura 2.1 [1] O arquivo de texto gerado na captura dos eventos é dividido em 4 colunas, a primeira é o tempo de ocorrência da jogada a segunda o nome do jogador envolvido no passe, a terceira o tipo de passe e a ultima coluna são as coordenadas em metros de onde aconteceu o evento no campo.

13 O modulo de síntese consiste basicamente em uma tabela, onde são contabilizados os passes de cada jogador [1]. A figura 2.3 representa esta tabela Figura 2.3 tabela com a contagem dos passes por jogador [1] Existem alguns problemas na abordagem apresentada acima. O mais grave é que com base na descrição do Mayrhofer [1], os eventos são armazenados em memória até o momento em que o usuário decida salvar os dados em um arquivo.o acontecimento de alguma coisa inesperada com o computrador levara a perda dos dados levantados na partida. Outro problema é que cada partida possui o seu arquivo de eventos, isso obriga ao usuário ter que concatenar os arquivos das partidas que deseja analizar em conjunto, se algum erro acontecer neste processo, os dados serão perdidos ou corrompidos. A sintese de informações consiste basicamente na contagem de eventos por jogador, o que em geral não serve de muita ajuda para o técnico.

14 2.1.2 Solução: Scout Graph Existe uma aplicação nacional para a coleta de dados no scout, trata-se do software proprietário Scout Graph[9], para analise do programa foi utilizada uma versão gratuita. Antes do inicio da partida o usuário deve selecionar a modalidade esportiva, são suportadas 4 modalidades: futebol, basquete, vôlei e handball, e os eventos (passes caracteristicos da modalidade esportiva) que estarão presentes durante a marcação. O software consiste basicamente em uma tela com o desenho do campo da modalidade esportiva escolhida no menu anterior. A marcação de eventos ocorre da seguinte forma: 1 Selecionar uma posição do campo 2 Selecionar a equipe a que pertence o jogador que fez o passe 3 Selecionar o jogador que realizou o passe 4 Selecionar o evento pré configurado que carateriza o passe. A cada um dos passos acima é aberto um menu sobre o mouse, onde a opção é selecionada. A figura 2.4 mostra como o campo fica após a marcação de eventos. Ao marcar um evento no campo, um ícone característico para cada evento é inserido no campo(como pode ser observado na figura 2.4). É possível trocar este ícone pelo nome do jogador ou pelo nome do evento, onde o ícone continua na tela até o inicio de uma nova partida. Ao clicar no ícone do evento é aberta uma janela no canto superior esquerdo, que contém as informações do evento.

15 FIgura 2.4 : tela de marcação do Scout Graph [7] Existe uma funcionalidade em um menu localizado na barra superior da aplicação, onde é possível gerar relatórios estatísticos[12] das equipes que estão sendo observadas e relatórios individuais dos jogadores. Estes relatórios contem basicamente um soma da ocorrência dos eventos da partida. A aplicação Scout Graph [9] apresenta algumas deficiências, quanto a dinâmicidade para a coleta de informações, são necessárias quatro ações do usuário para a marcação de um único evento e a cada ação um menu é gerado, poluindo a tela. Este processo tende a ser muito desgastante para o usuário,pois em uma partida ocorrerem muitos eventos. Caso o jogador receba a bola num ponto A e se deslocar com ela até o ponto B, é necessário que sejam realizadas duas marcações, ou seja 8 ações para o usuário executar, 4 ações no ponto A e 4 ações no ponto B.

16 Outro problema apresentado na coleta é de ordem estética, uma vez inseridos os eventos continuam povoando o campo, considerando a dinâmicidade dos esportes coletivos como o futebol, esta política gera muita informação visual para o usuário e pode acabar atrapalhando a marcação de eventos. 2.1.3 Solução: OptaSports Data Scout Uma solução mais sofisticada e usando tecnologia web é o software da OptaSports Data Scout [7]. A aplicação também é proprietária, portanto analisamos algumas características apresentadas na página de divulgação da empresa. O objetivo da aplicação é prover uma síntese dos dados coletados aos clientes. Os dados são coletados das seguintes maneira : Observadores assistem a gravação de um jogo, a cada passe da bola a posição do passe é marcada na tela da aplicação de coleta de dados, que consiste basicamente em um desenho do campo. O vídeo de apresentação da parte estatística no site da empresa, leva a crer que os dados coletados são: jogador de origem, jogador de destino, posição em que ocorreu o passe (em relação a um plano cartesiano sobre o campo) e tempo de ocorrência. Estes dados são capturados e transferidos para um database central, onde é feita uma analise estatística, que é disponiblizada via web. Os usuários podem selecionar as informações sobre time e jogadores da modalidade esportiva de interesse. A análise estatística contém em alguns casos, o histórico inteiro da carreira de um jogador ou de um time. A aplicação provê dados de performance, que podem ser divididos por área de atuação, isto é, ataque, defesa, posição de ocorrência (lateral esquerda, meio de

17 campo, grande área), dados físicos dos jogadores, velocidade média e desempenho em determinadas áreas do campo. É possível também comparar jogadores de diferentes equipes e obter gráficos comparativos. 2.2 Ferramentas e Tecnologias A sessão 2.2.1, apresenta o conceito de HTML5, 2.2.2 PHP, o script que gera a pagina de html, 2.2.3 e 2.2.4 apresentam tecnologias utilizadas no front-end(scripts). Também apresentamos na sequência, rpc e web services, framework utilizado como base e ferramentas de banco de dados. 2.2.1 HTML5 (Hyper Text Markup Language) É uma linguagem de marcação hipertexto que é utilizada para desenvolver páginas web, é uma linguagem client-side ou seja roda no lado do cliente. A primeira versão do HTML surgiu quando Tim Berners-lee (Fisico britânico) precisou compartilhar com seus colegas de pesquisa ideias e trabalhos. Na época a internet não era muito difundida então, Tim teve que criar inclusive os protocolos associados ao HTTP. Foi bem aceito pela comunidade e logo ganhou atenção global. Desde então o HTML vem sendo melhorado e incrementado em diversas formas. Atualmente o HTML está na verão 5 e fornece uma serie de benefícios tais como manipulação de vídeo, imagens e desenhos. No contexto da aplicação, utilizamos uma característica especifica da versão 5 que é chamado de Canvas. Canvas proporciona o desenho em tempo real de diferentes formas. Essa funcionalidade foi empregada nos desenhos dos campos para as diferentes modalidades esportivas.

18 2.2.2 PHP Originalmente chamado de Personal Home Page surgiu em 1995,conhecida também como Hipertext Preprocessor, é uma linguagem de script que roda no lado do servidor. Esta linguagem é interpretada no servidor e gera código html dinâmicamente, além de servir como uma linguagem script de propósito geral.o web-service em nossa abordagem é escrito em php além do serviços por ele utilizados(chamados). 2.2.3 Javascript Javascript é uma linguagem interpretada pelo navegador do cliente, ou seja, é uma linguagem client-side. Seu objetivo é interar com o navegador do cliente por meio, da programação dirigida a eventos. É possível fazer com que uma ação seja disparada após o clique em determinada área da pagina web.possui tipagem dinâmica ou seja uma variável não precisa ser especificada explicitamente, podendo assumir tipos diferentes em partes distintas do código. 2.2.4 JQuery Jquery é um biblioteca javascript, sua primeira versão foi lançada em 2006. Seu objetivo é simplificar navegação na página html, lidar com programação dirigida a eventos e criações de plugins. Abaixo segue a diferença entre o código javascript e jquery, para acessar o valor da opção selecionada de um objeto <select> do HTML : Em Javasript puro: var e=document.getelementbyid( id_elemento ); e.options[e.selectedindex].value;

19 Em Jquery: $( #id_elemento :selected ).val() Comparando Jquery com Javascript puro, uma ação Jquery executa muitas tarefas, com menos linhas de código, por isso é mais simples e minimalista que o Javascript. 2.2.5 RPC e Web Service RPC[15], chamada de procedimento remoto, é usado para a comunicação de processos, geralmente entre computadores diferentes e ou redes diferentes. O programador não precisa se preocupar com detalhes, basta efetuar a chamada do procedimento, e o RPC faz todo o trabalho de achar o local correto onde o procedimento está implementado. A idéia do RPC é facilitar a chamada de procedimentos remotos, de tal forma que, para o programador não haja diferença entre procedimento local e remoto. O próprio RPC se encarrega de localizar o procedimento e transportar os dados necessários para a chamada e retorno, é amplamente utilizado em aplicações do tipo cliente-servidor na plataforma distribuida. Web service é um RPC para aplicações web, uma solução usada para garantir a independência da comunicação da aplicação. Há duas formas de implementar, usando REST ou SOAP. SOAP é um protocolo de RPC, e utilizamos esse protocolo para a chamada e transporte na interação com web service. O motivo da escolha deve-se ao fato de já existir bibliotecas padronizadas na linguagem utilizada para o desenvolvimento da aplicação (PHP). Web service permite que diferentes aplicações em diferentes linguagens possam interagir entre si, pelo fato que os dados são transportados em formato XML, que é

20 universal. Isso garante a eficiência e a dinamicidade de que os dados estejam disponíveis a qualquer um que tiver acesso a informação, independente de sua plataforma de origem. O objetivo principal do web service é realizar a comunicação da aplicação através da internet. Web service é bastante usado em comercio eletrônico, justamente pelo fato de padronizar a comunicação entre diferentes aplicações e plataformas. Basta ter a documentação disponivel da função que deseja chamar e qualquer um que tenha acesso pode realizar uma chamada a essa função passando os parametros necessários. A figura 2.5 abaixo, segue exemplo da documentação das funcões disponiveis no nosso servidor web: Figura 2.5: Documentação da função setjogador

21 A figura 2.5, é o resultado da documentação gerada pelo web service. Esta informação pode ser acessada pelo navegador, onde é possivel visualizar todas os serviços disponíveis e suas peculiaridades. Observando a função setjogada, pode-se notar que para utilizá-la, basta realizar uma chamada passando em XML os campos codpermissão, Jogador e Id do Cadastro. CodPermissão é um código enviado pelo servidor que autentica o usuário, composto por id do usuário e uma string codificada com uma validade apenas para a sessão corrente.tipo Jogador segue o mesmo padrão, basta olhar os detalhes descritos no campo documentação. Todas as funções são documentadas, para que o usuário chamador saiba exatamente o que passar ao chamar a função. 2.2.6 Framework Code Igniter Um Framework é um conjunto de bibliotecas que contém funções comuns. Estas funções garantem a agilidade ao desenvolvimento do projeto, ou seja, evita refazer a roda, deixando ao programador a preocupação de desenvolver realmente a aplicação e não se preocupar em desenvolver funções primitivas. CodeIgniter é um framework PHP. Foi lançado em 2006 e garante a aplicação do padrão MVC(modelo, visão e controle) e implementa principalmente segurança. Métodos de acesso a banco de dados, funções de apoio e bibliotecas ficam mais fácil de manipular com o uso do codeigniter. Existem vários frameworks em php, como pode ser visto na web¹, a escolha do codeigniter deu-se devido ao fato de disponibilizar uma ampla documentação e a adoção do padrão MVC, tornando fácil o uso e manutenção. Este framework foi a base para o desenvolvimento do código do sistema proposto. Sua escolha se deve ao fato de que possui uma ampla documentação[13] e os membros da equipe já estavam familiarizados com o framework. 1 existem varios frameworks php, a sua lista pode ser consultada no link: www.phpframeworks.com

22 2.2.7 Servidor Apache O apache é o servidor HTTP mais popular do mundo [10], seu desenvolvimento iniciou-se em 1995. Ele é mantido por uma comunidade de desenvolvedores sob a tutela da Apache Software Foundation. O nome Apache foi escolhido em respeito as nações nativo americanas coletivamente referenciadas como Apache, conhecidas por suas habilidades em estratégia no campo de batalha e sua resistência inesgotável[2]. Este nome serve também como trocadilho em um servidor web irregular, um servidor feito com uma série de patches (caminhos). Uma das vantagens do apache é a virtualização de hosts [11], dessa forma uma maquina pode ter mais de um domínio associado a ela e e todos eles compartilharem o mesmo servidor Apache e possuir suporte as mais variadas linguagens de programação dentre elas destaca-se o PHP, utilizada como linguagem de server-side em nossa abordagem. 2.2.8 MYSQL, SQL e PHPMYADMIN MYSQL [3] é um sistema de gerenciamento de banco de dados(sgbd) surgiu na década de 80, destaca-se pela sua facilidade de integração com o PHP e possui diversas características, tais como portabilidade, baixo consumo de recursos e bom desempenho no acesso ao dados. A linguagem de manipulação dos dados é SQL ( Linguagem de Consulta Estruturada), é padronizada na maioria dos banco de dados e foi originalmente criada nos laboratórios da IBM.[4] PHPMYADMIN [5], por sua vez, é uma aplicação web desenvolvida em PHP para facilitar a admistração do SGBD MYSQL. Apenas facilita a manipulação de um jeito mais amigável. Foi bem aceita pela comunidade que hoje em dia, a maioria dos sites de hospedagem web utiliza essa ferramentas como base para seus clientes.

23 Todas as funcionalidade básicas de nivel usuário-administrador é possivel ser manipulada, funcionalidades tais como: Criação de tabelas, consultas, inserção, criação de banco de dados, realização de backups e outros.

24 3 CONCEITUAÇÃO E IDÉIA GERAL A aplicação proposta se divide em dois módulos: 1. Scout 2. Administrador O módulo scout é responsavel pela captura de eventos, configurações de tempo da partida e configurações de dimensões do campo. Na figura 3.1 estão representados os caso de uso para um usuário em modo scout, as configurações de tempo e campo fazem parte do caso de uso gerenciar partida. Figura 3.1: Casos de uso do usuário em modo scout A figura 3.2 ilustra os casos de uso para o usuário em modo administrador, este modo resume-se em : gerenciar times : adicionar e remover jogadores de um time gerenciar jogador : adicionar e remover jogadores gerenciar jogo : remover jogos e visualizar a parte estatística

25 gerenciar eventos : configurar os passes do jogo Figura 3.2: Casos de uso do usuário em modo administrador 3.1 Conceitução da Infra-estrutura Para teste da aplicação proposta, desenvolvemos um servidor web, disponibilizado na plataforma unix, e gerenciado pelo servidor http APACHE. Um servidor WEB é responsável por aceitar requisições HTTP e respondê-las de acordo com cada pedido. Pode retornar ao cliente páginas inteiras como também fragmentos de dados, dependendo de cada situação. Num primeiro momento foi disponibilizado uma aplicação web como outra qualquer, isto é, sem a utilização de web service. Com o intuito de deixar a aplicação independente de qualquer linguagem, foi implementado o web service. Este por sua vez é basicamente uma camada a mais tanto no lado do cliente como também no servidor, que garante a dinamicidade da comunicação dos dados. Isso garante também a abertura a novos adendos à aplicação, usuários podem construir novas funcionalidades que comunicam-se com nossa aplicação. Essa troca de dados é traduzida para linguagem XML, dessa forma, padronizado de acordo com normas mundiais.

26 Nesse modelo, o cliente passa a conversar diretamente com a interface cliente, esse por sua vez traduz os comandos solicitados em XML e repassa para a interface do servidor, que faz o processo inverso, ou seja, traduz o XML para a linguagem adotada, no nosso caso o PHP. Figura 3.3: Fluxo da comunicação dos dados Na figura 3.3, mostramos a interação com o cliente e o servidor. O cliente envia sua requisição ao web service, por meio da tecnologia de comunicação JSON, o web service por sua vez traduz a requisição para XML e passa a mensagem traduzida ao servidor. O processo de comunicação entre o web service e cliente ocorre de forma contrária ou seja o web sercive recebe a resposta em XML do servidor e traduz a resposta para JSON e então envia a resposta ao cliente. Para o armazenamento dos dados, foi configurado um banco de dados relacional gerenciado pelo MYSQL, sendo SQL a linguagem para manipulação dos dados. Para o acesso fora da rede local, foi definido um DNS dinâmico, denominado: http://scoutapp.dyndns.org, para que a aplicação seja visível à usuários da internet.

27 3.2 Ideia Geral O trabalho foi desenvolvido em suma em HTML5, Javascript, JQuery e PHP. É composto basicamente em 2 módulos, modo scout e modo administrador. O modo Scout serve para realizar anotações e marcações, basicamente consiste em levantamento de dados.um membro da comissão fica em uma posição com a visão do jogo,anotando todos os passes e lances que ocorrem.essa analise é enviada ao servidor que processa os dados e gera dados estatísticos. No trabalho do Mayrhofer [1] podemos notar que a solução proposta ainda é complicada no ponto de vista do usuário. O usuário tem que interagir com o mouse e ficar carregando um notebook ou Desktop. A nossa proposta por sua vez, visa trazer facilidade, inovação e agilidade. Hoje em dia, HTML5 funciona em qualquer plataforma e em diferentes devices. A comissão técnica pode ficar proximo ao campo apenas com um tablet, smartphone, notebook, desktop, etc. Isso facilita a captação de dados e também o manuseio da aplicação. O usuário dessa forma consegue fazer anotações utilizando toques, sem a necessidade do uso do mouse, quando se tratando de aparelhos portáteis. Outro ponto chave é a analise estatística. Nos softwares citados no capítulo 2 com exceção da Opta[7], ocorre apenas uma contagem de eventos por jogador. Um gráfico de espalhamento com a posição da equipe durante a partida e a opção de comparar jogadores ou times seria de maior utilidade para a comissão técnica, porque proporciona uma análise visual e rápida.

28 4 Implementação da aplicação Na análise do capítulo 2, percebe-se que os sistemas de captação propostos [1][9], não são muito intuitivos ao usuário. Por isso implementamos em nosso trabalho uma interface mais amigável, ou seja, uma interface com menos menus temporários e de mais fácil manuseio, conforme pode ser observado na figura 4.1. O formato da interface foi projetado para que não haja poluição na tela do usuário e tenha todas as funcionalidades necessárias, i.e, jogadores e eventos. 4.1 Módulo Scout O processo da captação de eventos é de responsabilidade do módulo scout. Na figura 4.1, observa-se duas listas que descrevem a escalação de cada time. Tem-se uma visão mais limpa, eliminando menus desnecessários. Quanto a marcação de eventos, a lista de jogadas definidas só aparecem na tela, quando é realmente o momento de contabilizar um evento. Figura 4.1 Tela de Marcação de eventos

29 Para realizar uma marcação de evento, deve-se selecionar o jogador de interesse, selecionar no campo sua posição inicial e final. Quando isso ocorre, um menu com as opções de eventos é mostrado ao usuário conforme a figura 4.2. Observa-se que o jogador selecionado, em nosso exemplo André Luiz um nome fictício, teve suas posições marcadas no campo e só após isso o menu de eventos é apresentado, sendo esse processo automático. Figura 4.2 Tela de Marcação de eventos no momento da captura de um evento Após a captação do evento, será transmitido para o web-service uma mensagem no formato XML, com os seguintes campos:

30 Este formato pode ser observado na figura 4.3, contém alguns pontos chave: 1. codpermissao: código de liberação para o uso do web service. Esta permissão é adquirida quando o usuário loga no sistema e vale por 6 horas. Sem essa, a requisição é descartada. Detalhes podem ser vistos no apêndice A. 2. idcadastro: identificação do cadastro do usuário na aplicação. Isso garante que o ambiente do usuário seja único. 3. Jogadas: objeto que contém os dados que foram gerados, sendo eles: código do passe, tempo, time, hora, posições da ocorrência e jogador selecionado. Figura 4.3 Arquivo XML, que contém a marcação do evento selecionado na figura 4.2

31 O sistema aguarda o retorno do servidor, caso esse retorno não seja detectado, o mesmo pacote será re-enviado quando a conexão for restabelecida. 4.2 Módulo Administrador O módulo Administrador fornece ao usuário um espaço onde é possivel realizar configurações de times, jogadores e visualizar informações estatísticas. Nesse módulo, denomina-se usuário, o técnico, comissão técnica e ou responsável pela análise de desempenho do time. Os dados que foram enviados pelo módulo scout, são analisados e processados afim de ajudar o usuário a tomar decisões. Qualquer usuário com acesso ao sistema pode visualizar as informações sintetizadas. Essas informações podem ser acessadas em tempo real, ou seja, a medida que os dados são captados no módulo scout. A seguir será apresentado algumas telas e suas respectivas funções. Figura 4.4 Tela inicial do módulo administrador

32 O contato inicial com a administração do sistema é mostrado na figura 4.4. É possivel visualizar uma listagem na parte central com todos os jogos. Cada jogo pode ter 4 definições de status: 1. Pré-jogo: Indica que o jogo ainda não começou, está em fase de definições. 2. Pausado: Pausa da partida, bem como intervalo etc. 3. Finalizado: Jogo encerrado 4. Andamento: Jogo está ativo e o módulo scout está enviando informações. Na figura 4.4, temos 2 exemplos, um jogo em fase de definição e outro que já foi finalizado. Qualquer jogo na listagem com excessão de jogos com status pré-jogo, tem informações em formas de gráficos e tabelas para serem visualizadas. Basta selecionar o icone gráficos para ter acesso a essas informações. A figura 4.5, é o contato inicial para visualizar informações, note que foi destacado dois pontos chaves para obter a informação buscada. Figura 4.5 Visualisando informações.

33 A visualização das informações é dividida em duas partes: 1. Equipe: mostra dados que agrupam a equipe, bem como indicadores gerais. 2. Jogador: mostra informações específicas de desempenho do jogador. Para ilustrar, abordaremos apenas informações específicas do jogador. O acesso a informações específicas é mostrado na figura 4.6, 4.7 e 4.8. Figura 4.6 Tela inicial que agrupa informações do jogador específico. A figura 4.6 acima mostra um apanhado geral de toda a interação do jogador selecionado para a partida analisada.

34 A figura 4.7 e 4.8 mostra exemplos de indicadores. Esses foram 3 exemplos que implementamos para demostrar o funcionamento da aplicação, porém cabe a cada utilizador implementar indicadores que melhor atendam suas necessidades. A aplicação dispõe de um sistema de captação de eventos eficiente. Sintetizar esses dados para que possam ser geradas informações fica a critério do usuário. Figura 4.7 Indicativo de jogadas para o jogador específico. Os gráficos apresentados na figura 4.8, surgiram de uma necessidade apresentada por um clube de fubebol. Para o clube é importante ter informações sobre a área de atuação dos jogadores no campo. Dessa forma, foi desenvolvido um gráfico de espalhamento, onde é possível visualizar em que área do campo ocorre a maior concentração de determinado evento ou todos os eventos para um determinado jogador. Também é disponibilizado um gráfico de percentual de posse de bola, onde mostra em qual quadrante do campo o jogador teve mais atuação.

35 Figura 4.8 Indicativo de espalhamento e posse de bola para o jogador específico. Existem outras funcionalidades disponíveis no módulo administrador que não foram exemplificados neste capítulo. Toda a parte de definições de times e jogadores, podem ser acessadas a partir da tela inicial ( figura 4.4). Esta aplicação é possivel configurar diferentes esportes. Para demostração apresentamos a modalidade de futebol, mas é possivel utilizar o menu de configuração para alterar o esporte requerido. O apêndice A, detalha a implementação do sistema para quem tenha maior curiosidade sobre como foi implementado, entrando em detalhes de codificação.

36 5 Conclusão A proposta de aplicação apresentada teve como objetivo complementar a solução proposta pelo aluno Mayrhofer. O grande diferencial é a independência de plataforma que uma aplicação web permite e a camada de comunicação entre as partes do sistema, não existindo mais a necessidade de transportar um arquivo de texto para outro programa de análise estatística, ou marcar os dados do jogo em um papel como é feito atualmente. A análise da ferramenta desenvolvida pelo aluno, foi realizada através da leitura de seu trabalho escrito, uma vez que não conseguimos uma versão do software para teste. 5.1 Trabalhos Futuros Durante o desenvolvimento do software, notou-se a necessidade de um sistema que analisasse as informações coletadas e enumerasse possíveis cenários com o comportamento da equipe. A criação de um sistema de inteligência artificial com esta capacidade, dependeria de uma grande base dados da equipe e das equipes adversárias também. Aliado a uma análise estatística mais eficiente e completa, este sistema poderia auxiliar melhor a tomada de decisão da comissão técnica. Também, do ponto de vista de negócio, é importante investir em design, pois segundo Maeda [6] uma aplicação pode ser extremamente eficiente, mas se não contar com um bom designer, é bem provável que pouco usuários vão adotá-la, lógicamente uma interface mais amigável é um bônus para a evolução do projeto (IHC). Permitir que as informações apresentas pela interface do usuário seja exportada em diferentes formatos, como por exemplo: excel, csv, xml. Isso permite a análise na ferramenta que o usuário tem preferência. Atualmente apenas um observador pode marcar os eventos, logo a confiabilidade dos dados depende apenas de uma pessoa, para garantir uma confiabilidade melhor, mais de um observador seria necessário, acreditamos que 3 seria

37 o numero suficiente. É importante mencionar que o sistema não foi projetado para fornecer mais de uma conexão simultânea no modo scout, oque requer algoritmos de fusão de registros no servidor. Outro ponto interessante que foi observada em outra ferramenta similiar é a implementação de gráficos de espalhamentos, mostrando a maior concentração de determinada ação durante a partida.

38 6 Referências [1] Carlos Eduardo C Mayrhofer. Método para captação de dados para o futebol, disponivel em <http://www.inf.ufpr.br/bmuller/tg/tcc%20scout%20no%20futebol.pdf> Ultimo acesso em Outubro 2013. [2] Apache Software foundation, disponivel em <http://www.apache.org/> Ultimo acesso em Setembro 2013. [3] MYSQL, disponivel em < http://www.mysql.com/> Ultimo acesso em Setembro 2013. [4] SQL, Linguagem de Consulta Estruturada, disponivel em < http://www.w3schools.com/sql/ > Ultimo acesso em Setembro 2013. [5] PHPMYADMIN, admistração do SGBD, disponivel em < http://www.phpmyadmin.net/home_page/index.php > Ultimo acesso em Setembro 2013. [6] Maeda, disponivel em < http://www.amanha.com.br/marketing-internas/54-marketing-1/5294-para-maeda-o-que-importae-o-design-e-nao-a-tecnologia > Ultimo acesso em Setembro 2013. [7] Opta Sports, disponivel em < http://optasports.com/en/football-team-and-player-widget-showcase.aspx > Ultimo acesso em Outubro 2013. [8] Estrutura do HTML5, disponivel em < http://www.uxdesign.blog.br/padroes-web/html5/entendo-a-estrutura-e-asemantica-do-html5/ > Ultimo acesso em Setembro 2013. [9] Socut Graph, disponível em < http://www.sfwinfo.com.br/site/html/linkscout.htm >, Ultimo acesso em Novembro 2013 [10] Apache percentual de utilização no mundo, disponível em : < http://w3techs.com/technologies/details/wsapache/all/all> ultimo acesso em Novembro de 2013 [11] Virtualização de hosts Apache, disponivel em < http://httpd.apache.org/docs/2.2/vhosts/> ultimo acesso em Novembro de 2013 [12] Scout Graph, Exemplos de Relatórios, disponivel em < http://www.sfwinfo.com.br/site/html/scout/relatorio/scout.html > Ultimo acesso em Novembro 2013. [13] CodeIgniter Documentação, disponivel em <http://ellislab.com/codeigniter/user-guide/> Ultimo acesso em Novembro 2013. [14] w3school Tutoriais, disponivel em < http://www.w3schools.com/ > Ultimo acesso em Novembro 2013. [15] Andrew S. Tanenbaum. Computer Networks. 4º ed. Editora Campus, pag. 399-404

39 Apêndice A Detalhes da Implementação Este apêndice aborda detalhes de implementação para uma aplicação simples, que pode ser tomada de base para desenvolver mais funcionalidades, mostrando que é possivel ter um software grátis e de qualidade. O protótipo desenvolvido, possui duas partes separadas, denominadas de scout e administrador. A parte do scout, consiste na tela para geração dos dados, onde está presente os eventos, jogadores, times e um mapa do campo onde se pode fazer as marcações de inicio e fim de um evento. A parte do administrador, consiste em telas onde se pode verificar e analisar as jogadas contidas em cada jogo, ao vivo, ou seja, pode-se ver os dados ao mesmo tempo em que são gerados na parte de scout. Ainda na parte do administrador, pode-se fazer toda a administração dos times, jogadores e eventos, podendo-se criar, deletar ou alterar cada um destes. A seguir será visto com detalhes o funcionamento de cada uma das partes e como elas executam por baixo dos panos. Denomina-se controller o módulo responsável pela tomada de decisão do sistema. A.1 O HTML5 Começamos a desenvolver a aplicação em HTML 5 e Javascript. HTML 5 é relativamente fácil de entender. Tem muitos tutoriais e boms exemplos na internet para recorrer em caso de dúvida. A estrutura do HTML5 pode ser observado na figura A.1:

40 Figura A.1: Estrutura do HTML5 Na figura A.1 podemos notar algumas tags. O DOCTYPE referência no inglês o Document type Definition que é a definição do documento. Isso indica ao navegador ou broswer que o documento em questão é um HTML e o navegador vai ter que processar isso de alguma forma. A referência <html> indica o inicio de uma sequência de linhas codificadas em html.dentro da sessão <html>,temos dois elementos importantes: <head> e <body>. Head é onde colocamos informações referente ao cabeçalho e a página, tais como título, tipo de codificação, inclusão de CSS, inclusão de scripts e metadados. Body é a sessão onde vai todo o conteúdo da página em questão, conteudo que pode ser gerado dinâmicamente ou estático. No nosso trabalho integraremos o HTML com o PHP para gerar conteúdos dinâmicos dependendo também da interação do usuário. Visto como funciona a estrutura do HTML podemos citar a interface da aplicação de scout. A.2 Funcionalidade do módulo Scout A tela de scout é carregada logo após o login do usuário no sistema. Para ser carregada após o login é chamado uma função redirect('scout/main') nativa do codeigniter, passando como parâmetro o controller que deve ser acessado, o nome do

41 arquivo do controller e a função deste controller que deve ser executada (Obs.: quando a função não é especificada, o framework chama a função padrão 'index'). Com a função sendo executada, alguns dados são buscados através de funções definidas na biblioteca models e logo em seguida uma página é carregada, no caso, a tela principal do scout. No lado do cliente (Client Side) é executado uma série de scripts, para manter controle e confiabilidade dos dados anotados. A.2.1 Scripts de Controle Após a tela do scout ser carregada, alguns dados vindos do servidor são colocados em variáveis do tipo <input type= hidden > do html (Obs.: O type 'hidden', informa ao browser que interpreta o código html, que aquela variável <input> deve ficar invisível na tela), facilitando o uso desses dados por scripts de controles, jquery e javascript que são executados na página. Alguns desses scripts são executados logo após o carregamento da página para verificar se deve ser criado elementos html contendo os times e se o relógio deve ser configurado para um certo horário. Ambos foram implementados para manter o funcionamento após a queda de conexão e ou se a página é re-carregada. Caso o jogo carregado seja um pré-jogo (Obs.: Um jogo possui 4 estados: pré-jogo, andamento, pausado, finalizado), o script, comentado acima, carrega a tela de menu que será detalhada na próxima seção. Outros scripts são responsável por acionar o envio dos dados ao servidor, bem como restabelecer os dados em caso de perda de conexão. A.3 A interface do sistema A interface foi feita para ser bem simples, a fim de facilitar o uso e deixar a página leve. O primeiro contato com o software ocorre na pagina de login, caso autenticado, o usuário é redirecionado para o módulo desejado.

42 A figura A.1.2 mostra a página de login interpretada por um navegador WEB, e a figura A.1.3 uma parte do código correspondente em HTML para gerar o formulário apresentado. Figura A.1 1: Página de autênticação do usuário

43 Figura A.1 2: Código a ser interpretado pelo navegador WEB A.3.1 Interface do Módulo Scout e Funcionalidades Após autenticado, o módulo scout segue da mesma forma uma interface simples, sua tela é composto por um campo no formato futebol, onde o desenho pode ser configurado para diferentes esportes. A tela é dividida em 3 quadrantes mais 1 que indica o cabeçalho(figura 3.1). O primeiro indica o time da casa e seus jogadores, sendo possivel selecionar um dentre os times disponíveis, o segundo quadrante é o desenho do campo e o terceiro quadrante indica o time adversário. O cabeçalho oferece acesso ao menu e opção de inicio e fim de jogo, mostrando o timer com o tempo de jogo decorrido.

44 A tela de menu, pode ser acessada a qualquer momento durante ou antes de um jogo começar. O menu abrange 2 funcionalidades, sendo a primeira, a configuração do jogo e a segunda o cadastro e gerenciamento de times e jogadores. Na configuração do jogo, pode-se alterar o tipo do jogo (ex: futebol, handebol, vólei, tenis, basquete e futsal), as dimensões do campo (ex: largura e comprimento) e a duranção da partida. Quando ou dados são alterados, ou não, um script é disparado, enviando os dados ao servidor para salvá-los no banco de dados. Este esquema será detalhadamente explicado nas próximas seções Na tela principal, as principais funcionalidades são iniciar ou pausar o relógio, apagar um jogada, finalizar o jogo, fazer uma marcação. Ao iniciar o relógio, se o jogo está no estado de pré-jogo, seu estado mudará para andamento e o relógio começará a rodar se houver times escolhidos para jogar. Uma vez que o relógio estiver rodando, um script jquery será executado a cada três segundos, para enviar três dados ao servidor: o tempo corrente, o id do time A e o id do time B. Os dados enviados são salvos no banco de dados, para que caso a página for recarregada, os dados da partida não sejam perdidos. Toda vez que o jogo é pausado ou iniciado, é atualizado o estado do jogo no banco de dados. A funcionalidade de apagar um jogada, apenas apaga os marcadores do mapa e reseta algumas variaveis do javascript que contem informações da jogada marcada. Já a funcionalidade de finalizar o jogo, pode ser executada a qualquer momento do jogo. Quando esta é executada, um script jquery envia o estado de finalizado para o servidor, onde ocorre a atualização no banco de dados. Além deste script ser executado com o pressionamento do botão, o script também é executado quando o tempo de jogo atinge o tempo limite da partida. Após o termino uma confirmationbox nativa do javascript, espera uma interação do usuário

45 para saber se continua na página ou se redireciona para a parte do administrador para ver os resultados coletados. A.3.2 Interface do Módulo Administrador e Funcionalidades O módulo de administrador tem uma interface simples, mas que oferece informações em tempo real para a pessoa que está analisando. Sua interface inicial pode ser observada na figura 4.4. A tela é dividida em dois quadrantes, esquerda e centro. A tela esquerda contém um menu para gerenciamento de funcionalidades do sistema e o centro contém dados estatísticos gerados pelo módulo scout. Pode se observar uma lista de jogos, onde é possivel ver para cada jogo, estatísticas e gráficos. A.4 Dados Estatísticos no módulo Administrador O grande desafio é gerar informação que de fato possa a ser utilizado pela equipe técnica. Em uma reunião que participamos com um clube de futebol, foi levantado que dados de contagem ajudam, mas não trás grandes benefícios para a pessoa que está analisando. Então com isso em mente, o ideal é buscar mostrar ao usuário dados comparativos. Até este ponto apresentamos um sistema que permite um mecanismo de captação eficiente de dados. Com esses dados, pode-se extrair e sintetizar diferentes informações. Inicialmente construimos os modelos de exemplo para mostrar dados de contagem, porém no fim do projeto essa visão foi extendida para dados

46 comparativos.então, pode-se notar que o sistema mostra facilmente quantidade de jogadas por jogador, bem como quais as modalidades de passes que o jogador efetuou. Com isso é possivel a comissão técnica perceber em que lugar do campo ocorre maior perda de bola e planejar alguma estratégia para evitar isso. Distância de chute, posição inicial e final, também fica disponível para consulta. Comparar posse de bola por quadrante do campo, pode ser uma informação interessante, dessa forma implementamos também essa funcionalidade. Note que esses são apenas alguns exemplos do que pode ser feito.como foi levantado anteriormente, a massa de dados o sistema detém, basta decidir que informações são relevantes e então incrementar o software para mostrá-la. A.5 Comunicação dos Dados A comunicação dos dados consiste basicamente de 4 passos: Cliente ClientXML ServidorXML Servidor. A tradução para XML é necessária porque utilizamos webservices. O XML ajuda na padronização e garante que demais softwares possam conversar com o nosso através de mensagens XML. Nas próximas sessões entraremos em detalhes de como funciona o WebService e sua implementação, bem como o protocolo SOAP e o formato dos arquivos XML. A.5.1 Web Service O web service consiste em especificar uma função com seus parametros e registra-lá. Para verficar o que o Web Service disponibiliza, basta olhar a url da página gerada pelo WSDL.

47 WSDL (Web Service Description Language) é uma interface que tem como objetivo descrever o serviço prestado, informando a documentação da função e seus respectivos parâmetros. A.5.1.2 Criando o Servidor O primeiro passo para instânciar o servidor consiste em incluir a biblioteca NuSoap, que é responsável pelo transporte e configurar o nome do WSDL. require_once(apppath.'libraries/nusoap/nusoap'.ext); $this->server = new soap_server(); $this->server->configurewsdl("scouttransportlayer", "urn:scouttransportlayer"); Após isso, podemos definir na sequência tipos de dados, ou seja a estrutura que será utilizada na chamada das funções. Nesse caso, somente estruturas complexas, tipos básicos como um integer ou string não é necessário definir, apenas objetos complexos. A figura abaixo mostra um exemplo de definição de um tipo complexo. 16 $this->server->wsdl->addcomplextype( 17 "User", 18 "complextype", 19 "struct", 20 "all", 21 "", 22 array( 23 "iduser"=>array("name"=>"iduser", "type"=>"xsd:int"), 24 "idcad"=>array("name"=>"idcad", "type"=>"xsd:int"), 25 "codpermissao"=>array("name"=>"codpermissao", "type"=>"xsd:string") 26 ) 27 ); Na Figura acima, estamos definindo um tipo User, que é um objeto composto por três elementos, onde 2 deles são do tipo integer e um do tipo String.

48 Após todas as definições de tipos forem feitas, é necessário registrar a função que quero declarar no server. Se uma função não está registrada o servidor não reconhece e ninguém poderá acessá-la, mesma que a função tenha sido especificada. Note que para utilizar uma função é necessário 2 passos: o registro da função e sua declaração. Abaixo temos o exemplo de do código necessário para registrar a função setjogada. 363 $this->server->register( 364 'setjogada', 365 array( 366 "codpermissao" => "tns:user", 367 "idcadastro" => "xsd:int", 368 "jogada" => "tns:jogada" 369 ), 370 array( 371 "return" => "xsd:string" 372 ), 373 "urn:scouttransportlayer", 374 "urn:scouttransportlayer#setjogada", 375 "rpc", 376 "encoded", 377 "Escreve uma jogada no BD" 378 ); O Registro da função acima, utiliza dois tipos complexos, tipo User e Jogada, a documentação de ambas definições podem ser encontrada na pagina gerada pelo WSDL. No Registro definimos quais são as entradas e saídas que a função vai utilizar, e quando solicitada no web Service, qual função o servidor deve repassar os dados. A função a ser chamada é sempre precedida do simbolo #, no nosso trabalho para questão de padronização, utilizamos o mesmo nome do registro, mas poderia ser qualquer outro nome.

49 Após o registro vem a declaração da função, onde devemos escrever a função em si, programar o que ela deve fazer.abaixo temos um exemplo da declaração da função setjogada. 765 function setjogada($codpermissao,$idcadastro,$jogada){ 766 $ci =& get_instance(); 767 $ci->load->model(array("scout/jogadas_model","login_model")); 768 if($ci->login_model->verifypermition($codpermissao["iduser"],$idcadastro, $codpermissao["codpermissao"]) == "false") 769 return "errop"; 771 $result = $ci->jogadas_model->setnovajogada($jogada["jogadas"],$idcadastro); 772 return $result; 773 } A função realiza algum teste de permissão e então chama o model(padrão MVC) para realizar algumas operações. No servidor para a função descrita funcionar, está pronto. Agora temos que fazer a chamada no cliente. A.5.1.2 Criando o Cliente O Cliente segue o mesmo padrão, basta instanciá-lo e realizar a chamada das funções de acordo com seu respectivo registro no servidor. Para instânciar o cliente, temos que criar um objeto cliente, passando o endereço do webservice onde está registrado as funções que almejamos chamar. 72 $client = new nusoap_client("http://192.168.1.7/tg/server/f_generic"); Tendo em mãos todos os parametros necessários, efetuamos um call para o servidor solicitando o serviço. 86 $result=$client->call($func_call, $func_data,'urn:scouttransportlayer', 'urn:scouttransportlayer#'.$func_call);

50 No exemplo acima, basta carregar na variável $func_call o nome da função que queremos chamar, e em func_data, os dados no mesmo formato do registro. O formato e definições das respectivas funções podem ser visto na página gerada pelo WSDL, conforme exemplo abaixo. A.5.2 SOAP e NuSOAP SOAP (Simple Object Access Protocol) é um protocolo simples para troca de mensagens, onde visa independência da linguagem, transporte e modelo de objetos. NuSoap é um grupo de de classes PHP que nos permite criar e consumir Web Services utilizando o protocolo SOAP. Então, utilizamos as classes do NuSoap para realizar a interface entre XML e seu transporte com o protocolo SOAP. A.5.3 XML Vimos nós tópicos anteriores como criar uma função, registrá-la e chamá-la no cliente, mas não vimos como a mensagem trafega na rede.

51 Basicamente, antes de enviar a mensagem com os respectivos parâmetros, é feita uma tradução para XML. O responsável por essa tradução e o layout do XML está descrito nos arquivos dentro da biblioteca NuSOAP. Uma requisição da função setjogada é transportado da seguinte maneira em XML através do protocolo SOAP: Conforme percebemos pela registro da função no WSDL, o retorno é uma string e pode ser observado na imagem abaixo.

52 A.6 Segurança Para que o usuário tenha acesso as funcionalidades do sistema é necessário passar por dois níveis de autenticação: Login e código de permissão. O código de permissão foi criado para descartar conexões no web service, caso o usuário não seja autorizado. O Login autentica o usuário para usar a interface WEB do sistema, mas uma aplicação que gere uma requisição diretamente ao web Service é necessário ter um código criptografado para manipular os dados, caso contrario a conexão é descartada. Dessa forma, todo usuário que é autenticado com senha diretamente pelo interface web do sistema, automáticamente ganha um código de permissão temporário. Esse código é um código aleatório de uma sequência de números e em cima desse número é gerado uma codificação HASH de 128 bits(md5). Então toda conexão que chega no web service é verificado se o código para determinado usuário é valido, com o adicional de verificação de session verificando se o usuário está logado no sistema e tem um código de permissão válido. Isso garante que os dados de um determinado cadastro seja visível apenas pelo seu dono, evitando requisições mal intensionadas com o propósito de roubar dados estatísticos de determinada equipe. Abaixo temos um exemplo de código criptografado que é enviado em toda requisição XML, lembrando que esse código é variável, e perde validade a cada 6 horas. Exemplo de cód. de permissão criptografado(32x4=128bits): 21f71f43b9415783c13700d0a4087bee