Mauricio Gomes - TCC - Sistemas de Informação

FACULDADE DE BALSAS
CURSO DOE SISTEMAS DE INFORMAÇÃO
SUMDIG:
A SÚMULA DIGITAL
Mauricio da Costa Gomes
BALSAS-MA
2013
1
FACULDADE DE BALSAS
CURSO DE SISTEMAS DE INFORMAÇÃO
SUMDIG:
A SÚMULA DIGITAL
Mauricio da Costa Gomes
Trabalho de conclusão de curso para Curso de
Sistemas de Informação como requisito para a
obtenção do grau de Bacharel em Sistemas de
Informação.
Aluno: MAURICIO DA COSTA GOMES
Orientador: JEFFERSON FONTINELE DA SILVA
Orientador: Jefferson Fontinele da Silva
Coordenador do Curso de Sistemas de Informação: Junior Marcos Bandeira
Balsas - MA
2013
2
AGRADECIMENTOS
Agradeço a Deus primeiramente por me dar a oportunidade de vivenciar este
momento único que é estar concluindo um curso superior na área em que sempre me
identifiquei e gosto de atuar, aos meus amigos que sempre me apoiaram torcendo pela
minha vitória e aos meus familiares que sempre me deram forças para alcançar os meus
objetivos apoiando as minhas decisões quando corretas e me sugerindo opções e caminhos
alternativos, contribuindo assim com a minha formação intelectual e profissional.
Um agradecimento especial ao meu orientador Jefferson Fontinele, que sempre
acreditou em mim e em meu potencial para o desenvolvimento desse projeto, tirando
minhas dúvidas e me aturando durante todo esse período cansativo, porém, muito rico em
conhecimento e em troca de experiências.
Agradeço a minha mãe querida, Sonia Regina Barbosa da Costa Noleto, por sempre
ter lutado para me proporcionar o melhor perante os seus limites, ao meu padrasto,
Francisco Noleto Junior, por ter me orientado em muitas ocasiões, ao meu pai Gregório
Gomes Neto que é meu grande ídolo e exemplo de vida por suas vitórias e conquistas em
sua longa jornada de vida e que até hoje surpreende a todos.
A todos só tenho a agradecer do fundo do coração pelo apoio moral durante esses
meus inesquecíveis (04) quatro anos de Unibalsas.
3
RESUMO
Em uma partida de futebol de salão são geradas várias informações que são armazenadas em
um documento que oficializa a partida. Essas informações geradas são necessárias para a
definição de uma equipe campeã de um torneio ou para medidas administrativas. Com isso se
faz necessário a utilização de um documento que oficialize a partida, este documento é
chamado de súmula. A informatização deste documento junto com o melhoramento da
interação entre árbitros e auxiliares é o foco principal desta pesquisa que configura um
trabalho de conclusão de curso. No desenvolvimento da aplicação foi utilizado métodos de
engenharia de software que sustentam a implementação de software multiplataforma, ou seja,
softwares capazes de atuar em mais de uma plataforma. As ferramentas e plataformas
adotadas para o desenvolvimento deste sistema serão descritas ao longo do trabalho.
Palavras-chaves: Futebol de salão, Súmula digital, Comunicação, Metodologia de
desenvolvimento, aplicações multiplataforma.
4
ABSTRACT
In an indoor soccer match many informations are generated and stored in a document
which formalizes the match. Those informations are necessary for the definition of a
winner team of a champions hipor for admistrative actions. With that, its necessary to use
a document that formalizes the match, this document is called docket. The
computerization of this document allied to the improvement of the interaction between
referees and auxiliary is the main focus of this research, which sets a End-coursework. In
the development of the application, methods of software engeneering which supports the
implementation of multiplataform software has been used, that softwares capable of
acting in more than one plataform. The tools and plataform adopted for the development
of this system willbed escribed during this work.
Key words: Indoor Soccer, Digital Docket, Comunication, Development Methodology,
Multiplataform applications.
5
LISTA DE FIGURAS
Figura 1 - Ambiente de Trabalho do GGTS ............................................................................. 12
Figura 2 - Arquitetura Grails .................................................................................................... 14
Figura 3 - Camadas da Arquitetura Android ............................................................................ 18
Figura 4 - Hierarquia de Views e Viewgroups ......................................................................... 19
Figura 5 - Ambiente ADT-Bundle............................................................................................ 20
Figura 6 - Recursos Phonegap .................................................................................................. 21
Figura 7 - One-Way Data Binding ........................................................................................... 22
Figura 8 - Tela principal da aplicação SUMDIG em um dispositivo móvel ............................ 24
Figura 9 - Telas de listagem da aplicação SUMDIG em um dispositivo móvel ...................... 25
Figura 10 - Tela inicial da aplicação SUMDIG ........................................................................ 26
Figura 11 - Tela de Registro das equipes e a listagem das cadastradas .................................... 26
Figura 12 - Tela de registro de jogadores e tela de listagem dos cadastrados .......................... 27
Figura 13 - Registro da Equipe Técnica ................................................................................... 27
Figura 14 - Registro de Pessoas ................................................................................................ 28
Figura 15 - Registo do Árbitro e a lista dos cadastrados .......................................................... 28
Figura 16 - Registro da Equipe de Arbitragem e a listagem da equipe registrada ................... 29
Figura 17 - Registro de cartões, faltas, gols, pedidos de tempo. .............................................. 30
Figura 18 - Listagem das informações registradas no decorrer da partida. .............................. 30
Figura 19 - Criação da sumula e a listagem das criadas. .......................................................... 31
Figura 20 - Arquitetura do Projeto ........................................................................................... 32
Figura 21 - Súmula Oficial da Confederação Brasileira de Futebol de Salão. ......................... 42
Figura 22 - Súmula Oficial da Confederação Brasileira de Futebol de Salão. ......................... 43
6
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................... 07
1.1 Problemática ............................................................................................................... 08
1.2 Objetivos ...................................................................................................................... 08
1.2.1 Geral ............................................................................................................................. 08
1.2.2 Específicos .................................................................................................................... 08
1.3 Justificativa ................................................................................................................. 09
1.4 Metodologia ................................................................................................................. 09
2 REVISÃO BIBLIOGRÁFICA ....................................................................................... 10
2.1 As Regras e Leis do Futebol de Salão .......................................................................... 10
2.2 Definição das Plataformas de Desenvolvimento ......................................................... 11
2.2 Grails .............................................................................................................................. 11
2.2.1 Scaffolding ................................................................................................................... 13
2.2.2 Plugins .......................................................................................................................... 13
2.2.3 Jetty............................................................................................................................... 13
2.2.4 Arquitetura Grails ......................................................................................................... 14
2.2.5 Git ................................................................................................................................. 15
2.2.6 A linguagem Groovy .................................................................................................... 15
2.3 Android ........................................................................................................................... 16
2.3.1 Plataforma Android ...................................................................................................... 16
2.3.2 A Arquitetura Android ................................................................................................. 16
2.3.3 Interface Gráfica e Layouts .......................................................................................... 18
2.4 Framework PHONEGAP .......................................................................................... 19
2.5 O Framework ANGULARJS ...................................................................................... 21
2.6 O IDE Eclipse .............................................................................................................. 23
3 DESCRIÇÃO DO FUNCIONAMENTO DO SISTEMA ............................................ 24
3.1 A Versão Mobile ............................................................................................................ 24
3.2 A Versão WEB ............................................................................................................... 25
4 ARQUITETUA DO PROJETO .................................................................................... 32
5 CONCLUSÃO.................................................................................................................. 33
REFERÊNCIAS ................................................................................................................ 34
ANEXOS ............................................................................................................................ 36
7
1 INTRODUÇÃO
Sobre o surgimento do futebol de salão, segundo a Confederação Brasileira de
Futebol de Salão (CBFS - 2009), existem duas versões: a primeira é que o futebol de salão
começou a ser jogado por volta de 1940 por frequentadores da Associação Cristã de Moços
em São Paulo - SP, pois encontravam dificuldades para jogar em campos de futebol por
estarem sempre superlotados e se reuniam em quadras de basquete e hóquei para jogar as
famosas “peladas”. A segunda versão é que o futebol de salão foi inventado em 1934 na
cidade de Montevidéu, Uruguai, pelo professor Juan Carlos Ceriani, que denominou este
esporte de “indoor-foot-ball”.
No início, este esporte era jogado com bolas grandes feitas de materiais caseiros e
com uma quantidade indefinida de jogadores, às vezes sete, seis ou cinco em cada equipe. Ao
longo do tempo as bolas foram diminuídas e tornadas mais pesadas para que não saíssem
pulando das quadras, daí veio o nome de “Esporte da Bola Pesada”.
Com o surgimento das regras veio o surgimento das primeiras entidades oficiais
deste esporte. Em 28 de Julho de 1954 foi fundada a primeira federação de futebol de salão
estadual do Brasil, a Federação Metropolitana de Futebol de Salão, que logo se tornou a
Federação de Futebol de Salão do Estado do Rio de Janeiro. Com a criação da primeira
federação estadual, veio o desencadeamento de origem de federações estaduais por todo o
Brasil. Foi criada, a partir de então, a Confederação Brasileira de Futebol de Salão (CBFS), a
Confederação Sul Americana de Futebol de Salão (CFAS) e a Federação Internacional de
Futebol de Salão (FIFUSA).
Estas regras cabem às equipes que disputam os campeonatos oficiais, aos árbitros,
regulamenta as quadras oficiais e toda a disputa em si. Baseada em algumas dessas regras,
acontecem punições para alguns jogadores, como por exemplo, em um campeonato oficial, se
o jogador for expulso em uma partida, o mesmo não poderá participar da próxima partida do
time na mesma etapa do campeonato. Essas são algumas das informações geradas em uma
partida de futebol de salão podendo, também, definir uma equipe campeã de um campeonato
oficial. Essas informações são armazenadas na súmula da partida onde concentram-se todos
os dados gerados como, por exemplo, registro dos jogadores que irão disputar a partida,
quantos cartões foram aplicados, se houve expulsão ou não, quem é o técnico, quantos gols
foram marcados, e outros.
A solução desenvolvida neste período trata de uma primeira versão da aplicação
final, todas essas características das súmulas oficiais são tratadas informatizando o processo
8
de controle das partidas de futebol de salão, porém, de forma ainda primitiva visando o seu
melhoramento gradativo.
A solução desenvolvida trata-se de um software disponível em mais de uma
plataforma, substituindo a súmula utilizada nos dias atuais por uma súmula digital, onde são
armazenadas todas as informações coletadas durante uma partida de futebol de salão, os
cartões utilizados pelos árbitros por um dispositivo móvel portando a versão mobile da
aplicação e efetuando a troca de informações dos auxiliares para os árbitros ou vice-versa.
1.1 Problemática
As partidas de futebol de salão são grandes geradoras de informações que necessitam
de controle e gerenciamento. É possível a criação de um software gerenciador dessas
informações e, ainda, a melhoria da troca de informação entre árbitro e mesários com um
sistema móvel?
1.2 Objetivos
1.2.1 Geral
Analisar e desenvolver um software multiplataforma (WEB e Móvel), para gerenciar
as informações obtidas em uma partida de futebol de salão. Esta aplicação deverá identificar a
melhoria da eficiência na coleta, no armazenamento e na utilização das informações para
tomada de decisão.
1.2.2 Específicos

Pesquisar em meio às entidades e órgãos responsáveis pela organização de
torneios de futebol de salão em Balsas - MA, os métodos utilizados atualmente
na coleta dessas informações;

Pesquisar e analisar softwares desenvolvidos para a solução de problemas
similares ao proposto;

Identificar os requisitos funcionais e não funcionais para o desenvolvimento da
aplicação;

Especificar o conjunto de ferramentas e linguagens de programação para o
desenvolvimento do software;

Desenvolver o software proposto usufruindo das técnicas utilizadas nos
modelos de processo de software;
9
1.3 Justificativa
Nas partidas de futebol de salão geram-se vários dados que devem ser trabalhados e
armazenados para que seja possível a organização e gerência desse tipo de evento. Há também
uma troca de várias informações entre os árbitros e seus auxiliares.
Uma partida de futebol de salão é representada oficialmente por uma súmula que, por
sua vez, é assinada por árbitros e preenchida por mesários com as informações obtidas ao
decorrer da partida, porém, todo o processo é feito de forma manual, consumindo muito
tempo e atenção de quem trabalha nesta atividade. A solução visa alterar um pouco esse
quadro tornando a súmula um documento digital que possa ser preenchido pelos mesários de
forma mais rápida e prática, e trazendo melhorias aos árbitros substituindo seus antigos
cartões por um doispositivo móvel.A manipulação do sistema será feita em paralelo e, ao final
de uma partida, as informações serão conciliadas entre o dispositivo móvel e o computador,
mesmo em locais onde a conexão à internet ainda é inexistente.
1.4 Metodologia
No trabalho foram realizadas pesquisas bibliográficas sobre o desenvolvimento de
softwares multiplataforma, também, realizou-se uma pesquisa relativa a programas que
realizam as mesmas funções ou funções parecidas ao software proposto, foram encontradas
algumas soluções parciais ao problema proposto, mas não capaz de suprir todas as suas
necessidades. Foi feita uma análise do problema para o levantamento dos requisitos, o
desenvolvimento
da
aplicação
seguindo
as
técnicas
trabalhadas
no
modelo
de
desenvolvimento em espiral, que mais se adequou ao problema apresentado, tomando como
base bibliográfica o livro de Engenharia de Software (SOMMERVILLE, 2003). Foi realizada
uma pesquisa através de documentos oficiais da CBFS para um melhor entendimento do
processo de armazenamento de informação por meios convencionais.
A pesquisa foi realizada através de documentação indireta (pesquisa em livros,
artigos e outros), e através de documentação direta (pesquisa de campo, incluindo a
observação de como é feito o trabalho dos mesários e árbitros nas disputas dos campeonatos
de futebol de salão).
10
2 REVISÃO BIBLIOGRÁFICA
Houve a necessidade de conhecer alguns conceitos necessários para o
desenvolvimento do trabalho como, por exemplo, obras sobre o assunto, artigos de eventos
relacionados ao tema em questão, artigos e documentos oficiais sobre as regras e leis que
regem o regulamento do futebol de salão, da ferramenta de desenvolvimento WEB Grails, da
linguagem de desenvolvimento web HTML 5, CSS 3 e Java Script de algumas ferramentas e
plug-ins que auxiliam no desenvolvimento da aplicação, como o phonegap, e tudo que está
direcionado ao desenvolvimento da aplicação.
Em relação a escolha da plataforma utilizada para o desenvolvimento da aplicação,
questionou-se muito para que tipo de público seria destinado a aplicação. A decisão de utilizar
uma plataforma WEB usufruindo da linguagem HTML 5 foi praticamente unânime por
existirem inúmeras características positivas em relação a linguagem. Em algumas de suas
características podemos citar, por exemplo, o dinamismo e a praticidade da plataforma para
com diversos meios de acesso, seja por meio de aparelhos móveis ou fixos com sistemas
operacionais distintos.
Para a versão mobile do sistema, mais uma vez levou-se em consideração a
praticidade e o dinamismo optando-se, assim, por se trabalhar com a própria linguagem de
script HTML 5, CSS 3, Java Script e ferramentas para aumentar a flexibilidade da aplicação e
a não limitação a uma só plataforma como o framework Phonegap.
2.1 As Regras e Leis do Futebol de Salão
O futebol de salão, assim como em outros esportes, baseia-se em regras e leis
específicas e gerais que contemplam o livro nacional de regras da confederação brasileira de
futebol de salão. Estas regras servem para criar um padrão oficial para o esporte e, assim,
tornar todas as partidas de futebol de salão, que seguem esse padrão, oficiais.
A aplicação a ser desenvolvida se baseia em algumas regras deste livro que se fazem
necessárias para a criação da súmula, como o número de atletas por equipe, árbitros principais
e auxiliares, cronometrista e anotador, duração da partida, faltas e incorreções, tiros livres,
penalidades, decisão por penalidades, a própria súmula e o modelos de relatórios gerados,
conforme é possível verificar no Livro de Nacional de Regras, aprovado pela FIFA, da
Confederação Brasileira de Futebol de Salão - CBFS.
11
2.2 Definição das Plataformas de Desenvolvimento
Após muitas dúvidas levantadas e algumas pesquisas realizadas, definiu-se que as
plataformas de desenvolvimento, tanto para a versão WEB quanto para a versão Mobile,
seriam voltadas para uma maneira onde as duas se comunicariam de uma melhor forma, ou
seja, as duas seriam desenvolvidas em uma linguagem parecida para a melhoria da
comunicação entre si.
Levando em consideração as definições anteriormente concluídas, decidiu-se que as
a linguagem utilizada para o desenvolvimento das aplicações seria a linguagem de Script
HTML 5, CSS 3 e Java Script. A partir destas definições, só restou decidir para qual
plataforma seria desenvolvida a primeira versão mobile da aplicação, decidiu-se então que a
escolhida seria a Android por se tratar da plataforma que vem sendo mais utilizada no mundo
dos mobiles.
Segundo uma pesquisa realizada pela Kantar World panel Comtech, e divulgada no
jornal britânico The Guardian em Abril de 2011, o sistema Android teve uma elevação nas
vendas em todos os países pesquisados. Somente em dois desses países o sistema não é líder
de mercado. Na Itália a liderança é do Sybian, sistema da Nokia, e na Austrália a liderança é
do iOS, da Apple. Mas, também segundo a pesquisa, o Android em poucos meses virará o
jogo nesses países, pelo fatídico crescimento de 17% e 25,6% na Itália e Austrália
respectivamente.
Com um público maior e com uma maior facilidade de disponibilidade da aplicação a
esse público, definiu-se então que a aplicação móvel seria desenvolvida para essa tecnologia.
A aplicação Web ficou mais a critério da “dominância” da linguagem e da facilidade de se
trabalhar Java utilizando Grails, e pela facilidade em sincronização entre as tecnologias, já
que dispunham da mesma linguagem.
2.2 Grails
O framework de aplicações web Grails, segundo ANSELMO (2010), é um
framework completo para a máquina virtual Java, por tirar proveito da linguagem de
programação Groovy e fornecer uma experiência de desenvolvimento produtivo e de fluxo
alinhado.
12
Este framework foi à base do desenvolvimento da versão WEB da SUMDIG, pois,
utilizando suas ferramentas, foi possível sua utilização de forma integral no funcionamento da
aplicação, até mesmo na manipulação dos dados gerados pela aplicação com o banco de dados
da mesma.
Segundo ANSELMO (2010), a ferramenta Groovy Grails Tool Suite – GGTS, é um
ambiente de desenvolvimento para criação de aplicações Grails, podendo ser utilizada
também, na criação de aplicações em linguagens distintas.
A GGTS fornece suporte para as últimas versões de Grails, e suporta aplicação de
direcionamento para servidores locais, virtuais e em nuvem e, também, é uma ferramenta
open source e com um ambiente de desenvolvimento bastante interativo, conforme mostrado
na figura 1.
Figura 1 - Ambiente de Trabalho do GGTS
Fonte: Print Screen da aplicação no sistema operacional Windows 8.
O paradigma de configuração baseado em conversão trabalha para preparar todas as
configurações necessárias para qualquer tipo de necessidade básica. Este paradigma dispõe de
uma flexibilidade para as necessidades específicas, que apareça no desenvolvimento da
aplicação.
13
O Grails gera, de forma automática, muitos detalhes necessários em uma aplicação
WEB. Assim obteve-se pronta uma aplicação web em um curto espaço de tempo, e com uma
mínima complexidade possível.
O framework Grails baseia-se em tecnologias abertas e conhecidas como a Spring
que é um framework de código aberto não intrusivo para plataforma Java baseado nos padrões
de projeto de inversão de controle e injeção de dependência (JOHNSON, 2002), e, também, o
Hibernate que é um framework que cuida do mapeamento das classes Java para tabelas de
banco de dados e de tipos de dados SQL (KING, 2001).
O principal objetivo do Grails é disponibilizar caminhos simples e fáceis para o
desenvolvimento de um sistema web de uma forma bastante rápida.
Grails foi desenvolvido para projetos rápidos e fáceis sem deixar de lado a qualidade
e a eficiência se enquadrando perfeitamente para o objetivo principal deste projeto, por isso,
este framework foi escolhido para o desenvolvimento da aplicação.
2.2.1 Scaffolding
O Grails possui uma estrutura scaffolding, um recurso que gera aplicações do tipo
CreateRead Update Delete – CRUD, de forma automática com uma quantidade mínima de
código, proporcionando ao desenvolvedor apenas a preocupação da definição na classe de
domínio Groovy as propriedades do atributo, seu comportamento e suas restrições. Após o
CRUD das classes, o Scaffolding identifica o comportamento do controle e cria as GPS
(Groovy Server Pages) que estão associadas com as funcionalidades do CRUD nas classes de
domínio. Também gera, ao mesmo tempo, o esquema de banco de dados, criando as tabelas e
seus respectivos relacionamentos para cada uma das classes de domínio.
2.2.2 Plugins
O Grails fornece uma arquitetura plug-in e uma comunidade onde são encontrados
vários plugins para aspectos como segurança, análise, pesquisa, comunicação e web services.
2.2.3 Jetty
Para garantir um completo ambiente de desenvolvimento, o Grails disponibiliza de
um servidor web jetty, que já é pré-configurado para qualquer aplicação gerada, isso permite
realizar testes sem a necessidade de instalar um Apache Tomcat, por exemplo.
14
O servidor jetty, segundo LECHETA (2012), é um servidor HTTP e Servlet
Container 100% escrito na linguagem Java. Ele é um grande concorrente do servidor Tomcat,
e ficou mais conhecido por ser utilizado como o servlet container do JBoss.
A grande vantagem do Jetty com relação ao Tomcat e a sua fácil configuração.
2.2.4 Arquitetura Grails
A figura 2 mostra a arquitetura do Grails.
Figura 2 - Arquitetura Grails
Fonte: Grails: desenvolvimento web sem grandes dores de cabeça.1
Podemos perceber que a base do Grails é a máquina virtual Java, no nível acima da
JVM, temos duas linguagens de programação sendo usadas, que é o Java e o Groovy
respectivamente. Acima destas linguagens encontramos o Grails em si, que é composto por
vários componentes à exemplo de Spring, Site Mesh e GORM. O Grails não se limita apenas
ao uso de bibliotecas Groovy, pode usar qualquer biblioteca Java, seja de código aberto ou
proprietário.
A camada final, não poderia deixar de ser a camada das aplicações. É nesta camada
que são desenvolvidos as aplicações do sistema, seguindo um padrão MVC que torna mais
simples a sua organização e execução.
1
Disponível em: http://www.dsc.ufcg.edu.br/~pet/jornal/fevereiro2009/materias/informatica.html. Acesso em
Dezembro de 2013.
15
2.2.5 Git
O Git é um sistema de controle de versão distribuído, livre e de código aberto
desenhado para lidar com tudo, desde pequenos a grandes projetos com rapidez e eficiência.
(CHACON, 2013).
Esta ferramenta foi utilizada no desenvolvimento da aplicação como forma de
sincronismo de informações com o repositório Git. É uma ferramenta fácil de se aprender e
supera ferramentas SCM como Subversion, CVS, Perforce, e Clear Case com recursos como
ramificações locais baratas, convenientes áreas de estágio, e vários fluxos de trabalho.
Git é rápido. Com Git, quase todas as operações são realizadas no local, dando-lhe
uma enorme vantagem de velocidade em sistemas centralizados que constantemente tenham
que se comunicar com um servidor em algum lugar.
Git foi construído para trabalhar no kernel do Linux, o que significa que ele teve de
lidar eficazmente com grandes repositórios, salvo que Linux é open source, sendo assim o
maior repositório de códigos fontes existente. Git é escrito em C, reduzindo a sobrecarga de
tempos de execução associados com linguagens de alto nível.
2.2.6 A linguagem Groovy
A linguagem Groovy foi utilizada no desenvolvimento da interação da aplicação com
o banco de dados por se tratar de uma linguagem totalmente integrada ao Grails.
Esta linguagem de programação é uma linguagem script e dinâmica destinada a
Máquina Virtual Java – JVM, suportando o padrão Java de construção, segundo afirmações
de GRAHL (2010). Ela também fornece muitas simplificações ou facilitações na escrita em
relação ao padrão de características da própria linguagem Java.
A linguagem groovy é uma forma simplificada da linguagem Java, tendo como
principais diferenças a utilização do ponto e vírgula no final das linhas sendo opcional, a
palavra-chave return deixa de existir uma vez que o Groovy assume o valor do último
comando de uma função como sendo o valor a ser retornado, valor bolleanoTrue assumindo
qualquer valor diferente de null como sendo verdadeiro, possui também uma forma
simplificada para representação de beans não havendo mais a necessidade de criar os
gettersesetters para cada atributo do bean, o tratamento de Strings com as concatenações
facilitadas e algumas outras alterações que facilitam a vida do utilizador da linguagem para
criação de aplicações web.
16
2.3 Android
Em 2007, a Google tornou pública a primeira plataforma Open Source de
desenvolvimento para dispositivos móveis baseada na plataforma Java com o sistema
operacional Linux, ganhando o nome de Android. Por ela ser código aberto, tornou-se alvo
dos desenvolvedores Java de todo o Mundo. Android é uma plataforma totalmente voltada
para o desenvolvimento de aplicações para dispositivos móveis como smartphones e tablets.
A aplicação desenvolvida está voltada para uma tecnologia flexível para todas as
plataformas mobile existentes, porém, a plataforma foco foi o Android, por se tratar de uma
plataforma aberta e de fácil acesso.
2.3.1 Plataforma Android
A plataforma Android foi, inicialmente, desenvolvida e mantida pela Google. Hoje
em dia é mantida pelo Open Handset Alliance, que é um grupo composto por mais de 30
empresas, as quais se uniram para inovar e acelerar o crescimento do desenvolvimento de
aplicações, serviços, e melhorando os recursos utilizados por seus consumidores.
Esta plataforma foi desenvolvida utilizando o sistema operacional Linux,
incorporando todas as suas características.
2.3.2 A Arquitetura Android
Afirma RABELLO (Pág. 02) que a plataforma Android está dividida em várias
camadas: Applications, Aplication Framework, Libraries e Android Runtime; e Linux Kernel.
Na camada Applications, encontra-se localizada uma lista de aplicações padrões que
incluem programas de SMS (Short Message Service - Serviço de Mensagens Curtas),
calendário, mapas, navegadores, gerenciadores de contatos, serviços de e-mails, todos criados
em linguagem Java. Na camada Framework, são encontrados os componentes que permitiram
que novas estruturas sejam utilizadas para a criação de novas aplicações enfatizando a ideia
da reutilização de códigos.
São componentes da camada Framework:

Um rico e extensível conjunto de componentes gráficos que pode ser utilizado
para construir uma aplicação como listas, grids, caixas de textos, botões, e até
um navegador web embutido.
17

Provedores de conteúdo que habilitam às aplicações acessar dados de outras
aplicações como os “Contatos” gravados na memória interna do aparelho, por
exemplo, ou compartilhar seus próprios dados.

Gerenciador de recursos que prove acesso a recursos não-codificados como
strings, gráficos, e arquivos de layout.

Um gerenciador de notificação que permite que todas as aplicações exibam
mensagens de alerta personalizáveis na barra de status.

Um gerenciador de atividade que gerencia o ciclo de vida das aplicações e
permite controlar os recursos previamente alocados, sendo que caso eles não
estejam sendo mais utilizados, os mesmos são desalocados para liberar
memória.
A próxima camada está dividida em um grupo de bibliotecas (Libraries) e o
ambiente de execução (Runtime) da plataforma Android, composto pelas bibliotecas padrão e
pela máquina virtual chamada de Dalvik.
Estas são as bibliotecas que são utilizadas pela plataforma Android:

Biblioteca de sistema C: é uma implementação da biblioteca C padrão (libc),
otimizada para dispositivos que suportam a plataforma Linux (embbededlinux).

Bibliotecas de Mídias: as bibliotecas suportam execução e gravação da maioria
dos formatos de áudio e vídeo, bem como exibição de imagens, incluindo
MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG.

Gerenciador de Superfície: gerencia o acesso ao display do dispositivo e
camadas de gráficos 2D e 3D de múltiplas aplicações.

Lib Web Core: uma moderna engine de navegador web que turbina tanto o
navegador da plataforma Android e um outro navegador qualquer
desenvolvido.

SGL: uma engine de gráficos 2D.

3D libraries: uma implementação baseada na especificação OpenGL ES 1.0, a
qual utiliza tanto aceleração de hardware 3D e um avançado e otimizado
software para renderização de modelos tridimensionais.

Free Type: renderização em formatos bitmaps e vetoriais de fontes.
18

SQ Lite: uma ponderosa e leve engine de banco de dados relacional disponível
para todas as aplicações.
Toda e qualquer aplicação Android é executada em seu próprio processo, ou seja, no
contexto de sua instância de máquina virtual. Essa máquina foi escrita para que dispositivos
possam suportar múltiplas máquinas funcionando de forma eficiente.
Na base está localizado o Kernel Linux, que para o Android será a versão 2.6,
fornecendo serviços do núcleo do sistema com segurança, gerenciamento de memória,
gerenciamento de processos, pilhas, etc. A figura 04, mostra como fica disposta esta
arquitetura.
Figura 3 - Camadas da Arquitetura Android
Fonte: Conhecendo o Android2
2.3.3 Interface Gráfica e Layouts
Os principais itens que compõe a interface gráfica são os Views e os Viewgroups.
(RABELLO, pág. 05).
2
Disponível em: http://www.dicas-l.com.br/arquivo/conhecendo_o_android.php#.Ut6rq9JTtkh.
Acesso em Junho de 2013.
19
Um view é representado pela classe android.view.View. Este componente nada mais
é do que uma estrutura de dados que representa uma área retangular limitada da tela do
dispositivo, é a área que deverá ser explorada pelo desenvolvedor para ter a noção de largura e
altura, desenho, mudança de foco, capacidade de rolagem (Scrolling) e capturas de comandos
simulando as teclas dos dispositivo que são percebidas e determinadas por aquela área
específica. Esta classe pode se estender e serve de base para outros widgets, que segundo
Emmanuel (2008), é um componente de interface gráfica composta por botões, menus,
janelas, etc., e que permite adicionar ao sistema operacional uma funcionalidade específica,
como por exemplo, widgets de relógio, previsão do tempo, e assim por diante.
A plataforma vem equipada com vários widgets já disponíveis, prontos para serem
usados, como: Text, EditText, InputMethod, MovementMethod, Button, RadioButton,
Checkbox, e o ScrollView.
O outro componente está presente na classe android.view.Viewgroup. Um Viewgroup
pode ser considerado um layout, isto é, um container de Views (e também de Viewgroups) que
pode ser utilizado para criar estruturas mais complexas, ricas e robustas. Um Viewgroup é a
classe de layouts do Android, constituída por LinearLayout, RelativeLayout, AbsolutLayout,
etc. No momento em que o método setContentView() é chamado, o mesmo recebe uma
referência para o nó raiz da árvore que representa o layout a ser mostrado. A figura 4 mostra
um árvore hierárquica formada por Views e Viewgroups.
Figura 4 - Hierarquia de Views e Viewgroups
Fonte: Artigo WebMobile 21 – Construindo Layouts Completos em Android3
2.4 Framework PHONEGAP
O Framework PHONEGAP é considerado um dos melhores para mobile web
aplications, tornando possível a fácil criação de aplicativos utilizando HTML, CSS e
3
Disponível em: http://www.devmedia.com.br/artigo-webmobile-21-construindo-layouts-complexos-emandroid/10761. Acesso em Maio de 2013.
20
JavaScript e sua distribuição em várias plataformas como, por exemplo, Android, Windows
Phone, IOS, e outros.
Segundo MARINHO (2012), para o desenvolvimento de um aplicação voltada a
plataforma Android, a plataforma escolhida para este projeto, deve-se seguir algumas
orientações e obter alguns pré-requisitos como o Java JDK, que é um kit de desenvolvimento
java, e do Apache Ant, que é uma ferramenta utilizada para automatizar a construção de
software.
Após os pré-requisitos prontos deve-se instalar o SDK do Android, o Eclipse e o
plugin ADT. A ADT–bundle é um pacote composto pelo mínimo necessário para o início do
desenvolvimento de uma aplicação para Android, nela estão contidos a Android SDK Tools
(API e ferramentas para a construção, testes e debugs dos aplicativos), Android Platform
Tools (Ferramenta para o controle das variadas versões do Android que serão emuladas para
testar o aplicativo) e a última versão do Android para ser emulado.
Assim como o ambiente GRAILS, o ambiente Phonegap também é bastante
agradável e de fácil manuseio, como pode ser notado na figura a seguir.
Figura 5 - Ambiente ADT-Bundle
Fonte: Print Screen da aplicação em execução no sistema operacional Windows 8.
Este framework foi utilizado no desenvolvimento da versão mobile da aplicação uma
vez que, segundo Frederico MARINHO (2012), este framework proporciona uma maior
flexibilidade na implantação da aplicação e por ser de fácil utilização em projetos rápidos.
Segundo Marcel GUINTHER (2011) o Phonegap é uma tecnologia open source que
tem como característica principal o desenvolvimento de aplicativos webapp, que poder ser
instalados e operados em ambientes online ou off-line e, também, em várias plataformas.
21
Para que não haja conflitos e que se adeque às linguagens nativas de cada plataforma,
ele utiliza dos melhores padrões web, que é a linguagem de script HTML, as de estilo CSS e
de programação JavaScript, tornando o desenvolvimento de uma aplicação bastante simples.
Dentro da realidade brasileira, onde há uma vasta variedade de aparelhos
comportando sistemas nativos variado, tamanhos de telas variados, e comprando a ideia
inicial da utilização da aplicação em smartphones, os arquivos CSS são encarregados de
exibir a aplicação corretamente.
O Phonegap também possui suporte a alguns recursos de extrema utilidade dos
aparelhos. A figura 6 mostra alguns desses recursos suportados pela API (Interface de
Programação de Aplicativos) do Phonegap:
Figura 6 - Recursos Phonegap
Fonte: Desenvolvimento Mobile Multiplataforma com Phonegap.4
Esta é uma tecnologia indicada para projetos de menor porte, como é o caso da
aplicação desenvolvida.
2.5 O Framework ANGULARJS
O framework JavaScript ANGULARJS utiliza a linguagem HTML 5 como uma
“templateengine”, ou seja, um motor de modelos, para poder fornecer uma solução completa
para os desenvolvedores de aplicações WEB. Segundo Wilson Mendes (2013) o
4
Disponível em: http://www.mobiltec.com.br/blog/index.php/desenvolvimento-mobile-multiplataforma-comphonegap/. Acesso em Junho de 2013.
22
ANGULARJS é um conceito novo em desenvolvimento de WEB APPS e tem total
compatibilidade com as bibliotecas JavaScript mais utilizadas, como o jQuery.
Esta ferramenta foi utilizada na construção do front-end da aplicação, ou seja, na
parte visível ao utilizador da aplicação na versão web.
No registro de pessoas utilizou-se uma data binding, ou seja, uma ligação de dados
que em aplicações angular é a sincronização automática de dados entre o modelo e os
componentes de visualização. Quando o modelo for alterado, o ponto de vista reflete a
mudança, e vice-versa.
A maioria dos sistemas de templates vinculam dados em uma única direção: eles
unem o template e o modelo para, posteriormente, serem visualizados como ilustrado na
figura a seguir.
Figura 7 - One-Way Data Binding
Fonte: Vinculação de dados em sistemas modelo clássico.5
Somente após a união do modelo e do template é que as alterações poderão ser
visualizadas.
Já nos modelos angulares a forma como ocorre essa interação de dados é
diferenciada, porque o modelo é compilado no browser e essa compilação produz uma
exibição ao vivo, como mostrado na figura 8.
5
Disponível em: http://docs.angularjs.org/guide/databinding. Acesso em Maio de 2013.
23
Figura 8 - Two-Way Data Binding
Fonte: Vinculação de dados em modelos angulares.6
Todas as alterações à vista são refletidas diretamente no modelo, isso simplifica o
modelo de programação para o desenvolvedor.
2.6 O IDE Eclipse
O Ambiente Integrado de Desenvolvimento (IDE) Eclipse começou a ser criado em
1998 pela IBM. Em paralelo, a IBM iniciou a preparação de equipes para a criação de novos
produtos construídos sobre esta plataforma. A IBM criou o consórcio Eclipse juntamente com
outras oito organizações em virtude de dificuldades encontradas no inicio em encontrar
parceiros comerciais, tornando-o assim, um modelo de código aberto.
Em 2004 foi criada a Eclipse Foundation, com o objetivo de desvincular o projeto da
IBM. Esta fundação é independente, sem fins lucrativos, possui sua própria equipe e é
mantida através de doações das próprias organizações que a compõe. Após essa mudança, foi
lançado o Eclipse 3.0 seguido da versão 3.1, que foram aceitas com um nível muito maior que
as versões anteriores em meio a comunidade mundial de programadores.
O Eclipse é conhecido mais comumente no desenvolvimento em Java, no entanto,
por meio de plug-ins, ele pode ser usado no desenvolvimento de aplicações em várias
linguagens, como C/C++, Python, PHP e inclusive para a plataforma Android. Seguindo com
base nestas informações, esta IDE foi utilizada no desenvolvimento da aplicação nas versões
mobile e web, por suportar o desenvolvimento de projetos Phonegap, através do ADT Bundle
(Plugin que comporta o SDK Android), Angularjs e por dar suporte ao desenvolvimento de
aplicações utilizando GRAILS, ou seja, todas as ferramentas utilizadas no desenvolvimento
desta aplicação.
6
Disponível em: http://docs.angularjs.org/guide/databinding. Acesso em Maio de 2013.
24
3 DESCRIÇÃO DO FUNCIONAMENTO DO SISTEMA
A SUMDIG é um sistema criado para substituir futuramente o processo realizado
atualmente na oficialização de campeonatos de futebol de salão.
Este aplicativo está distribuído em duas versões, a mobile e a web, funcionando em
complemento de um ao outro.
3.1 A Versão Mobile
A versão Mobile é a versão que será acessada em um smartphone através de qualquer
navegador, independente do sistema operacional instalado. O dispositivo deverá estar em
posse dos árbitros da partida substituindo os cartões utilizados normalmente nos dias atuais.
Nos smartphones, os árbitros terão acesso às informações cadastradas no software,
das duas equipes em disputa. O software irá se redesenhar automaticamente para que o árbitro
não tenha dificuldades para entender as informações. A figura a seguir mostra a tela inicial da
aplicação em um smartphone com o sistema operacional Android instalado.
Figura 8 - Tela principal da aplicação SUMDIG em um dispositivo móvel
Fonte: Print Screen da tela inicial da aplicação utilizando um dispositivo móvel na versão 4.2 do Android
25
Na versão mobile os árbitros terão acesso a todas as funcionalidades do software,
porém, por questões de agilidade da utilização da aplicação, não haverá a necessidade de
cadastro, todo esse trabalho deverá ser pré-cadastrados pelo mesário, assim, os árbitros
acessarão as listagens do que estão cadastrados no sistema, como mostra as telas a seguir.
Figura 9 - Telas de listagem da aplicação SUMDIG em um dispositivo móvel
Fonte: Print Screen das telas de listagem da aplicação em um dispositivo móvel utilizando a versão 4.2 do Android
A função dos árbitros será apenas o registro dos cartões, amarelo e vermelho, para as
equipes no decorrer da partida.
3.2 A Versão WEB
Na versão WEB há uma pequena diferença no Layout da tela inicial, porém as
mesmas funcionalidades mostradas anteriormente serão trabalhadas nesta versão. Confira na
figura a seguir a tela inicial da aplicação SUMDIG.
26
Figura 10 - Tela inicial da aplicação SUMDIG
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
Na tela inicial encontram-se todas as funcionalidades da aplicação, o cadastro das
equipes, cadastro dos jogadores, cadastro das pessoas que participarão da partida como
mesários e cronometristas, o registro dos jogos, dos árbitros, da comissão técnica, os dados
informativos e opcionais registrados na súmula, os cartões, faltas, gols e pedidos de tempo das
equipes ao decorrer da partida.
O registro das equipes deverá ocorrer primeiramente, pois a partir deste momento os
outros cadastros que necessitam da equipe estarão aptos a serem preenchidos, como por
exemplo, o registro dos jogadores, e a definição da partida. A figura a seguir mostra como
funciona o registro da equipe e a listagem das equipes registradas.
Figura 11 - Tela de Registro das equipes e a listagem das cadastradas
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
27
O cadastro de jogadores é feito da mesma maneira, porém, deverá ser informado
todos os dados do mesmo. Veja:
Figura 12 - Tela de registro de jogadores e tela de listagem dos cadastrados
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
A partir de então, após o registro das equipes e seus jogadores, podemos estar
registrando a equipe técnica e a equipe de arbitragem. Para o registro da equipe de arbitragem
há a necessidade do registro de pelo menos mais duas pessoas primeiramente, o mesário e o
cronometrista. Veja nas próximas telas como são feitos esses registros:
Figura 13 - Registro da Equipe Técnica
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
28
Figura 14 - Registro de Pessoas
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1
.
Figura 15 - Registo do Árbitro e a lista dos cadastrados
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
29
Figura 16 - Registro da Equipe de Arbitragem e a listagem da equipe registrada
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
A definição da partida trabalha da mesma forma, onde o mesário estará cadastrando
as informações necessárias para identificar a partida, como a seguir.
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
O preenchimento é bem simples, o mesário irá informar o número identificador da
partida (ID), a categoria (Adulto, juniores, etc.), o Grupo, a Chave e os dados sobre o local
onde ocorrerá o jogo (Cidade, UF, Competição, Data, a Fase e o nome do Ginásio).
Um fator bastante importante e o mais exercido pelo mesário é o registro das
atividades que ocorrem durante a partida, por exemplo, a quantidade de faltas, gols, pedidos
de tempo, cartões aplicados e placar do primeiro e segundo tempo de partida. Estas
informações serão adicionadas como é mostrado a seguir:
30
Figura 17 - Registro de cartões, faltas, gols, pedidos de tempo.
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
Estas informações serão mostradas na listagem de cada funcionalidade, como pode
ser verificador a seguir:
Figura 18 - Listagem das informações registradas no decorrer da partida.
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
Ao término da partida ou em seu decorrer, as observações e colocações da
arbitragem devem ser anotadas, então foi criada a funcionalidade chamada de sumula, onde
estas informações deverão ser registradas. Veja a seguir:
31
Figura 19 - Criação da sumula e a listagem das criadas.
Fonte: Print Screen da aplicação SUMDIG no Sistema Operacional Windows 8.1.
32
4 ARQUITETUA DO PROJETO
O projeto caracteriza-se pela interação das informações entre um dispositivo móvel e
um desktop conectado à Internet, conforme exposto na figura a seguir:
Figura 20 - Arquitetura do Projeto
Fonte: Elaborado pelo autor.
O dispositivo móvel com acesso a versão Web Mobile da aplicação terá acesso as
informações registradas através da rede, onde essas informações serão sincronizadas e
atualizadas conforme ocorrerá a partida. Essas informações coletadas e organizadas serão
armazenadas em um servidor nas nuvens.
33
5 CONCLUSÃO
Com o desenvolvimento da aplicação SUMDIG houve uma melhoria no processo de
preenchimento do documento que oficializa uma partida de futebol de salão, a súmula. A
aplicação torna o processo de busca, atualização e preenchimento destas informações mais
prático e rápido.
Apesar dos bons resultados obtidos no desenvolvimento da SUMDIG, ainda há a
necessidade de alterações e adequações futuras. Como trabalhos futuros podemos citar o
desenvolvimento de diferentes perfis de acesso à aplicação (O perfil torcedor, clube, árbitro
jogador, confederação), alterações na amostragem final dos resultados, possibilitar a emissão
de um relatório ao final de cada partida/torneio. Com isso, nota-se então que o objetivo do
trabalho foi concluído, mas outras funcionalidades devem ser adicionadas ao software.
34
REFERÊNCIAS
Livros:
SOMMERVILLE, I. (2003). Engenharia de Software. (6ª ed.). (A. M. Ribeiro, Trad.) Adisson
Wesley: Pearson.
Internet:
Android é o sistema que mais cresce no mundo, diz pesquisa. (01 de Junho de 2013). Fonte:
Terra: http://tecnologia.terra.com.br/celular/android-e-o-sistema-que-mais-cresce-no-mundodiz-pesquisa,34788a19d13ea310VgnCLD200000bbcceb0aRCRD.html
Android é o sistema que mais cresce no mundo. (18 de Maio de 2013). Fonte: Terra
Tecnologia: http://goo.gl/huWKR
Artigo: o Android é seguro? (02 de Junho
http://itweb.com.br/59504/artigo-o-android-e-seguro/
de
2013).
Fonte:
IT
WEB:
Conheça a súmula utilizada nos jogos. (31 de Março de 2013). Fonte: Futsal do Brasil:
http://www.futsaldobrasil.com.br/2009/cbfs/sumula.php
CHACON, Scott. GIT – rápido e fácil. (16 de Maio de 2013). Fonte: GIT-SCM: http://gitscm.com/about/small-and-fast
GRAHL, C. A. (16 de Maio de 2013). Groovy & Grails. Fonte: SOA SOA BEM:
http://soasoabem.blogspot.com.br/2010/02/groovy-grails-tutorial.html
Groovy/Grails Tool Suite. (28 de Maio de 2013). Fonte: Grails: http://grails.org/products/ggts
Hibernate. (01 de Junho de 2013). Fonte: Hibernate: http://www.hibernate.org/about/history
JONHSON, R. (10 de Junho de 2013). Introduction to Spring Framework. Fonte: Free Java
Basic Books: http://www.freebookcentre.net/Java-Books-Download/Introduction-to-SpringFramework-(Rod-Johnson)-PDF.html
KING, G. (10 de Junho
http://www.hibernate.org/
de
2013).
Framework
Hibarnate.
Fonte:
Hibernate:
MARINHO, Frederico. (06 de Novembro de 2013). Instalando Phonegap com Eclipse IDE:
preparando o ambiente para programação Android no Windows. Fonte:
http://www.fredericomarinho.com/instalando-phonegap-com-eclipse-ide-preparando-oambiente-para-programacao-android/
O esporte da bola pesada que virou uma paixão. Origem do Futsal. (31 de Março de 2013).
Fonte: Futsal do Brasil: http://www.futsaldobrasil.com.br/2009/cbfs/origem.php
O que é Grails? (28 de Maio de 2013). Fonte: ITexto: http://www.itexto.net/devkico/?p=224
O que são Gadgets e Widgets? (28 de Maio de 2013). Fonte: Código Fonte:
http://www.codigofonte.net/dicas/web/391_o-que-sao-gadgets-e-widgets
35
RABELLO, R. R. (12 de Maio de 2013). Android: um novo paradigma de desenvolvimento
móvel. Fonte: CESAR: http://www.cesar.org.br/site/files/file/WM18_Android.pdf
RhoSync Tutorial. (29 de Maio de 2013). Fonte: RHO Mobile:
http://docs.rhomobile.com/rhosync/tutorial
LECHETA, Ricardo Rodrigues.Introdução ao JETTY. (28 de Maio de 2013).
http://www.devmedia.com.br/introducao-ao-jetty/1982
36
ANEXOS
37
ANEXOS A - Documento de Requisitos
SUMDIG
A Súmula Digital
Versão 0.04
MAURICIO DA COSTA GOMES
Balsas-MA
2013
38
Histórico de Revisão
Data
Versão
Descrição
Autor
09.05.2013
0.01
Criação de Requisitos Funcionais [RF]
Maurício
11.05.2013
0.02
Inclusão dos Requisitos Não Funcionais
Maurício
[RNF]
12.07.2013
0.03
Inclusão dos Diagramas de Classes [DC]
Maurício
12.11.2013
0.04
Atualização do Documento de Requisitos
Maurício
39
Introdução
Finalidade
Esse documento tem por finalidade reunir todas as informações necessárias para o
desenvolvimento da súmula digital multiplataforma para a gerência de informações de uma
partida de futebol de salão.
Visão geral do Documento
O documento está subdividido em passos de uma etapa do desenvolvimento do software, que
é o documento de requisitos, onde mostra passo a passo como funciona os requisitos
funcionais e não-funcionais.
40
Requisitos Funcionais
[RF 01 – Cadastro de Integrantes] Na tela inicial do sistema deverá conter campos para
cadastro de integrantes, proporcionando ao usuário do sistema as opções de cadastrar um
nome ao integrante, um código de registro, uma opção para definir a qual perfil esse
integrante se encaixa (Técnico, Atendente, Preparador Físico, Médico, Fisioterapeuta,
Jogador, Arbitro 1, Arbitro 2, Anotador, Cronometrista, Representante) e um botão para
salvar o cadastro.
[RF 02 – Cadastro da Partida] Caso a partida ainda não esteja cadastrada, o sistema deverá
fornecer a opção para cadastrá-la, recebendo os dados coletados na sumula manual, que são:
os nomes das duas equipes que se enfrentarão e o horário que a partida iniciará.
[RF 03 – Registro do Jogo] Nesta opção deverá ser informado os dados do jogo (Categoria,
Chave, Cidade, Competição, Data, Fase, Ginásio, Grupo, Número do Jogo e UF).
[RF 03 – Cadastro de Equipes] O sistema deverá conter um cadastro de equipes simulando a
súmula real e oficial, com todos os campos da sumula utilizada em partidas oficiais.
[RF 04 – Interface do Dispositivo Móvel] O sistema deverá contar com uma interface voltada
para dispositivo móvel contendo dois botões principais, o amarelo e o vermelho, uma vez que
a versão mobile substitui o cartão utilizado pelos árbitros e suas características de uso. Após
pressionar um dos botões a tela do dispositivo deverá estar na cor indicada pelo nome do
botão e, após um segundo clique, deverá ser mostrado o teclado numérico do dispositivo para
que o árbitro informe o número da camisa para qual o respectivo cartão será adicionado.
[RF 05 – Interface WEB] O sistema deverá contar com uma interface WEB voltada para o
usuário que irá gerir as informações ao decorrer da partida. Esta tela deverá conter, no menu
principal, todos as opções fornecidas na aplicação como: as opções de preenchimento em
tempo real (gols por etapa, cartões por etapa, pedidos de tempo, número de faltas cometidas
por ambas equipes por etapa), Cadastro das Equipes, Cadastro dos Integrantes (Árbitros,
Equipe Técnica e Jogadores).
41
Requisitos Não Funcionais
[RNF01 - Interface] A interface do sistema deverá ser flexível ao tamanho da tela do
dispositivo.
[RNF02 – Interação de Dados] A interação entre o dispositivo móvel e o fixo deverá ser feita
via Bluetooth.
[RNF03 - App-Offline] O aplicativo deverá ser desenvolvido utilizando técnicas app-offline.
[RNF04 - Armazenamento] O sistema deverá armazenar as informações coletadas em um
servidor nas nuvens.
Diagrama de Classes
[DC 01 – SUMDIG]
42
ANEXO B - Súmula Oficial da CBFS (Confederação Brasileira de Futebol
de Salão)
Figura 21 - Súmula Oficial da Confederação Brasileira de Futebol de Salão.
Fonte: Confederação Brasileira de Futebol de Salão.7
7
Disponível em: www.cbfs.com.br/. Acesso em Maio de 2013.
43
Figura 22 - Súmula Oficial da Confederação Brasileira de Futebol de Salão.
Fonte: Confederação Brasileira de Futebol de Salão.8
8
Disponível em: www.cbfs.com.br/. Acesso em Maio de 2013.