Ricardo Hiroyuki Eihara Junior Orientador
Transcript of Ricardo Hiroyuki Eihara Junior Orientador
rev. 2.0
FACULDADE DE TECNOLOGIA DE SOROCABA "JOSÉ CRESPO
GONZALES"
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
RELATÓRIO FINAL
Ricardo Hiroyuki Eihara Junior
Refatoração de Aplicativo Mobile: Estudo de Caso (Padrões de Projeto e
Boas Práticas)
Sorocaba
Junho/2016
Refatoração de Aplicativo Mobile: Estudo de Caso (Padrões de Projeto e
Boas Práticas)
Ricardo Hiroyuki Eihara Junior
Orientadora: Prof.ª M. ª Denilce de Almeida Oliveira Veloso
Sorocaba
Junho/2016
LISTA DE FIGURAS
Figura 1 : O modelo Model-View-Controller. .................................................... 12
Figura 2 : O Ciclo Red-Green-Refactor. ........................................................... 16
Figura 3: Instalação do RVM, Ruby, Rails e Postgresql ................................... 24
Figura 4: Configuração do Postgresql. ............................................................. 25
Figura 5: Configuração do Rails com o banco de dados. ................................. 25
Figura 6: Instalação do Rbenv. ......................................................................... 27
Figura 7: Instalação do Ruby, Gem Bundler, Rails, Postgresql. ....................... 27
Figura 8: Configuração do Postgresql e edição do database.yml. ................... 28
Figura 9: Instalação do rbenv-vars, responsável pelas variáveis ambiente. .... 29
Figura 10: Criação do banco de dados e instalação do Puma. ........................ 29
Figura 11: Configuração do Puma. ................................................................... 30
Figura 12: Configuração entre o Puma e o Nginx ............................................ 30
Figura 13: Criando um upstart script para o Puma iniciar sempre na
inicialização do sistema. ................................................................................... 31
Figura 14: Model do Estágio............................................................................. 34
Figura 15: Model do Usuário. ........................................................................... 35
Figura 16: Controller da Notícia. ....................................................................... 36
Figura 17: Controller da Notícia modificado. .................................................... 36
Figura 18: Modificadores de acesso. ................................................................ 36
Figura 19: Comando para executar todos os testes. ........................................ 38
Figura 20: Executar apenas um arquivo teste no rspec. .................................. 38
Figura 21: Execução do teste de estresse do servidor. .................................... 39
Figura 22: Gráfico indicando o número de acessos concorrentes por teste. .... 41
Figura 23: Gráfico indicando o tempo de resposta por teste. ........................... 41
LISTA DE TABELAS
Tabela 1: o número de acessos por teste e tempo de resposta por teste. ....... 40
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface (Interface de Programação de
Aplicativo).
BD - Banco de Dados.
CPU – Control Process Unit (Unidade de Controle de Processo)
GNU – GNU’s not Unix (GNU não é Unix).
IP – Internet Protocol (Protocolo de Internet).
MVC – Model-View-Controller (Modelo-Vista-Controlador).
RJI - Regime de Jornada Integral.
RVM - Ruby Version Manager (Gerenciador de Versões do Ruby).
SCP – Secure Copy.
SGDB – Sistema Gerenciador de Banco de Dados.
SQL – Structured Query Language (Linguagem de Consulta Estruturada).
SSH – Secure Shell.
TDD - (Test Driven-Development ou Desenvolvimento dirigido por testes).
TCP - Transmission Control Protocol (Protocolo de Controle de Transmissão).
RESUMO
Em uma época em que tanto se fala tanto em metodologias ágeis, a
preocupação dos desenvolvedores durante o desenvolvimento de software
além de fazer o mesmo funcionar, principalmente devido ao prazo para
atendimento dos clientes deveria ser também com a qualidade do código. O
projeto pretende estudar os principais conceitos sobre refatoração e aplicar em
um Estudo de Caso que se encontra na sua versão protótipo, que foi
desenvolvido por um grupo de Iniciação Científica e tinha como objetivo criar
aplicativos para mostrar notícias e estágios na Faculdade de Tecnologia de
Sorocaba "José Crespo Gonzales". Foram criados: um Web Service para
comunicação dos aplicativos das plataformas Android e Windows Phone, uma
aplicação para entrada de dados, um aplicativo na plataforma Android e um
aplicativo na plataforma Windows Phone. O projeto completo está sendo
desenvolvido em equipe e este projeto/relatório em particular pretende focar
Padrões de Projetos e Boas Práticas para auxiliar na refatoração.
Palavras-Chave: refactoring, mobile, qualidade de software, Ruby on rails, Web
Service
SUMÁRIO
LISTA DE FIGURAS .......................................................................................... 0
LISTA DE TABELAS .......................................................................................... 1
LISTA DE ABREVIATURAS E SIGLAS ............................................................. 2
RESUMO............................................................................................................ 3
1 INTRODUÇÃO E JUSTIFICATIVA ............................................................... 10
2 REVISÃO BIBLIOGRÁFICA ......................................................................... 11
2.1 Padrão de Projeto de Software .................................................................. 11
2.1.1 Exemplo Padrão de Projeto .......................................................... 11
2.2 Refatoração ............................................................................................... 13
2.2.1 Por que utilizar a refatoração? ...................................................... 15
2.2.2 Técnicas de Refatoração .............................................................. 18
5.4.1.1. Renomear variável..................................................................... 18
5.4.1.2. Extração de método................................................................... 18
5.4.1.3. Mover método ............................................................................ 18
5.4.1.4. Mover atributo ............................................................................ 18
5.4.1.5. Extrair superclasse .................................................................... 18
5.4.1.6 Renomear Método ...................................................................... 18
2.2.3 Refatoração do WebService ......................................................... 18
5.4.3.1. Sobre o código do autor ............................................................ 18
3 OBJETIVOS ................................................................................................. 19
4 MATERIAIS E MÉTODOS ........................................................................... 20
4.1 Etapas ........................................................................................................ 20
4.2 Ferramentas ............................................................................................... 20
4.2.1 Ferramentas a serem instaladas no computador do autor (aluno) 20
4.2.2 Ferramentas a serem instaladas no servidor ................................ 21
4.2.2.1 RVM........................................................................................... 21
4.2.2.2 Rbenv ........................................................................................ 21
4.2.2.3 Ruby ........................................................................................... 22
4.2.2.4 Ruby On Rails ........................................................................... 22
4.2.2.5 Postgresql .................................................................................. 22
4.2.2.6 Nginx .......................................................................................... 22
4.2.2.7 Puma .......................................................................................... 22
4.2.2.8 Gem Bundler .............................................................................. 23
4.2.2.9 SSH ............................................................................................ 23
4.2.2.10 Fatec-Api .................................................................................. 23
4.2.2.11 SCP .......................................................................................... 23
4.2.2.12 Siege ........................................................................................ 23
4.2.2.13 Android Studio .......................................................................... 23
5 RESULTADOS E DISCUSSÕES ................................................................. 24
5.1 Instalação dos Softwares ........................................................................... 24
5.1.1 Instalação da aplicação na máquina do usuário ........................... 24
5.1.2 Instalação da máquina servidora e aplicação ............................... 27
5.1.3 Ferramenta de transferência de arquivos ..................................... 32
5.2 Refatoração e Problemas encontrados ...................................................... 33
5.2.1. Instalação do Servidor .................................................................. 33
5.2.2. Normas seguidas (guia de conduta Ruby/Rails) ........................... 34
5.2.3. Correção de Funcionalidade ......................................................... 35
5.2.4 Refatoração do aplicativo Android .................................................... 36
5.3 Testes de Código ....................................................................................... 37
5.3.1 Rspec ........................................................................................... 37
5.3.2 Executando os testes do rspec ..................................................... 38
5.4 Testes do Servidor ..................................................................................... 39
5.4.1 Resultados dos testes do servidor ................................................ 40
5.6.1.1. Discutir o tempo de resposta mais apropriado para as APIs ..... 42
5.6.1.2. Explicar a limitação do hardware e banda do servidor .............. 42
5.6.1.3. Abrangência do servidor na Faculdade. .................................... 43
5.5 Análise do código do aplicativo Android .................................................... 44
6 CONCLUSÃO .............................................................................................. 45
REFERÊNCIAS ................................................................................................ 46
GLOSSÁRIO .................................................................................................... 49
10
1 INTRODUÇÃO E JUSTIFICATIVA
A procura alta por softwares/aplicações que atendam a demanda exigida pelo
mercado, influencia diretamente na competitividade entre as empresas que são
desenvolvedoras. Desenvolver softwares com qualidade e dentro do prazo
previamente estabelecido tem sido um desafio para a Engenharia de Software.
O projeto completo está sendo desenvolvido em equipe e pretende estudar
conceitos, práticas e ferramentas de Refatoração e aplicar em Estudo de Caso uma
aplicação mobile já existente na sua versão protótipo. A ideia deste projeto surgiu
por dois motivos:
Um grupo anterior de Iniciação Científica concluiu o protótipo do projeto e
acreditou-se que valia a pena continuar o projeto por se tratar de interesse da
comunidade acadêmica.
Para continuar o código do referido projeto optou-se por utilizar técnicas de
refatoração, pois sempre na segunda versão são melhorados diversos aspectos.
Além disso é uma oportunidade para o grupo estudar sobre o assunto.
A equipe do projeto e suas tarefas são as seguintes:
Bruno Garcia Moura - Refatoração Aplicativo versão Android
Gabriel Mendonça - Refatoração Aplicativo Web Service
Ricardo Hiroyuki Eihara Junior - Padrões de Projeto e boas práticas
Vinicius da Silva Puente - Refatoração Aplicativo versão Windows Phone
Com a desistência dos alunos Vinicius da Silva Puente e Bruno Garcia Moura
do projeto por motivos pessoais, a Refatoração Aplicativo versão Windows Phone
passou a ser atribuição do aluno Gabriel Mendonça e a Refatoração do Aplicatico
versão Android passou a ser atribuição do aluno Ricardo Hiroyuki Eihara Junior.
11
2 REVISÃO BIBLIOGRÁFICA
2.1 Padrão de Projeto de Software
Design Pattern surgiu por Christopher Alexander quando ele propôs a criação
de catálogos de padrões de arquitetura. "Um padrão descreve um problema que
ocorre inúmeras vezes em determinado contexto, e descreve ainda a solução para
esse problema, de modo que essa solução possa ser utilizada sistematicamente em
distintas situações." (ALEXANDER, 1978). Mais tarde a definição foi adaptada para
o desenvolvimento de software. O resultado disso culminou no surgimento do livro
Design Patterns: Elements of Reusable Object-Oriented Software - em 1994 por Eric
Gamma, Richard Helm, Ralph Johnson e John Vlissides. Os quatro eram conhecidos
como “A Gangue dos 4” justamente por causa do trabalho realizado.
Pode-se resumir que padrão de projeto é como seguir uma solução recorrente
para um problema em um determinado tipo de contexto, mesmo que em áreas e
projetos distintos. Contexto diz respeito ao ambiente do projeto e as circunstâncias
de existência. O Problema é a questão a ser resolvida. A Solução se refere a
resposta do problema encontrado e quais são os meios de resolver o problema.
Logo a solução para um problema só se torna um padrão se este sempre for usado
em um determinado tipo de problema.
“Cada padrão descreve um problema no nosso ambiente e o núcleo da sua
solução, de tal forma que você possa usar esta solução mais de um milhão de
vezes, sem nunca o fazer da mesma maneira”. (ALEXANDER, 1978)
2.1.1 Exemplo Padrão de Projeto
MVC, que significa Model View Controller.
Explicando de forma bem simplista:
Model: modelo dos dados, normalmente um banco de dados, mas é mais que
só interface com BD. O recomendado é que toda regra de negócio (escrita,
validação, leitura) fique nele. Por exemplo, uma loja, ao gravar um novo
pedido, o modelo faz todo o cálculo de frete, checagem de estoque,
processamento de pagamento etc.
12
View: como os dados serão vistos e como alguém pode interagir com esses
dados, normalmente páginas HTML com forms.
Controller: é quem interpreta eventos que acontecem na View e manipula os
dados que estão no Model, normalmente são ações como listar, procurar,
alterar, inserir e deletar dados. Mas é importante notar que o Controller não
faz qualquer tipo de ação, mas sim controla a interação entre o Model e a
View.
Esse modelo (mostrado na figura 12) é a separação entre essas três camadas
distintas da aplicação que permite até que pessoas ou equipes diferentes trabalhem
em diferentes camadas, sem impacto no trabalho dos outros. O padrão separa a
informação manipulada pelo código com a interface que o usuário interage, ou seja,
o modelo se torna mais centralizado e modularizado, facilitando o trabalho de quem
o desenvolve.
Figura 1 : O modelo Model-View-Controller.
Fonte: http://blog.ifuturz.com/ruby-on-rails/ruby-on-rails-mvc-learn-with-fun.html
13
2.2 Refatoração
Na década de 80 programadores da comunidade Smalltalk começaram a usar o
termo Refactoring para definir alterações realizadas no software em que apenas
melhorava se o código sem adicionar funcionalidades ao mesmo. Dois dos principais
difusores dessa nova ideia eram Ward Cunningham e Kent Beck, programadores
respeitados e que já naquela época iniciavam também o desenvolvimento da
metodologia ágil XP. Desta maneira a nova técnica foi ganhando popularidade e
força, cada vez mais atraindo pesquisadores e ela foi amadurecendo. O problema é
que não existiam referências bibliográficas sobre o tema, assim a técnica era
praticada muitas vezes de forma equivocada não atingindo seus principais
benefícios. Até que em 1992, Bill Opdyke faz sua tese de doutorado com refactoring
como tema central, que se chamou “Refactoring of Object Oriented Frameworks”,
considerado até hoje um dos melhores trabalhos, senão o melhor, no que se diz
respeito a esse assunto. Em 1999, Don Roberts também apresenta sua tese de
doutorado baseada nessa ascendente prática de engenharia de software, o título era
“Analisys for Refactoring ”. Mas o tema Refactoring ganha força máxima quando
ainda em 1999, Martin Fowler pública seu livro totalmente voltado a esse assunto,
“Refactoring: Improving the Design of Existing Code” , listando um catálogo de mais
de 70 técnicas de refatoração, quais problemas elas solucionavam, quando e como
usá-las,além de vários outros tópicos que estão ligados ao Refactoring . (PATRICK e
LUCIANO, 2015).
A qualidade de um software pode ser avaliada não somente pelo seu
desempenho mas também pela sua facilidade na manutenção do código.
Refatorar, é uma modificação feita na estrutura interna de um software para
torná-lo mais fácil de se entender e mais barato de se modificar sem alterar seu
comportamento externo. (FOWLER, 1999).
Refatoração não altera em nada o funcionamento do sistema mas sim
melhora o design do código e sua legibilidade e manutebilidade, melhorando assim
alguma qualidade não funcional. Outros possíveis aspectos de qualidade não
funcional que podem ser melhorados: simplicidade, flexibilidade e desempenho.
Exemplos de refatoração:
Mudança do nome de variáveis;
14
Mudança de parâmetros de métodos para aumentar a clareza do método;
Mudanças nas interfaces dos objetos;
Comentários no código;
Encapsular código repetido em um novo método;
Eliminar códigos redundantes;
Flexibilizar métodos para novos usos;
Melhorar o código sempre foi uma prática existente, com sua popularização (e
aceitação acadêmica), surge um vocabulário de refatorações comuns e um catálogo
compartilhado.
Refatoração é um processo de modificação de uma aplicação no propósito de
melhorar a estrutura interna do código sem alterar seu comportamento externo.
FOWLER (2009) fala que refatoração é tornar o código mais limpo no sentido
de torná-lo mais fácil de ler sem alterar sua interação com o ambiente externo, mas
tal ato implica em uma série de efeitos na escrita do código já que ele provê uma
técnica mais eficiente e de um melhor controle do código. Explica ainda que
refatoração é um elemento essencial no processo de desenvolvimento de software.
O mesmo autor ainda diferencia refatoração com otimização de performance
do código uma vez que apesar dos dois alterarem apenas o comportamento interno
da estrutura do sistema, ambos possuem objetivos diferentes durante seus
processos, refatoração tem o objetivo de tornar a leitura do código mais fácil e
otimização de tornar a sua performance mais rápida.
Refatoração é uma técnica disciplinada em que o desenvolvedor muda a
estrutura interna do código sem mudar o comportamento externo do sistema. Apesar
de parecer que no primeiro momento o ato da refatoração é muito dispendioso,
refatorar o código oferece inúmeros benefícios para o desenvolvedor e para o
sistema, seguem as vantagens:
Manutenção fácil no código refatorado;
Código mais limpo e com mais clareza;
O ato de refatorar o código recompensa em tempo menor na implementação
futura de novas funcionalidades;
15
Modularização do código melhorada tendo cada elemento distinto de sua
função.
A refatoração deve ser realizada de forma gradual e em pequenos passos
para remover os bad smells e atingir o design desejado. A cada passo é necessário
fazer testes no código para se certificar que a refatoração não tenha mudado ou
quebrado o sistema. A forma gradual em pequenos passos pode se assemelhar ao
TDD (Test Driven-Development ou Desenvolvimento dirigido por testes), ambos
quando combinados formam uma poderosa dupla de desenvolvimento do código
pois um complementa o outro.
2.2.1 Por que utilizar a refatoração?
FOWLER (2009) comenta que sem refatoração a tendência do nível de
qualidade do software é diminuir já que código é modificado a medida que novas
exigências ou necessidades surgem com o tempo, suas mudanças são feitas com
objetivos de curto prazo ou mudanças que são feitas sem entender a estrutura
inteira do código. Ele se torna mais e mais difícil de entendê-lo. Quanto mais difícil
de entendê-lo mais difícil é manter a estrutura do software e mais verborrágico o
código se torna.
Em TDD codifica-se primeiro algo muito simples, apenas o suficiente para
passar nos testes previamente escritos. Depois disso, melhora-se o código até que
este fique com a qualidade mínima desejada, e a melhor maneira de melhorar um
código que está funcionando é via refatoração.
Testes automatizados são necessários em refatoração. Eles devem ser
escritos primeiramente antes de se iniciar o processo de refatoração do código pois
assim será feita a comparação dos resultados esperados com os resultados reais.
Os testes dirão se a refatoração está causando algum tipo de mudança na
funcionalidade.
O processo de refatoração aliada em conjunto com o TDD é normalmente
representada pelo fluxo Vermelho/Verde/Refatorar (mostrado na figura 13) que
significa sempre testar em qualquer tipo de refatoração feita e ajustar o código até
todos os testes passarem.
16
Figura 2 : O Ciclo Red-Green-Refactor.
Fonte: http://pt.slideshare.net/progmania1/tdd-class-1
Bad Smells (cheiro ruim) é um termo cunhado no livro do Martin Fowler sobre
Refatoração. No livro “Aperfeiçoando o Projeto de Código Existente”, (FOWLER,
2003) define que Bad Smell é todo aquele código que apesar de ter sua
funcionalidade estar executando como esperado a leitura do código gera
desconfiança para quem o lê e indica alta possibilidade de refatoração desse código.
É sensato também dizer que o Bad Smell apenas indica a necessidade de
refatoração mas não a sua obrigatoriedade, logo um bad smell pode causar nenhum
prejuízo no código.
Alguns exemplos de Bad Smells:
Comentários que poderiam ser dispensados através de uma reescrita melhor
do código. Comentários são necessários, mas devem ser utilizados apenas
quando não há melhor forma de indicar o propósito do código.
17
Método Longo, Classe Grande (Long Method, Large Class): Classes e
métodos que acumulam funcionalidades demais. Difícil de reutilizar e testar.
Cirurgia com Espingarda (Shotgun Surgery): Ao fazer uma mudança do
código é necessária a mudança em várias outras partes do código.
Generalidade Especulativa (Speculative Generality): Deixar o código
complexo demais para um propósito simples.
Intimidade Inapropriada (Inappropriate Intimacy): Quando uma classe
depende dos detalhes de implementação de outra.
Inveja de Funcionalidade (Feature Envy): Quando uma classe usa em
demasia a funcionalidade de outra classe.
Código duplicado (Duplicated code): Quando existe código duplicado no
código-fonte.
18
2.2.2 Técnicas de Refatoração
5.4.1.1. Renomear variável
Mudar o nome da variável para tornar seu contexto dentro do código mais
claro.
5.4.1.2. Extração de método
Pegar parte do método e criar um novo método com ele.
5.4.1.3. Mover método
Move o método de uma classe para outra onde é mais utilizada.
5.4.1.4. Mover atributo
Similar ao mover método, ele move o atributo para a classe que a utiliza com
mais frequência.
5.4.1.5. Extrair superclasse
Criar uma abstração que capture os métodos e atributos comuns entre duas
classes.
5.4.1.6 Renomear Método
Quando o nome do método não descreve o seu propósito.
2.2.3 Refatoração do WebService
5.4.3.1. Sobre o código do autor
O idealizador do projeto utilizou boas práticas indicadas pelas guidelines
criadas pela comunidade de Ruby. No processo de desenvolvimento do código
foram criados testes para cada função inserida no código pelo padrão MVC. Logo
não foi encontrado nenhuma necessidade de refatoração aparente no projeto.
19
3 OBJETIVOS
O objetivo é estudar sobre os conceitos de Refatoração assim como os
Padrões de Projeto, bem como as técnicas e ferramentas existentes e aplicar a um
Estudo de Caso. O protótipo que foi desenvolvido na Iniciação Científica:
"Desenvolvimento de Aplicação para dispositivos móveis para divulgação de
notícias". Na época foram desenvolvidos os protótipos nas versões Android
utilizando Eclipse e Windows Phone utilizando o Visual Studio, além de que para
isso foi necessário a criação de Web Service.
20
4 MATERIAIS E MÉTODOS
Em 31/07/2015, os aplicativos a serem refatorados estavam em sua versão
protótipo, havia sido desenvolvido pelo grupo de Iniciação Científica Vinícius SILVA,
Thaís MARINACI e Felipe SILVA (2). Haviam sido criados:
Um web service para comunicação dos aplicativos das plataformas Android e
Windows Phone
Uma aplicação para entrada de dados
Um aplicativo na plataforma Android
Um aplicativo na plataforma Windows Phone
Os computadores a serem utilizados no projeto, são os do laboratório da
faculdade, computadores particulares e vez ou outra haverá a necessidade da
colaboração dos estagiários ou auxiliares de docente para a instalação das
ferramentas.
4.1 Etapas
Conforme ajustado entre a equipe (inclui a orientadora) no Desenvolvimento
do projeto foram criadas algumas etapas de trabalho:
1. Primeira etapa: Revisão Bibliográfica;
2. Segunda etapa: Pesquisa para entender a refatoração, suas principais
técnicas e como aplicá-las;
3. Terceira etapa: Instalação de todos os sistemas (Ruby, Android e Windows
Phone) para estudo e melhor entendimento de cada um, situação atual, etc.
4. Quarta etapa: Aplicação da Refatoração do sistema em cada versão, gerando
assim uma nova versão de cada um.
4.2 Ferramentas
4.2.1 Ferramentas a serem instaladas no computador do autor (aluno)
GNU/Linux Ubuntu 14.04 x86
21
RVM - Versão 1.26.11
Ruby – Versão 2.2.1p85
Rails – Versão 4.2.5
Postgresql – Versão 9.3
Fatec-API - Aplicação / Web Service
4.2.2 Ferramentas a serem instaladas no servidor
GNU/Linux Ubuntu 14.04 x86
Rbenv - Versão 1.0.0-19-g29b4da7
Ruby – Versão 2.2.1p85
Rails – Versão 4.2.5
Postgresql – Versão 9.3
Fatec-API - Aplicação / Web Service
Nginx – Versão: nginx/1.8.1
Puma Manager - Versão: 3.1.0
Gem Bundler – Versão 2.2.1p85
SSH – Versão 2.0
SCP – Versão 1.2.4
4.2.2.1 RVM
O RVM(Ruby Version Manager) é um gerenciador de versões do Ruby por
linha de comando, designado para facilitar o desenvolvedor que necessita mudar a
versão do ambiente Ruby quando tiver a necessidade para tal. (RVM, 2015).
4.2.2.2 Rbenv
Gerenciador de versões do Ruby. Durante o desenvolvimento da aplicação a
versão do interpretador Ruby pode não ser o mais recentemente lançado, logo um
gerenciador de versões do Ruby é recomendado caso queira ficar continuamente
mudando de versões. (RBENV, 2015)
22
4.2.2.3 Ruby
Ruby é a linguagem de programação utilizada no Web Service. Dinâmica,
open source com foco na simplicidade e na produtividade. Tem uma sintaxe
elegante de leitura natural e fácil escrita. (RUBY, 2015)
4.2.2.4 Ruby On Rails
Framework de desenvolvimento web na linguagem Ruby. É um framework
livre focado na velocidade e facilidade no desenvolvimento de sites orientados a
banco de dados (database-driven web sites), uma vez que é possível criar
aplicações com base em estruturas pré-definidas. (RAILS, 2015)
4.2.2.5 Postgresql
Banco de dados relacional open-source. Indicado para o desenvolvimento de
aplicações em Ruby on Rails. "O PostgreSQL é um SGBD (Sistema Gerenciador de
Banco de Dados) objeto-relacional de código aberto, com mais de 15 anos de
desenvolvimento. É extremamente robusto e confiável, além de ser extremamente
flexível e rico em recursos. Ele é considerado objeto-relacional por implementar,
além das características de um SGBD relacional, algumas características de
orientação a objetos, como herança e tipos personalizados. ” (OLIVEIRA, 2015).
4.2.2.6 Nginx
Nginx é um servidor HTTP e proxy reverso, proxy de email, proxy genérico
TCP/UDP, escrito por Igor Sysoev. (NGINX, 2015).
O Web Server será utilizado para colocar a aplicação online com a ajuda do
Puma.
4.2.2.7 Puma
Puma é um servidor de aplicação que habilita a aplicação rails a processar
requests paralelamente. (PUMA, 2015).
Como Puma não é feito para ser acessado diretamente pelos usuários, o
Nginx é usado como reverse proxy que fará um buffer dos requests e respostas
entre os usuários e sua aplicação rails.
23
4.2.2.8 Gem Bundler
Ferramenta integrada ao Ruby que faz o gerenciamento das dependências da
aplicação.
4.2.2.9 SSH
Programa e protocolo que permite a conexão com outro computador na rede
de forma a permitir a execução de comandos remotamente. O SSH faz parte da
suíte de protocolos TCP/IP que torna segura a administração remota de servidores
do tipo Unix. (SSH, 2016).
4.2.2.10 Fatec-Api
Aplicação em Ruby on Rails construída por Vinicius Venâncio no Projeto:
"Desenvolvimento de Aplicação para dispositivos móveis para divulgação de notícias
- Web Services". Aqui está incluído o Web Service para ser utilizados pelos
aplicativos Android e Windows Phone e também uma aplicação utilizada para
entrada dos dados. (FATEC-API,2015).
4.2.2.11 SCP
Programa e protocolo que permite a conexão com outro computador na rede
de forma a permitir a transferência de arquivos remotamente. O SCP faz parte da
suíte de protocolos TCP/IP que torna segura a administração remota de servidores
do tipo Unix.
4.2.2.12 Siege
A ferramenta de teste Siege faz o teste de a carga em HTTP e é um utilitário
de medição dos resultados. Foi feito para que desenvolvedores web pudessem
analisar o desempenho do código escrito em estresse. (SIEGE,2016).
Para efetuar o teste foi criado um arquivo (SiegeStressTest.in) com os
endereços das páginas a serem testadas. Em seguida foi executado o seguinte
comando.
4.2.2.13 Android Studio
Ambiente de desenvolvimento comumente utilizado para desenvolvimento de
aplicativos Android.
24
5 RESULTADOS E DISCUSSÕES
5.1 Instalação dos Softwares
5.1.1 Instalação da aplicação na máquina do usuário
Para realizar a instalação da Fatec-API: Aplicação e Web Service criado pelo
Projeto que serviu de referência para esse novo, foi feita a instalação de uma
distribuição Linux (Ubuntu) além dos programas Postgresql, Rvm, Ruby, Rails.
Todos as ferramentas foram instaladas via terminal do Linux.
A Figura 3 compreende a instalação e download das seguintes ferramentas:
Fatec-API, o RVM, Ruby, Rails e instalação do Postgresql.
Figura 3: Instalação do RVM, Ruby, Rails e Postgresql
Fonte: (Autor, 2016)
A Figura 4 indica como configurar o Postgresql depois de instalado.
25
Figura 4: Configuração do Postgresql.
Fonte: (Autor, 2016)
A Figura 5 compreende a parte de criação do Banco de Dados para uso da
aplicação, configuração do Rails e a execução da aplicação.
Figura 5: Configuração do Rails com o banco de dados.
Fonte: (Autor, 2016)
26
A execução da aplicação aceita o request de um usuário por vez. Na
instalação do servidor será visto a solução para este problema de escalabilidade
com a instalação do Nginx e do Puma.
27
5.1.2 Instalação da máquina servidora e aplicação
A instalação na máquina utilizada como servidor foi um pouco diferente da
máquina do aluno. Foi feito primeiramente o download e instalação do repositório do
antigo projeto (Fatec-API), a instalação do Rbenv, Ruby, Rails, Gem Bundler e
Postgresql como exemplificado nas figuras 6 e 7.
Figura 6: Instalação do Rbenv.
Fonte: (Autor, 2016)
Instalação do Ruby, Gem Bundler, Rails e Postgresql.
Figura 7: Instalação do Ruby, Gem Bundler, Rails, Postgresql.
Fonte: (Autor, 2016)
28
Na figura 8, configurando o usuário do Postgresql, criação de sua senha,
redefinindo o database.yml da aplicação para que este faça a comunicação com o
banco de dados através do usuário criado. Lembrando que variáveis ambiente são
utilizadas neste trecho como forma de esconder o nome do usuário e sua senha.
Figura 8: Configuração do Postgresql e edição do database.yml.
Fonte: (Autor, 2016)
Para esconder o usuário, senha e a chave secreta, por segurança, o rben-
vars é instalado para ajudar na configuração da aplicação como mostrado na figura
9.
29
Figura 9: Instalação do rbenv-vars, responsável pelas variáveis ambiente.
Fonte: (Autor, 2016)
Criação do banco de dados (Figura 10) no modo produção, caso aconteça
alguma falha, verifica-se as informações de usuário, senha e banco no arquivo
database.yml. É feito também neste trecho a instalação do Puma e parte de sua
configuração.
Figura 10: Criação do banco de dados e instalação do Puma.
Fonte: (Autor, 2016)
É necessário saber o número de núcleos do processador para que o Puma
possa utilizar o processador em sua máxima capacidade como mostrado na figura
11 e 12.
30
Figura 11: Configuração do Puma.
Fonte: (Autor, 2016)
Continuação da configuração do Puma e instalação do Nginx.
Figura 12: Configuração entre o Puma e o Nginx
Fonte: (Autor, 2016)
Configuração do Nginx. Nesse trecho, na figura 12, é configurado como o
Puma se comunicará com o Nginx durante as requisições dos usuários.
Na figura 13, o Puma é configurado de forma que ele sempre inicie quando o
servidor for ligado.
31
Figura 13: Criando um upstart script para o Puma iniciar sempre na inicialização do sistema.
Fonte: (Autor, 2016)
32
5.1.3 Ferramenta de transferência de arquivos
Durante o processo de refatoração, para realizar qualquer tipo de modificação
ou atualização do código-fonte do servidor foi necessária a utilização de um outro
programa para ser possível passar os arquivos devido ao acesso remoto do servidor
por um terminal, o programa utilizado foi o scp que funciona de forma similar ao
comando mv do unix, mas o scp faz a utilização do login, senha assim como o ip do
servidor remoto.
33
5.2 Refatoração e Problemas encontrados
5.2.1. Instalação do Servidor
Durante a instalação da distribuição Ubuntu no servidor, notou-se que a
máquina precisava de uma configuração mínima para o uso da interface gráfica, pois
vinha instalada de forma padrão do sistema, dificultando a instalação das outras
ferramentas no servidor. Devido a tal situação, foi sugerida a utilização do SSH para
fazer o acesso remoto do terminal do servidor e assim poder instalar o resto das
ferramentas. Vários benefícios surgiram por causa dessa sugestão já que a máquina
fica em uma sala em que só o Auxiliar de Docente tem acesso e tinha que ser
carregada para outra. Também poupou o grupo de desnecessárias reuniões no
laboratório para efetuar as instalações e configurações, pois estas puderam ser
feitas sem a presença física de cada um.
Durante a instalação e configuração do Web Service na máquina do servidor
foi discutido/sugerido inicialmente a instalação do Passenger-Phusion, este software
tem a mesma funcionalidade do Puma. Após inúmeras tentativas foi constatado a
extrema dificuldade em realizar a instalação e configuração do mesmo. Logo depois,
como ajuda de um especialista na área de aplicação Rails, foi sugerido que a melhor
opção seria o deploy da aplicação Rails através do Puma em conjunto com o Nginx.
Um problema que veio depois da sugestão foi em reinstalar e remover todas as
configurações que tinham sido feitas no Nginx para se comunicar com o Passenger
assim como desinstalar o RVM e colocar em seu lugar o Rbenv. Apesar de todos os
problemas apresentados durante a instalação e configuração, tudo foi realizado com
sucesso e a máquina atualmente está funcionando como planejado.
O aluno que era responsável inicialmente pelo trabalho da refatoração do
aplicativo Android abandonou o grupo de iniciação científica, foi então transferido a
responsabilidade para o autor.
O aplicativo Android não estava em condições de uso, uma vez que ele não
estava funcionando como previsto, gerava erros durante seu uso e não tinha as
funcionalidades esperadas. Foi realizado então uma análise do código, tentativa de
reuso e reparo.
34
5.2.2. Normas seguidas (guia de conduta Ruby/Rails)
Por convenção da comunidade de Ruby, algumas regras de código foram
estabelecidas como forma de padronizar e melhorar a legibilidade do código pela
comunidade toda. Pela lista ser extensa, serão selecionadas as regras mais
utilizadas ou de fácil observação e comparadas depois com o código feito no
WebService.
Nomenclatura:
Os identificadores precisam estar em inglês.
Usar Snake Case para variáveis, métodos, símbolos, arquivos.
Usar Camel Case para classes, módulos, diretórios.
Constantes precisam ser nomeadas inteiramente em maiúsculas e em Snake
Case.
Os trechos de código a seguir foram retirados do código fonte do projeto em
uso.
Nas figuras 14 e 15 percebe-se a diferença que o autor usa identificadores
entre Classes e variáveis. Usando CamelCase para classes e SnakeCase para os
demais.
Figura 141: Model do Estágio.
Fonte: (Autor, 2016)
35
Figura 15: Model do Usuário.
Fonte: (Autor, 2016)
Nota-se, portanto, que o autor do projeto seguiu as condutas de estilo da
comunidade de Ruby, não foi considerado apenas o escopo do projeto ou fazer o
“código funcionar”. Houve um prezo e zelo pelo seguimento de guidelines sugeridas
pelas comunidades de Ruby e Rails. Alguns aspectos de certa forma foram
influenciados devido a popularidade centralizada que o framework Rails tem sobre a
linguagem Ruby. Essa centralização ajuda no processo de formação de padrões no
uso do framework e guias de conduta no quesito de como fazer tal procedimento,
ajudando assim a manter uma homogeneidade dos projetos por toda a comunidade.
Benefícios como facilidade de leitura e manutenção são alguns dos pontos fortes
que se pode ter em seguir condutas. Em contraponto pode-se citar a comunidade
Python que é toda fragmentada com vários frameworks com diversas maneiras de
lidar com o projeto além de dois guias de conduta diferentes (PEP-8 e Google
Python Style). Essa fragmentação dificulta e fragiliza a comunidade em si devido a
sua característica natural de isolamento, isto é, tem por ventura tentar se separar da
comunidade.
5.2.3. Correção de Funcionalidade
Durante a utilização da API do WebService, notou-se a falta de um campo no
JSON de notícias, o cadastro de notícias especificava para quais cursos ela era
relevante, mas no JSON faltava a indicação de qual curso que era, a orientadora
pediu que fosse possível fazer o filtro de notícias por curso. Foi então feita a
correção do código através da mudança da estrutura do API.
36
As figuras 16 e 17 abaixo mostram como estava antes e depois da correção.
Figura 16: Controller da Notícia.
Fonte: (Autor, 2016)
Figura 17: Controller da Notícia modificado.
Fonte: (Autor, 2016)
5.2.4 Refatoração do aplicativo Android
Durante o processo de refatoração do código do aplicativo do Android, foram
removidos comentários desnecessários do código. Foi melhorado o encapsulamento
de alguns atributos (mostrado na figura 18), que estavam sem nenhum tipo de
modificador de acesso e como consequência melhor padronização do código (os
outros fragmentos possuíam seus atributos como privado). Também foram
realizadas algumas extrações de método (Extract Method) nos fragmentos como
forma de não deixar métodos gulosos (que fazem tudo) na classe deixando assim o
código mais modularizado.
Figura 18: Modificadores de acesso.
Fonte: (Autor, 2016)
37
5.3 Testes de Código
Os testes realizados no código do projeto trazem inúmeros benefícios para
todo o sistema. São utilizados como forma de encontrar possíveis erros de lógica,
bugs ou interações não esperadas. Podem apontar para melhorias de performance
ou refatoração. Fiscaliza o desenvolvimento do código seja por TDD (Test-Driven
Development) ou BDD (Behavior-Driven Development). Tudo isso implica em uma
melhora de qualidade do software.
Toma-se como exemplo o desenvolvedor criando uma função matemática de
fatorial. A função fatorial receberá um número fatorial e retornará o seu resultado. O
desenvolvedor escreveu a função e alguns testes com os resultados esperados. O
desenvolvedor viu que o teste do número 4 retornava 0 quando na verdade era para
retornar o valor 24. Olhando no código, constatou um erro na sua função recursiva.
O exemplo acima claramente mostra a importância do teste antes de encaminhar o
código para o nível de produção. Os testes do código indicam possíveis falhas ou
erros no comportamento das funções durante seu desenvolvimento.
5.3.1 Rspec
RSpec é uma ferramenta de desenvolvimento orientado ao comportamento
(behavior-driven development – BDD) no processo de escrever especificações que
validam diretamente o desenvolvimento da sua aplicação e sejam entendíveis para
pessoas. (REGINATO, 2016).
Os testes realizados pelo rspec envolvem todo o conjunto do padrão MVC.
Logo, o model, a view e o controller tem seus testes escritos no rspec. Nestes testes
o rspec instrui o desenvolvedor quais são os comportamentos pedidos para o
funcionamento de determinada parte do código do projeto.
38
5.3.2 Executando os testes do rspec
Para efetuar todo o teste do rspec, no diretório do projeto de rails escreve-se
o comando no terminal como mostrado na figura 19.
Figura 19: Comando para executar todos os testes.
Fonte: (Autor, 2016)
Para executar apenas um dos testes escreve-se como na figura 20:
Figura 20: Executar apenas um arquivo teste no rspec.
Fonte: (Autor, 2016)
39
5.4 Testes do Servidor
Os testes no servidor foram realizados como forma de mensurar o
desempenho dele em certos tipos de situações. O teste utilizado em questão tentou
estressar o servidor e mensurar o tempo de resposta por ele emitido a partir de uma
grande quantidade de acessos concorrentes. Os benefícios dos testes em questão
tentam averiguar o comportamento do servidor em situações anormais ou atípicas
do dia-a-dia do servidor e podem indicar algumas ações que podem resolver caso
algum problema apareça.
Figura 21: Execução do teste de estresse do servidor.
Fonte: (Autor, 2016)
Na figura 21, o parâmetro –b indica que será feito um benchmark do teste. O
parâmetro –cNUMEROS indica o número de acessos concorrentes a ser feitos em
média. O parâmetro –t indica o tempo de duração do teste. O parâmetro –f indica o
arquivo com os endereços a serem lidos.
40
5.4.1 Resultados dos testes do servidor
As informações a seguir foram obtidas com base em testes de 10 minutos de
duração variando a quantidade de acessos concorrentes e páginas acessadas. Foi
feito a relação entre a quantidade de acessos concorrentes, isto é, a quantidade de
acessos simultâneos de vários usuários, com o tempo de resposta do servidor.
As páginas foram acessadas de forma aleatória (simulando o acesso do
usuário e das requests feitas pelos aplicativos) o site principal do WebService onde
era feito o login para o cadastro das informações do estágio, cursos, notícias e
empresas. Outros endereços foram os endereços em que eram acessadas
informações fornecidas pela API como informações dos cursos, estágios e notícias,
tais endereços são usados extensivamente pelas aplicações mobile (Windows
Phone e Android). A tabela 1 indica o número de acessos por teste e tempo de
resposta por teste respectivamente. As figuras 22 e 23 indicam o número de
acessos concorrentes em média pelo tempo de duração do teste (10 minutos) e o
tempo de resposta que cada usuário recebeu.
Tabela 1: o número de acessos por teste e tempo de resposta por teste.
Concorrentes (em média) Tempo de Resposta (segundos)
9,99 0,19
48,75 0,81
88,77 1,42
149,53 2,63
176 3,1
229,75 3,74
272,44 4,29
Fonte: (Autor, 2016)
41
Figura 22: Gráfico indicando o número de acessos concorrentes por teste.
Fonte: (Autor, 2016)
Figura 23: Gráfico indicando o tempo de resposta por teste.
Fonte: (Autor, 2016)
As tabelas indicam uma relação entre o número de acessos concorrentes no
servidor com o tempo de resposta por ele recebidos. Percebe-se que a medida que
9,99
48,75
88,77
149,53
176
229,75
272,44
1 2 3 4 5 6 7
Concorrentes (em média)
0,19
0,81
1,42
2,63
3,1
3,74
4,29
1 2 3 4 5 6 7
Tempo de Resposta (segundos)
42
o número de acessos concorrentes aumenta, o tempo de resposta recebida pelo
acesso aumenta.
5.6.1.1. Discutir o tempo de resposta mais apropriado para as APIs
Quanto menor o tempo de resposta do servidor em relação ao request
enviado pelo usuário melhor será o desempenho do sistema, mas em relação ao
teste de estresse efetuador determina-se que o servidor em uma alta carga deve ter
a capacidade de responder a quase todas as requisições além de manter um baixo
tempo de resposta. Determinando-se que o tempo de resposta não deve passar de 1
segundo já que seria imperceptível para o usuário, conclui-se que em média o
servidor deve ser capaz de aguentar uma carga de cerca de 50 acessos
concorrentes em média.
5.6.1.2. Explicar a limitação do hardware e banda do servidor
Vários fatores podem ser causa da performance do servidor em questão. E
um destes aspectos seria a configuração da máquina utilizada como servidor.
Devido a característica didática e de disponibilidade do servidor, foi utilizado um
servidor com características que não se adequariam em um servidor de grande
escala. O servidor era um computador doméstico e antigo. Logo, como o estado
inicial dos testes já não era ideal, existe a possibilidade de imprecisão com relação
aos resultados dos testes de estresse do servidor.
O servidor utilizava uma máquina com a seguinte configuração:
Processador: Intel ® Pentium ® D CPU 3.00 GHZ
Memória: 2GB DDR2
HD: 160 GB
A velocidade foi medida utilizado uma ferramenta do speedtest no terminal.
Download 9.10 Mbit/s
Upload 4.30 Mbit/s
43
5.6.1.3. Abrangência do servidor na Faculdade.
Foi informado pela secretaria da faculdade que atualmente a quantidade de
alunos ativos na FATEC de Sorocaba é de aproximadamente 2300 alunos, contando
todos os cursos. Logo, o servidor consegue suprir a demanda toda em cerca de 46
segundos se for feito apenas um acesso por usuário e seja feito em média 50
acessos concorrentes (como acessar a seção de notícias).
44
5.5 Análise do código do aplicativo Android
O projeto da aplicação entregue a nós estava defasado e sem algumas
funcionalidades importantes. Foi feito então uma análise do código e observado o
que poderia ser reaproveitado e quais seriam os problemas do projeto. Para isso foi
utilizado o método Log.d para efetuar o debug do programa. Log.d imprime no
console do Android Studio uma mensagem definida pelo usuário, dessa forma foi
possível descobrir a origem da grande maioria dos problemas encontrados.
Existiu a necessidade da mudança do endereço do servidor, uma vez que o
endereço do servidor utilizado antes era um servidor local, agora teria que ser
trocado pelo servidor instalado nas dependências da Fatec Sorocaba.
Descobriu-se também a inexistência da CourseActivity que compõe a tela dos
Cursos cadastrados.
Foi descoberto a falta de implementação da Fragment1 que seria da parte de
Notícias que estava incompleto.
Existiu também a necessidade de relacionar as notícias com os cursos
relacionados a ela, já que a funcionalidade ainda não existia no servidor API
antigamente.
45
6 CONCLUSÃO
No segundo semestre do trabalho de iniciação científica, as técnicas de
refatoração foram aplicadas no projeto e constatou-se a pouca necessidade de fazer
a refatoração no projeto na parte do Ruby, devido ao autor ter seguido guias de
conduta da comunidade da tecnologia utilizada. O padrão utilizado no projeto do web
service foi o MVC que é composta da Model, View e Controller o que facilita a
organização e modulariza o projeto. O contrário acontece com o aplicativo Android,
este por sua vez apresentava vários problemas que foram corrigidos.
Os testes do servidor indicam a alta qualidade do projeto apesar da
configuração utilizada no servidor. Mais testes talvez sejam necessários com o
servidor ideal para obter resultados mais precisos.
Os testes de código indicam que os comportamentos dos trechos dos códigos
são esperados.
Concluindo o projeto de WebService e aplicação possui o potencial para o
deploy ou seu uso pelos demais aplicativos.
46
REFERÊNCIAS
ALEXANDER, Christopher. A Pattern Language. Oxford Press, Oxford, R. Unido, 1977, 1216p.
ALEXANDER, Christopher. A Timeless Way of Building. ALEXANDER, Oxford Press, Oxford, R. Unido, 1978, 576p.
FIELDS, Jay; HARVIE, Shane; FOWLER, Martin; BECK, Kent. Refactoring: Ruby Edition. Addison-Wesley Professional, 2009, 480p.
FOWLER, Martin. Refatoração - Aperfeiçoando o Projeto de Código Existente. Bookman. 2004, 366p.
FOWLER, Martin. Improving the Design of Existing Code. FOWLER. 1st Edition. Addison-Wesley Longman, inc., EUA, 1999, 464p.
FREIRE, Alexandre; Cheque Paulo. Disponível em: http://ccsl.ime.usp.br/agilcoop/files/2-Refatoracao.pdf Acesso em: 13.DEZ.2015.
FULMER, Jeffrey. Siege Home. Disponível em https://www.joedog.org/siege-home/ - Acesso em 20/06/2016.
GAMMA, Erich. HELM, Richard. JOHNSON, Ralph. VLISSIDES , John. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. EUA, 1994, 416p.
GAMMA, Erich. HELM, Richard. JOHNSON, Ralph. VLISSIDES , John. Padrões de Projeto - Soluções Reutilizaveis de Software Orientado a Objetos. Addison-Wesley. 1994. 368p.
LECHETTA, R. Ricardo – Desenvolvendo para Windows 8 – Aprenda a desenvolver aplicativos para Windows Phone 8 e Windows 8, 1ª Edição, Julho 2013, 624p.
MARINACI. Thais Rodrigues. Relatório Final de Iniciação Científica:
Desenvolvimento de Aplicação para dispositivos móveis para divulgação de
47
notícias - Case 1. Faculdade de Tecnologia de Sorocaba José Crespo Gonzales.
Ago.2015.
MONTEIRO, João Bosco. GOOGLE ANDROID: Crie aplicações para celulares e tablets. São Paulo: Casa do Código, 2014, 315p.
NGINX. Disponível em https://www.nginx.com/ - Acesso em: 13.DEZ.2015.
OPDYKE,William F. Refactoring Object-oriented Frameworks.Ph.D thesis, University of Illinois at Urbana-Champaign, 1992.
OLIVEIRA, Diogo de. Introdução e Histórico do Postgresql. Disponível em: https://wiki.postgresql.org/wiki/Introdu%C3%A7%C3%A3o_e_Hist%C3%B3rico Acesso em 13.DEZ.2015.
PATRICK, Marlon. CABRAL, Luciano. RP : Refactored Programming Conjunto de boas práticas para uma programação limpa e produtiva. Disponível em: <http://www.unibratec.edu.br/tecnologus/wp-content/uploads/2010/12/patrick_cabral.pdf> Acesso em: 13.DEZ.2015.
POSTGRESQL. Disponível em http://www.postgresql.org/ - Acesso em: 13.DEZ.2015.
REGINATO, Andrea. Better Specs – rspec guidelines with ruby. 2016. Acessado em: 20.JUN.2016.
RUBYONRAILS. Disponível em http://rubyonrails.org/ - Acesso em: 13.DEZ.2015.
RBENV. Disponível em http://rbenv.org/ - Acesso em: 13.DEZ.2015.
RUBY. Disponível em https://www.ruby-lang.org/pt/ - Acesso em: 13.DEZ.2015.
RVM. Disponível em: <https://rvm.io/> Acesso em: 13.DEZ.2015.
RODRIGUES, Ana Nathalie; MOURA. Mirtes; RODRIGUES, Paula; SANTOS, Vanusa dos. Disponível em: http://www.devmedia.com.br/qualidade-de-software-parte-01/ Acesso em: 13.DEZ.2015.
48
SILVA, Vinícius Venâncio da. Relatório Final de Iniciação Científica:
Desenvolvimento de Aplicação para dispositivos móveis para divulgação de
notícias - Web Services. Faculdade de Tecnologia de Sorocaba José Crespo
Gonzales. Ago.2015.
SILVA(2), Felipe Fedel. Relatório Final de Iniciação Científica:
Desenvolvimento de Aplicação para dispositivos móveis para divulgação de
notícias - Case 2. Faculdade de Tecnologia de Sorocaba José Crespo Gonzales.
Ago.2015.
SSH. Disponível em http://www.ssh.com/ - Acesso em: 13.DEZ.2015.
Venâncio, Vinicius. Fatec-API. Disponível em https://github.com/ViniciusVenancio/fatec-api. Acesso em: 13.DEZ.2015.
VELOSO, Denilce de Almeida O. Veloso. Projeto de Regime de Jornada Integral: "Integração entre Dispositivos Móveis e Web". Centro Paula Souza. 04/2014.
VIEIRA, Nando. Howto – Guia Rápido de Rspec. Hellobits, 2011.
49
GLOSSÁRIO
AUXILIAR DE DOCENTE – Técnico contratado pelo Centro Paula Souza (Fatec)
para auxiliar professores e cuidar das redes e computadores no laboratório de
informática.
API - API é um conjunto de rotinas e padrões de programação para acesso a um
aplicativo de software ou plataforma baseado na Web. A sigla API refere-se ao
termo em inglês "Application Programming Interface" que significa em tradução para
o português "Interface de Programação de Aplicativos".
DEPLOY – Colocar o projeto ou sistema de aplicação em uso comercial, em
produção.
GUIDELINES – Orientações e práticas indicadas sobre determinado assunto.
HTTP - protocolo HTTP (HyperText Transfer Protocol - Protocolo de Transferência
de Hipertexto) data de 1996, época em que os trabalhos conjuntos de Tim Berners-
Lee, Roy Fielding e Henrik Frystyk Nielsen levaram à publicação de uma RFC
(Request for Comments) descrevendo este protocolo. Trata-se de um protocolo de
camada de aplicação (segundo o modelo OSI) e, portanto, de relativa facilidade de
manipulação em aplicações.
Este protocolo foi desenvolvido de maneira a ser o mais flexível possível para
comportar diversas necessidades diferentes. Em linhas gerais, este protocolo segue
o seguinte formato de requisições:
<método><URL> HTTP/<versão>
<Cabeçalhos - Sempre vários, um em cada linha>
<corpo da requisição>. SAUDATE (2014, p.14).
SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL,
é a linguagem de pesquisa declarativa padrão para banco de dados relacional (base
de dados relacional).
50
URL - URL significa Universal Resource Locator e URI, Universal Resource Identifier
. Uma URL, como diz o próprio nome, pode ser utilizada para identificar qualquer
item – dar um caminho para um determinado conteúdo, dar nome a este, etc. Já
uma URL pode ser utilizada apenas para fornecer caminhos – sendo que uma URL
é, portanto, uma forma de uma URI. SAUDATE (2014, p. 5).
WEB SERVICE - Web service é uma solução utilizada na integração de sistemas e
na comunicação entre aplicações diferentes.