curso de anÁlise e desenvolvimento de sistemas...
TRANSCRIPT
CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
AMANDA LONGO PIRES
STHÉPHANE MACIEL RANGEL MEIRELES
TATIANA FREITAS DE SOUZA
INTEGRANDO ANDROID COM FRAMEWORK RUBY ON RAILS
ESTUDO DE CASO: APLICATIVO DE NOTAS E FALTAS
Campos dos Goytacazes/RJ
2013
II
AMANDA LONGO PIRES
STHÉPHANE MACIEL RANGEL MEIRELES
TATIANA FREITAS DE SOUZA
INTEGRANDO ANDROID COM FRAMEWORK RUBY ON RAILS
ESTUDO DE CASO: APLICATIVO DE NOTAS E FALTAS
Monografia de Conclusão de Curso Análise e
Desenvolvimento de Sistemas apresentada no
Instituto Federal de Educação, Ciências e
Tecnologia.
Orientador: Prof. Luiz Gustavo Lourenço Moura, DSC.
Campos dos Goytacazes/RJ
2013
III
AMANDA LONGO PIRES
STHÉPHANE MACIEL RANGEL MEIRELES
TATIANA FREITAS DE SOUZA
INTEGRANDO ANDROID COM FRAMEWORK RUBY ON RAILS
ESTUDO DE CASO: APLICATIVO DE NOTAS E FALTAS
Aprovada em 03 de outubro de 2013
Banca Avaliadora:
.............................................................................................................................................
Prof. Dr. Luiz Gustavo Lourenço Moura (orientador) Doutor em Engenharia de Sistemas e Computação/Coppe /UFRJ
Instituto Federal de Educação, Ciência e Tecnologia Fluminense / Campus
Campos Centro
.............................................................................................................................................
Prof. Dr. Breno Fabricio Terra Azevedo Doutor em Informática na Educação / UFRGS
Instituto Federal de Educação, Ciência e Tecnologia Fluminense / Campus
Campos Centro
{{
.............................................................................................................................................
Prof. Dr. Maurício José Viana Amorim Doutor em Informática na Educação /UFRGS
Instituto Federal de Educação, Ciência e Tecnologia Fluminense / Campus
Campos Centro
Monografia apresentada ao Instituto Federal
de Educação, Ciência e Tecnologia
Fluminense de Campos como requisito
parcial para conclusão do Tecnólogo em
Análise e Desenvolvimento de Sistemas.
IV
AGRADECIMENTOS
Agradeço ao nosso professor orientador que teve paciência e que nos ajudou bastante a
concluir este trabalho. Agradecemos também a Deus, pois sem ele não teríamos forças para
essa longa jornada.
V
"Há homens que lutam um dia e são bons.
Há outros que lutam um ano e são
melhores.
Há os que lutam muitos anos e são muito
bons.
Porém, há os que lutam toda a vida.
Esses são os imprescindíveis."
VI
Dedico essa monografia primeiramente a
Deus que me deu força para persistir no
término desse trabalho e meus pais que
sempre me ensinaram a nunca desistir de
alcançar os meus objetivos.
VII
RESUMO
Aplicativos mobile são softwares usados para funções específicas em dispositivos móveis
como smartphones e tablets. Eles estão disponíveis através de plataformas de distribuição de
aplicações que são normalmente operadas pelo proprietário do sistema operacional móvel,
como App Store, Android Market, BlackBerry App World, Ovi Store, entre outros. Alguns
aplicativos são gratuitos, e outros têm um preço. Normalmente eles são baixados da
plataforma para um dispositivo de destino, como um iPhone, BlackBerry, Android ou
telefone, mas às vezes eles podem ser baixados para computadores menos móveis, tais como
laptops ou desktops. A tecnologia móvel deixou de ser uma invenção para se tornar uma
revolução, pois foi capaz de atingir o quotidiano das pessoas e fazer parte da vida delas,
modificando suas rotinas e formas de tomar decisões. Este tipo de tecnologia permite o acesso
a dados e informações em qualquer momento e em qualquer lugar. Os aplicativos são
destinados à facilitar o desempenho de atividades práticas do usuário assim como para puro
divertimento.O presente estudo pretende facilitar o cotidiano dos professores do IFF , em
relação a nova forma de inserir notas e faltas dos alunos no Sistema Acadêmico pelo celular.
Esse aplicativo tem como objetivo, comodidade e rápido acesso em qualquer lugar durante o
fechamento de cada período.
Palavras chave: Android, Aplicativo, Plataforma e Tecnologia.
VIII
ABSTRACT
Mobile software applications are used for specific functions in mobile devices as smart
phones and tablets. They are available through distribution platforms for applications that are
typically operated by the owner of the mobile operating system, as the App Store, Android
Market, BlackBerry App World, Ovi Store. Some apps are free and others have a price.
Usually they are downloaded from the platform to a target device, like iPhone, BlackBerry or
Android phone, but sometimes they can be downloaded for computer less mobile, as laptops
or desktops. Mobile technology has ceased to be an invention to become a revolution, because
it was able to reach people's daily lives and be part of their lives, changing their routines and
ways of making decisions. This type of technology allows access to data and information
anytime and anywhere. The applications are designed to facilitate the performance of practical
activities of the user as well as for pure fun. The present study intends to facilitate the daily
lives of IFF teachers, regarding the new form of insert grades and absences of students in the
Academic System by phone. This application aims convenience and quick access anywhere
during the closing of each period.
Key words: Android, Application, Platform e Technology.
IX
LISTA DE CÓDIGOS
Código 1: Classe ConsultaAlunoTask....................................................................................................49
Código 2: Classe HTTPUtils....................................................................................................................50
X
LISTA DE FIGURAS
Figura 1: Logotipo do Android ................................................................................................... 9
Figura 2: Smartphone HTC-Mobile G1..................................................................................... 9
Figura 3: Arquitetura do Android ............................................................................................ 10
Figura 4: Ciclo de Vida BDD ................................................................................................... 21
Figura 5: Ciclo de Vida TDD ................................................................................................... 24
Figura 6: Esquema das camadas do padrão MVC .................................................................... 31
Figura 7: Caso de Uso .............................................................................................................. 34
Figura 8: Diagrma de Classe ................................................................................................... 35
Figura 9: Login e Senha .......................................................................................................... 40
Figura 10: Consultar Aluno ...................................................................................................... 40
Figura 11: Consultar Notas e Faltas ......................................................................................... 41
Figura 12: Cadastrar Notas e Faltas ........................................................................................ 41
Figura 13: Entidade-Relacionamento ...................................................................................... 42
Figura 14: Conexão Android e Servidor ................................................................................. 43
Figura 15: A Tela Inicial do Terminal Mobile IFF e o Menu Principal do Aplicativo........... 44
Figura 16: Telas para Gerência de Consulta de Alunos........................................................... 45
Figura 17: Tela de Consulta de Notas e Faltas......................................................................... 45
Figura 18: Menus que aparecem ao Clicar no Spinner de Curso e Disciplina .........................46
Figura 19: Tela para Edição de Notas e Frequências .............................................................. 47
XI
LISTA DE TABELAS
Tabela 1: Comparativo entre os processos da XP e do modelo em cascata ............................ 19
Tabela 2: Descrição da classe Curso ........................................................................................ 36
Tabela 3: Descrição da classe Disciplina ................................................................................ 36
Tabela 4: Descrição da classe CursoDisciplina ........................................................................ 36
Tabela 5: Descrição da classe Professor ................................................................................... 37
Tabela 6: Descrição da classe Turma ....................................................................................... 37
Tabela 7: Descrição da classe Aluno ........................................................................................ 37
Tabela 8: Descrição da classe TurmaAnoletivo ....................................................................... 38
Tabela 9: Descrição da classe Anoletivo .................................................................................. 38
Tabela 10: Descrição da classe CursoDisciplinaProfessor ....................................................... 38
Tabela 11: Descrição da classe AlunoTurmaAnoletivo .......................................................... 39
Tabela 12: Descrição da classe AnoletivoCursoDisciplinaProfessor ...................................... 39
Tabela 13: Descrição da classe NotasFaltas ........................................................................... 39
XII
LISTA DE ABREVIATURAS E SIGLAS
SMS – Short Message Service
API – Application programing Interface
BREW – Binary Runtime Environment for Wireless
IFF – Instituto Federal Fluminense
WEB – World Wide Web
AMPS – Advanced Mobile Phone System
TAC – Total Access Communication System
ETACS – Extended Total Access Communication System
SDK – Software development Kit
XML – Extensible Markup language
IDC – International Data Corporation
OHA – Open Handset Alliance
GPS – Global positioning System
AAC – Advenced Audio Coding
AMR – Adaptive Multi-Rate
JPG – Joint Photographic Experts Group
PNG – Portable Network Graphics
OpenGL – Open graphics Library
USB – Universal Serial Bus
NFC – Near Field Communication
ICS – Ice Cream Sandwich
J2ME – Java 2 Micro Edition
PC – Personal Computer
XP – Extreme programming
TDD – Test Driver development
HTML – Hypertext Markup Language
GUI – Graphical user Interface
MUC – Model View Controller
COC – Convention Over Configuration
DRY – Don’t repeat Yourself
SMTP – Simple Mail Transfer Protocol
CRUD – Create, Read, Update, Delete
XIII
JSON – Java Script Object Notation
ADP – Android Development Tools
ADT – Android Development Tools
HTTP – Hyper Text Transfer Protocol
URL - Uniform Resource Locator
SUMÁRIO
Capítulo I .................................................................................................................................... 3
1. Introdução ............................................................................................................................. 3
1.1 Motivação ......................................................................................................................... 3
1.2 Objetivo ....................................................................................................................... 4
1.3 Estrutura da Monografia ................................................................................................... 4
Capítulo II ................................................................................................................................... 6
2. Tecnologia Móvel . ................................................................................................................. 6
2.1 Plataforma Android .......................................................................................................... 7
2.2 História do Android ......................................................................................................... 8
2.3 Arquitetura do Android ................................................................................................... 9
2.4 Versões da plataforma Android ......................................................................................11
2.5 Android X IOS ...............................................................................................................14
2.6 Outras Plataformas .........................................................................................................15
Capítulo III ............................................................................................................................... 17
3. Metodologia Ágil de Desenvolvimento .............................................................................. 17
3.1 Metodologia Ágil XP (Extreme Programming) .............................................................. 17
3.2 Metodologia Ágil BDD (Behavior Driven Development) …………………………… 19
3.3 Metodologia Ágil Scrum ............................................................................................... 21
3.4 Metodologia Ágil TDD – Test Driver Development ..................................................... 22
3.5 Metodologia Ágil Kanban ............................................................................................. 24
3.6 Principais Diferenças entre Metodologia Tradicional e Ágil ......................................... 26
3.7 A Linguagem Ruby e o Framework Rails ...................................................................... 26
3.8 A Linguagem Ruby ......................................................................................................... 27
3.9 Ruby on Rails ................................................................................................................. 28
3.10 JSON ............................................................................................................................. 32
4
Capítulo IV ............................................................................................................................... 33
4. Desenvolvimento do Protótipo . ........................................................................................... 33
4.1 Requisitos de Software ................................................................................................... 33
4.1.1 Diagrama de Casos de Uso ..................................................................................... 34
4.1.2 Diagrama de Classe ................................................................................................. 35
4.1.3 Diagrama de Sequência ........................................................................................... 40
4.1.4 DER ......................................................................................................................... 42
4.2 Estudo de Casos .............................................................................................................. 42
4.2.1 A Aplicação .............................................................................................................. 43
4.2.1.1 Interface Inicial .................................................................................................. 43
4.2.1.2 Gerência de Consulta de Alunos ........................................................................ 44
4.2.1.3 Gerência de Consulta de Notas e Faltas ............................................................. 45
4.2.1.4 Gerência de Lançamento de Notas e Faltas ....................................................... 45
4.2.1.5 Gerência de Consulta de Notas e Faltas ............................................................. 46
4.2.2 O Processo de desenvolvimento ............................................................................... 47
4.2.2.1 A base de dados .................................................................................................. 51
4.2.2.2 Publicação.......................................................................................................... 51
Capítulo V................................................................................................................................ 52
5. Conclusão..............................................................................................................................52
5.1 Trabalhos Futuros...........................................................................................................52
Capítulo VI................................................................................................................................53
6. Bibliografia...........................................................................................................................53
3
Capítulo I
1. Introdução
Atualmente, ninguém mais consegue viver sem um aparelho celular. Ele é considerado
mais que essencial para o nosso dia-a-dia, o maior meio de comunicação de todo o tempo.
Mas o aparelho celular já foi grande e até mesmo estranho, sem toda essa tecnologia e
praticidade dos dias de hoje. Veja mais um pouco da evolução do aparelho celular
(FERNANDO, 2011).
Foi criado no ano de 1947 o primeiro celular, pela empresa Motorola. Esse aparelho
tinha o formato de um tijolo, e chegava a pesar em media 1kg e tinha 30 centímetros de altura.
Na época somente pessoas de alto poder aquisitivo tinham esse tipo de aparelho, e suas
funções eram apenas as de realizar e receber chamadas; outros modelos menores de celular
foram surgindo com o passar dos anos (FERNANDO, 2011).
Surgiram novos modelos de celular na década de 1990, e estes tinham um peso e
tamanhos bem menores. Surgiram também a agenda telefônica e as mensagens SMS, o celular
também ganhou um visor mais colorido e com o passar dos anos tivemos mais algumas
mudanças. Dessa época em diante tivemos muitos avanços para chegarmos aos celulares de
hoje em dia (FERNANDO, 2012).
Os atuais celulares, além da sua principal função, possuem câmera filmadora,
reprodutor de música MP3, jogos, câmera fotográfica, televisão, acesso a internet, calendário,
relógio e vários outros aplicativos, e uma grande vantagem é que os celulares ficaram mais
acessíveis e baratos e, hoje em dia, mais de oitenta por cento da população possui um celular
(FERNANDO, 2011).
Segundo os pesquisadores do Instituto de Tecnologia de Massachusetts, em um futuro
bem próximo será possível que um aplicativo de celular – que ainda está em fase de testes –
diagnostique a catarata. Testes também estão sendo feitos no Hospital da Conceição, em Porto
Alegre, onde uma equipe desenvolveu outro aplicativo que mede o grau de hipermetropia,
miopia, presbiopia e astigmatismo. Muitos testes para regulamentação médica precisam ser
feitos, por isso ainda é difícil falar em custo e comercialização desses aplicativos. (ZIEGLER,
2011).
4
1.1 Motivação
Todos os professores do IFF utilizam o sistema acadêmico para o lançamento de notas
e faltas dentro de um determinado período de fechamento, ocasionando perda de
produtividade e desgaste físico devido ao congestionamento do sistema.
Durante esse congestionamento muitas notas e faltas acabam se perdendo e o sistema
não grava alguns desses dados, fazendo com que os professores tenham que lançar as mesmas
notas e faltas várias vezes no sistema.
A realidade apresentada motivou a criação deste projeto, que consiste no
desenvolvimento de uma aplicação (protótipo) para o lançamento de notas e faltas de forma
simples e remota utilizando o sistema Android. Para a sua implementação, foi utilizada a
interface de desenvolvimento Eclipse. Também foi necessário o uso de um servidor para o
armazenamento dos dados. Sendo assim, foi utilizado os serviços Rails.
1.2 Objetivo
O objetivo do projeto é desenvolver uma aplicação (protótipo) para celulares Android,
permitindo o acesso ao lançamento de notas e faltas, através do acesso aos serviços Rails.
Os celulares, em sua maioria, proporcionam maior comodidade para realização de
tarefas simples, como citado anteriormente. Além disso, pela popularização dos celulares e
pela viabilidade de implementação nestes dispositivos móveis, a aplicação até então só
acessada e realizada em computadores e notebooks poderá ser feita em celulares e acessados
em qualquer lugar por ser um objeto de fácil manuseio.
1.3 Estrutura da Monografia
Esta monografia apresenta cinco capítulos, incluindo esta introdução:
CAPÍTULO I – INTRODUÇÃO:
A evolução das funções dos celulares e o crescimento e desenvolvimento das
aplicações dos dispositivos móveis, motivando desta forma o desenvolvimento de uma
5
aplicação (protótipo) especialmente para profissionais (professores) do IFF, levando em
consideração as necessidades e o objetivo apresentado.
CAPÍTULO II – TECNOLOGIA MÓVEL:
Este capítulo apresenta uma introdução sobre Tecnologia Móvel, aborda, também, um
breve histórico sobre a plataforma Android. Será feito um levantamento das principais versões
existentes e suas funcionalidades. E um comparativo entre IOS e Android; além de outras
plataformas.
CAPÍTULO III – METODOLOGIA ÁGIL DE DESENVOLVIMENTO:
Descreve sobre as Metodologias Ágeis existentes. As principais diferenças entre
Metodologia Tradicional e Ágil. E as principais características da linguagem Ruby e o
Framework Ruby on Rails.
CAPÍTULO IV – DESENVOLVIMENTO DO PROTÓTIPO:
Mostra as fases do projeto com os requisitos de software, o diagrama de casos de uso
detalhado, a estrutura da aplicação, as ferramentas e tecnologias utilizadas no
desenvolvimento, a implementação do banco de dados e a evolução do protótipo. Descrito,
também, o desenvolvimento do protótipo, suas funções e funcionalidades.
CAPÍTULO V – CONCLUSÃO:
Por fim, a conclusão traz as considerações sobre o desenvolvimento, além da proposta
de melhoria do protótipo apresentado.
6
Capítulo II
2. Tecnologia Móvel
Toda tecnologia que permite que o usuário se movimente de um lado para o outro
durante o seu uso é considerada uma tecnologia móvel. Esse tipo de tecnologia foi capaz de
fazer parte do dia a dia das pessoas e modificar suas vidas. Muitas pessoas não vivem sem
celular, outras estão 24 horas disponíveis e as encontramos em qualquer lugar. Algumas não
abrem mão de estarem com seu celular ou tablet conectado na Internet e ao mesmo tempo se
movimentando pela casa (WIKIPEDIA, A ENCICLOPÉDIA LIVRE, 2013).
A geração 1G foi a primeira versão da tecnologia móvel, que surgiu em meados de
1976 nos Estados Unidos com o padrão AMPS (Advanced Mobile Phone System). Esse
padrão foi muito usado na Rússia e na Ásia e era um padrão de telefonia analógico, e apesar
do nome em português significar Sistema Avançado de Telefones Móveis, possuía um
sistema fraco de segurança que facilitava a clonagem de linhas telefônicas.
O sistema TAC (Total Access Communication System) surgiu na Europa e era uma versão do
AMPS, e usava uma banda de freqüência de 900Mhz.
O padrão para celular 1G foi essencial para o avanço das tecnologias móveis, mas se
tornaram muito ultrapassadas com o surgimento da segunda tecnologia – denominada 2G
(TECMÓVEL, 2009).
As tecnologias 3G permitem que os usuários recebam serviços mais avançados de suas
operadoras, já que possuem uma capacidade de rede maior devido a uma grandena eficiência
espectral. Entre os serviços, há a transmissão de dados a longas distâncias e a telefonia por
voz, tudo em um ambiente móvel. São fornecidos normalmente serviços com taxas de 5 a 10
megabits por segundo.
As redes 3G permite que a telefonia móvel seja de grande alcance e avançam para
conseguir redes de acesso à Internet e vídeo telefonia de alta velocidade. As redes Wi-Fi são
de pequeno alcance e grande largura de banda e foram desenvolvidas para redes de dados,
além de não ter muita preocupação quanto ao consumo de energia, aspecto fundamental para
aparelhos que possuem pouca autonomia energética.
As redes 3G demoraram a ser mplementadas em alguns países, devido a enormes
custos adicionais para licenciamento do do mesmo. Em muitos países, as redes 3G não usam
as mesmas frequências de rádio que as 2G, fazendo com que as operadoras tenham que
7
licenciar novas frequências e construir redes completamente novas; uma exceção são os
Estados Unidos, onde as empresas operam serviços 3G na mesma frequência que outros
serviços. Em alguns países europeus, os custos com licença foram particularmente altos
devido a leilões do governo de um número limitado de licenças e a leilões com propostas
confidenciais, além da excitação inicial sobre o potencial do 3G. Outros atrasos se devem a
despesas com atualização dos equipamentos para os novos sistemas (WIKIPÉDIA, 2013).
A mobilidade começou como uma facilidade, e se tornou nos dias de hoje uma
necessidade. E esta tecnologia evoluiu tão rápido pelo fato de que este tipo de tecnologia
facilita o acesso a informações em qualquer local e a qualquer hora. Isto se torna um atrativo
poderoso.
A mobilidade se tornou popular pelo lançamento e evolução dos telefones celulares de
handhelds (entende-se palm). O produto foi lançado em abril de 1996 e criado por Jeff
Hawkings . Além da Palm Jeff fundou a Handspring, empresa ligada a evolução dos
computadores de mão. (WIKIPÉDIA, 2013).
2.1 Plataforma Android
Android é um sistema operacional móvel que roda sobre o núcleo Linux, embora por
enquanto a sua versão do núcleo Linux divirja da versão oficial.
O android foi desenvolvido primeiramente pela Google e depois pelo Open
Handsetalliance, mas a Google é a responsável pela gerência do produto e engenharia de
processos. O Android concede aos desenvolvedores que escrevam softwares na linguagem de
programação Java, controlando o dispositivo via bibliotecas desenvolvidas pela Google. Em
janeiro de 2012, existiam mais de 400 mil aplicações disponíveis para Android (WIKIPÉDIA,
2013).
A plataforma do Google Android está a cada dia mais ganhando força no mercado de
aplicativos móveis. O SDK tem evoluído bastante, e uma grande quantidade de aparelhos já
está sendo fabricada com o Android como Sistema Operacional (LIMA, 2012).
As vantagens do Android não são apenas aos usuários de aparelhos móveis; ele
também disponibiliza um framework poderoso para o desenvolvedor. Ele traz o melhor do
Java para seu desenvolvimento, que somadas às vantagens do uso do xml para o design, textos
(ideal para questões de internacionalização) e mapeamentos, torna o desenvolvimento de
aplicativos Android uma tarefa mais fácil para o desenvolvedor (LIMA, 2012).
8
2.2 História do Android
O universo da telefonia móvel nunca esteve tão aquecido quanto às demandas do
mercado consumidor. De acordo com a consultoria IDC, as fabricantes de smartphone
(telefone celular com funcionalidades avançadas) distribuíram 43,3 milhões de dispositivos
durante o terceiro trimestre de 2009, número 4,2% superior aos 41,5 milhões do mesmo
período de 2008. Já atentas a este mercado em constante crescimento, diversas empresas –
entre elas a Google – se uniram para formar, em novembro de 2007, a OHA (Open Handset
Alliance) e lançar a plataforma Android (MARTINS, 2009).
Andy Rubin foi o idealizador do Android e fundador da Android Inc, que em julho de
2005 foi comprada pela Google com a intenção de trazer para a empresa a idéia e os
engenheiros da Android Inc. Em novembro de 2007, sob a Open Handset Alliance, a Google
lançou a primeira versão do SDK (Software Development Kit) do Android (MARTINS, 2009).
O Android é um conjunto de programas para dispositivos móveis que inclui
importantes aplicativos e um sistema operacional. É uma plataforma de código aberto e foi
feito para aparelhos com especificações diversas. Ele chega a suportar tecnologias presentes
nos smartphones mais modernos atualmente como GPS (Global Positioning System – Sistema
de Posicionamento Global e touchscreen (tela sensível ao toque); permite identificar a posição
em termos de latitude e longitude da Terra). O logotipo do Android é exibido na Figura 1.
Figura 1- Logotipo do Android
Fonte: http://www.icad.puc-rio.br/~projetos/androida/files/monografia (MARTINS, 2012)
O Android tem uma loja virtual, a Play Store, que possibilita ao desenvolvedor
disponibilizar uma aplicação gratuitamente para o usuário ou lucrar com a sua venda, em um
modelo parecido com AppStore, loja virtual de aplicativos para os aparelhos da marca Apple
(MARTINS, 2009) .
9
A tecnologia Android tem também outras características, como a facilidade na
integração com serviços oferecidos pelo Google. Além disto, várias ferramentas estão sendo
disponibilizadas gratuitamente para os seus desenvolvedores (MARTINS, 2009).
O primeiro smartphone lançado com o Android, o T-Mobile G1 (veja Figura 2), feito
pela HTC, foi liberado nos Estados Unidos em setembro de 2008 e, seis meses depois do seu
lançamento, já havia vendido 1 milhão de unidades. Outras importantes empresas, entre elas
Motorola e Samsung, já anunciaram dispositivos que contém a plataforma Android. A
tecnologia Android foi anunciada no Brasil em setembro de 2009.
Figura 2: Smartphone HTC T-Mobile G1
Fonte: http://www.icad.puc-rio.br/~projetos/android/files/monografia (MARTINS, 2012)
2.3 Arquitetura do Android
Mué
Figura 3: Arquitetura do Android
Fonte: http://www.vivasemfio.com/blog/arquitetura-do-android/
Aplicações
10
O Android tem um conjunto de aplicativos centrais, como um cliente de e-mail,
programa para SMS (Short Message Service), mapas, calendário, navegador e gerenciador de
contatos. Tudo produzido em Java (VIVA SEM FIO, 2008).
Framework de Aplicações
A arquitetura deste framework foi feita para melhorar a reutilização dos componentes.
Desta forma, qualquer desenvolvedor pode desenvolver um aplicativo e disponibilizar suas
“capacidades”, deixando que elas sejam usadas por outros programas. Vale destacar que o
desenvolvedor tem acesso total à mesma estrutura de APIs usada nos aplicativos centrais,
podendo, assim, aproveitá-las conforme achar melhor (VIVA SEM FIO, 2008).
Bibliotecas
O sistema conta com um conjunto de bibliotecas C/C++ utilizadas por diversos
componentes do Android. Essas bibliotecas possibilitam trabalhar com arquivos de mídia
comuns como MPEG4, H.264, MP3, AAC, AMR, JPG e PNG. Componentes como o Surface
Manager facilita a exibição de conteúdo tanto em 2D como em 3D. Há, inclusive, uma
biblioteca 3D cuja implementação foi baseada no famoso OpenGL (Open Graphics Library).
O OpenGL basicamente é um conjunto de várias funções que concedem acesso a todos os
recursos do hardware de vídeo praticamente. Para completar, foi lançado também o SQLite,
um poderoso e leve banco de dados relacional (VIVA SEM FIO, 2008).
Android Runtime
Cada aplicação do Android roda em seu próprio processo e cada processo é uma
instância da máquina virtual Dalvik, feita para que o dispositivo possa rodar múltiplas
máquinas virtuais de forma eficiente. Os arquivos são executados no formato Dalvik
Executable (.dex) e são otimizados para ocupar uma pequena parte de memória. Os arquivos
são criados por um compilador Java, que converte o resultado no formato .dex (VIVA SEM
FIO, 2008).
Kernel do Linux
Para serviços básicos do sistema o Android usa o Linux na versão 2.6, como
segurança, gerenciamento de processos, gerenciamento de memória, drivers e rede. O kernel
11
do Linux também trabalha como uma camada de abstração entre o hardware do dispositivo e
o resto do conjunto de softwares que são desenvolvidos em paralelo (VIVASEMFIO, 2008).
2.4 Versões da plataforma Android
A partir do desenvolvimento da terceira versão do sistema operacional, o software
recebe o nome de um doce. A ideia veio em abril de 2009, com o lançamento do Android 1.5,
essa versão do software foi batizada de cupcake (LANDIM, 2011).
A letra “C”, inicial do doce, é também a terceira do alfabeto. Essa ordem foi mantida
e, desde então, todas as versões posteriores do SO ganharam nomes de doces: donut, eclair,
froyo, gingerbread e honeycomb (LANDIM, 2011).
A versão do Android lançada em 2011 ficou conhecida como Ice Cream Sandwich.
Outro fato interessante é que a cada nova versão lançada, a Google encomenda uma estátua,
no formato do doce em questão. As obras de arte podem ser vistas na sede da empresa, em
Mountain View, nos Estados Unidos (LANDIM, 2011).
Versões Beta, 1.0 e 1.1
Essas versões do Android não obtiveram nomes de doces. Os aparelhos que receberam
a versão Beta do Android foram apenas aqueles feitos pelos fabricantes para desenvolver o
Android, não havendo nenhum aparelho com essa versão disponível para o público. O
Android 1.0 foi desenvolvido com o T-Mobile G1, que recebeu as atualizações até o Android
1.6. A versão 1.1 foi liberada somente para o G1, que era o único aparelho que rodava o
Android na época (BRASILDROID, 2011).
Versão 1.5 (Cupcake)
A versão 1.5 foi uma das primeiras a estar em vários aparelhos. Os primeiros
lançamentos foram o Samsung Galaxy e o HTC Magic. Entre as novidades, estão os widgets,
que tem a capacidade de gravar vídeos com a câmera, a habilidade de copiar/colar texto e
animações nas transições de tela (BRASILDROID, 2011).
Versão 1.6 (Donut)
Essa versão foi lançada em setembro de 2009. As principais melhorias foram na
câmera e galeria, pesquisas (incluindo pesquisa por voz), e suporte a telas com resolução de
12
até 480×800 pixels. Os principais modelos lançados com o Donut são o HTC Tattoo, Samsung
Galaxy Lite e SonyEricsson XPeria X10 (o primeiro Android “blockbuster”)
(BRASILDROID, 2011).
Versões 2.0/2.1 (Eclair)
Essa versão foi lançada em outubro de 2009, o Android 2.0 foi a primeira atualização
do sistema. Em janeiro de 2010 seria lançada a versão 2.1, que manteria o nome da bomba de
chocolate. Os aparelhos lançados com essa versão foi o Motorola Droid (conhecido aqui
como Milestone) e o Google Nexus One (o primeiro “Googlephone”, aparelho “sem marca”,
com atualizações controladas pela Google, e “experiência Android pura”, sem customizações
de fabricantes). As novidades dessa versão são mudanças na câmera, melhor contraste na tela
(antes, o sistema só suportava até 65 mil cores, mesmo com hardware melhor), mais
resoluções suportadas, suporte a multi-touch e wallpapers animados (BRASILDROID, 2011).
Versão 2.2 (FroYo)
Essa versão chegou em maio de 2010, o FroYo (abreviação de Frozen Yogurt) talvez
possa ser a atualização mais significativa do sistema até agora, com mudanças muito
importantes. As principais são: melhoria no desempenho geral do sistema (até 450% no Nexus
One, de acordo com o pessoal do Android Police), uso da mesma engine de JavaScript do
Google Chrome (v8) no navegador, tethering (por USB ou WiFi), atualizações automáticas de
aplicativos baixados pelo Google play e suporte ao Adobe Flash, algo muito esperado pelos
usuários. Foi adicionada também a capacidade de usar resoluções super altas (320
pixels/polegada, próxima à do iPhone 4 (BRASILDROID, 2011).
Versão 2.3 (Gingerbread)
Essa versão foi oficialmente lançada em dezembro de 2010 juntamente com o Nexus S.
As principais novidades dessa versão Android são o suporte a NFC, sensores como
giroscópio, VOIP, uma interface mais simples e minimalista, capacidade para vídeo chamadas
(em aparelhos com câmera frontal), possibilidade de usar mais de uma câmera (inclusive
câmeras frontais) entre outros. Aparelhos como o XPeria X10, Galaxy S e Nexus One e estão
recebendo a atualização para essa versão. Além do Nexus S, o XPeria Arc e o Galaxy SII são
smartphones já lançados com essa versão (BRASILDROID, 2011).
13
Versão 3.0/3.1/3.2 (Honeycomb)
A primeira versão do Android desenvolvida especificamente para tablets, o
Honeycomb chegou em fevereiro do ano de 2011. O Motorola Xoom foi o primeiro aparelho
lançado com esse sistema, posteriormente o Galaxy Tab e o Huawei MediaPad também
receberam essa versão. As maiores novidades dessa versão dizem respeito a funções
otimizadas ou específicas para tablets, como o navegador padrão com suporte a abas, duas
barras (uma “de sistema”, na parte inferior da tela, com relógio e botões de ação virtuais; e
outra “de ações”, no topo da tela, com botões específicos para a o aplicativo aberto no
momento), suporte a processadores com múltiplos núcleos e aceleração de vídeo por
hardware e (essas duas funções devem ser incluídas também em versões futuras do
Gingerbread, devido ao avanço do hardware dos smartphones) (BRASILDROID, 2011).
Versão Ice Cream Sandwich
Essa versão foi lançada em maio de 2011 na conferência Google I/O (onde também foi
anunciado o Music Beta), o Ice Cream Sandwich (ou ICS) será a próxima atualização do
Android. Segundo Mike Claren, um dos engenheiros do projeto, é “o lançamento mais
ambicioso até agora” do Android. A novidade maior, por agora, é a integração de versões para
smartphones e tablets (acabando com a separação criada pelo Honeycomb). Muito pouco é
conhecido sobre essa versão, nem mesmo o número se sabe. Até agora, sabe-se que o Android
3.2 ainda será considerado Honeycomb, mas não se sabe se a versão 2.4 será Gingerbread ou
Ice Cream Sandwich, mas a primeira opção é a mais provável, pois se sabe que o 2.4 não terá
muitas diferenças em relação ao 2.3. O nome é complicado (porque não Ice Cream somente,
em vez de Ice Cream Sandwich?) para diferenciar o “ícone” do FroYo, que, apesar de se tratar
de iogurte congelado, também é um pote de sorvete (BRASILDROID, 2011).
Não se sabe por que os engenheiros da Google usam nomes de doces para as versões
do Android (a suspeita é que se trata de uma piada interna que decidiram tornar pública), mas
sabe-se que seguem a ordem alfabética (como você pode ver acima). A pergunta que fica é:
quais seriam, então, as versões começadas com A e B? Há rumores de que sejam “Apple Pie”
e “Banana Bread”, mas, convenhamos ninguém quer “homenagear” o maior concorrente no
nome de um de seus produtos (BRASILDROID, 2011).
Versão Jelly Bean
Essa versão do Android não teve muitas mudanças ao ser comparado com o Ice
CreamSandwich. Por tanto, algumas melhorias podem ser citadas, como imagens mais
14
modernas e uma organização ainda mais intuitiva de ferramentas e ícones. A tela inicial do
Android ganhou a possibilidade de ter ícones e widgets reposicionados e redimensionados de
maneira inteligente, sem que o usuário precise perder tempo com isso. O teclado ganhou um
visual totalmente novo, ficando com um formato mais simples para a digitação e ainda mais
escuro. Além disso, o Jelly Bean conta com uma nova opção chamada Voice Typing, que
permite escrever mensagens usando apenas comandos de voz, sem você nem mesmo tocar no
gadget. Com a proposta de popularizar o Android ainda mais, a Google proporcionou para o
Jelly Bean um monte de recursos específicos para deficientes visuais. Com isso, o sistema
operacional ganhou ferramentas ativadas com gestos e novas maneiras ainda mais intuitivas
de navegar com o aparelho (HECKE, 2012).
Versão 5.0 Kitkat
Essa versão é o sucessor do Android 4.3 Jelly Bean. Após recente acordo com a
Nestlé, o novo sistema Android levará o nome de um dos doces mais famosos da marca. Esse
acordo prevê ainda campanhas de marketing em conjunto, com vale-brindes de aparelhos
Nexus 7 e de conteúdo na Play Store.
2.5 Android X IOS
Sistema Operacional
Lançado depois do iOS a plataforma Android hoje, tem muito mais mercado e
praticamente não existem limitações. É muito citada a capacidade “multitarefa” do sistema
iOS, mas sabe-se que isso é algo totalmente falso neste sistema, pois o mesmo não existe
realmente. Enquanto na plataforma Android as aplicações podem ficar rodando em
background sem problemas, tanto com os apps de terceiros quanto com os apps do próprio
SO. Não é necessário entrar no contexto de personalização, afinal de contas, iOS não tem
widgets, nem diferentes versões de home ou até mesmo versões do sistema operacional
(ZARATIN, 2011).
Disponibilidade de aplicativos
Em relação aos apps, tem-se uma proporção de 1.000 uteis para 1 milhão de Apps
inúteis e repetidos. Garantia mesmo só de que os principais apps estão disponíveis em ambas
15
as plataformas. Um ponto positivo da plataforma Android é o Google Play onde pode-se
instalar apps no aparelho com apenas 1 clique na página web, além de poder obter jogos
mesmo estando no Brasil sem violação de contrato de serviço ou cometer nenhum crime de
falsidade ideológica (ZARATIN, 2011).
Transferência de Arquivos
É impossível comparar iOS com Android nesse ponto. No Android basta um cabo
para transferência de arquivo já no iOS precisa de cabo proprietário mais um software para
tal. No Android é possível também pegar um SD Card ou um pendrive e utilizar no aparelho
(ZARATIN, 2011).
2.6 Outras Plataformas
Superwaba
Essa plataforma é uma linguagem de programação usada para desenvolvimento de
aplicações para aparelhos móveis como telefones celulares e aparelhos que comportam
sistemas como PalmOS, Windows, Windows Mobile, WindowsCE e SymbianOS. O
SuperWaba se baseia e estende o Waba. A linguagem de programação do SuperWaba é uma
versão reduzida da definida em Java. Existem algumas semelhanças com o Java, também é
usada uma máquina virtual cuja implementação é específica de cada aparelho onde é
instalada. Diferentemente do Java, SuperWaba não suporta o modelo de sincronização e,
como tal, não pode ser considerada verdadeiramente tecnologia Java. SuperWaba cumpre um
papel semelhante à tecnologia J2ME. A diferença fundamental é sua maior integração com os
aparelhos móveis e um modelo de API mais pragmático que a API J2ME (WIKIPÉDIA,
2013).
Brew
Esssa é uma plataforma aberta gerada pela empresa Qualcomm para criação e
distribuição de aplicações para telefones celulares (WIKIPÉDIA, 2013).
A distribuição das aplicações é realizada através de um aplicativo da Qualcomm
chamado BREW Shop. Este aplicativo vem pré-instalado em todos os aparelhos que suportam
16
esta tecnologia, e facilita a compra e download das aplicações aprovadas pela operadora para
uso de seus clientes (WIKIPÉDIA, 2013).
É utilizada a linguagem de programação C++ para o desenvolvimento de aplicações e
um framework disponibilizado pela Qualcomm, que facilita o acesso às principais funções de
um aparelho celular. Para rodar suas aplicações nos celulares o desenvolvedor tem que se
cadastrar no site da Qualcomm, esse cadastro custa 400 dólares e dá direito a 100 builds de
programa (WIKIPÉDIA, 2013).
O BREW é uma plataforma extremamente pequena e roda tanto em aplicativos que
possuem algum sistema operacional quanto em aplicativos que não possuem recursos
suficientes para isso, pois uma de suas metas é dar suporte ao maior número de dispositivos
possíveis. Os dispositivos usados para executar nossos aplicativos possuem recursos bastante
limitados e precisam ser tratados de maneira diferenciada em relação à maneira que são
tratados os PCs, laptops, etc (FRANCO, 2012).
17
Capítulo III
3. Metodologia Ágil de Desenvolvimento
As mudanças nas descrições dos projetos de software têm proporcionado maior espaço
na utilização de metodologias ágeis. Já as abordagens tradicionais são pouco favoráveis às
mudanças para atender as necessidades do projeto. No entanto, a realidade atual é constituída
por requisitos em constante evolução e por alterações a todo o momento (MÁRCIA
SAVOINE, 2009).
O “Manifesto Ágil” trata de um documento que foi criado por vários desenvolvedores,
tendo como idealizadores Kent Beck, Ken Schwaber, Martin Fowler e Jim Highsmith,
abrangendo um conjunto de princípios, que definem critérios para o processo de
desenvolvimento de software ágil. Defendendo desta forma a valorização do que é necessária
ao se desenvolver um software, nas respostas rápidas a mudanças e alterações, na
funcionalidade do código fonte, na cooperação com o cliente, na comunicação entre
indivíduos. Deixando em segundo plano a documentação, a negociação de contratos e o
planejamento.
Esses conceitos aproximam-se melhor com a forma que pequenas companhias de
Tecnologia da Informação trabalham e respondem a mudanças (BORBOREMA, 2007).
Para ser realmente considerada ágil a metodologia deve aceitar a mudança ao invés de
tentar prever o futuro. O problema não é a mudança em si, mesmo porque ela ocorrerá de
qualquer forma. O problema é como receber, avaliar e responder às mudanças.
Enquanto as metodologias ágeis variam em termos de práticas e ênfases, elas
compartilham algumas características, como desenvolvimento iterativo e incremental,
comunicação e redução de produtos intermediários, como documentação extensiva. Desta
forma existem maiores possibilidades de atender aos requisitos do cliente, que muitas vezes
são modificados (LIBARDI, 2010).
3.1 Metodologia Ágil XP (Extreme Programming)
É um modelo de desenvolvimento de software e foi criado em 1996 no Departamento
de Computação da montadora de carros Daimler Crysler nos Estados Unidos, por Kent Bech,
18
e por ajudar a criar sistemas de melhor qualidade em um curto tempo e de forma mais
econômica vem fazendo bastante sucesso em diversos países (SOUZA, 2007).
A metodologia é indicada para equipes de desenvolvimento pequenas e médias, às
quais tem que lidar com requisitos vagos ou em constante mudança com a proposta de
aumentar o foco nas pessoas e não nos processos de desenvolvimento. Além disso, existe a
preocupação de se gastar menos tempo com a documentação e mais com a resolução do
problema, gerando produtos com melhor aceitação e qualidade (REIS, 2008).
A metodologia Extreme Programming (XP) é um conjunto bem definido de regras que
enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de
favorecer o cumprimento das estimativas.
O grupo de desenvolvedores utilizando a metodologia XP deve estar por dentro de
todas as fases do desenvolvimento do projeto, ser bastante interessada, ter pro atividade,
melhorando a comunicação para assegurar a alta produtividade, constituindo desta forma uma
equipe de 2 a 10 integrantes. Sendo necessária a realização de vários testes, às vezes,
alterando o projeto em decorrência destes. Sendo necessário que o cliente esteja sempre
disponível para tirar dúvidas, rever requisitos, atribuir prioridades, utilizando-se de sistemas
de nomes, em vez de termos técnicos para facilitar a comunicação e tomar decisões em
relação ao projeto (SOUZA, 2007).
O XP poderá trazer inúmeros benefícios, de forma que o processo de desenvolvimento
se torne mais ágil e flexível. Um desses benefícios é a agilidade no Planejamento (Planning
Games) de não definir uma especificação completa e formal dos requisitos, ao contrário das
metodologias tradicionais. Outro é a produção de sistemas simples que atendam aos atuais
requisitos, não tentando antecipar o futuro e permitindo atualizações freqüentes em ciclos
bastante curtos (TELES, 2005).
Outra característica importante do XP é que o código é sempre escrito em duplas,
visando a melhorar a qualidade do código por um custo muito baixo, às vezes menor do que o
desenvolvimento individual. O código deve estar padronizado, para que todos na equipe
possam entender o que está sendo escrito e possa ser validado durante todo o
desenvolvimento, tanto pelos desenvolvedores quanto pelos clientes, a fim de se saber se os
requisitos estão ou não sendo atendidos (TELES, 2005).
Contudo, além de os métodos tradicionais de desenvolvimento de software ter o foco
voltado para a documentação, necessitam de requerimentos completos e fixos, o que os torna
uma metodologia pesada e não flexível. Foi contrapondo a este cenário que, surgiu o Extreme
Programming – uma metodologia ágil, que visa um rápido desenvolvimento, atende às reais
19
necessidades do cliente e, ainda, permite modificações, à medida que novas necessidades
apareçam (MÁRCIA SAVOINE, 2012).
Ciclo de vida do
Software
Desenvolvimento ágil
XP (Extreme Programming)
Desenvolvimento
Tradicional
Modelo em cascata
Definição dos requisitos
Obrigatório. Os requisitos são
atualizados ao longo do
desenvolvimento.
Obrigatório. É gerada uma
versão que servirá de base
para todos os itens a seguir.
Projeto de software
Opcional. Surge informalmente
durante o desenvolvimento do
software.
Obrigatório. E só se dá início
ao término da definição dos
requisitos.
Desenvolvimento
Implementa os incrementos
(user stories) levantados junto
ao cliente.
Implementa sequencialmente
cada funcionalidade que o
projetista especificou no
projeto.
Teste de sistema
É feito um plano de teste antes
da implementação que vão
sendo executados
freqüentemente.
O teste é feito apenas pela
equipe de desenvolvimento no
final do projeto.
Implantação
Parte do software vai sendo
implantada até concluir todos
os requisitos.
O software só é entregue ao
usuário quando estiver
totalmente pronto.
Tabela 1 – Comparativo entre os processos da XP e do modelo em cascata
Fonte: (GONÇALVES, 2011)
3.2 Metodologia Ágil BDD (Behavior Driven Development)
Foi originalmente concebido em 2003, por Dan North. É uma evolução de outra
técnica ágil chamada TDD - Test Driven Development, e tem se expandido bastante nos
últimos anos.
A metodologia foi criada com o objetivo de facilitar o entendimento de TDD para
aqueles que estão começando a lidar com o desenvolvimento dirigido por testes.
O BDD é uma técnica cujo foco não está apenas em gerar testes, mais, também, em
avaliar o comportamento do sistema. Esta nova visão faz com que os testes sejam apenas uma
conseqüência necessária para garantir que o sistema esteja de acordo com as user stories
(DANNORTH, 2009).
Nessa linguagem são usados termos que fazem parte das conversas diárias entre
especialistas de negócio e desenvolvedores. Todos devem usar os mesmos termos tanto na
20
linguagem falada quanto no código que poderá ser compreendida por todos os envolvidos no
projeto. (DANNORTH, 2009).
O foco desta metodologia está em testar o que realmente importa para o usuário e
verificar se de fato o que ele espera do sistema esta acontecendo, desta forma será mais fácil
convencé-lo de que o tempo utilizado na criação de testes não é tempo perdido. Não será mais
necessário buscar o que deve ser testado, as user stories e os critérios de avaliação dirão isso
para os desenvolvedores (DANNORTH, 2009).
De modo geral, o BDD apresenta um framework baseado em três princípios: 1. A área
de negócios e a de tecnologia precisa se referir a mesma parte do sistema da mesma forma; 2.
Toda parte do sistema precisa ter um valor identificável e verificável para o negócio; 3.
Analisar, projetar e planejar tudo de cima a baixo tem retorno decrescente (DANNORTH,
2009).
As atividades necessárias ao desenvolvimento de uma funcionalidade são realizadas
segundo um ciclo denominado outside-in. O ciclo recebe este nome devido à sequência que
deve ser percorrida, que se inicia dos requisitos e da visão do cliente (outside) até as entranhas
dos artefatos de software (in) (5CQUALIBR, 2012).
BDD é guiado pelos valores de negócios; que é o benefício trazido para o negócio no
qual a aplicação está sendo produzida. A única maneira na qual o benefício pode ser
percebido é através de interfaces de usuário para a aplicação, comumente (mas nem sempre) a
interface gráfica de usuário (5CQUALIBR, 2012).
Figura 4 – Ciclo de Vida BDD
Fonte: (NASCIMENTO, 2011).
21
3.3 Metodologia Ágil Scrum
A popularização da metodologia Scrum ocorreu em 1995, após a realização de sua
definição, feita por Ken Schwaber, sendo criado para gerenciamento de projetos de fabricação
de automóveis e produtos de consumo (NETO, 2008).
Trata-se de uma metodologia prática, adaptativa, inovadora, usada no
desenvolvimento de sistemas de modo iterativo e incremental, onde os requisitos podem
sofrer mudanças durante o processo de fabricação do produto (DOS SANTOS e BOEIRA,
2008).
É uma metodologia com o foco na coordenação da equipe, preocupada na organização
dos processos, no modo como as atividades devem ser executadas, deixando que os
participantes do projeto escolham a melhor maneira de concluir com sucesso essas etapas.
A Scrum aplica-se a projetos tanto pequenos como grandes. O seu principal objetivo é
conseguir uma avaliação correta do ambiente em evolução, adaptando-se constantemente aos
interesses e as necessidades, indicadas e utilizadas para o desenvolvimento de softwares em
ambientes complexos, onde os requisitos mudam com certa freqüência, sendo o caminho
utilizado para aumentar a produtividade nesses tipos de sistemas (DOS SANTOS e BOEIRA,
2008).
Os requisitos do software são levantados e organizados em uma lista de
funcionalidades, chamada product backlog, que contém todo o escopo do projeto definido
juntamente com o cliente, e suas respectivas prioridades de desenvolvimento, sendo que o
product backlog deve ser constantemente revisado, validado e atualizado (SILVA e S. C. P.
HOENTSCH, 2009)
O scrum por trabalhar com desenvolvimento incremental, onde o desenvolvimento é
dividido em iterações, chamado de sprints, de duração entre duas a quatro semanas. Cada
sprint é composta de uma lista de tarefas, funcionalidades com prioridades retiradas do
product backlog, chamada de sprint backlog (lista de tarefas dos sprint) garantindo que os
requisitos mais importantes sejam implementados primeiro e que a equipe mantenha o foco
durante o sprint. O sprint possui um objetivo claro e definido, conhecido de toda a equipe
(SILVA e DOS SANTOS, 2011).
É comum que os requisitos do final do product backlog, com o tempo, percam sua
importância e acabem removidos da lista.
Definidas as atividades a serem realizadas em cada sprint, a equipe foca o
desenvolvimento de mais um ciclo que se repete ao longo do projeto. Após o encerramento
22
das sprints é realizada a sprint retrospective, uma das mais importantes práticas dentro da
Scrum, que são discutidos os pontos positivos e os negativos.
Na Scrum, durante a fase das sprints, ocorrem reuniões de acompanhamento diárias.
Nessas reuniões, que são preferencialmente de curta duração (aproximadamente quinze
minutos), feita com todos os integrantes da equipe, são discutidos pontos como o que foi feito
desde a última reunião e o que precisa ser feito até a próxima, essas reuniões diárias são
chamadas daily scrum meetings. As dificuldades encontradas e os fatores de impedimento
(bottlenecks) são identificados e resolvidos (SOARES, 2004).
3.4 Metodologia Ágil TDD - Test-Driven Development
Foi introduzida por Kent Beck para produzir o que se chama de “código limpo que
funciona”.
Consiste em uma metodologia ágil de desenvolvimento de software, onde primeiro,
são criados os testes, e somente depois é escrito o código de produção, é realizada a
compilação e verificada as falhas necessárias para passar por eles.
Apesar de ser um processo simples, alguns desenvolvedores têm dificuldades de
aplicar essa técnica no dia-a-dia e não conseguem guiar um projeto orientado a objetos a partir
de testes. (LAPOLL, MOTTA, et al., 2010).
TDD é uma forma de programação que incentiva a um bom design e é um processo
disciplinado o que ajuda a evitar erros de programação, promovendo a qualidade desde o
início do desenvolvimento.
O método ágil TDD oferece diversos benefícios, como a compreensão do programa,
incentivando programadores a explicar o seu código usando casos de teste; eficiência; falhas
são identificadas, de forma mais rápida, antes do novo código ser adicionado ao sistema;
testabilidade, escrever código automaticamente testável (PRANGE, 2012).
O ciclo básico do TDD é formado por cinco etapas fundamentais:
Adicionar um teste rapidamente: Cada nova funcionalidade inicia com a
criação de um teste. Este teste precisa, inevitavelmente falhar porque ele é escrito antes da
funcionalidade a ser implementada. Para escrever um teste, o desenvolvedor deve primeiro
entender as especificações e requisitos da funcionalidade, ou seja, o que deve ser produzido e
como ele vai chegar a esse resultado. O desenvolvedor pode fazer isso através de casos de uso
ou user stories que cubram os requisitos e exceções condicionais. Esta é a diferenciação entre
23
desenvolvimento dirigido a testes entre escrever testes de unidade depois do código
desenvolvido. Ele torna o desenvolvedor focado nos requisitos antes do código.
Executar todos os testes e verificar se algum deles falha: O caso de teste
deve ser executado assim que for definido, mesmo que não exista implementação para que
este passe. Esse passo valida se todos os testes estão funcionando corretamente, e se o novo
teste não traz nenhum equívoco, sem requerer nenhum código novo. Pode-se considerar que
este passo então testa o próprio teste: ele regula a possibilidade de novo teste passar. O novo
teste deve então falhar pela razão esperada: a funcionalidade não foi desenvolvida. Isto
aumenta a confiança (por outro lado, não exatamente a garante) que se está testando a coisa
certa, e que o teste somente irá passar nos casos intencionados.
Escrever código: O próximo passo é escrever código que irá ocasionar ao teste
passar. O novo código escrito até esse ponto poderá não ser perfeito e pode, por exemplo,
passar no teste de uma forma não elegante. Isso é aceitável porque posteriormente ele será
melhorado. O importante é que o código escrito deve ser construído somente para passar no
teste; nenhuma funcionalidade (muito menos não testada) deve ser predita ou permitida em
qualquer ponto.
Executar os testes automatizados e verificar se são executados com
sucesso: Após verificar que existe um teste que falha, é necessário escrever o código para que
este passe. Neste ponto, deve ser escrito o mínimo de código para o teste ser executado com
sucesso. Esta característica do TDD faz com que o desenvolvimento seja feito através de
pequenos incrementos, formados por poucos métodos e pouca lógica. Ao final, esses
incrementos juntos produzem uma solução completa.
O próximo passo é executar os casos de teste automatizados e observar se eles passam
ou não. Em caso de sucesso, o programador terá certeza de que o código implementado por
ele atende aos requisitos testados. Caso contrário, o código ainda precisa ser modificado.
Refatorar código: Nesse ponto o código pode ser limpo como necessário. Ao
re-executar os testes, o último passo é a refatoração que é a remoção de duplicação de código,
considerando um importante aspecto ao design de software. Nesta etapa nenhuma
modificação relacionada à lógica do sistema deve ser feita.
Apenas modificações estruturais são permitidas. Nesse caso, entretanto, isso aplica
remover qualquer duplicação entre código de teste e código de produção — por exemplo,
magic numbers or strings.
24
Depois disso, os casos de teste devem ser executados mais uma vez para garantir que a
refatoração não danificou alguma parte do sistema que já estava funcionando anteriormente
(LAPOLL, MOTTA, et al., 2010).
Estes são os passos do ciclo de desenvolvimento dirigido por testes. Quando se inicia
o uso desta abordagem fica evidente a necessidade de muita disciplina. Distrair-se e escrever
código funcional sem ter escrito um novo teste antes é muito fácil (PRANGE, 2012).
A grande vantagem dessa prática não está nos testes gerados, mas sim no fato de se
pensar no design antes de escrever a primeira linha de código, no momento em que se
descreve o comportamento do sistema (LAPOLL, MOTTA, et al., 2010).
Figura 5 - Ciclo de vida TDD
Fonte: (COELHO, 2012)
3.5 Metodogia Ágil Kanban
Kanban é uma metodologia de produção que utiliza controles visuais (cartões) como
status de uma determinada etapa do processo. O Kanban é a mais adaptativa das
metodologias, extremamente simples e incrivelmente eficiente (MARIOTT, 2012).
25
O Kanban é baseado na idéia onde atividades em andamento devem ser limitadas. Um
novo item só pode ser iniciado quando o item em andamento é finalizado ou quando uma
função automática inicia o mesmo instantaneamente.
O sistema Kanban fornece um método simples, barato e fácil de implementar, e
rapidamente começa a apresentar resultados permitindo gerenciar o limite de atividades em
andamento e garantindo o bom desempenho da equipe (MARIOTT, 2012).
O Kanban, basicamente, tem como principal objetivo transformar o trabalho em
andamento visível para toda equipe, criando um sinal visual que indica que o novo trabalho
pode ou não ser iniciado e se o limite acordado para cada fase está sendo respeitado.
Portanto, o Kanban não é um processo e nem descreve papeis e faces para serem
seguidos. Podemos dizer que o Kanban é uma abordagem para mudança gerencial do projeto,
um conceito para introduzir alterações em um ciclo de desenvolvimento de software ou
gerenciamento de projetos (LEMOS, 2012)
O Kanban dá transparência ao processo e seu fluxo, expondo gargalos, filas,
variabilidade e desperdícios. Portanto, tudo que impacta no desempenho da equipe de
produção e para entrega de valor, fica explícito no modelo Kanban (MARIOTT, 2012).
O Kanban, com seu mecanismo de sinalização, tem como objetivo apresentar uma
atividade de trabalho em processo, ou seja, o número de atividades ou cartões em circulação é
equivalente à capacidade do sistema. Outra característica importante do modelo Kanban é o
conceito de “puxar tarefa” quando há capacidade de processá-la.
Portanto, ao invés dos membros que produzem o produto receberem atividades
conforme suas demandas, os requisitos são adicionados à lista de backlog e “puxados” pelos
membros que liberam suas atividades correntes e se tornam disponíveis para iniciar uma nova
tarefa (MARIOTT, 2012).
3.6 Principais Diferenças entre Metodologia Tradicional e Ágil
As duas principais diferenças entre as metodologias ágeis e as tradicionais são:
As metodologias tradicionais são pesadas ou orientadas a planejamentos onde os
requisitos do sistema são estáveis, e requisitos futuros são previsíveis, elas planejam uma
grande parte do software em muitos detalhes com bastante antecedência. Por isto elas são
resistentes à mudança. Já nas metodologias ágeis, as mudanças de requisitos são bem aceitas
durante o desenvolvimento. Elas tendem a ajustar o desenvolvimento do software às
mudanças de requisitos, tornando-se mais flexíveis (SOARES, 2004).
26
O Objetivo das metodologias ágeis de desenvolvimento é desenvolver um
processo que vai funcionar da mesma maneira, independente de quem o esteja usando, ou
seja, elas são orientadas às pessoas, não aos processos. Tendem a se ajustar equipes de
desenvolvimento, levando em conta, desta forma, a habilidade do grupo (FOWLER, 2010).
Em métodos tradicionais, o projeto só é bem realizado no final, em sua
totalidade mesmo que existam alterações no escopo (devidamente documentadas e
aprovadas). Em métodos ágeis, é considerado de grande valor para o cliente um conjunto
mínimo de funcionalidade, mesmo que o projeto seja descontinuado depois de um tempo, o
cliente já recebeu um valor efetivo. No entanto, não se trata em ter, ou não, entregas
intermediárias, mas sim, se trata de um sucesso progressivo no desenvolvimento ou só no
final (RUOSO, 2009).
Em métodos ágeis, à medida que é realizada a entrega das funcionalidades do
software; quem faz os orçamentos é o desenvolvedor e o gerente negocia com o cliente quais
serão as próximas atividades desenvolvidas, mas a eficiência da equipe não é propriamente
um centro da discussão. Isso ocorre porque o cliente não tem uma visão completa de quanto
vai custar o produto final. Enquanto em métodos tradicionais a medida das entregas está
100% sobre o escopo especificado, e, em geral, o valor total do investimento também é
conhecido a princípio, de forma que o papel do cliente é validar o escopo, e quanto à
eficiência da equipe é um problema única e exclusivamente do próprio laboratório (RUOSO,
2009).
3.7 A Linguagem Ruby e o Framework Rails
O Ruby on Rails surgiu da integração de duas ferramentas: o Ruby, que é uma
linguagem de programação orientada a objetos, onde todos os valores são objetos inclusive a
própria definição de uma classe que também é um objeto, utilizada para a manipulação de
dados dentro da aplicação web, e o Rails, que é uma ferramenta para o desenvolvimento de
aplicações-web orientadas a banco de dados, baseado na junção de quatro frameworks (Active
Record, Action Pack, Action Mailer e Active Support) (LOVATTO, 2007) .
Tecnicamente falando, Rails é um framework criado na linguagem de programação
Ruby (daí o nome Ruby on Rails).
27
3.8 A linguagem Ruby
A linguagem Ruby foi originalmente planejada e desenvolvida no Japão em 1995, por
Yukihiro Matsumoto, para ser usada como linguagem de script. Matsumoto queria uma
linguagem de script que fosse mais poderosa do que Perl, e mais orientada a objetos do que
Python. Ruby suporta programação funcional, orientada a objetos, imperativa e reflexiva. Foi
inspirada principalmente por Python (Python é uma linguagem de programação de alto nível,
interpretada, imperativa, orientada a objetos, de tipagem dinâmica e forte. A linguagem foi
projetada com a filosofia de enfatizar a importância do esforço do programador sobre o
esforço computacional. Prioriza a legibilidade do código sobre a velocidade ou
expressividade. Combina uma sintaxe concisa e clara com os recursos poderosos de sua
biblioteca padrão e por módulos e frameworks desenvolvidos por terceiros) (MENEGOTTO e
MIERLO, 2002).
O Ruby é uma linguagem bastante simples e flexível integra o processamento de dados
ao código HTML, permitindo que o acesso a partes dos modelos que acessam o banco de
dados, que geram a visualização da interface com o usuário, ou que façam o processamento
dos dados e comandos recebidos sejam separados de forma lógica e funcional dentro da
codificação (REHM, 2009).
As principais características da linguagem Ruby são:
Ruby é orientada a objetos não existindo nenhum tipo primitivo. Em Ruby,
mesmo os números, assim como Inteiros, Strings, Estrutura de Decisão, blocos de controle,
loops e o próprio valor nulo, tudo é feito através de mensagens entre objetos, assim como na
linguagem Smalltalk nulo são objetos;
A sintaxe do Ruby é fortemente influenciada pela sintaxe da linguagem Eiffel.
Assim como em outras linguagens, tem blocos em sua sintaxe (código delimitado por ‘{‘...‘}’
ou ‘do’...’end’), porém com a vantagem que eles podem ser passados para métodos, ou, até
mesmo, convertidos em closures. Do ponto de vista do aprendizado, isto facilita muito a vida
do programador, pois como a sintaxe é muito simples você escreve programas mais legíveis
de uma forma mais elegante e fica fácil de outro programador fazer manutenção de código
posteriormente (LOVATTO, 2007).
É uma linguagem Interpretada, o que permite rápido desenvolvimento pelo fato
de não ser necessário recompilar os programas para executá-los novamente, basta executá-lo
através do interpretador. Isto pode ser bom do ponto de vista da facilidade do programador na
28
hora da implementação e fase de testes, mas diminui o desempenho de um programa
complexo, devido à interpretação do código fonte cada vez que alguma instrução é chamada.
Ruby é altamente portável, isto significa que um programa Ruby executa sem
nenhuma mudança em qualquer plataforma. É claro que isto somente é verdade se você não
estiver utilizando módulos específicos de uma plataforma, como algumas GUIs para UNIX ou
WinGKR (Win32 GUI Kit for Ruby). Isto traz como vantagens um menor custo, porque
apenas um programa deve ser gerenciado e uma maior distribuição do programa, além dele
poder ser executado em várias plataformas.
Sua tipagem é dinâmica e forte, isso significa que todas as variáveis devem ter
um tipo (fazer parte de uma classe) não necessariamente precisam ser declaradas e a classe
pode ser alterada dinamicamente e expressiva que incorpora conceitos interessantes como
(REHM, 2009):
Duck-typing : os métodos não levam em consideração o tipo do objeto que é passado
como parâmetro, desde que o objeto tenha o comportamento esperado.
Módulos e mixins: semelhante a uma classe, um módulo é um grupo de métodos,
constantes e variáveis de classe, podendo ser utilizado como namespaces ou mixins. Se um
módulo define métodos de instância, esses métodos podem sem acrescentados a outras
classes, simulando uma espécie de herança múltipla.
Meta-programação: em Ruby está diretamente ligada a criação de Linguagens
Específicas de Domínio.
Classes abertas: permite redefinir uma classe previamente carregada (REHM, 2009).
3.9 Ruby on Rails
O Rails ou Ruby on Rails é um framework de código aberto, escrito na linguagem de
programação Ruby, para desenvolvimento de aplicações web. Ele foi criado por David
Heinemeier Hansson, na Dinamarca, e foi publicado em julho de 2004. Este framework foi
idealizado tendo em vista os seguintes objetivos:
Fornece todas as ferramentas necessárias para a criação de aplicações web,
incluindo persistência, lógica e apresentação. Tratando-se de uma solução de
desenvolvimento completa;
De forma mais transparente, permite a comunicação entre suas camadas;
Escrito por inteiro em apenas uma única linguagem;
29
Seguir o padrão de arquitetura MVC (ModelViewController - é um modelo de
desenvolvimento de Software, considerado um Design Pattern (padrão de projeto) utilizado
na Engenharia de Software. O modelo isola a "lógica" (A lógica da aplicação) da interface do
usuário (Inserir e exibir dados), permitindo desenvolver, editar e testar separadamente cada
parte.)) para organizar a estrutura das aplicações;
Dois princípios são seguidos pelo framework, com o objetivo de aumentar a
produtividade do desenvolvedor: O Ruby on Rails usa os principios CoC (Convention over
Configuration) e o Dry (Don't repeat yourself) para acelerar o desenvolvimento de aplicações.
DRY: é o conceito por trás da técnica de definir nomes, propriedades e códigos
em somente um lugar, reaproveitando esta informação em outros lugares que seja necessário.
Por exemplo, ao invés de ser mantida uma tabela “papers” e uma classe “Paper”, com uma
propriedade, um getter e um setter para cada campo na tabela, esta informação é mantida
apenas em banco de dados. Todas as propriedades e métodos necessários são “injetados” na
classe através de funcionalidades do framework. Isso gera uma grande economia de tempo e
aumenta a manutenibilidade das aplicações desenvolvidas – alterando apenas o banco de
dados, tudo o que se baseia nestas informações é atualizado automaticamente.
Convention over Configuration: Significa que o desenvolvedor só precisa
especificar aspectos não convencionais da aplicação. É dada a liberdade ao desenvolvedor de
fazer alterações conforme sua vontade, de forma que não siga a convenção, mas, se seguir a
convenção, geralmente nenhuma configuração será necessária, e o tempo de desenvolvimento
será reduzido. Por exemplo, os dados da classe “Paper” devem ficar na tabela “papers”; caso
isto seja feito, não será necessária nenhuma configuração. Porém, se o desenvolvedor quiser,
pode colocá-los em outra tabela, mas deverá configurar a aplicação para indicar essa
informação (AKITA, 2006).
Ruby on Rails é formado por um conjunto de cinco (5) outros frameworks, a saber:
Action Mailer, Action Pack, Action Web Service, Active Record e Active Support. A seguir,
uma breve descrição de suas funções:
1. Action Mailer é um framework responsável pelo desenvolvimento de camadas que
contenham serviços de email, pois consegue enviar emails via serviços SMTP ou responder
ao recebimento de e-mails. É relativamente pequeno e simples, porém poderoso e capaz de
realizar diversas operações apenas com chamadas de entrega de correspondência. Estas
camadas são utilizadas para criar código para enviar senhas perdidas, mensagens de boas
vindas durante a assinatura de determinado site ou serviço, e quaisquer outros casos de uso
que requeiram uma notificação escrita a uma pessoa ou sistema. Além disso, uma classe
30
Action Mailer pode ser utilizada para processar mensagens de email recebidas, como, por
exemplo, permitir que um weblog receba postagens diretamente do email.
2. Action Pack é responsável por fazer a separação da resposta de uma requisição web
em uma parte de controle (que faz a lógica) e outra de visão (processando um template). Esta
abordagem é realizada em dois passos, para normalmente criar (create), ler (read), atualizar
(update) ou deletar (delete) (CRUD – create, read, update, delete) a parte do modelo, que
geralmente tem um banco de dados por trás, antes de escolher entre renderizar um template ou
redirecionar para outra action. Neste framework são implementados o Action Controller e a
Action View.
3. Action WebService este pacote fornece ao aplicativo funcionalidades para que
possa publicar APIs (exposta via WSDL com mensagens transportadas via SOAP) a outros
sistemas e aplicativos ao invés de ser apenas uma interface gráfica via HTML.
4. Active Record é responsável por fazer o mapeamento entre os objetos da aplicação
e as tabelas da base de dados para criar um modelo de persistência do domínio onde a lógica e
os dados são apresentados e tratados de uma única forma. É uma implementação do padrão
(design pattern) Active Record. É graças a este pacote que funções antes tediosas e repetitivas
são dramaticamente simplificadas.
5. Active Support é uma coleção de várias classes utilitárias e extensões de
bibliotecas padrão que dão forma e coerência ao framework Rails. É responsábel por tomar
conta da carga de outras bibliotecas, dependências, recursos avançados como breakpoint em
tempo de execução, cachê, logs, plugins e muito mais (AKITA, 2006).
O framework Ruby on Rails, além de ter sido desenvolvido com o objetivo de
aumentar a produtividade e manter baixa a curva de aprendizagem, também foi pensado como
um framework que incentiva as boas práticas de codificação e organização das aplicações.
Neste âmbito, deve ser destacada a arquitetura das aplicações desenvolvidas sobre
Rails, que seguem o Padrão de Projeto (design pattern) MVC: ModelViewController ou
Modelo-Visão-Controlador (JUNQUEIRA e FORTES, 2012).
MVC é um padrão de projeto no qual as aplicações são desenvolvidas em camadas.
Neste caso, existem as camadas de modelo, visão e controle. Em cada uma dessas camadas,
deve ser alocar diferentes partes da aplicação em desenvolvimento, conforme o seguinte
critério: separar a lógica da aplicação (Model) da interface do usuário (View) e do fluxo da
aplicação (Controller) permitindo o desenvolvimento, teste e manutenção isolado de ambos.
Isso facilita bastante a manutenção do código e deixa a estrutura da aplicação bem organizada.
31
Modelo: Implementa o modelo representando a estrutura de baixo nível do
projeto, podendo ser o modelo objeto-relacional que implementa a camada de dados, e ou
num caso de MVC de Interface poderia guardar informações de estado dos controles;
Por exemplo, author, title e abstract fazem parte do domínio de um sistema para
revisão sistemática. Esta camada opera com os dados crus, e não possui a lógica necessária
para o tratamento dos dados. Em Ruby on Rails, esta camada é manipulada pelo Active
Record, que é uma implementação do design pattern Active Record.
Visão: camada responsável por exibir os dados (modelo) em uma forma
específica para a interação – no caso do Ruby on Rails, páginas web disponibilizadas no
navegador. Rails fornece o framework Action View para compor a camada de visão.
Controle: Implementa a camada respónsavel pelo gerenciamentos de eventos
no projeto, tais como cliques do usuario, chamando a camada Model para processar os
eventos, também pode manter informações de estado do usuario na aplicação;
Em Ruby on Rails, o Action Controller possui as funcionalidades para esta camada.
Figura 6 - Esquema das camadas do padrão MVC
Fonte: (DANIEL CÁRNIO JUNQUEIRA, 2012)
O fluxo de eventos que ocorrem entre as camadas do MVC é o seguinte:
1. O usuário interage com a interface (botões, links);
2. O Controller manipula o evento da interface, através de uma rotina prescrita,
também conhecida como action;
3. O Controller acessa o Model, atualizando-o caso seja necessário;
32
4. A View utiliza o Model para gerar uma interface apropriada, recuperando os dados
atualizados;
5. A interface do usuário espera por próximas interações, que iniciarão o ciclo
novamente (o protocolo HTTP não permite que uma comunicação seja iniciada no servidor)
(JUNQUEIRA e FORTES, 2012).
Dentre os benefícios na utilização do framework expostos pelo criador David
Heinemeier Hansson podemos citar:
Agilidade para o desenvolvimento de aplicações web.
Foco na criação da aplicação ao invés de configuração do framework.
Testes são incorporados diretamente no framework e são de fácil utilização,
por isso são utilizados.
Feedback instantâneo já que não é necessário recompilar a aplicação após uma
alteração.
Os geradores de código existentes facilitam o início do desenvolvimento de
uma nova Funcionalidade (REHM, 2009)
3.10 JSON
JSON (JavaScript Object Notation) é uma estrutura de dados em javascript.
Apesar de falarem muito disso recentemente, JSON não é uma tecnologia nova, faz parte do
javascript puro e não precisa de nenhum script pra trabalhar.
O JSON pode substituir o XML, e faz isso muito bem na hora de trabalhar com
respostas em AJAX.
A estrutura de dados fica mais simples de trabalhar e o tempo de execução de um
script lendo dados em JSON é dezenas de vezes mais rápido do que ler um conteúdo XML.
As principais linguagens de programação server side tem suporte pra escrever dados
em JSON (MARTINS, 2009).
33
CAPÍTULO IV
4. Desenvolvimento do Protótipo
4.1 Requisitos de Software
Para desenvolvedores, o Android SDK fornece um conjunto rico de ferramentas,
incluindo depurador, bibliotecas, emulador de telefone portátil, documentação, código de
amostra e tutoriais.
Aplicativos Android podem ser facilmente desenvolvidos usando Eclipse (a
plataforma oficial de desenvolvimento do Android) com a ajuda de um plug-in chamado
Android Development Tools (ADT). Isto ajuda no aproveitamento dos recursos ricos do
Eclipse, como assistente de conteúdo, recursos abertos, integração com JUnit e diferentes
visualizações e perspectivas para desenvolver um aplicativo Android.
Uma ampla variedade de widgets, que são similares a widgets do Java swing, facilita a
criação de uma UI rica para os aplicativos. Um Javadoc detalhado torna o processo de
desenvolvimento bem fácil.
Antes de começar a desenvolver o Android, assegure-se de ter instalado:
Eclipse SDK: V3.5 é a versão sugerida para uso com o SDK mais recente do
Android. O download pode ser feito na página de download do Galileo.
Android SDK: Para fazer o download, vá até developer.android.com/sdk e
selecione a versão correta para seu sistema operacional. Após completado o download,
execute o instalador. Para que seja possível a instalação, você precisará ter o java SDK
previamente instalado (http://www.felipesilveira.c om.br/minicurso-android).
Android Development Tools (ADT): Este é um plug-in do Eclipse. Ele é
equivalente ao JDT (Java Development Tools) para Android Development. Siga as instruções
detalhadas para a instalação do plug-in ADT e para a configuração da localização do SKD do
Android no Eclipse (http://imasters.com.br/artigo/19953/mobile/desenvolvimento-para-
android-usando-widgets-eclipse-e-android-parte-01).
34
4.1.1 Diagrama de Casos de Uso
Figura 7 – Caso de Uso
Descrição do caso de uso
Consultar Aluno:
Ator do caso de uso: Professor
Pré-condições: O aparelho deve estar conectado com uma rede do banco de
dados.
Fluxo Principal:
1 – O usuário acessa a opção consultar aluno no menu do aparelho.
2 – O usuário visualiza todos os cursos pelo protótipo.
3 – O usuário fecha a tela de visualização
Consultar Notas e Faltas:
Ator do caso de uso: Professor
Pré-condições: O aparelho deve estar conectado com uma rede do banco de
dados.
Fluxo Principal:
1 – O usuário acessa a opção consultar notas e faltas no menu do aparelho.
2 – O usuário visualiza todas as notas e faltas pelo protótipo.
3 – O usuário fecha a tela de visualização
35
Cadastrar Notas e Faltas:
Ator do caso de uso: Professor
Pré-condições: O aparelho deve estar conectado com uma rede do banco de
dados.
Fluxo Principal:
1 – O usuário acessa a opção cadastrar notas e faltas no menu do aparelho.
2 – O usuário cadastra notas e faltas pelo protótipo.
3 – O usuário salva as notas e faltas ou cancela a operação.
4 – O usuário fecha a tela de cadastro.
4.1.2 Digrama de Classe
Figura 8 – Diagrama de Classe
36
Tabela 2 - Descrição da classe Curso
Classe: Curso
Atributo Descrição
Codcurso Código atribuído a todos os cursos criados no
sistema (gerado pelo sistema)
Descricao Descreve o nome para cada curso (ex:
Informática, Design Gráfico, etc.)
Turno Período do dia que o curso será oferecido
(ex: manhã, tarde, etc.)
Tabela 3 - Descrição da classe Disciplina
Classe: Disciplina
Atributo Descrição
Coddisciplina Código atribuído a todos as disciplinas
criados no sistema (gerado pelo sistema)
Nome Descreve o nome para cada disciplina (ex:
Português, Matemática, etc.)
Tabela 4 - Descrição da classe CursoDisciplina
Classe: CursoDisciplina
Atributo Descrição
Codcursodisciplina Código que herda os atributos das classes
Curso e Disciplina
Codcurso Código atribuído a todos os cursos criados no
sistema (gerado pelo sistema)
Coddisciplina Código atribuído a todos as disciplinas
criados no sistema (gerado pelo sistema)
37
Tabela 5 - Descrição da classe Professor
Classe: Professor
Atributo Descrição
Codprofessor Código atribuído a todos os professores
cadastrados no sistema
Nome Descreve o nome de cada professor. (ex:
João, Pedro, etc.)
Telefone Número de telefone referente a cada
professor associado
Endereço Descreve o endereço de cada professor
Email Email de cada professor
Tabela 6 - Descrição da classe Turma
Classe: Turma
Atributo
Descrição
Codturma Código atribuído a todas as turmas
cadastradas no sistema
Descrição Descreve o nome de cada turma.
(ex:Arquitetura01, Arquitetura02, etc.)
Tabela 7 - Descrição da classe Aluno
Classe:Aluno
Atributo Descrição
Codaluno Código atribuído a todos os alunos
cadastrados no sistema
Matricula Descreve o número que é associado ao aluno
assim que é efetuada a matrícula do aluno.
(ex: 20013110010, 200132101019, etc.)
Nome Nome de cada aluno cadastrado no sistema
38
Tabela 8 - Descrição da classe TurmaAnoletivo
Tabela 9 - Descrição da classe Anoletivo
Classe: Anoletivo
Atributo Descrição
Codanoletivo Código atribuído a cada ano letivo criado no
sistema
Anoletivo Descreve o ano letivo a qual o período
pertence (ex: 2013, 2012, etc.)
PeriodoLetivo Descreve o período pertencente a cada ano
letivo (ex: 1, 2)
Tabela 10 - Descrição da classe CursoDisciplinaProfessor
Classe: CursoDisciplinaProfessor
Atributo Descrição
Codcursodisciplinaprofessor Código que herda os atributos das classes
Curso, Disciplina e Professor
Codcursodisciplina Código que herda os atributos das classes
Curso e Disciplina
Codprofessor Código atribuído a todos os professores
cadastrados no sistema
Classe: TurmaAnoletivo
Atributo Descrição
Codturmaanoletivo Código que herda os atributos das classes
Turma e AnoLetivo
Codturma Código atribuído a todas as turmas
cadastradas no sistema
Codanoletivo Código atribuído a cada ano letivo criado no
sistema
39
Tabela 11 - Descrição da classe AlunoTurmaAnoletivo
Classe: AlunoTurmaAnoletivo
Atributo Descrição
Codalunoturmaanoletivo Código que herda os atributos das classes
Curso, Turma e Anoletivo
Codturmaanoletivo Código que herda os atributos das classes
Turma e AnoLetivo
Codaluno Código atribuído a todos os alunos
cadastrados no sistema
Tabela 12 - Descrição da classe AnoletivoCursoDisciplinaProfessor
Classe: AnoletivoCursoDisciplinaProfessor
Atributo Descrição
Codanoletivocursodisciplinaprofessor Código que herda os atributos das classes
Anoletivo, Curso, Disciplina e Professor
Codanoletivo Código atribuído a cada ano letivo criado no
sistema
Codcursodisciplinaprofessor Código que herda os atributos das classes
Curso, Disciplina e Professor
Tabela 13 - Descrição da classe NotasFaltas
Classe: NotasFaltas
Atributo Descrição
Codnotasfaltas Código que herda os atributos das classes
Aluno, Turma, Anoletivo, Curso, Disciplina
e Professor
Codalunoturmaanoletivo Código que herda os atributos das classes
Curso, Turma e Anoletivo
Codanoletivocursodisciplinaprofessor Código que herda os atributos das classes
Anoletivo, Curso, Disciplina e Professor
Notas Notas que serão lançadas referentes a cada
aluno associado às respectivas disciplinas de
cada período cursado
40
Faltas Faltas lançadas referente a cada disciplina
cursada correspondente ao período letivo de
cada curso
4.1.3 Diagrama de Seqüência
Figura 9 – Login e Senha
Figura 10 – Consultar Aluno
41
Figura 11 – Consultar Notas e Faltas
Figura 12 – Cadastrar Notas e Faltas
42
4.1.4 Diagrama de Entidade de Relacionamento – DER
A título de protótipo, somente as classes abaixo foram implementadas, sendo, desta
forma, apenas esboçado no diagrama de Entidade, as classes em funcionalidade na aplicação
desenvolvida neste trabalho.
Figura 13 – Entidade-Relacionamento
4.2 Estudo de Caso
Nos capítulos anteriores formam apresentados conceitos sobre a plataforma android e
sobre a linguagem Ruby e o framework Ruby on Rail.
Neste capítulo, será apresentado o estudo de caso com o objetivo de aplicar os
conceitos estudados na criação de um aplicativo que possa trazer benefícios para os usuários,
fazendo com que o Android, Sistema Operacional, seja uma interface na qual os dados serão
inseridos, e o Rail seja um servidor de serviços.
43
Figura 12 – Conexão Android e Servidor
Em relação a figura 12, utilizou-se como ferramentas de desenvolvimento do protótipo
a plataforma Android, como sistema operacional, na versão 2.2 (FroYo). Utilizando o Eclipse
como ambiente de desenvolvimento.
E em relação ao Servidor realizou-se consultas aos Serviços Rails, que foi
implementado através do banco de dados SQLite.
4.2.1 A Aplicação
O estudo de caso deste trabalho tem como objetivo à criação de um aplicativo que
proporcionará ao usuário o lançamento de notas e faltas.
O aplicativo possibilitará a consulta e o cadastro de notas e faltas, e também, a
consulta de dados dos alunos.
4.2.1.1 Interface Inicial
O aplicativo Terminal Mobile IFF possui uma tela inicial onde os usuários
(professores) deverão inserir seu número de matrícula e senha e clicar no botão Entrar. Na
próxima tela, Menu Principal, é possível observar o nome do respectivo usuário (professor),
na parte central da interface, e logo abaixo, existem três botões. Destes, dois botões são
responsáveis por abrir uma nova interface para controle de Dados do Aluno e Notas e Faltas,
respectivamente. Ao pressionar o botão Sair o aplicativo fechará.
44
Figura 15 – A Tela Inicial do Terminal Mobile IFF e o Menu Principal do aplicativo
4.2.1.2 Gerência de Consulta de Alunos
Ao clicar no botão Consultar Aluno, a interface de consulta será aberta. Nesta é
possível gerenciar a consulta dos dados dos alunos. Ao inserir o número de matrícula do aluno
no campo Matrícula Aluno e pressionar o botão Pesquisar, será listada as informações do
mesmo, tais como: a matrícula, o nome, o curso e o período. Ao pressionar o botão Voltar,
retornará ao Menu Principal.
45
Figura 16 – Telas para Gerência de Consulta de Alunos
4.2.1.3 Gerência de Consulta de Notas e Faltas
Ao clicar no botão Notas e Faltas, na Tela Inicial, a interface de Consulta de Notas e
Faltas será aberta. Como mostra na figura 17 é possível gerenciar o cadastro das Notas e
Faltas ao selecionar um dos Cursos e uma das Disciplinas no spinner, presente na parte
superior desta tela onde serão listados os nomes dos alunos cadastrados, suas Notas e Faltas,
respectivamente.
Figura 17 – Tela de Consulta de Notas e Faltas
46
Nas duas telas abaixo, conforme mostra as figuras 18, ao clicar nas opções Disciplinas
e Cursos serão listados todas as disciplinas e todos os cursos cadastrados, respectivamente.
Porém, ao selecionar apenas um Curso e apenas uma Disciplina, a lista passará a conter
apenas as informações das opções escolhidas.
Figura 18 – Menus que aparece ao clicar no spinner de Curso e Disciplinas
4.2.1.4 Gerência Lançamento de Notas e Faltas
A interface de controle de Lançamento pode ser acessada ao clicar sobre o nome de
cada aluno listado, após ser escolhido o curso e a disciplina, respectivamente. Nesta é possível
Editar as Notas e as Frequências. No topo da tela existe um campo com a descrição do Curso,
da Disciplina e do Nome do Aluno. Logo abaixo, dois campos para digitação da nota e da
freqüência. E para finalizar a adição destes dados, o usuário deverá clicar no botão Editar.
Este processo deverá se repetir até que todas as notas e faltas dos alunos de suas respectivas
disciplinas e curso sejam adicionados. Ao pressionar o botão Voltar, retornará a tela de
Consulta de Notas e Frequência.
47
Figura 19 – Tela para editação de Notas e Freqüências
4.2.2 O Processo de Desenvolvimento
Trata-se de um processo pelo qual o aplicativo passa desde sua criação ate sua
finalização.
Este projeto foi divido em partes de acordo com a função que elas exercem. Em
seguida foi definida a ordem de implementação de cada uma das partes, considerando as
dependências de cada uma delas pelas demais. Foi implementado o aplicativo na seguinte
ordem: gerência de Consulta de Alunos, gerência de Consulta de Notas e Faltas, gerência de
Cadastro de Notas e Faltas.
A criação dessas partes passou pelos seguintes processos: criação da base de dados e
métodos para a gerencia dos mesmos, criação da interface gráfica, implementação das
acticitys e testes.
Em relação ao protótipo desenvolvido, vale ressaltar a integração de aplicações através
de serviços da web. Como mostra o código 1, foi realizada a consulta ao Serviço Rails,
implementada no projeto, a partir de uma requisição em HTTP. Como não é permitido o
acesso a rede a partir da thread principal que roda a activity, pois pode ocasionar o travamento
da aplicação, o Android disponibiliza através da classe AsyncTask uma forma simples de criar
tarefas distintas que executam operações em background, em outra thread, e que publica os
resultados da operação na UI thread (activity).
48
public void pesquisarAluno(View v) {
String filtro = this.matricula.getText().toString();
new ConsultaAlunoTask().execute(filtro + ".json");
}
private class ConsultaAlunoTask extends AsyncTask<String, Void, String[]> {
ProgressDialog dialog;
@Override
protected void onPreExecute() {
dialog = new ProgressDialog(ConsultaAlunoActivity.this);
dialog.show();
}
@Override
protected void onPostExecute(String[] result) {
if (result != null) {
txvmatricula.setText(result[0]);
txvnome.setText(result[1]);
txvcurso.setText(result[1].substring(5, result[1].indexOf("
")));
txvperiodo.setText("1o.");
}
dialog.dismiss();
}
@Override
protected String[] doInBackground(String... params) {
// String[] dadosAlunos = new String[100];
try {
String filtro = params[0];
if (TextUtils.isEmpty(filtro)) {
return null;
49
}
String modelo = "alunos/" + filtro;
Sring conteudo = HTTPUtils.acessar(modelo);
JSONObject aluno = new JSONObject(conteudo);
String[] dadosAlunos = new String[2];
dadosAlunos[0] = aluno.getString("matricula");
dadosAlunos[1] = aluno.getString("nome");
return dadosAlunos;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
Código 1 - Classe ConsultaAlunoTask
A classe AsyncTask, utilizada no desenvolvimento da aplicação, ela executa três
métodos:
onPreExecute: foi o primeiro método a ser implementado antes que a tarefa
fosse executada. Neste, incluiu-se a exibição de um ProgressDialog, que foi inserida na UI
thread, antes da tarefa ser executada, nos permitindo modificar a interface, através de uma
caixa de progresso;
doInBackground: foi o segundo método executado em uma outra thread, onde
a operação foi implementada. Neste método foram recebidos os Params (tratam de um tipo de
parâmetro que são enviados para a execução da tarefa) definidos pela AsyncTask e retornando
os resultados da operação como sendo do tipo Result (é um tipo de retorno da operação
realizada). Neste método pode ser invocado o publishProgess para informar o andamento da
operação;
onPostExecute: por fim, o terceiro método, também inserido na Ui thread. Foi
neste método que recebeu-se o Result como parâmetro e realizou-se as atualizações
necessárias de tela, como fechar o ProgressDialog e atualizar uma ListView com os dados
obtidos do método doInBackground.
50
public class HTTPUtils {
public static String acessar(String modelo) {
try {
//String urlIFF = "http://192.168.0.100:3000/";
String urlIFF = "http://10.12.255.18:3000/";
String url1 = Uri.parse(urlIFF + modelo).toString();
URL url = new URL(url1);
URLConnection conn = url.openConnection();
InputStream is = conn.getInputStream();
Scanner scanner = new Scanner(is);
String conteudo = scanner.useDelimiter("\\A").next();
scanner.close();
return conteudo;
} catch (Exception e) {
return null;
}
}
}
Código 2 - Classe HTTPUtils
Para a implementação do método doInBackground, foi necessário a realização de uma
requisição em HTTP para uma determinada URL, que foi montada a partir dos termos de
busca informados como parâmetro e em seguida, processado a resposta obtida que estava em
formato JSON, criando um String [] com os dados do Acadêmico em Rails.
Foi feito uma classe chamada HTTPUtils para fazer a requisição em HTTP e a captura
de respostas para o encerramento desta implementação.
Nesta classe foi inserido um método chamado acessar, que recebeu uma String como
parâmetro e que tratou da URL desejada e retornou uma String que foi o conteúdo obtido
como resposta da solicitação.
51
Na implementação foi aberto uma conexão a partir do endereço informado e nas linhas
seguintes foi feita a leitura dos dados recebidos utilizando um Scanner.
4.2.2.1 A Base de Dados
A criação da base de dados utilizada pela aplicação é uma parte importante do
processo de desenvolvimento e merece atenção do desenvolvedor. A forma em que esta base
será estruturada e a forma como seus dados serão manipulados, influenciará diretamente na
essência da aplicação, visto que os recursos dos dispositivos móveis são mais limitados.
Por fim, a base de dados da Aplicação desenvolvida foi criada independente da base
de dados do IFF.
4.2.2.2 Publicação
O aplicativo desenvolvido neste estudo de caso ainda é um protótipo, além disso, este
ainda não possui todos os testes implementados. Por estes motivos, o aplicativo não foi
submetido à publicação.
Porém, os resultados obtidos ao final deste estudo de caso estão disponibilizados no
site de compartilhamento de projetos GitHub (tfsouza, 2013). Neste é possível encontrar uma
cópia deste trabalho e o código fonte do estudo de caso apresentado, além do instalador do
aplicativo gerado (.apk). Para instalar este aplicativo basta o copiar para o dispositivo móvel e
executá-lo.
O código fonte será acompanhado da Licença GNU GPL (Licença Pública Geral) que
possibilitará qualquer usuário copiar, utilizar, alterar e distribuir este aplicativo. Como
qualquer licença de software, esta também exige a execução dos termos dispostos além de
assegurar os direitos do autor ou desenvolvedor e do usuário final.
52
Capítulo V
5. Conclusão
Este trabalho descreveu o Sistema Operacional Android, o qual promove o acesso à
consulta de dados de alunos, suas notas e faltas, além do cadastro de notas e faltas pelos
professores.
Neste processo foi descrita a estrutura da plataforma e, também, as ferramentas
utilizadas no desenvolvimento.
Os principais resultados do projeto estão associados ao fato de poder efetuar o acesso
ao protótipo para consulta e inserção de dados, desta forma pudemos perceber que o projeto
foi válido pela facilidade no desenvolvimento e pelo fato de proporcionar ao usuário
comodidade e rápido acesso durante a integração dos dados.
Desta forma, através do desenvolvimento do protótipo, podemos demonstrar que foi
possível acessar através do celular a consulta ao serviço Rails.
A princípio, uma das maiores dificuldades no desenvolvimento da aplicação foi a falta
de conhecimento da linguagem Ruby, sendo necessário um tempo disponível para pesquisas,
análises e testes desta linguagem.
O desenvolvimento deste projeto nos trouxe novos conhecimentos relacionados à
Orientação a Objetos, Tecnologias Móveis, Servidores de Aplicação e a Plataforma Android.
5.1 Trabalhos Futuros
Como trabalhos futuros faz-se necessário aprimorar a interface da aplicação, além de
implementar novos recursos, tornando-a mais completa, e que atenda as necessidades dos
usuários. A partir disso é sugerida a implementação completa para o professor baseado no
sistema Qualidata e a criação de um novo módulo para o acesso dos alunos ao histórico
escolar e o CR e disponibilizando-o na loja Google Play.
Além disso, é sugerido que em Consulta de Dados de Alunos, seja listado, além da
matrícula, nome, curso e período, as notas do aluno selecionado.
E também, inserir a opção de escolher o ano/período letivo para as informações de
consulta e inserção de dados.
53
Capítulo VI
6. Bibliografia
5CQUALIBR. Portal do Software Público Brasileiro, 2012. Disponivel em:
<http://www.softwarepublico.gov.br/5cqualibr/xowiki/bdd>. Acesso em: 29 abr. 2012.
AKITA, F. Repensando a Web com Rails. Rio de Janeiro: Brasport, 2006.
ALENCAR, R. L. S. D. Test-Driven Development (TDD). DevMedia, 2012.
Disponivel em:
<http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=10025>. Acesso em: 29
abril 2012.
BLOG LOCAWEB. Scrum – Entidades e Sprints. bloglocaweb, 2008. Disponivel em:
<http://blog.locaweb.com.br/metodologias-ageis/scrum-entidades-do-scrum/>. Acesso em: 27
agosto 2012.
BORBOREMA, T. Impacto da aplicação da metodologia XP nas organizações de
desenvolvimento de software, Pouso Alegre, 2007.
BRASILDROID. As versões do Android e suas diferenças. Brasildroid, 2011.
Disponivel em: <http://brasildroid.com.br/discussoes-gerais/535-artigo-as-versoes-do-
android-suas-diferencas.html>. Acesso em: 18 maio 2013.
COELHO, C. D. S. Relato de experiência na implantação de um método ágil em uma
equipe de desenvolvimento de software, Lavras, 2012.
DANNORTH. Behaviour Driven Development, 2009. Disponivel em:
<http://behaviour-driven.org/BehaviourDrivenDevelopment?action=SpellCheck>. Acesso em:
29 abr. 2012.
DOS SANTOS, E. G.; BOEIRA, H. D. R. F. Ferramenta para Gerenciamento de
Requisitos em Metodologias Ágeis. revistaseletronicas.pucrs, 2008. Disponivel em:
<http://revistaseletronicas.pucrs.br/ojs/index.php/hifen/article/viewFile/4593/3480>. Acesso
em: 12 abr. 2012.
54
ELIAS, G. D. S. Métricas associadas ao desenvolvimento de software usando métodos
ágeis, Gravataí, abril 2008.
FERNANDO. A evolução da tecnologia dos celulares. Dicas de como fazer, 2011.
Disponivel em: <http://dicasdecomofazer.net/a-evolucao-da-tecnologia-dos-celulares/>.
Acesso em: 12 abr. 2013.
FERNANDO. A evolução da teconolgia dos celulares. A evolução das tecnologias,
2012. Disponivel em: <http://lagjean.blogspot.com.br/2012_04_01_archive.html>. Acesso
em: 14 abr. 2013.
FOWLER, M. XPManager - Metodologias Ágeis. Naphta, 2010. Disponivel em:
<http://www.naphta.com.br/xpmanager/xpmanager_metodologiasageis.html>. Acesso em: 14
fevereiro 2012.
FRANCO, M. Introdução ao Brew. Devmedia, 2012. Disponivel em:
<http://www.devmedia.com.br/introducao-ao-brew/7803>. Acesso em: 11 maio 2012.
GONÇALVES, J., 2011. Disponivel em:
<http://www.hiperbytes.com.br/geral/metodologia-xp-extreme-programming-comparativos-
entre-as-metodologias/>. Acesso em: 27 abr. 2012.
HECKE, C. Android 4.1 Jelly Bean: saiba tudo sobre o novo sistema operacional
móvel. Tecmundo, 2012. Disponivel em: <http://www.tecmundo.com.br/jelly-bean/25784-
android-4-1-jelly-bean-saiba-tudo-sobre-o-novo-sistema-operacional-movel.htm>. Acesso
em: 12 dez. 2012.
HECKE, C. Android 4.1 Jelly Bean: saiba tudo sobre o novo sistema operacional
móvel. Tecmundo, 2012. Disponivel em: <http://www.tecmundo.com.br/jelly-bean/25784-
android-4-1-jelly-bean-saiba-tudo-sobre-o-novo-sistema-operacional-movel.htm>. Acesso
em: 12 dez. 2012.
JUNQUEIRA, D. C.; FORTES, R. P. D. M., 2012. Disponivel em:
<http://www2.icmc.usp.br/~renata/RoR-capitulo_webmedia07.pdf>. Acesso em: 15 março
2012.
55
LANDIM, W. Os doces do Android. Tecmundo, 2011. Disponivel em:
<http://www.tecmundo.com.br/infografico/13640-os-doces-do-android-infografico-.htm>.
Acesso em: 17 novembro 2012.
LANDIM, W. Os doces do Android [infográfico]. Tecmundo, 2011. Disponivel em:
<http://www.tecmundo.com.br/infografico/13640-os-doces-do-android-infografico-.htm>.
Acesso em: 10 abr. 2013.
LAPOLL, F. R. et al. Modelo de desenvolvimento de objetos de aprendizagem
baseado em Metodologias Ágeis. Revista Brasileira de Informática na Educação, Rio de
Janeiro, v. 18, n. 2, 2010.
LEMOS, A. C. D. Aplicação de uma metodologia de ajuste do sistema kanban em um
caso real utilizando simulação computacional. ufsc - repositorio de conteúdo digital, 2012.
Disponivel em: <http://repositorio.ufsc.br/handle/123456789/81207>. Acesso em: 2012 dez.
20.
LIMA, E. Introdução ao Android - Parte 1. eddersonlima.net, 2012. Disponivel em:
<http://www.blog.edersonlima.net/?p=68>. Acesso em: 15 maio 2013.
LIMA, E. R. D. edersonlima.net. Introdução ao Android - Parte 1 (Activity, Intent
e Android Manifest), 2012. Disponivel em: <http://www.blog.edersonlima.net/?page_id=2>.
Acesso em: 11 maio 2012.
LOVATTO, C. W. Comparando ambientes de desenvolvimento Java e Ruby on Rail.
Wikipedia, 2007. Disponivel em:
<http://pt.wikipedia.org/wiki/Ruby_%28linguagem_de_programa%C3%A7%C3%A3o%29#c
ite_note-About-2>. Acesso em: 06 fevereiro 2012.
MÁRCIA SAVOINE, L. M. M. R. C. D. S. Utilizando Metodologia Ágil XP e Scrum:
Um Estudo de Caso Prático. XI Encontro de Estudantes de Informática do Tocantins,
Palmas, p. 93-102, 2009.
MARIOTT, F. S. Kanban: o ágil adaptativo. Engenharia de Software Magazine, n.
45, fevereiro 2012.
56
MARTINS, D. A. O que é JSON, como e quando utilizar? Tidbits, 2009. Disponivel
em: <http://www.tidbits.com.br/o-que-e-json-como-e-quando-utilizar>. Acesso em: 19 dez.
2012.
MARTINS, M. Utilizando Kanban com a metodologia ágil SCRUM. DevMedia,
2009. Disponivel em: <http://www.devmedia.com.br/-net-magazine-63-utilizando-kanban-
com-a-metodologia-agil-scrum/13537>. Acesso em: 30 abril 2012.
MARTINS, R. J. W. D. A. Desenvolvimento de Aplicativo para Smartphone com a
Plataforma Android. puc-rio, 2009. Disponivel em: <http://www.icad.puc-
rio.br/~projetos/android/files/monografia.pdf>. Acesso em: 20 abr. 2013.
MENEGOTTO, A. B.; MIERLO, F. A linguagem Ruby. dotlib, 2002. Disponivel em:
<http://www.dotlib.com.br/i/4768a22a0d58da3cfa71294e40ed6229.pdf>. Acesso em: 12 out.
2012.
MURIS LAGE JUNIOR, M. G. F. Evolução e avaliação da utilização do sistema
kanban em empresas paulistas. Revista de Administração, São Paulo, v. 44, n. 4, dezembro
2009.
NASCIMENTO, P. BDD – Foco no comportamento do sistema. Blog Scrumhalf,
2011. Disponivel em: <http://blog.myscrumhalf.com/2011/10/bdd-%E2%80%93-foco-no-
comportamento-do-
sistema/?utm_source=facebook&utm_medium=social&utm_campaign=post-2011-10-20>.
Acesso em: 20 nov. 2012.
NETO, E. I. Ferramenta Educacional para Ensino de Práticas do SCRUM, Porto
Alegre, 25 julho 2008.
NETO, E. I. Scrumming Ferramenta Educacional para Ensino de Práticas do Scrum,
Porto Alegre, 25 julho 2008.
PAULA L.O. LIBARDI, V. B. Métodos Ágeis, Limeira, 2010.
PRANGE, H. F. Uma avaliação empírica de um ambiente favorável para o
desenvolvimento dirigido por testesS, Rio de Janeiro, 29 abril 2012.
REHM, F. G. Aplicando Domain-Driven Design Utilizando Ruby e o framework
Rails. Salvador: [s.n.], 2009.
57
REIS, D. F. Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento de
Software (Metodologias Clássicas x Extreme Programming). Devmedia, 2008. Disponivel
em: <http://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis-para-
desenvolvimento-de-software-metodologias-classicas-x-extreme-programming/10596>.
Acesso em: 25 abr. 2012.
RUOSO, D. Diferenças entre métodos ágeis e tradicionais. Software Livre Brasil,
2009. Disponivel em: <http://softwarelivre.org/ruoso/blog/diferencas-entre-metodos-ageis-e-
tradicionais>. Acesso em: 30 abril 2012.
SAVOINE, M. et al. Análise de gerenciamento de projeto de software utilizando
metodologia ágil XP e Scrum: um Estudo de caso prático, Araguaína, 27 agosto 2012.
SILVA, F. G.; S. C. P. HOENTSCH, L. S. Uma análise das Metodologias Ágeis FDD
e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR. Revista Scientia Plena, 2009.
Disponivel em: <http://www.scientiaplena.org.br/ojs/index.php/sp/article/view/678>. Acesso
em: 10 out. 2012.
SILVA, T. M.; DOS SANTOS, H. A. SATI - Sistema de Atendimento Técnico de
Informática, Brasília, 2011.
SILVEIRA, F. Android - Desenvolvimento Android. Minicurso Android, 2012.
Disponivel em: <http://www.felipesilveira.com.br/minicurso-android/#%282%29>. Acesso
em: 16 nov. 2012.
SOARES, M. D. S., 2004. Disponivel em:
<http://revistas.facecla.com.br/index.php/reinfo/article/viewArticle/146>. Acesso em: 16 fev.
2012.
SOUZA, L. M. D. Método Ágil XP (Extreme Programming). Academos - Revista
Eletrônica da FIA, v. III, n. 3, julho - dezembro 2007.
TECMÓVEL. Novas tendência de tecnologia móvel. TecMóvel, 2009. Disponivel em:
<http://www.tecmovel.xpg.com.br/internet_movel_telefonia_geracoes.html>. Acesso em: 10
novembro 2012.
TELES, V. M. Um estudo de caso da adoção das práticas e valores do Extreme
Programming, Rio de Janeiro, 2005.
58
VIVA SEM FIO. Arquitetura do Android. Viva sem fio, 2008. Disponivel em:
<http://www.vivasemfio.com/blog/arquitetura-do-android/>. Acesso em: 28 abr. 2013.
VIVASEMFIO. Arquitetura do Android. Vivasemfio, 2008. Disponivel em:
<http://www.vivasemfio.com/blog/arquitetura-do-android/>. Acesso em: 15 novembro 2012.
WIKIPÉDIA. 3G. Wikipédia, 2013. Disponivel em:
<http://pt.wikipedia.org/wiki/3G>. Acesso em: 14 abr. 2013.
WIKIPÉDIA. Anexo:Histórico de versões do Android. Wikipédia, 2013. Disponivel
em:
<http://pt.wikipedia.org/wiki/Anexo:Hist%C3%B3rico_de_vers%C3%B5es_do_Android>.
Acesso em: 02 maio 2013.
WIKIPÉDIA. Brew. Wiipédia, 2013. Disponivel em:
<http://pt.wikipedia.org/wiki/Brew>. Acesso em: 20 abr. 2013.
WIKIPÉDIA. SuperWaba. Wikipédia, 2013. Disponivel em:
<http://pt.wikipedia.org/wiki/SuperWaba>. Acesso em: 20 abr. 2013.
WIKIPÉDIA. Tecnologia móvel. Wikipédia, 2013. Disponivel em:
<http://pt.wikipedia.org/wiki/Tecnologia_m%C3%B3vel>. Acesso em: 10 maio 2013.
WIKIPEDIA, A ENCICLOPÉDIA LIVRE. Tecnologia móvel. Wikipedia, 2013.
Disponivel em: <http://pt.wikipedia.org/wiki/Tecnologia_m%C3%B3vel>. Acesso em: 12
abr. 2013.
WIKIPÉDIA. Android. Wikipédia, 2013. Disponivel em:
<http://pt.wikipedia.org/wiki/Android>. Acesso em: 12 maio 2013.
ZARATIN, R. Android ou iOS? Texto de resposta. Mobilidade.FM, 2011. Disponivel
em: <http://mobilidade.fm/coluna/2011/12/android-ou-ios-texto-de-resposta/>. Acesso em: 29
abr. 2013.
ZARATIN, R. AndroidxiOS. euandroid, 2011. Disponivel em:
<http://www.euandroid.com.br/coluna/2011/12/android-ou-ios-texto-de-resposta/>. Acesso
em: 16 novembro 2012.
59
ZIEGLER, M. F. Aplicativo de celular é capaz de diagnosticar catarata. ig, 2011.
Disponivel em:
<http://ultimosegundo.ig.com.br/ciencia/aplicativo+de+celular+e+capaz+de+diagnosticar+cat
arata/n1596984073925.html>. Acesso em: 13 setembro 2012.
Tfsouza – Terminal Mobile IFF. 2013. Disponível em :
<https://github.com/tfsouza/TerMobileAndroidRails>