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.


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.


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.


Instalação do Ruby, Gem Bundler, Rails e Postgresql.

Figura 7: Instalação do Ruby, Gem Bundler, Rails, Postgresql.


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.


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.


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.


É 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.


Continuação da configuração do Puma e instalação do Nginx.

Figura 12: Configuração entre o Puma e o Nginx


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.


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.


35

Figura 15: Model do Usuário.


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.


Figura 17: Controller da Notícia modificado.


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.


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.


Para executar apenas um dos testes escreve-se como na figura 20:

Figura 20: Executar apenas um arquivo teste no rspec.


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.


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


41

Figura 22: Gráfico indicando o número de acessos concorrentes por teste.


Figura 23: Gráfico indicando o tempo de resposta por teste.


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:


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:


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.

ricardo hiroyuki eihara junior orientador

Documents