universidade tecnolÓgica federal do paranÁ...

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ ESPECIALIZAÇÃO EM TECNOLOGIA JAVA E DESENVOLVIMENTO

PARA DISPOSITIVOS MÓVEIS

LEANDRO KIOSHI KIMURA

DESENVOLVIMENTO DE SOFTWARE GERENCIADOR DE PARTIDAS DE

FUTEBOL DIRECIONADO À ÁRBITROS

MONOGRAFIA DE ESPECIALIZAÇÃO

CURITIBA 2014

2

LEANDRO KIOSHI KIMURA

DESENVOLVIMENTO DE SOFTWARE GERENCIADOR DE PARTIDAS DE FUTEBOL DIRECIONADO À ÁRBITROS

Monografia de especialização apresentada ao Curso de Especialização em Tecnologia Java e Desenvolvimento para Dispositivos Móveis da Universidade Tecnológica Federal

do Paraná como requisito parcial para a obtenção do título de especialista.

Orientador: Prof. Msc. Josivan Pereira de Souza

CURITIBA

2014

3

AGRADECIMENTOS

Agradeço primeiramente à Deus por eu conseguir concluir o trabalho, e

segundo a minha esposa, Jaqueline, que sempre me apoiou durante todo o período

de desenvolvimento do projeto.

Agradeço também ao professor orientador, Josivan Pereira de Souza, que

sempre esteve disponível para esclarecer dúvidas referentes ao trabalho.

E por último, aos meus familiares, amigos e a todos aqueles que direta ou

indiretamente contribuíram para a realização do mesmo.

4

RESUMO

Este trabalho aborda o desenvolvimento de uma aplicação móvel para controle de

eventos realizados durante uma partida de futebol.

Atualmente, em uma partida de futebol os árbitros e membros da mesa arbitrária não

utilizam recursos computacionais em tempo real para marcações de eventos que

acontecem durante uma partida de futebol. Toda esta ação é conduzida

manualmente por ambos, sendo necessária a verificação cruzada das informações

entre árbitro e mesa, para a elaboração do documento oficial com o resultado final, a

súmula.

Assim sendo, foi desenvolvida uma solução computacional com o objetivo de

gerenciar toda a partida. Esta solução é direcionada à dispositivos móveis que

utilizam o sistema operacional Android.

Palavras-chaves: Partida. Futebol. Árbitro. Android. Dispositivos móveis. Interface

Web. Desenvolvimento mobile.

5

ABSTRACT

This work addresses the development of a mobile application for control of events

held during a football match.

Currently, in a football match referees and members of arbitrary table do not use

computing resources for real-time markings events that happen during a football

match. All this action is conducted manually by both the cross-checking of

information between referee and table, for the preparation of the official document

with the end result , a summary document.

Therefore, we developed a computational solution in order to manage the entire

match. This solution is targeted to mobile devices using the Android operating

system.

Keywords: Match. Football. Referee. Android. Mobile devices. Web interface. Mobile

development.

6

LISTA DE ABREVIATURAS E SIGLAS

ADT: Android Development Tools (Ferramentas de desenvolvimento Android).

APK: Android application package file.(Arquivo de pacote de aplicação Android).

DVM: Dalvik Virtual Machine (Máquina Virtual Dalvik).

GUI: Graphical User Interface (Interface Gráfica do Usuário).

HTTP: HyperText Transfer Protocol (Protocolo de Transferência de HiperTexto)

IDE: Integrated Development Environment (Ambiente Integrado de

Desenvolvimento).

JSON: JavaScript Object Notation (Notação de Objetos JavaScript).

NCSA: National Center for Supercomputing Applications (Centro Nacional de

aplicações para super computadores).

PHP: Personal Home Page (Página Pessoal).

SDK: Software Development Kit (Kit de Desenvolvimento de Software).

SGBD: Sistema Gerenciador de Banco de Dados.

SMS: Short Message Service (Serviço de mensagem curta)

RAD: Rapid Application Development (Desenvolvimento de aplicação rápida)

RDBMS: Relational Database Management System (Sistema de gerenciamento de

banco de dados relacional)

REST: Representation State Transfer (Técnica de Engenharia de Software usado

para sistemas Distribuídos).

SOAP: Simple Object Access Protocol ( Protocolo de acesso de objeto simples)

URI: Uniform Resource Identifier (Identificador Padrão de Recurso)

7

URL: Uniform Resource Locator (Localizador-Padrão de Recurso)

XML: eXtensible Markup Language (Linguagem de marcação extensivel)

8

LISTA DE FIGURAS

Figura 1 - Porcentagem de uso Android por versão. .................................................................... 14

Figura 2 - Ilustração de como uma Intent implícita é entregue por meio do sistema para

iniciar outra atividade. ........................................................................................................................ 17

Figura 3 - Arquitetura Android. ......................................................................................................... 19

Figura 4 - Exemplo de estrutura JSON. .......................................................................................... 23

Figura 5 - Exemplo de código PHP. ................................................................................................ 25

Figura 6 - Súmula da partida - 01. ................................................................................................... 33

Figura 7- Súmula da partida - 02. .................................................................................................... 34

Figura 8 - Imagens do aplicativo "I, Referee". ............................................................................... 36

Figura 9 - Imagens do aplicativo ―Referee Assistant‖. .................................................................. 37

Figura 10 - Imagens do aplicativo ―Whistle‖. .................................................................................. 37

Figura 11 - Diagrama de fluxo básico do aplicativo "Soccer Referee". ..................................... 41

Figura 12 - Diagrama de caso de uso do aplicativo Android ―Soccer Referee‖. ...................... 44

Figura 13 - Diagrama de caso de uso da aplicação Web. ........................................................... 44

Figura 14 - Diagrama de classe do aplicativo "Soccer Referee". ............................................... 45

Figura 15 - Modelagem de dados do aplicativo Android "Soccer Referee". ............................. 46

Figura 16 - Modelagem de dados da aplicação Web. .................................................................. 46

Figura 17 - Ícone "Soccer Referee". ................................................................................................ 47

Figura 18 - Splash Screen do aplicativo "Soccer Referee". ........................................................ 48

Figura 19 - Tela de Login do aplicativo "Soccer Referee". .......................................................... 48

Figura 20 - Tela principal do aplicativo "Soccer Referee". ........................................................... 49

Figura 21 - Tela de cronômetro do aplicativo "Soccer Referee". ................................................ 50

Figura 22 - Tela de cartão amarelo do aplicativo "Soccer Referee" . ........................................ 51

Figura 23 - Tela de cartão vermelho do aplicativo "Soccer Referee". ....................................... 52

Figura 24 - Tela de registro de gols do aplicativo "Soccer Referee". ......................................... 53

Figura 25 - Tela de substituição do aplicativo "Soccer Referee". ............................................... 54

Figura 26 - Tela de súmula do aplicativo "Soccer Referee". ....................................................... 55

Figura 27 - Tela de login da aplicação Web. .................................................................................. 56

Figura 28 - Tela de registro da aplicação Web. ............................................................................. 57

Figura 29 - Tela de consulta de partida. ......................................................................................... 58

Figura 30 - Tela de serviço JSON. .................................................................................................. 59

9

LISTA DE QUADROS E TABELAS

Tabela 1 - Comparação de aplicativos pesquisados e suas funcionalidades........................38

Tabela 2 – Comparativo entre funcionalidades dos aplicativos pesquisados........................61

10

SUMÁRIO

1. INTRODUÇÃO ............................................................................................................................ 13

1.1. JUSTIFICATIVA ..................................................................................................................... 13

1.2. OBJETIVOS ............................................................................................................................ 13

1.2.1. Objetivo Geral ................................................................................................................... 13

1.2.2. Objetivo Específico .......................................................................................................... 13

1.3. METODOLOGIA ..................................................................................................................... 14

1.4. APRESENTAÇÃO ................................................................................................................. 15

2. REVISÃO DA LITERATURA ................................................................................................... 16

2.1. SISTEMA OPERACIONAL ANDROID ............................................................................... 16

2.1.1. R.java ................................................................................................................................... 16

2.1.2. Activities ............................................................................................................................. 16

2.1.3. Intents .................................................................................................................................. 17

2.1.4. Fragments .......................................................................................................................... 18

2.1.5. Layout .................................................................................................................................. 18

2.2. ARQUITETURA ANDROID .................................................................................................. 19

2.3. GOOGLE PLAY...................................................................................................................... 20

2.4. SQLITE .................................................................................................................................... 21

2.5. WEB SERVICES .................................................................................................................... 21

2.6. FORMATO JSON DE MENSAGENS ................................................................................. 22

2.7. ARQUITETURA REST .......................................................................................................... 23

2.8. IDE ECLIPSE .......................................................................................................................... 24

2.9. ANDROID SDK ....................................................................................................................... 24

2.10. INTERNACIONALIZAÇÃO .............................................................................................. 25

2.11. LINGUAGEM DE PROGRAMAÇÃO PHP ..................................................................... 25

2.12. SERVIDOR APACHE ........................................................................................................ 26

2.13. CONSIDERAÇÕES FINAIS DESTE CAPÍTULO ......................................................... 26

3. FUTEBOL .................................................................................................................................... 27

3.1. HISTÓRIA DO FUTEBOL ..................................................................................................... 27

3.2. O INÍCIO .................................................................................................................................. 27

3.3. SÍNTESE DO FUTEBOL ....................................................................................................... 28

3.4. REGRAS DO FUTEBOL DE CAMPO ................................................................................ 29

11

3.4.1. O campo de futebol.......................................................................................................... 29

3.4.2. Dimensões de campo de futebol .................................................................................. 29

3.4.3. Dimensões do gol ............................................................................................................ 29

3.4.4. A bola de futebol .............................................................................................................. 30

3.4.5. Os jogadores ..................................................................................................................... 30

3.4.6. Equipamentos dos jogadores ....................................................................................... 30

3.4.7. O árbitro de futebol .......................................................................................................... 30

3.4.8. Duração da partida ........................................................................................................... 31

3.4.9. Impedimento ...................................................................................................................... 31

3.4.10. Faltas ............................................................................................................................... 31

3.4.11. Cartões ............................................................................................................................ 31

3.4.12. Arremesso lateral ......................................................................................................... 32

3.4.13. Tiro de meta ................................................................................................................... 32

3.4.14. Escanteio ........................................................................................................................ 32

3.4.15. O vencedor ..................................................................................................................... 32

3.5. SÚMULA .................................................................................................................................. 32

3.6. CONSIDERAÇÕES FINAIS SOBRE O FUTEBOL .......................................................... 35

4. TRABALHOS CORRELATOS ................................................................................................. 36

4.1. APLICATIVO “I, REFEREE” ............................................................................................... 36

4.2. APLICATIVO “REFEREE ASSISTANCE” ........................................................................ 36

4.3. APLICATIVO “WHISTLE” .................................................................................................... 37

4.4. CONSIDERAÇÕES FINAIS DESTE CAPÍTULO ............................................................. 38

5. SISTEMA DE GERENCIAMENTO DE PARTIDAS DE FUTEBOL ................................... 40

5.1. ARQUITETURA ...................................................................................................................... 40

5.2. REQUISITOS FUNCIONAIS ................................................................................................ 41

5.2.1. Logar no Sistema ............................................................................................................. 41

5.2.2. Registrar Infrações .......................................................................................................... 41

5.2.3. Remover Infrações ........................................................................................................... 41

5.2.4. Controlar tempo de partida ............................................................................................ 42

5.2.5. Registrar pontuação ........................................................................................................ 42

5.2.6. Remover pontuação ........................................................................................................ 42

5.2.7. Carregar dados da súmula ............................................................................................ 42

5.3. REQUISITOS NÃO-FUNCIONAIS ...................................................................................... 42

5.3.1. Requisito não funcional 01 ............................................................................................ 42

12






5.4. DIAGRAMA DE CASO DE USO ......................................................................................... 43

5.5. DIAGRAMA DE CLASSES .................................................................................................. 45

5.6. DIAGRAMA DE MODELAGEM DE DADOS ..................................................................... 45

5.7. FUNCIONAMENTO DO SISTEMA ..................................................................................... 47

5.8. INTERFACE DO APLICATIVO ANDROID ........................................................................ 47

5.8.1. Ícone .................................................................................................................................... 47

5.8.2. Tela de apresentação ...................................................................................................... 47

5.8.3. Tela de login ...................................................................................................................... 48

5.8.4. Tela principal ..................................................................................................................... 49

5.8.5. Tela de cronômetro .......................................................................................................... 49

5.8.6. Tela de cartão amarelo.................................................................................................... 50

5.8.7. Tela de cartão vermelho ................................................................................................. 51

5.8.8. Tela de gol .......................................................................................................................... 52

5.8.9. Tela de substituição ........................................................................................................ 53

5.8.10. Tela de súmula .............................................................................................................. 54

5.9. INTERFACE WEB.................................................................................................................. 55

5.9.1. Tela de login da aplicação Web. ................................................................................... 56

5.9.2. Tela de registro de dados da aplicação Web. ........................................................... 56

5.9.3. Tela de consulta da aplicação Web. ............................................................................ 57

5.9.4. Tela de serviço JSON da aplicação Web. .................................................................. 58

5.10. CONSIDERAÇÕES FINAIS ............................................................................................. 60

6. CONCLUSÃO ............................................................................................................................. 61

6.1. TRABALHOS FUTUROS ..................................................................................................... 62

6.2. APLICAÇÃO MOBILE .......................................................................................................... 62

6.3. APLICAÇÃO WEB ................................................................................................................. 62

6.4. OUTROS DISPOSITIVOS .................................................................................................... 63

7. REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................... 64

13

1. INTRODUÇÃO

O presente trabalho destaca a importância da utilização de ferramentas de

controle de partidas de futebol, com foco em estudo de automatização de processos

que hoje são feitos manualmente, auxiliando árbitros e membros de arbitragem.

Os eventos ocorridos durante uma partida de futebol, tais como cartões amarelos

e vermelhos, substituições de jogadores e registro de gols, serão coletados em

tempo real por meio do aplicativo, tanto pelo árbitro quanto pela mesa arbitrária, e

no final da partida será gerada a súmula de jogo contendo todas as informações

coletadas.

1.1. JUSTIFICATIVA

O conceito deste software surgiu de um interesse na área esportiva,

especificamente na prática do futebol. Por meio da participação em campeonatos, foi

observada a necessidade da automatização do processo que atualmente é feito de

forma manual, o que pode resultar em falhas no processo, beneficiando ou

prejudicando equipes pela divergência dos dados.

1.2. OBJETIVOS

1.2.1. Objetivo Geral

O objetivo geral é automatizar o processo de controle de partidas de futebol.

1.2.2. Objetivo Específico

Como objetivos específicos temos :

a criação de uma GUI (Graphical User Interface) para o sistema operacional

Android, para que o usuário possa manusear o software desenvolvido.

14

Além disso:

Pode ser gerado um relatório final, chamado de súmula, para que as partidas

sejam devidamente registradas, assinadas e arquivadas pelas partes

interessadas.

1.3. METODOLOGIA

O presente projeto baseia-se em pesquisas inter-pessoais junto a árbitros e

membros de arbitragem, os quais mostraram interesse na automatização dos

processos de registro de eventos ocorridos durante uma partida de futebol, que

atualmente é feito de forma manual.

Para o desenvolvimento do aplicativo foi utilizado o ambiente de desenvolvimento

Eclipse, com plugin SDK (Software Development Kit) , que possue as bibliotecas

necessárias para desenvolvimento, depuração e teste de aplicações a serem

executadas no sistema operacional Android. O software foi desenvolvido para ser

aplicado na versão 4.1 ou superior, pois conforme Figura 1, é a versão que possui o

maior número de dispositivos ativos. A implementação foi testada no aparelho

Motorola Razr i XT890.

Figura 1 - Porcentagem de uso Android por versão.

Fonte: Android Developer, 2014.

Para o armazenamento de dados foi utilizado o Sistema Gerenciador de Banco

de Dados (SGBD) SQLite, por ser um SGBD Open Source.

15

E por fim, para o consumo de informações foi utilizado JSON como forma de

recuperar os dados por meio de um servidor, com o objetivo de popular os campos

da súmula e disponibilizá-la para a equipe de arbitragem, por ser um web-service de

fácil manutenção e eficiente.

1.4. APRESENTAÇÃO

Este trabalho está dividido em seis capítulos. No Capítulo 1 está a introdução

que apresenta a justificativa e os objetivos gerais e específicos. Também, está

presente, a metodologia aplicada, de maneira resumida, e a organização geral do

trabalho.

No Capítulo 2, está a revisão das literaturas das tecnologias móveis e sua

relevância nos dias atuais.

Seguindo no Capítulo 3, é apresentada as diversas tecnologias e ferramentas

utilizadas neste trabalho, incluindo o ambiente de desenvolvimento, banco de dados

e web services, e também o kit de desenvolvimento Android SDK, que foram

utilizados no desenvolvimento do aplicativo Android.

No Capítulo 4 são apresentados alguns aplicativos móveis que estão

relacionados à área esportiva, especificamente o futebol.

Finalmente, no Capítulo 5 é apresentada a solução desenvolvida, e a

metodologia aplicada, assim como a arquitetura, interfaces da aplicação e suas

funcionalidades.

Por último, no Capítulo 6 está presente a conclusão, sendo apresentado os

principais resultados e as possibilidades de trabalhos futuros relacionados.

16

2. REVISÃO DA LITERATURA

Este capítulo descreve a revisão da literatura, para as tecnologias utilizadas para

o desenvolvimento do software, os quais serão descritos nas seguintes seções:

2.1. SISTEMA OPERACIONAL ANDROID

O Android é um sistema operacional para dispositivos móveis do Google,

baseado em uma plataforma de código aberto, no qual permite que os fabricantes de

smartphones ou aparelhos que possuam sistema operacional Android, modifiquem

seu código fonte, dando a liberdade para que novos recursos sejam implementados

constantesmente. O sistema operacional Android está disponível em mais de 190

países ao redor do mundo. É a maior base instalada de qualquer plataforma móvel e

a cada dia mais de um milhão de usuários ligam seus dispositivos para utilizarem

aplicativos, jogos e outros conteúdos digitais. O sistema operacional Android é

composto de vários artefatos que fazem parte da arquitetura do sistema

operacional. Dentre estes artefatos existem alguns que estão explicitamente ligados

ao desenvolvimento. Em relação aos itens usados para o desenvolvimento, temos a

classe R.java. [ANDROID DEVELOPERS,2014].

2.1.1. R.java

A classe R.java é um arquivo gerado automaticamente ao criar um aplicativo

Android. Ela contém identificadores únicos (números normalmente de 32 bits) para

elementos em cada categoria (drawable, string, layout, color, etc) de recursos

(elementos sob o diretório res) disponíveis em sua aplicação android. O principal

objetivo do arquivo R.java é a acessibilidade rápida de recursos no projeto. Se

qualquer recurso tenha sido removido ou adicionado ao projeto, o arquivo R.java

será atualizado automaticamente, isto pode ser feito por meio do plugin ADT no

Eclipse. Outro artefato relacionado ao desenvolvimento é a Activity. [ANDROID

DEVELOPERS,2014]

2.1.2. Activities

Uma Activity é um componente de aplicação que fornece ao usuário uma tela

na qual o usuário pode interagir, sendo discando, enviando e-mail, visualizando

17

fotos, entre outros. Uma aplicação geralmente consiste em uma relação de várias

Activities, tendo em vista que cada Activity pode acionar uma próxima Activity

preservando a atividade em uma pilha. Outro artefato não menos importante é o

Intent. [ANDROID DEVELOPERS,2014]

2.1.3. Intents

As Intents representam uma ação que a aplicação deseja executar, ou seja, a

intenção da aplicação realizar determinada tarefa. Pode-se utilizar uma Intent para

abrir uma nova tela da aplicação, interceptar mensagens de SMS (Short Message

Service), abrir o browser em uma determinada URL, entre outras, conforme Figura

2.

Figura 2 - Ilustração de como uma Intent implícita é entregue por meio do sistema para iniciar outra atividade.

Fonte: ANDROID DEVELOPER, 2014.

A Atividade A cria uma Intent com uma descrição da ação e passa para

startActivity (). [2] O sistema Android pesquisa todos os aplicativos para um filtro da

Intent que coincide com outra Intent. Quando for encontrada uma correspondência,

[3] o sistema inicia a atividade de correspondência (Atividade B) invocando o método

onCreate () e passando-a Intent. [ANDROID DEVELOPERS,2014]

O método startActivity(Intent intent) envia dados e requisições de telas, o

método getIntent() recupera uma intent enviada por meio do startActivity(), o método

putExtra(―chave‖, valor) insere na Intent algum valor, ou seja, o primeiro parâmetro é

18

um nome para que possa ser identificado mais tarde e o segundo parâmetro um

valor que pode ser String, boolean, int, float, etc. O getStringExtra(―chave‖) pode

recurar, por exemplo, uma String inserido na Intent por meio do putExtra(―chave‖,

valor).

O conceito de chave-valor é utilizado por meio da interface Map, que não

estende a interface Collection, em vez disso, tem sua própria hierarquia de interfaces

e classes que são utilizadas para gerenciar associações entre chaves e elementos.

[MENDES, 2011]

2.1.4. Fragments

Um Fragment representa um comportamento de uma parte da interface de

usuário em uma atividade. Permite combinar múltiplos fragmentos em uma única

atividade para construir uma interface de usuário e reutilizar um fragmento em

múltiplas atividades . Permite pensar em um fragmento como uma seção modular de

uma atividade, que tem seu próprio ciclo de vida, recebe os seus próprios eventos

de entrada, e que você pode adicionar ou remover enquanto a atividade está em

execução (como uma espécie de "sub atividade", que permite reutilizar em diferentes

atividades) . [ANDROID DEVELOPERS,2014]

2.1.5. Layout

Um layout define a estrutura visual para a interface do usuário, tais como a

interface do usuário para uma atividade ou widget (programas leves, na maioria das

vezes que se tornam ―atalhos‖ para serviços e utilidades) do aplicativo . No Android

é possível declarar um layout de duas maneiras: a primeira é por meio de XML que

corresponde à visão de classes e subclasses, tais como os de widgets e layouts. A

outra forma é instanciando os elementos em tempo de execução, no qual o

aplicativo cria seus Views e ViewGroup e manipula suas propriedades de

programação. [ANDROID DEVELOPERS,2014]

19

2.2. ARQUITETURA ANDROID

O sistema operacional Android, foi desenvolvido com base no kernel do Linux.

Pode-se dividir esta arquitetura em 4 níveis ou camadas, conforme Figura 3:

Figura 3 - Arquitetura Android.

Fonte: ANDROID DEVELOPERS, 2014.

Na primeira camada, está a base da pilha, ou seja, o Kernel. Nesta mesma

camada encontramos os programas de gerenciamento de memória, configurações

de segurança e vários drivers de hardware. Em seguida, estão as camadas de

bibliotecas (Libraries) e tempo de execução (Android Runtime). A primeira é um

conjunto de instruções que dizem ao dispositivo como lidar com diferentes tipos de

dados, incluindo um conjunto de biblioteca C / C++ usadas por diversos

componentes do sistema e são expostas a desenvolvedores por meio da estrutura

de aplicativo Android. Já a camada de tempo de execução inclui um conjunto de

bibliotecas do núcleo Java (Core Libraries) [ANDROID DEVELOPERS,2014].

20

Para desenvolver aplicações para o Android, os programadores utilizam a

linguagem de programação Java, nesta camada encontraremos a Máquina Virtual

Dalvik (DVM), que é muito importante por algumas razões: as aplicações são

independentes, ou seja, caso alguma aplicação deixe de funcionar corretamente,

não afetará as demais simplificando assim o gerenciamento de memória. A próxima

camada é a camada de framework da aplicação (Application Framework), que é a

primeira camada que os desenvolvedores tem acesso, tendo disponível um conjunto

de artefatos básicos com o qual poderão construir artefatos mais complexos. E por

fim, na última camada, está a camada de aplicação, por meio da interação entre o

usuário e o dispositivo móvel, o qual encontram-se diversos aplicativos como de e-

mail, SMS (Short Message Service), calendário, mapas, navegador, contatos entre

outros.

Para o armazenamento de aplicativos Android há várias lojas, dentre elas, a loja

oficial é o Google Play que será visto a seguir.

2.3. GOOGLE PLAY

Google Play Store é a loja oficial do Android, na qual estão disponíveis diversos

os aplicativos destinados à plataforma. Conhecida anteriormente como Android

Market, vários aplicativos estão na loja como jogos, redes sociais, mensageiros,

corporativo, entretenimento, navegadores, segurança e fotografia, além da venda e

aluguel de filmes online e livros digitais.

O serviço permite a instalação de aplicativos remotamente, atualizar

automaticamente, avaliar e comentar sobre os aplicativos e sugere novos títulos com

base nas suas preferencias de aplicativos e jogos. A loja permite ao usuário

personalizar sua experiência de leitura, compartilhar livros e encontrar diversos e-

books do mundo ou assistir aos seus filmes favoritos.

A sincronização na nuvem possibilita que o conteúdo esteja disponível na Web e

em seus dispositivos Android. Em artigo, Steve Caniano, 2013, fala sobre a

evolução da cloud móvel e o impacto em aplicativos e profissionais de tecnologia. ―A

crescente adoção de aplicativos como serviço impacta o gasto de capital. Embora

não seja um jogo de compensações de perdas e ganhos, já estamos vendo os

avanços que a computação em nuvem está fazendo em relação aos gastos de

21

capital alocados à infraestrutura tradicional de TI. As empresas estão seriamente

considerando a compra de serviços sob demanda no lugar da compra de

equipamentos físicos (ex: servidores, racks, switches de rede, PCs), de licenças de

software e de contratos de manutenção. Esta mudança não se limita somente às

nuvens públicas, mas também às privadas, com um número crescente de empresas

preferindo pagar por X-as-a-service na forma de um serviço sob demanda, em seus

próprios centros de dados ou nos de um provedor. Isso pode ser resumido como

uma tendência rumo a um modelo de negocio que favorece despesas incorridas com

operações ao invés de gastos de capital. Reciprocamente, fornecedores de serviços

de nuvem estão se tornando grandes clientes de fornecedores de hardware e

software.‖ [CANIANO, 2013].

2.4. SQLITE

O SQLite, é uma base de dados leve e poderosa, que cada dia mais se

populariza na comunidade de TI, principalmente para desenvolvedores de aplicativos

móveis, devido sua leveza e perfomance que estão entre os requisítos para este tipo

de dispositivos. O SQLite foi desenvolvido em linguagem C, que implementa um

amplo subconjunto do standard SQL 92, sendo a sua reputação proveniente da

combinação do motor de base de dados com a interface dentro de uma única

biblioteca. As aplicações que usam SQLite podem ter assim acesso a uma base de

dados racional SQL, sem a necessidade de correrem processos RDBMS (relational

database management system) em separado e sem grandes overheads. O SQLite

foi desenvolvido em 2000 e é atualmente uma base de dados amplamente adoptada

em dispositivos móveis, suportando até 2 TB de dados [LECHETA, 2013 ].

2.5. WEB SERVICES

O objetivo do uso de Web Service é expor uma aplicação como um serviço para

clientes na Web, independentemente da aplicação do cliente e seu ambiente de

execução. Uma das características mais importantes de um Web Service é a

interoperabilidade, significando um menor acoplamento dos serviços, que permite

que máquinas e usuários de sistemas distribuídos sejam fundamentalmente

independentes e ainda interajam de forma limitada quando isto for necessário.

[NETO, 2006].

22

Um Web Service é considerado também uma aplicação de software, que

identificado por uma URI, cuja interface e atribuição são definidas, descritas e

descobertas por meio de artefatos XML o qual suporta interação direta com outras

aplicações de software utilizando mensagens XML via internet . [NETO, 2006]

Os Web Services usam os protocolos padrões, como HTTP, XML e SOAP, este

último sendo cada vez mais aceito como o padrão básico para a troca de

informações utilizando a internet.

2.6. FORMATO JSON DE MENSAGENS

JSON (JavaScript Object Notation - Notação de Objetos JavaScript) é uma

formatação leve de troca de dados. Para seres humanos, é fácil de ler e escrever.

Para máquinas, é fácil de interpretar e gerar. Está baseado em um subconjunto da

linguagem de programação JavaScript, Standard ECMA-262 3a Edição -Dezembro -

1999. JSON é em formato texto e completamente independente de linguagem, pois

usa convenções que são interpretáveis às linguagens C e familiares, incluindo C++,

C#, Java, JavaScript, Perl, Python e muitas outras. Estas propriedades fazem com

que JSON seja um formato ideal de troca de dados. [JSON, 2014].

JSON está constituído em duas estruturas:

Uma coleção de pares nome/valor. Em várias linguagens, isto é caracterizado

como um object, record, struct, dicionário, hash table, keyed list, ou arrays

associativas.

Uma lista ordenada de valores. Na maioria das linguagens, isto é caracterizado

como uma array, vetor, lista ou sequência.

Estas são estruturas de dados universais. Virtualmente todas as linguagens de

programação modernas as suportam, de uma forma ou de outra. É aceitavel que um

formato de troca de dados que seja independente de linguagem de programação se

baseie nestas estruturas.

Em JSON, os dados são apresentados desta forma:

Um objeto é um conjunto desordenado de pares nome/valor. Um objeto começa

com { (chave de abertura) e termina com } (chave de fechamento). Cada nome é

23

seguido por : (dois pontos) e os pares nome/valor são seguidos por ―,‖ (vírgula).

[JSON, 2014].

Exemplo, conforme Figura 4, para criar um menu baseado nas informações

disponibilizadas por meio do formato JSON:

{"menu": {

"id": "arquivo",

"value": "Arquivo",

"popup": {

"menuitem": [

{"value": "Novo", "onclick": "CreateNewDoc()"},

{"value": "Abrir", "onclick": "OpenDoc()"},

{"value": "Fechar", "onclick": "CloseDoc()"}

]

}

}

}

Figura 4 - Exemplo de estrutura JSON.

Fonte: JSON.ORG, 2014.

2.7. ARQUITETURA REST

REST é um acrônimo para "Transferência de Estado Representacional"

(Representational State Transfer). O termo REST foi defenido por Roy Fielding em

sua tese de doutorado no qual ele descreve um estilo de arquitetura de software

sobre um sistema operado em rede.

24

REST nada mais é que um conjunto de princípios que definem como Web

Standards como HTTP e URIs devem ser usados (o que freqüentemente difere um

pouco do que muitos atualmente fazem). A promessa é que se for aderido os

princípios REST enquanto estiver desenhando sua aplicação, se tenha um sistema

que explora a arquitetura da Web e seu benefício.

2.8. IDE ECLIPSE

O Eclipse é um IDE (Integrated Development Environment) conhecido mais

comumente para desenvolvimento em Java, no entanto, por meio de plug-ins, ele

pode ser usado para desenvolver aplicações em várias linguagens, como C/C++,

Python, PHP e inclusive para a plataforma Android [DEVMEDIA ECLIPSE, 2014].

Diferente de uma RAD, na qual o objetivo é desenvolver o mais rápido possível

utilizando o arrastar-e-soltar do mouse, gerando muitos códigos automaticamente;

uma IDE que auxilia no desenvolvimento, de maneira não intrusiva [CAELUM, 2014].

2.9. ANDROID SDK

O Android SDK (Software Development Kit) fornece as bibliotecas de API e as

ferramentas necessárias para construir, desenvolver, testar e depurar aplicativos

para o Android. Sempre que o Google lança uma nova versão do Android, um SDK

correspondente também é lançado. Sendo assim, o desenvolvedor que pretende

usufruir dos últimos recursos da versão lançada, deve baixar e instalar o SDK para

cada versão em particular [ANDROID SDK, 2014].

As aplicações Android são escritas em linguagem de programação Java, portanto

as ferramentas do Android SDK compilam o código, e após reunir todos os arquivos

associados, geram um arquivo .apk. Este arquivo com extensão apk é uma

aplicação que pode ser instalada em qualquer dispositivo executando sistema

operacional Android. Outra funcionalidade importante é o SDK Manager que permite

efetuar download dos pacotes de ferramentas necessárias para desenvolver os

aplicativos [ANDROID DEVELOPER, 2014].

25

2.10. INTERNACIONALIZAÇÃO

A internacionalização de software cria, em um aplicativo, suporte a várias

localidades, na qual a localidade (locale) significa ―[um] subconjunto de ambiente de

usuários que define convenções para uma cultura específica‖, geralmente incluindo

o idioma. [IBM, 2014]

Internacionalização e localização, em informática, são processos de

desenvolvimento e/ou adaptação de um produto, em geral softwares de

computadores, para uma língua e cultura de um país. A internacionalização de um

produto não fabrica o produto novamente, somente adapta as mensagens do

sistema à língua e à cultura locais. Isto é importante porque permite que o

desenvolvedor de software respeite as particularidades de cada língua e cultura de

cada país. [IMASTERS, 2014].

2.11. LINGUAGEM DE PROGRAMAÇÃO PHP

PHP (um acrônimo recursivo para PHP: Hypertext Preprocessor) é uma

linguagem de script open source de uso geral, muito utilizada e especialmente

guarnecida para o desenvolvimento de aplicações Web embútivel dentro do HTML.

[PHP.NET, 2014]

Por ser uma linguagem simples e rápida, o PHP é capaz de satisfazer as

necessidades de programadores iniciantes e até mesmo ser sofisticado o bastante

para satisfazer as necessidades de programadores profissionais.

Na Figura 5, será apresentado um código na linguagem de programação PHP:

<?php

echo "Olá, Eu sou um script PHP!";

?>

Figura 5 - Exemplo de código PHP.

Fonte: PHP.NET, 2014.

26

Este pedaço de código apresenta ao usuário a mensagem ―Olá, Eu sou um script

PHP!‖. E a vantagem é que este pedaço de código pode ser inserido junto ao código

HTML, facilitando a implentação de diversas funcionalidades.

2.12. SERVIDOR APACHE

O servidor Apache (ou Servidor HTTP Apache, em inglês: Apache HTTP Server,

ou simplesmente: Apache) é o mais bem sucedido servidor web livre. Foi criado em

1995 por Rob McCool, então funcionário do NCSA (National Center for

Supercomputing Applications). [APACHE HTTP, 2014].

É a principal tecnologia da Apache Software Foundation, responsável por mais

de uma dezena de projetos envolvendo tecnologias de transmissão via web,

processamento de dados e execução de aplicativos distribuídos. [APACHE

FOUNDATION, 2014].

Suas funcionalidades são mantidas por meio de uma estrutura de módulos,

permitindo inclusive que o usuário escreva seus próprios módulos — utilizando a API

do software.

É disponibilizado em versões para os sistemas Windows, Novell Netware, OS/2

e diversos outros do padrão POSIX (Unix, Linux, FreeBSD, etc.). [APACHE

FOUNDATION, 2014].

2.13. CONSIDERAÇÕES FINAIS DESTE CAPÍTULO

Neste capítulo, foram revisados alguns conceitos sobre a tecnologia referente ao

sistema operacional Android, bem como sua arquitetura e funcionalidades

disponíveis, que foi utilizada para realizar o desenvolvimento do aplicativo.

Também foram descritas linguagens de programação e ferramentas utilizadas e

que facilitaram a construção e o desenvolvimento da aplicação.

O próximo capitulo aborda mais sobre uma partida de futebol.

27

3. FUTEBOL

Este capítulo descreve a história do futebol, bem como sua origem e suas regras.

3.1. HISTÓRIA DO FUTEBOL

A história moderna do futebol tem cerca de 150 anos. Tudo começou

precisamente no ano de 1863, quando na Inglaterra se separaram o "rugby-football"

e a "Association Football", para fundar a mais antiga do mundo: A "Football

Association".

Os dois tipos de jogo tinham praticamente as mesmas raizes. Conhecemos desta

pré-história pelo menos uma dezena de fatos diferentes divulgados pelos meios de

comunicação. Evidentemente, as vezes pode-se contestar certas deduções, mas

algumas coisas são claras: a "bola" se jogava com os pés a pelo menos 1000 anos

atrás e não existe nenhum motivo para considerar o jogo com o pé como sua forma

secundária degenerada do jogo "natural" com as mãos. [HISTÓRIA-DO-FUTEBOL,

2014].

3.2. O INÍCIO

Apesar da necessidade de ter que lutar com todo o corpo (incluindo também

pernas e pés) pela "Bola" em um grande tumulto geral sem regras, parece que, no

começo, se considerava uma coisa extremamente dificil e, por tanto, muito hábil,

dominar a bola com o pé. A forma mais antiga, que se pode considerar como

demonstração deste ponto de vista "cientifico", representa a tal prova de habilidade.

[HISTÓRIA-DO-FUTEBOL, 2014].

Mais precisamente na época da dinastia de Han, havia um livro de instruções

militar no qual figura, parte dos exercicios fisicos, o Tsuh Kuh. Uma bola de couro

enxertada com plumas e pelos teria que ser lançada com o pé a uma pequena rede,

com uma abertura de 30 a 40 cm, cercada de varas de bambu. Uma mostra de

habilidade que requeria seguramente muita destreza e técnica. [HISTÓRIA-DO-

FUTEBOL, 2014].

Outra versão seria a qual os jogadores estavam obstaculizados no caminho até a

meta, podendo jogar a bola com pés, peito e ombros, menos com as mãos, tendo

28

que salvar os ataques da equipe contraria. De modo que a técnica artistica da bola

dos jogadores atuais não é uma coisa tão nova como muitas vezes se supõe.

Do Oriente provem outra forma diferente, a uns 500 a 600 anos mais tarde e que

se joga todavia, ainda hoje. É um tipo de futebol em circulo, menos espetacular, más

digno e solene. É um exercicio cerimonial, que também exige certa habilidade. Em

uma superficie relativamente pequena, os "jogadores" teem que passar a bola uns

aos outros sem ter que deixar cair no chão. [HISTÓRIA-DO-FUTEBOL, 2014].

Muito mais animados eram os "Epislciros" gregos, da qual se sabe relativamente

pouco, e os "Harpastum" romano.

Os romanos tinham uma bola e duas equipes jogando em um terreno retangular,

limitado com linhas de marcação e dividido com uma linha mediana. A bola teria que

ser lançada atrás da linha de marcação do adversario. [HISTÓRIA-DO-FUTEBOL,

2014].

Este esporte foi muito popular entre os anos 700 e 800. Os romanos introduziram

este jogo na Bretanha e pode ser considerado como precursor do futebol,

igualmente o "Hurling", que era muito popular entre a população Celta e que se

pratica, ainda hoje, em Cornwell na Irlanda. De todas as maneiras, o jogo "decisivo"

que hoje conhecemos, tem sua origem na Inglaterra e Escocia. [FIFA, 2005]

3.3. SÍNTESE DO FUTEBOL

O futebol é um dos esportes mais populares no mundo. Praticado em centenas

de países, este esporte desperta tanto interesse em função de sua forma de disputa

atraente. Embora não se tenha muita certeza sobre os primórdios do futebol,

historiadores descobriram vestígios dos jogos de bola em várias culturas antigas.

Estes jogos de bola ainda não eram o futebol, pois não havia a definição de regras

como há hoje, porém demonstram o interesse do homem por este tipo de esporte

desde os tempos antigos. [HISTÓRIA-DO-FUTEBOL, 2014].

O futebol tornou-se tão popular graças a seu jeito simples de jogar. Basta uma

bola, equipes de jogadores e as traves, para que, em qualquer espaço, crianças e

adultos possam se divertir com o futebol. Na rua, na escola, no clube, no campinho

29

do bairro ou até mesmo no quintal de casa, desde cedo jovens de vários cantos do

mundo começam a praticar o futebol [FIFA,2005].

3.4. REGRAS DO FUTEBOL DE CAMPO

3.4.1. O campo de futebol

No futebol o campo tem o formato retangular com superfície verde formada por

grama natural ou artificial. O campo é composto de linhas brancas para

demarcações, essas linhas delimitam áreas, como a área do gol e das laterais. Uma

linha é atravessada de forma perpendicular ao centro das linhas laterais de modo a

dividir o campo em duas partes iguais, e essa linha é chamada de linha de meio

campo e é feita de ponto de onde o jogo deve começar e possui um círculo em seu

centro.. As traves do gol ficam nas duas laterais menores. Ainda existem quartos de

círculo nos quatro vértices do campo, nas quais a bola será colocada para as

cobranças de escanteio (tiro de canto) [CBF, 2013].

3.4.2. Dimensões de campo de futebol

As dimensões de um campo de futebol estão dispostas a seguir:

Comprimento (linha lateral): mínimo 90 m máximo 120 m

Largura (linha de meta): mínima 45 m máxima 90 m

Para partidas internacionais pedem-se as seguintes medidas: Comprimento

(linha lateral): mínimo 100 m máximo 110 m /Largura (linha de meta): mínima 64

m máxima 75 m. (CBF, 2013)

3.4.3. Dimensões do gol

As dimensões do gol estão dispostas da seguite forma:

7,32m de comprimento de uma trave à outra

2,44m de altura do travessão ao solo. [CBF, 2013]

30

3.4.4. A bola de futebol

A bola de futebol pode ser considerado o objeto mais importante dentro de uma

partida. Para isto, ela deve seguir determinadas características que estão listadas a

seguir:

Formato: esférica; circunferência não superior a 70 cm e não inferior a 68 cm

Material: de couro ou qualquer outro material adequado

Peso: não superior a 450 g e não inferior a 410 g no começo da partida

Pressão: 8.5 a 15.6 libras [CBF, 2013].

3.4.5. Os jogadores

Uma partida de futebol se inicia com duas equipes formadas por 11 jogadores

mais um goleiro para cada equipe. O time, como é chamado uma equipe, pode

realizar até 3 substituições de seus jogadores que estão em campo por jogadores

que estão no banco de reservas. Cada equipe deverá ter de 3 a 7 jogadores

reservas. Para realizar a substituição o árbitro deve parar o jogo por um tempo [CBF,

2013].

3.4.6. Equipamentos dos jogadores

Agasalho ou camisa; calção; meiões; caneleiras cobertas pelos meiões;

chuteira.

As duas equipes devem usar cores que as diferenciem entre si e também do

juiz e de seus dois assistentes (bandeirinhas) e cada goleiro ainda deverá usar cores

para seu uniforme que o diferencie de todos os demais participantes do jogo [CBF,

2013].

3.4.7. O árbitro de futebol

Tem a função de gerenciar o jogo, ou seja, por meio de seu tradicional apito ele

inicia a partida, para jogadas, marca faltas e comanda todo o jogo com a ajuda de

seus assistentes [CBF, 2013].

31

3.4.8. Duração da partida

A partida é dividida em dois tempos de 45 minutos com um intervalo de 15

minutos entre eles. A cada tempo é acrescido a critério do juiz o tempo que foi

perdido em substituições, avaliação de lesão de jogadores, transporte dos jogadores

lesionados para fora do campo de jogo para atendimento, perda de tempo ou

qualquer outro motivo constatado pelo juiz [CBF, 2013].

3.4.9. Impedimento

Um impedimento ocorre quando o jogador estiver mais próximo da linha de

fundo adversária do que a bola e o penúltimo adversário. Não será marcado

impedimento quando o jogador estiver no meio-campo de sua equipe, quando

estiver na mesma linha do penúltimo adversário ou na mesma linha dos dois últimos

adversários. A posição de impedimento é caracterizada no momento em que a bola

é tocada por um de seus companheiros [CBF, 2013].

3.4.10. Faltas

As faltas ocorrem quando um jogador tenta tomar a bola de outro de maneira

errada cometendo assim a falta. Também é caracterizada falta quando houver toque

de mão intencional na bola. As faltas são marcadas em tiro livre contra a equipe que

cometeu a infração [CBF, 2013]

3.4.11. Cartões

Cartão Amarelo: Usado para advertir um jogador que cometeu uma falta um

pouco mais agressiva, e que a segunda falta do mesmo tipo será penalizada com

cartão vermelho.

Cartão Vermelho: O jogador recebe quando já tem um cartão amarelo por falta

cometida anteriormente, e ele é expulso do jogo. Ou caso o árbitro interprete que a

infração cometida seja de uso excessivo de força, e assim expulsa o jogador sem a

necessidade do cartão amarelo, dando a ele o cartão vermelho diretamente [CBF,

2013].

32

3.4.12. Arremesso lateral

O arremesso lateral será cobrado com as mãos e ocorre quando a bola

ultrapassa as linhas de forma completa pelas linhas laterais maiores do campo [CBF,

2013].

3.4.13. Tiro de meta

É o chute cobrado pelo goleiro, e ocorre quando um jogador do time oposto

chuta a bola e ela ultrapassa os limites laterais menores do campo [CBF, 2013].

3.4.14. Escanteio

É marcado a favor de um time quando um jogador adversário chutar a bola de

forma que ela ultrapasse as linhas laterais menores do seu lado do campo [CBF,

2013].

3.4.15. O vencedor

Um jogo de futebol pode ser vencido pela equipe que fizer mais gols, ou,

quando empatado, pode ser vencido na questão das regras de gols fora de casa,

pela prorrogação ou ainda pela cobrança de pênaltis [CBF, 2013].

3.5. SÚMULA

Na área esportiva, as súmulas são documentos descritivos sobre o resultado,

envolvidos, condições e ocorrências de uma partida desportiva, mais comumente no

futebol e futsal, elaboradas pelos árbitros [AULETE, 2014].

A seguir será exibida por meio das Figuras 6 e 7, a súmula de jogo a qual foi

usada como base para retirar as informações necessárias no desenvolvimento do

aplicativo.

33

Figura 6 - Súmula da partida - 01.

Fonte: FFERJ, 2014.

34

Figura 7- Súmula da partida - 02.

Fonte: FFERJ, 2014.

35

3.6. CONSIDERAÇÕES FINAIS SOBRE O FUTEBOL

Não é de hoje que o futebol é um esporte popular e que atrai milhões de

pessoas. O futebol é considerado o esporte nacional aqui no Brasil, e movimenta

milhões de reais em campeonatos estaduais e nacionais. O futebol também é um

esporte que tem suas regras consolidadas mundialmente, o que facilita a

implantação de um aplicativo que gerencie os eventos ocorridos durante a partida.

No próximo capitulo serão mostrados alguns trabalhos correlatos, que

servirão como base de comparação para com a aplicação desenvolvida.

36

4. TRABALHOS CORRELATOS

Este capitulo trata de aplicativos relacionados a controle de partidas de futebol

que já estão disponíveis na loja Google Play para download. Porém muitos deles

não contemplam funcionalidades capazes de gerenciar uma partida oficial de futebol,

visto que possuem limitações funcionais.

4.1. APLICATIVO “I, REFEREE”

O aplicativo chamado ―I, Referee‖ (Figura 8) mostra os cartões amarelo e

vermelho quando ocorre alguma infração durante a partida. Também é possível

emitir o som do apito do árbitro caso ocorra a infração, podendo ser emitido uma

vez, duas ou três vezes seguidas, de acordo com a infração cometida.

Figura 8 - Imagens do aplicativo "I, Referee".

Fonte: GOOGLE PLAY, 2014 .

4.2. APLICATIVO “REFEREE ASSISTANCE”

Outro aplicativo relacionado é o ―Referee Assistant‖ (Figura 9), que oferece a

opção da marcação de cartões amarelo ou vermelho, porém podendo ser adicionado

o número do atleta infrator. O aplicativo também conta com o cronômetro

responsável pelo controle de tempo de partida, bem como um placar para marcar a

ocorrência dos gols efetuados durante a partida.

37

Figura 9 - Imagens do aplicativo “Referee Assistant”.


4.3. APLICATIVO “WHISTLE”

O aplicativo ―Whistle‖ (Figura 10), conta com um sistema de cronômetro para

controle de tempo de partida, e trabalha também com eventos ocorridos durante a

mesma, tais como gols, impedimentos, cartões, etc.

Figura 10 - Imagens do aplicativo “Whistle”.


38

4.4. CONSIDERAÇÕES FINAIS DESTE CAPÍTULO

Considerando o resultado das pesquisas, foram encontrados vários aplicativos,

com funcionalidades distintas, porém todos com o intuito de gerenciar uma partida

de futebol. Entretanto, o primeiro software citado, está limitado a marcar apenas

infrações. Não há uma funcionalidade para marcar o tempo de jogo, nem mesmo

anotar o número e motivo pelo qual o jogador infrator recebeu o cartão.

O segundo software citado, chamado ―Referee Assistance‖, também está

limitado a registrar as infrações somente com o número do jogador infrator, não

sendo possível registrar o tempo de jogo decorrido no momento da infração e nem o

motivo pelo qual a infração foi registrada.

Para finalizar, no último software citado, chamado ―Whistle‖, no registro efetuado

pelo mesmo, não consta número de jogador e motivo. Este aplicativo mostra apenas

os eventos ocorridos durante a partida, e assim como os aplicativos anteriores,

possuem limitações considerando uma partida completa.

Após todas as informações serem devidamente coletadas e filtradas, referente

aos aplicativos citados anteriormente, a Tabela 1, foi gerada com o intuito de facilitar

a comparação entre os aplicativos, e verificar quais funcionalidades estão sendo

abrangidas para cada um deles.

Nesta tabela estão sendo apresentadas as principais funcionalidades disponíveis

em cada aplicativo.

Tabela 1 - Comparação de aplicativos pesquisados e suas funcionalidades.

Fonte: autoria própria.

39

Na Tabela 1, temos o quadro ―Funcionalidade/Aplicativo‖ estão descritas

todas as funcionalidades de cada aplicativo, e nas colunas seguintes, estão

descritos os nomes dos aplicativos, seguidos da marcação de um ―X‖, nas linhas em

que os aplicativos contemplam tal funcionalidade.

A seguir será descrito cada funcionalidade detalhadamente:

Cronometro

o Para esta funcionalidade, será controlado o início e fim da partida,

juntamente com os minutos de acréscimo concedido pelo árbitro.

Anotação de cartão amarelo / vermelho

o Esta funcionalidade é responsável pelo registro de cartão

amarelo/vermelho quando um jogador é atuado pelo árbitro.

Mostrar cartão amarelo / vermelho

o Nesta funcionalidade, o cartão amarelo/vermelho será mostrado ao

jogador que cometeu a infração.

Emitir som de apito

o A função ―Emitir som de apito‖ é responsável por simular um som de

apito sempre que a funcionalidade for acionada.

Marcação de gols

o Nesta função, o árbitro poderá registrar os gols marcados no decorrer

da partida, juntamente com o número do jogador que efetuou o gol e o

tempo da partida.

Registro de substituições

o No registro de substituições, o árbitro indicará o número do jogador

que está entrando e o número do jogador que está saindo de campo.

40

5. SISTEMA DE GERENCIAMENTO DE PARTIDAS DE FUTEBOL

Este capitulo descreve a arquitetura utilizada na implementação do aplicativo,

bem como seus requisitos e as telas de interface web e interface do aplicativo

Android.

5.1. ARQUITETURA

O sistema proposto contém duas interfaces, a primeira é uma interface Web

responsável pelo cadastro dos dados referente a partida, bem como registro de

equipe de arbitragem, e a segunda sendo uma interface gráfica para o sistema

operacional Android, em que o usuário deve entrar com informações referentes a

eventos da partida de futebol. Com estas informações, ao final da partida, o cliente

enviará informações para um servidor remoto, utilizando web service, e este por sua

vez processará as informações, retornando para o cliente se as informações obtidas

por meio do árbitro e da equipe de arbitragem estão coerentes ou não.

Existem dois papéis na perspectiva do aplicativo, são eles: árbitro e mesa

abitrária. Ambos terão acesso a todas as funcionalidades do aplicativo, sendo que

apenas as informações de login serão utilizadas para efetuar a equiparação de

dados e envio final das informações coletadas no decorrer da partida.

Ao final da partida, os dados coletados serão enviados para um servidor de

aplicação e equiparados, no qual os mesmos serão persistidos e estarão disponíveis

para registro e impressão das partes interessadas e consultas futuras.

Na Figura 11, é apresentado um diagrama com as funcionalidades básicas do

aplicativo:

41

Figura 11 - Diagrama de fluxo básico do aplicativo "Soccer Referee".


5.2. REQUISITOS FUNCIONAIS

Os requisitos funcionais descrevem os serviços que o sistema deve oferecer e

suas "funções", quando da finalização da implementação, e qual o comportamento

esperado de acordo com as informações fornecidas pelo árbitro e mesa arbitrária.

Os requisitos estão apresentados nas seguintes seções:

5.2.1. Logar no Sistema

O sistema deverá permitir que árbitro e a equipe de arbitragem possuam

usuários e senhas, para que as informações de ambas as partes sejam identificadas

por meio do login. Isto é realizado por meio de um sistema de Login/Senha.

5.2.2. Registrar Infrações

O sistema deverá permitir o registro de infrações acrescidas de cartão amarelo

ou vermelho para o jogador que cometer algum tipo de ação julgada incorreta pela

arbitragem.

5.2.3. Remover Infrações

O sistema deverá permitir a exclusão de infrações uma vez que a mesma tenha

sido marcada erroneamente pela equipe de arbitrágem.

42

5.2.4. Controlar tempo de partida

O sistema deverá permanecer zerado ao inicio de cada partida, disponibilizando

ao árbitro e a equipe de arbitragem a função para iniciar, pausar e reiniciar o tempo

de partida, além de fazer o cálculo do acréscimo do tempo extra.

5.2.5. Registrar pontuação

O sistema deverá permitir o registro de gols para as equipes durante a partida,

tendo selecionado o número do atleta e o tempo de jogo decorrido no momento do

gol.

5.2.6. Remover pontuação

O sistema deverá possibilitar a exclusão do gol marcado uma vez que o mesmo

tenha sido registrado erroneamente.

5.2.7. Carregar dados da súmula

O Sistema deverá carregar os dados na súmula, tais como o nome das equipes,

horário da partida, local da partida, nome dos integrantes de arbitragem e os demais

eventos ocorridos e registrados durante a partida.

5.3. REQUISITOS NÃO-FUNCIONAIS

Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação

em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade,

manutenibilidade e tecnologias envolvidas. A partir da Seção 5.3.1, estão listados

os requisitos não funcionais para este sistema.

5.3.1. Requisito não funcional 01

Sistema será desenvolvido na linguagem Java de modo a ser compatível com o

sistema operacional Android.

43


Será criado um documento contendo casos de uso, diagrama de classes,

diagrama de modelagem de dados e demais diagramas, como também informações

sobre o código fonte.


A interface do sistema deverá ser agradável, objetiva e trivial ao usuário. Suas

funcionalidades e informações deverão estar bem intuitivas ao usuário.


O sistema deverá estar disponível durante 99,9% do tempo.


Para persistência de dados será utilizado o sistema gerenciador de banco de

dados SQLite. Por ser um software livre, haverá uma considerável diminuição dos

custos.


O sistema não apresentará ao usuário quaisquer dados privados,por exemplo

senha de login.

5.4. DIAGRAMA DE CASO DE USO

No diagrama de casos de uso (Figura 12), são descritos os requisitos funcionais

propostos para o aplicativo Android.

44

Figura 12 - Diagrama de caso de uso do aplicativo Android “Soccer Referee”.


E na Figura 13 são descritos os requisitos funcionais para a aplicação Web.

Figura 13 - Diagrama de caso de uso da aplicação Web.


45

5.5. DIAGRAMA DE CLASSES

No diagrama de classes, apresentado na Figura 14, estão presentes as

funcionalidades propostas para o aplicativo. No diagrama a seguir é possível notar

que a modelagem dos dados, bem como as funções criadas foram feitas para

atender as necessidades do sistema. Para possibilitar uma melhor performance da

aplicação, foi utilizado o banco de dados que é embutido no aplicativo.

Figura 14 - Diagrama de classe do aplicativo "Soccer Referee".


5.6. DIAGRAMA DE MODELAGEM DE DADOS

Modelar significa criar um modelo que explique as características de

funcionamento e comportamento de um software a partir do qual ele será criado,

facilitando seu entendimento e seu projeto, por meio das características principais

que evitarão erros de programação, projeto e funcionamento [DEVMEDIA

MODELAGEM, 2014].

46

A modelagem de dados referente ao aplicativo Android, está representada na

Figura 15.

Figura 15 - Modelagem de dados do aplicativo Android "Soccer Referee".


Para a aplicação Web, foi utilizada a modelagem de dados que está

representada na Figura 16.

Figura 16 - Modelagem de dados da aplicação Web.


47

5.7. FUNCIONAMENTO DO SISTEMA

O funcionamento do Sistema ―Soccer Referee‖ conta com a interface criada para

o sistema operacional Android.

Esta interface e suas funcionalidades são descritas nas próximas seções por

meio de suas telas, mostrando cada uma com sua respectiva descrição.

5.8. INTERFACE DO APLICATIVO ANDROID

As telas do aplicativo são de navegação intuitiva, comparados aos demais

aplicativos citados, uma vez que a disposição dos ícones e desenhos auto

explicativos estão dispostos na tela de forma organizada, conforme imagens a

seguir.

5.8.1. Ícone

Como figura principal, temos o ícone contendo um árbitro de futebol e um

conjunto de cartões, amarelo e vermelho, dando ênfase a funcionalidade do

aplicativo, conforme Figura 17.

Figura 17 - Ícone "Soccer Referee".


5.8.2. Tela de apresentação

Inicialmente, temos a chamada Splash Screen ou Tela de Apresentação, que é

exibida ao abrir um aplicativo no qual é dada ênfase nos cartões amarelo e

vermelho, junto com um apito referenciando a equipe de arbitragem, tendo

sobrescrito o nome do aplicativo sob os cartões, vide Figura 18.

48

Figura 18 - Splash Screen do aplicativo "Soccer Referee".


5.8.3. Tela de login

A tela de login é composta por campo de usuário e senha, número de

tentativas e botão de login, e pode ser visualizada na Figura 19.

Figura 19 - Tela de Login do aplicativo "Soccer Referee".


49

5.8.4. Tela principal

Ao carregar a página principal, estão dispostos ícones referentes a

funcionalidades para gerenciar uma partida de futebol. No canto superior esquerdo,

há um ícone de um cronômetro, que permite controlar o início e fim da partida. No

canto superior direito, há um ícone de uma súmula, cuja a função é coletar todos os

dados vindos dos outros eventos da partida, e gerar a súmula final de jogo.

Separados por Home Team e Away Team, estão os cartões amarelo e vermelho,

que representam a marcação de infrações, ícones de uma bola de futebol, utilizados

para a marcação de gol e ícone de duas flechas, que representam a substituição de

atletas. Estes detalhes podem ser visualizados na Figura 20.

Figura 20 - Tela principal do aplicativo "Soccer Referee".


5.8.5. Tela de cronômetro

A tela de cronômetro, exibe o início e fim da partida. Nesta tela há um botão de

Start que inicia a contagem, Stop que interrompe o tempo quando necessário, e

Reset que zera o cronometro, conforme Figura 21.

50

Figura 21 - Tela de cronômetro do aplicativo "Soccer Referee".


5.8.6. Tela de cartão amarelo

A tela de registro de cartão amarelo, registra o número do jogador e o motivo da

infração. Quando registrado, o tempo de jogo também é salvo com os demais dados,

vide Figura 22.

51

Figura 22 - Tela de cartão amarelo do aplicativo "Soccer Referee" .


5.8.7. Tela de cartão vermelho

A tela de registro de cartão vermelho, assim como a tela de cartão amarelo,

registra o número do jogador e o motivo da infração. Quando registrado, o tempo de

jogo também é salvo com os demais dados, vide Figura 23.

52

Figura 23 - Tela de cartão vermelho do aplicativo "Soccer Referee".


5.8.8. Tela de gol

A tela de registro de gols é composta pelo campo de número e um botão. O

usuário seleciona o número do jogador e ao registrar o gol, o tempo é adicionado ao

lado do número do jogador, conforme Figura 24.

53

Figura 24 - Tela de registro de gols do aplicativo "Soccer Referee".


5.8.9. Tela de substituição

A tela de substituição é composta pelos números dos jogadores que irão sair e

que irão entrar. Nesta tela, apresentada na Figura 25, o usuário deverá selecionar o

número do atleta que está saindo de campo e o número do atleta que está entrando

em campo.

54

Figura 25 - Tela de substituição do aplicativo "Soccer Referee".


5.8.10. Tela de súmula

Esta tela, conforme Figura 26, reúne todos os dados de jogo, como local de jogo,

horário de início do jogo, equipes que irão se enfrentar, entre outras informações

relevantes para a realização do jogo, bem como os demais dados coletados durante

a partida, para que sejam salvos e enviados para um servidor remoto.

55

Figura 26 - Tela de súmula do aplicativo "Soccer Referee".


5.9. INTERFACE WEB

A interface Web foi desenvolvida com o intuito de ser simples, prática e

funcional. Seu objetivo principal, é coletar os dados referentes a partida de futebol,

bem como os nomes dos árbitros responsáveis pela mesma. Após processamento,

as informações serão disponibilizadas por meio de um web service que retorna

dados no formato JSON, que deverá ser consumido pela aplicação Android.

A seguir serão apresentadas as imagens referentes a aplicação Web.

56

5.9.1. Tela de login da aplicação Web.

Na figura 27, está apresentada a tela de login da aplicação Web, na qual

somente usuários autorizados terão acesso as demais telas da aplicação.

Figura 27 - Tela de login da aplicação Web.


5.9.2. Tela de registro de dados da aplicação Web.

Nesta tela, apresentada na Figura 28, serão apresentados os dados

referentes a partida de futebol, e os dados referentes a equipe de arbitragem.

O usuário deve preencher todos os campos, uma vez que os mesmos são

mandatórios, e salvar os registros que foram inseridos no banco de dados.

57

Figura 28 - Tela de registro da aplicação Web.


5.9.3. Tela de consulta da aplicação Web.

A tela de consulta da aplicação, apresentada na Figura 29, é responsável por

mostrar as informações cadastradas anteriormente na tela de registro. Nela é

possível verificar informações importantes relacionadas a partida e a equipe de

arbitragem.

58

Figura 29 - Tela de consulta de partida.


5.9.4. Tela de serviço JSON da aplicação Web.

A tela representada na Figura 30, representa as informações cadastradas

anteriormente, porém já disponíveis em formato JSON, que será utilizada na

aplicação Android para o consumo de informações referente a partida de futebol e a

equipe de arbitragem selecionada para esta partida.

59

{

"futebol":[

{"campeonato":"Brasileiro",

"jogo":"Coritiba x Parana",

"data":"25\/08\/2014",

"horario":"16:00",

"estadio":"Couto Pereira",

"UF":"PR"}],

"arbitragem":[

{"arbitro":"Josival Pereira",

"arbitro1":"Roberto Dinamite",

"arbitro2":"Arnaldo Cesar Coelho",

"quartoarbitro":"Rodrigo Oliveira",

"quintoarbitro":"Rafael Vazques",

"delegado":"Marcio Garcia"}

]

}

Figura 30 - Tela de serviço JSON.


60

5.10. CONSIDERAÇÕES FINAIS

Neste capítulo foram apresentadas a arquitetura utilizada para o sistema Web e

para o aplicativo Android, bem como seus requisitos, suas telas e os diagramas

utilizados para o desenvolvimento do aplicativo.

No capítulo seguinte, será abordada a conclusão do projeto e algumas

melhorias que poderão ser implementadas em projetos futuros.

61

6. CONCLUSÃO

O objetivo principal deste trabalho foi desenvolver um aplicativo que seja

utilizado como ferramenta gerenciadora de uma partida de futebol, sendo utilizada

por árbitro e equipe de arbitragem, afim de coletar dados durante a partida e reuní-

los em um lugar comum, chamado súmula, servindo esta como documento final

contendo todo o histórico e resultado oficial da partida.

O intuito do aplicativo é fornecer um fácil manuseio para o árbitro e equipe de

arbitragem, uma vez que o mesmo deve ser utilizado durante a partida, portanto a

interface deve ser simplificada e intuitiva.

Durante o desenvolvimento do projeto foram pesquisados diversos documentos,

artigos e regulamentos relacionadosa partidas de futebol, a regras de arbitragem,incluse

tendo contatos frequentes com árbitros profissionais, afim de coletar informações para o

desenvolvimento do aplicativo.

O fator motivacional decisivo para escolha do tema, foi automatizar uma prática que é

efetuada manualmente até os dias atuais, e por consequência tornar o trabalho da

equipe arbitragem ágil e consistente.

Como base de comparação, foi utilizada uma tabela contendo o aplicativo

desenvolvido e os aplicativos pesquisados durante desenvolvimento do projeto. A

Tabela 2, representa cada aplicativo com suas devidas funcionalidades.

Tabela 2 – Comparativo entre funcionalidades dos aplicativos pesquisados

62

Conforme descrito na seção 4.4, foram detalhadas algumas das funcionalidades

dos aplicativos estudados. Como diferencial do aplicativo ―Soccer Referee‖, foi

adicionada uma nova funcionalidade conforme descrição a seguir:

Súmula

o A súmula é a principal funcionalidade do aplicativo, a qual é

responsável por reunir todos os dados coletados durante a partida em

uma mesma tela.

6.1. TRABALHOS FUTUROS

Consideração as características da plataforma Android, utilizada para a solução e

implementação para dispositivos móveis, e a definição de escopo e modelo

apresentado neste trabalho, é possível a visualização de melhorias que podem ser

implementadas.

Tais melhorias podem ser classificados como a aplicação em si e os dispositivos

disponíveis que suportem esta tecnologia.

6.2. APLICAÇÃO MOBILE

Em relação a aplicação mobile, uma sugestão seria o compartilhamento do

resultado oficial da partida em redes sociais, como por exemplo o Facebook, o Twitter, e

demais canais comunicação.

Também coletar os dados da partida, e gerar gráficos relacionados com o histórico

dos jogos, para que sejam usados como estatísticas para as futuras partidas.

6.3. APLICAÇÃO WEB

Na perspectiva da aplicação web, com intuito de comprovar a veracidade dos

dados coletados, sendo eles enviados pelo árbitro e pela mesa arbitrária, a sugestão

seria equiparar os dados obtidos de maneira automatizada, por meio de algoritmos

de comparação. Ao final deste processo, caso haja divergência de informações, os

dados deverão ser discutidos junto ao comitê julgador para que se tenha o resultado

final aprovado.

63

6.4. OUTROS DISPOSITIVOS

Na linha dispositivos, uma sugestão seria tornar este sistema compatível com os

chamados SmartWatch, ou os relógios inteligentes, uma vez que estes aparelhos teriam

as mesmas funcionalidades de um smartphone, porém em tamanho reduzido e de fácil

manuseabilidade, dispensando assim o uso de um relógio e de um smartphone para o

árbitro ou equipe de arbitragem designada para a partida.

A sugestão é que a partir de um SmartWatch o árbitro tenha controle dos dados da

partida, por meio das funções disponíveis neste aplicativo.

64

7. REFERÊNCIAS BIBLIOGRÁFICAS

ABNT.ORG.BR, Formatação pelas Regras Normas ABNT. 2014. Disponível em

<http:www.abnt.org.br> Acesso em Agosto de 2014.

APACHE FOUNDATION. The Apache Software Foundation. 2014. Disponível em:

< http://www.apache.org/> Acesso em: Junho de 2014.

APACHE HTTP. Apache HTTP Server Project. 2014. Disponível em: <

http://httpd.apache.org/> Acesso em: Agosto de 2014.

AULETE, Súmula. Brasil: Lexikon Editora Digital, 2014.

ANDROID DEVELOPERS. Android Developers. 2014. Disponível em:

<http://developer.android.com/index.html> Acesso em: Maio 2014.

ANDROID SDK. Android SDK. 2014. Disponível em:

<http://developer.android.com/sdk> Acesso em: Maio 2014.

CANIANO, Information Protection: Empowering Business Innovation, 2014.

Disponível em: <https://stevecaniano.sys-con.com/node/2292861> Acesso em:

Agosto de 2014.

CAELUM, Eclipse IDE, 2014. Disponível em < http://www.caelum.com.br/apostila-

java-orientacao-objetos/eclipse-ide/> Acesso em Julho de 2014.

CBF, Livro de Regras 2013 / 2014 – Português. 2014. Disponível em: <

http://www.cbf.com.br/arbitragem/comissao-publicacoes/livro-de-regras-2013-2014-

portugues#.U-bHZ-NdXAQ> Acesso em: Agosto 2014.

CREATELY.COM. Draw, Share, Validate and Export Diagram. 2014. Disponível

em: <https://creately.com/app/> Acesso em: Agosto 2014.

DEVMEDIA ECLIPSE, Conhecendo o Eclipse, 2014. Disponível em <

http://www.devmedia.com.br/conhecendo-o-eclipse-uma-apresentacao-detalhada-

da-ide/25589> Acesso em Agosto de 2014.

65

DEVMEDIA MODELAGEM, Introdução a modelagem de dados, 2014. Disponível

em < www.devmedia.com.br/introducao-a-modelagem-de-dados/24953> Acesso em

Agosto de 2014.

ECLIPSE FOUNDATION. About the Eclipse Foundation. 2014. Disponível em: <

http://projects.eclipse.org/> Acesso em: Junho 2014.

FIFA.COM, Início das regras do futebol. 2014. Disponível em <

http://pt.fifa.com/newscentre/features/news/newsid=1976230/> Acesso em: Junho

2014.

FFERJ, Federação de Futebol do Estado do Rio de Janeiro. 2014. Disponível em

<http://www.fferj.com.br> Acesso em Junho de 2014.

GARTNER. Gartner Says Cloud, Mobility and Open Source Will Drive

Application Development Market to Exceed $9 Billion in 2012. 2012. Disponível

em: <http://www.gartner.com/newsroom/id/2131115> Acesso em: Abril 2014.

GOOGLE PLAY, Referee. 2014. Disponível em <

https://play.google.com/store?hl=pt_BR> Acesso em Maio de 2014.

HISTORIA-DO-FUTEBOL, História do Futebol. 2014. Disponível em:

<http://historia-do-futebol.info> Acesso em: Julho 2014.

IBM, Internacionalização. 2014. Disponível em: <http://publib16.boulder.ibm.com/>

Acesso em: Abril 2014.

IMASTERS, Hangout sobre Internacionalização e Localização de aplicações

web. 2014. Disponível em <

http://imasters.com.br/artigo/25233/desenvolvimento/hangout-sobre-

internacionalizacao-e-localizacao-de-aplicacoes-web/> Acesso em Julho de 2014.

JSON.ORG, ECMA-404 The JSON Data Interchange Standard. 2014. Disponível

em <http:www.json.org> Acesso em Agosto de 2014.

LECHETA, R. Google Android - Aprenda A Criar Aplicações Para Dispositivos

Móveis Com o Android Sdk. Brasil: Novatec, 2014.

66

MENDES, D. Programação Java em Ambiente Distribuído. 2011. Brasil: Novatec,

2011

NETO, A. Web Services em Java, 2006. Brasil: Brasport, 2006.

PHP.NET. Manual do PHP. 2014. Disponível em:

<http://php.net/manual/pt_BR/index.php> Acesso em: Julho 2014.

universidade tecnolÓgica federal do paranÁ...

Documents