sistema web para os cursos de extensÃo · software e, obviamente, nos aprofundamos nas técnicas...
TRANSCRIPT
SISTEMA WEB PARA OS CURSOS DE EXTENSÃO
Igor Berquó Canêdo
Projeto de Graduação apresentado ao Curso de
Engenharia Eletrônica e de Computação da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessários à
obtenção do título de Engenheiro.
Orientador: Flávio Luis de Mello
Rio de Janeiro
Junho de 2015
ii
SISTEMA WEB PARA OS CURSOS DE EXTENSÃO
Igor Berquó Canêdo
PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO
DE ENGENHARIA ELETRÔNICA E DE COMPUTAÇÃO DA ESCOLA
POLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO
PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE
ENGENHEIRO ELETRÔNICO E DE COMPUTAÇÃO
Autor:
_________________________________________________
Igor Berquó Canêdo
Orientador:
_________________________________________________
Prof. Flávio Luis de Mello, D.Sc.
Examinador:
_________________________________________________
Prof. Edilberto Strauss, Ph. D.
Examinador:
_________________________________________________
Prof. Heraldo Luís Silveira de Almeida, D. Sc.
Rio de Janeiro – RJ, Brasil
Junho de 2015
iii
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
iv
DEDICATÓRIA
Aos meus pais, irmã, avós, avô, companheiros de graduação e de trabalho. Aos
professores do departamento pela dedicação incansável.
v
AGRADECIMENTO
Dedico este trabalho à minha família, que sempre me deu apoio total aos estudos
e acreditou que através dele seria possível a construção de uma vida melhor para mim e
para as pessoas a minha volta. Agradecimento especial ao meu avô, que tinha como
sonho ver um filho ou neto se tornar um engenheiro e que, finalmente, poderá ver esse
sonho se tornando realidade.
Agradeço aos amigos que estiveram presentes nessa árdua jornada que foi a
graduação. Foram momentos bons e ruins. Fins de semana e feriados de estudos.
Vitórias, derrotas, mas sempre juntos. Sem isso seria impossível.
Também agradeço aos professores, mestres, doutores que compartilharam e
continuam compartilhando suas experiências acadêmicas, profissionais e pessoais, e que,
sem a intenção, são pessoas que nos espelhamos para tomarmos decisões na vida. São
profissionais que superam muitas dificuldades para disseminarem conhecimento e
experiências com brilhantismo.
vi
RESUMO
Este trabalho utiliza técnicas de desenvolvimento web com a finalidade de criar
um portal para atender a uma demanda específica do Departamento de Engenharia
Eletrônica que era fornecer aos alunos dos cursos de extensão um portal capaz de exibir
suas notas e um acervo de monografias para consulta. Inicialmente, foi feito um
trabalho de pesquisa de tecnologias a serem utilizadas em cada parte do projeto. Este
tempo gasto nas escolhas dessas tecnologias se provou bastante útil, pois foi possível
chegar a conclusões sobre a linguagem de programação que mais se encaixava com o
paradigma de linguagem orientada a objeto para o projeto a ser criado. Neste sentido,
foi escolhida a linguagem Python, além do uso de seu framework Django para auxiliar
na criação do administrador do sistema, assim como todos os outros benefícios que o
framework pode proporcionar. Também foi feito um estudo para entender os tipos de
bancos de dados que poderiam ser escolhidos, para cada tipo de aplicação e, por fim, a
escolha pelo uso do MySQL, que se provou adequado para a aplicação desenvolvida,
além de ser simples de ser utilizado. Abordamos o conceito em torno de qualidade de
software e, obviamente, nos aprofundamos nas técnicas de testes automatizados. Seus
conceitos, suas vantagens em relação aos testes manuais e os tipos de testes
automatizados mais comuns e algumas ferramentas utilizadas para as suas
implementações. Por fim, dedicamos uma parte da obra para discutir as técnicas
utilizadas para a automação do processo de provisionamento. Citamos as tecnologias
utilizadas e introduzimos a ferramenta Chef-Solo, que vem sendo bastante utilizada para
garantir scripts simples e claros para o provisionamento de máquinas em qualquer tipo
de servidor web.
Palavras-Chave: Desenvolvimento Web, Testes Automatizados, Provisionamento,
Responsividade, Python, Django, Chef-Solo.
vii
ABSTRACT
This work uses web development techniques in order to create a portal to meet a
specific demand of the Department of Electronic Engineering that was to provide
extension course students with a portal that could show their grades and a collection of
monographs for consultation. Initially, research was carried out regarding the
technologies to be used in each part of the project. The time dedicated to choosing these
technologies has proved very worthwhile, because it was possible to come to a
conclusion about the programming language most appropriate to the object-oriented
paradigm for creating the project. Thus, the Python language was chosen, as well as its
Django framework to help to create the system administrator, along with all the other
benefits that the framework can provide. A study was also conducted to understand the
types of databases that could be chosen for each kind of application and, finally, the
choice was made to use MySQL. This DBMS has proved to be suitable for the
application developed, as well as being simple to use. We address the concept of
software quality and, of course, we delved into automated testing techniques - their
concepts and advantages compared to manual testing, as well as the most common types
of automated testing used and some tools for their implementation. Finally, we dedicate
part of the work to a discussion of the techniques used for automating the provisioning
process. We mention the technology used and introduce the Chef-Solo tool, which is
being widely used to ensure clear and simple scripts for provisioning machines in any
type of web server.
Key words: Web Development, Automated Testing, Provisioning, Responsiveness,
Python, Django, Chef-Solo.
viii
SIGLAS
API – Application Programming Interface
CPU – Central Processing Unit
CSS – Cascading Style Sheets
DBMS – Data Base Management System
DEL – Departamento de Engenharia Eletrônica
HTML – Hypertext Markup Language
HTTP – Hypertext Transfer Protocol
ISO – International Organization for Standardization
MBA – Master of Business Administration
SSH – Secure Shell
UFRJ – Universidade Federal do Rio de Janeiro
VNC – Virtual Network Computing
XP – Extreme Programming
ix
Sumário
1 Introdução 1
1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Estruturação do projeto e conceitos de computação 6
2.1 - Programação Orientada a Objetos . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 - Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 - Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 - Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 - Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5 - Instância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.6 - Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.7 - Encapsulamento . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.8 - Herança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.9 - Polimorfismo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8
8
8
8
9
9
9
10
2.2 - Python e seu framework Django . . . . . . . . . . . . . . . . . . . . . . . .
2.3 - Banco de dados e modelagem relacional . . . . . . . . . . . . . . . . . .
2.4 - Casos de uso do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 - Javascript, JQuery e Bootstrap para alterações na aplicação e
responsividade dos templates
10
13
15
18
x
2.6 - Programa Witty dentro do escopo do projeto . . . . . . . . . . . . . . 25
3 Qualidade de Software 27
3.1 - Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 - Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 - Tipos de Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 - Teste de Unidade . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 - Teste de Integração . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 - Teste de Interface de Usuário . . . . . . . . . . . . . . . .
3.3.4 - Teste de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5 - Teste de Desempenho . . . . . . . . . . . . . . . . . . . . . .
3.3.6 - Teste de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.7 - Teste de Longevidade . . . . . . . . . . . . . . . . . . . . . .
3.3.8 - Testes de Segurança . . . . . . . . . . . . . . . . . . . . . . .
30
30
30
31
31
31
32
32
4 Automação do processo de provisionamento 33
4.1 - Nginx e Gunicorn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 - Fabric, Chef-Solo e Vagrant . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5 Conclusões 37
Bibliografia
39
xi
Lista de Figuras
2.1 – Estrutura base do projeto dos cursos de extensão . . . . . . . . . . . . . . . . . . . . . 12
2.2 – Base de dados relacional do projeto dos cursos de extensão . . . . . . . . . . . . . 14
2.3 – Casos de uso para funcionários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 – Casos de uso para aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 – Casos de uso para usuário anônimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 – Função em Javascript para ajuste de texto selecionados para selecionadas . . 19
2.7 – Template modificado para inclusão de estilo de remoção de botões . . . . . . . 20
2.8 – Função em Javascript para tratar seção de downloads no administrador . . . . 21
2.9 – Download de monografia na visão de usuário não logado, ou aluno logado . 22
2.10 – Download de monografia na visão de administrador logado . . . . . . . . . . . . 22
2.11 – Histórico de download de uma monografia para administrador . . . . . . . . .
2.12 – Dados de uma monografia sem arquivo no servidor . . . . . . . . . . . . . .
23
24
4.1 – Script via Fabric para execução do Chef-solo . . . . . . . . . . . . . . . . . . . . . . . .
35
1
Capítulo 1
Introdução
1.1 – Tema
O tema principal deste projeto é o desenvolvimento de um sistema para atender
a uma demanda do Departamento de Engenharia Eletrônica e de Computação.
Neste sentido, o problema específico a ser resolvido é a construção de um
sistema web para o controle de notas e frequência dos alunos de cursos de MBA, bem
como para a geração de históricos e boletins situacionais.
1.2 – Delimitação
O principal ponto do estudo e do projeto é tornar o processo de inscrição,
alteração e exclusão de disciplinas, assim como o controle de grau e frequência
centralizados em um único contexto, no caso, o portal criado.
Além disso, existia também a demanda, por parte da secretaria do DEL em
possuir uma forma, centralizada, de construir um acervo online, com arquivos de
monografias e trabalhos acadêmicos, garantindo um fácil acesso a todos que tivessem
interesse em consultar ou obter alguma informação neste sentido.
Acredita-se que, com o trabalho realizado, a experiência dos usuários, os alunos
dos cursos de extensão do Departamento, e também dos funcionários da secretaria do
DEL, melhorará de forma acentuada, possibilitando um aumento na produtividade e
satisfação de todos os envolvidos no processo.
1.3 – Justificativa
O conhecimento da área de computação é muito importante nos dias de hoje e
está atrelado a todos, independente da especialização de cada pessoa. Porém, é preciso
ter muito cuidado com a quantidade de informação que temos acesso, principalmente
pelo fato de que a Internet é repleta de conteúdos que, não necessariamente, são de boa
2
qualidade ou possuem algum embasamento teórico e prático. Qualquer um pode
divulgar qualquer tipo de informação, correta ou não.
Estudar sobre computação, em especial sobre temas como qualidade de
softwares, provisionamento e estruturação de um banco de dados relacional, são
importantes não só no meio acadêmico, mas, principalmente, para a construção de um
perfil de um profissional com foco em desenvolvimento orientado a testes, que é capaz
de entender que a produção de um software com ferramentas de testes e boas práticas de
programação gera uma maior produtividade e produtos com maior qualidade, sem
onerar no tempo de projeto.
Vale ressaltar que o estudo de provisionamento de máquinas e servidores de
forma automatizada traz um enorme benefício para projetos a serem desenvolvidos por
qualquer profissional da área de computação. Possuir o conhecimento referente a este
tópico torna possível construir e destruir máquinas com pouco custo, o que pode evitar
problemas comuns em projetos de médio e grande porte.
Com base nas técnicas citadas previamente, foi possível a criação deste sistema
para os cursos de extensão do DEL, visando melhorar a experiência dos funcionários e
dos alunos, visto que, atualmente, todo o processo de inscrição em disciplinas, controle
de frequência, notas e alguns outros fluxos acadêmicos eram realizados de forma
arcaica, usando-se planilhas e documentos feitos manualmente, sem nenhuma
integração com a Internet.
1.4 – Objetivos
O objetivo geral do trabalho é criar um sistema que possua algumas
especificações para que seja útil e atenda aos requisitos de funcionamento dos cursos de
extensão do DEL.
Alguns objetivos específicos deste trabalho são:
1. Tornar possível com que um aluno cadastrado e logado tenha acesso a
suas notas e listagem de documentos necessários para o seu curso.
2. Dar a possibilidade dos funcionários cadastrados e logados possam fazer
uma gestão, simples e clara, do sistema, podendo criar, alterar e remover
disciplinas, e gerir inscrições e alunos de uma forma simples e intuitiva.
3
3. Facilitar o controle de grau e frequência de cada aluno para cada
disciplina.
4. Manter um histórico de disciplinas para que facilite a consulta, caso
necessário.
5. Reunir, dentro do portal, uma área com um acervo de monografias e
documentos, aberto ao público, com o intuito de facilitar a disseminação
de conhecimento acadêmico para eventuais interessados.
Além das especificações previstas no portal desenvolvido, também é objetivo do
trabalho disseminar e exemplificar técnicas de desenvolvimento web e automatização
de processos, conceitos de programação orientada a objetos, a escolha de um bom banco
de dados de acordo com a aplicação desenvolvida e o uso de ferramentas como o Fabric
e Chef-Solo para automatização de provisionamento de máquinas.
Por fim, o trabalho também tem como meta expor ao leitor a importância de
produzir um código com uma boa cobertura de testes, trazendo uma maior
confiabilidade e qualidade para o projeto desenvolvido.
1.5 – Metodologia
Inicialmente, a abordagem do problema foi uma pesquisa voltada para as
melhores tecnologias para a implementação do sistema proposto.
Era preciso buscar uma linguagem de programação completa, na qual fosse
possível implementar um sistema com adição, alteração e remoção de turmas,
disciplinas, pessoas, notas, documentos e arquivos. Foi escolhida a linguagem de
programação Python, com seu framework Django, que possui uma documentação
excelente, além de possuir uma grande aceitação na área de hospedagem de projetos.
Somado a isso, o Django é facilmente integrado com qualquer tipo de banco de dados,
que é um fator crucial para a persistência dos dados do sistema. No caso deste projeto,
foi utilizado o banco de dados MySQL.
Com a linguagem do lado servidor escolhida, seu framework para facilitar o
desenvolvido instalado e o banco de dados também escolhido, foi necessário pensar nas
4
tecnologias que seriam utilizadas para implementar o lado cliente do projeto. Junto da
linguagem Javascript, tomou-se a decisão de uso do JQuery, para atender a algumas
soluções necessárias, como alterações de comportamentos padrões do Django. Além
disso, optou-se por utilizar o Bootstrap, que é um excelente framework para o auxílio no
desenvolvimento responsivo de portais e que possui uma comunidade ativa, que sempre
busca novas soluções e melhorias no projeto, o que torna a escolha pela tecnologia
ainda mais atrativa.
Também era necessário a escolha do servidor que seria usado para fazer a
hospedagem do projeto. Após uma análise de custos, chegou-se a conclusão de utilizar
uma máquina da Digital Ocean, com sistema operacional Ubuntu em sua versão 14.0.4.
Por fim, era preciso realizar o provisionamento do projeto para o servidor
escolhido. Dentre as tecnologias existentes para o auxílio a provisionamento, neste
projeto foram usadas o Fabric juntamente do Chef Solo. O primeiro é uma excelente
biblioteca para o Python, que auxilia na criação de scripts para deploy. Já o Chef Solo é
uma ferramenta que auxilia na instalação e no provisionamento de máquinas para
quaisquer tipos de servidores. Com o uso das duas tecnologias foi possível implementar
uma solução de provisionamento que facilita muito ao desenvolvedor e a
administradores a realizar deploys e construção de novas máquinas com apenas uma
linha de comando, dependendo de configurações usadas.
1.6 – Descrição
No capítulo 2 serão expostas as decisões tomadas no projeto acerca da
linguagem de programação escolhida, juntamente com o framework que auxiliou no
processo de desenvolvimento do software. Falaremos também sobre conceitos
importantes na área da computação como o paradigma da programação orientada a
objetos, com suas definições e casos de uso. Além disso será apresentado o mapeamento
do banco de dados, casos de uso do projeto, assim como as tecnologias que foram
usadas para a montagem do template e alterações do funcionamento padrão do Django
[1].
O capítulo 3 apresentará a importância na preocupação do uso de ferramentas
para melhorar a qualidade de um software, com foco principal na definição e no uso de
testes em um projeto.
5
Já no capítulo 4, será explicitado como utilizar o Fabric [2] e o Chef Solo [3]
para criação de scripts para o provisionamento de máquinas de forma simples e
reaproveitável.
A conclusão, no capítulo 5, discute os resultados finais do projeto, alguns dos
principais problemas que ocorreram ao longo do desenvolvimento do software e
considerações finais sobre o processo como um tudo.
6
Capítulo 2
Estruturação do projeto e conceitos de
computação
A finalidade deste capítulo é introduzir ao leitor as primeiras decisões tomadas
no projeto, tais como a estrutura de dados, linguagem de programação e demais
tecnologias que foram utilizadas no software desenvolvido.
Na primeira parte é explicado o conceito de linguagem de programação
orientada a objetos e seus conceitos. Ainda nesta parte citaremos a linguagem Python,
que foi a escolhida para o desenvolvimento de mais de noventa por cento do projeto.
Também é apresentado o framework Django, uma ferramenta bastante utilizada por
empresas e desenvolvedores que programam com Python [4].
Na sequência falaremos sobre a estruturação do banco de dados do projeto. As
decisões envolvidas em cada classe, suas relações e heranças e a escolha do banco de
dados MySQL [5], assim como o funcionamento das queries criadas para o projeto.
Após a escolha e estruturação do banco de dados, citaremos os casos de uso do
projeto, assim como a diagramação do mesmo.
Por fim, na última seção do capítulo, trataremos da escolha por utilizar o
Bootstrap para a modelagem do template do projeto, assim como o uso de Javascript [6]
e JQuery [7] para alterar funcionalidades do Django, que, apesar de ser bastante flexível
e ser feito para aceitar que alguns de seus módulos sejam sobrescritos, acabou-se
optando por alterar algumas das suas funcionalidades e mensagens padrões.
2.1 – Programação Orientada a Objetos
A programação orientada a objetos [8] é um dos paradigmas para se escrever um
software. Vale ressaltar, desde o início, que utilizar linguagens que são voltadas a
programação orientada a objetos não é melhor nem pior do que utilizar outras técnicas
de programação, no entanto, como citaremos a seguir, a utilização desse paradigma de
programação possui certas vantagens em determinados cenários.
7
De forma geral, os paradigmas de programação [9] mais importantes e utilizados
são o paradigma procedural, funcional, lógico e a orientação a objetos de fato. Não
entraremos em detalhes específicos de cada um dos paradigmas citados, com exceção da
orientação a objetos, pois desvirtuaria o foco do trabalho.
Uma das grandes vantagens de se utilizar esse paradigma é pela facilidade de
reutilização do código e, de maneira geral, reduzir a quantidade de linhas escritas para a
produção de um software. Em teoria, isto ajuda a diminuir a probabilidade de obter
bugs, assim como torna a manutenção do código e a solução de potenciais bugs mais
fácil e simples.
Além disso, muitas empresas e projetos desenvolvidos, nos dias de hoje, tendem
a utilizar linguagens de programação orientadas a objetos pelo fato de ser mais fácil a
paralelização de trabalho, e isso tende a diminuir o tempo de entrega dos projetos,
mantendo um bom nível de qualidade de software.
A seguir, aprofundaremos alguns conceitos básicos fundamentais do paradigma
de orientação a objetos, como os conceitos de classes, atributos, métodos, objetos,
instâncias, heranças e polimorfismo.
2.1.1 – Classe
Classe, em linguagens orientadas a objetos, é um conjunto de dados estruturados
que são caracterizados por propriedades comuns. É vital para evitar redundâncias em
estruturas de dados complexas e se encaixa em uma série de outros conceitos que serão
expostos a seguir.
Se por um lado, um objeto individual é uma entidade concreta, que atua no
contexto de um sistema, uma classe é a representação e estrutura comum a todos os
objetos que são relacionados. É uma espécie de agrupador.
Como forma de exemplificação, podemos mostrar o que foi feito no projeto de
fato. Existia a necessidade de se criar diferentes tipos de permissões para diferentes
tipos de pessoas. Surgiram três grandes grupos que teriam grande importância no
projeto: alunos, professores e funcionários. Todos possuem características em comum,
como nome, sobrenome, contatos, mas os papéis desempenhados por cada um seriam
totalmente diferentes. Com isso em mente, foi criado uma classe Pessoa, que vem a ser
a base de todo o projeto. De acordo com o tipo que uma instância de Pessoa vai assumir,
8
os acessos, páginas visualizáveis, poderes e permissões dentro do sistema são alterados
dinamicamente.
2.1.2 – Atributos
Atributos são a estrutura de dados que representam um objeto. Seja o nome no
caso de um objeto da classe Pessoa, ou então a descrição de um objeto da classe
Medicamento. Basicamente, são características referentes ao objeto em questão.
2.1.3 – Métodos
Os métodos de um objeto são implementações de uma rotina, a caracterização de
um comportamento. De forma simplória, métodos de um objeto são o conjunto de ações
que o mesmo pode realizar. Ações essas que podem depender de alguns dados de
entrada, e que, majoritariamente, acabam dependendo de fato.
2.1.4 – Objeto
Um objeto é uma entidade lógica que contem dados e código para manipular
esses dados. Dados, na forma de atributos, e código, denominados pelos métodos, que
manipulam essa estrutura de dados do objeto visando diferentes tipos de comportamento
de acordo com a implementação.
De um modo geral, os objetos são representações de objetos físicos da vida real.
Pessoas, Medicamentos foram exemplos citados ao longo do capítulo, mas a realidade é
que objetos podem representar uma imensa gama de coisas.
Vale ressaltar que, apesar da orientação a objetos ser muito útil para problemas
próximos ao mundo real, como é o caso do trabalho proposto, nem sempre o uso de
orientação a objetos e a própria abstração do objeto de fato é a melhor forma de se
programar para se encontrar a solução de um problema. É por isso que os demais
paradigmas não são melhores nem piores, e sim possuem outras aplicações que tendem
a soluções mais simples ou a soluções com uma complexidade maior, de acordo com o
cenário proposto e as dificuldades que serão apresentadas.
2.1.5 – Instância
9
Dentro do escopo de um software, todos os objetos criados originados de uma
classe são denominados instâncias daquela classe.
Ao criar um objeto da classe Pessoa com certos atributos de entrada, como um
nome "João" e uma idade "20 anos", teríamos uma instância de Pessoa com nome João
e 20 anos de idade. Esse conceito se estende e pode persistir quando relacionado a um
banco de dados, que deixará gravado diversas instâncias de diversas classes e darão
sentido ao software proposto.
2.1.6 – Mensagens
Por definição, um método só pode ser ativado através do envio de uma
mensagem ao objeto. Cada objeto só pode responder a mensagens que constem do seu
protocolo, que são as mensagens correspondentes as suas operações.
Podemos não somente enviar mensagens iguais para objetos diferentes, assim
como é possível enviar a mesma mensagem para instâncias de classes diferentes, tendo
em vista que estas podem possuir métodos com a mesma interface.
Quando uma mensagem é enviada para um objeto ocorre a ativação de um
método. Após a execução desse método temos um resultado denominado resposta.
2.1.7 – Encapsulamento
O conceito de encapsulamento é decorrente do fato de se combinar os dados e o
código que o manipula em uma única entidade, o objeto em si. Este garante que a única
forma de acesso aos dados é através de métodos públicos. Os demais métodos e
atributos são considerados privados e só possuem acesso por funções e classes internas
a um projeto, direto ou indiretamente.
Este conceito não é exclusivo ao paradigma de orientação a objetos. Também o
encontramos na definição de tipos abstratos de dados.
Em suma, o encapsulamento diz respeito a definição de uma estrutura que
contenha os dados, defina quais os métodos são públicos ou privados e traz para a
aplicação uma camada extra de segurança.
2.1.8 – Herança
10
Herança é a propriedade dos objetos que permite a criação de uma hierarquia
entre eles, onde os seus descendentes herdam o acesso aos métodos e atributos dos seus
ancestrais
Peter Coad e Edward Yourdon [10] trazem a seguinte definição de herança:
"[...] mecanismo para expressar a similaridade entre classes, simplificando a definição
de Classes similares a outras que já foram definidas. Ela representa a generalização e
especialização, tomando atributos e serviços comuns em uma hierarquia de Classe."
De fato a aplicação do conceito de herança é muito útil para diversos projetos de
computação. A capacidade de criar classes bases e poder herdar atributos e métodos
para classes menos genéricas, diminui a quantidade de linhas de códigos, que tende a
reduzir a probabilidade de introdução de bugs em um sistema.
2.1.9 – Polimorfismo
O polimorfismo é um conceito que se refere à capacidade de uma variável,
função ou objeto poder assumir múltiplas formas.
Uma linguagem que apresenta polimorfismo permite aos desenvolvedores
programar de forma genérica, ao invés de uma forma específica, e adaptar métodos e
objetos de acordo com o contexto, utilizando alguns recursos da própria linguagem.
Com isso, é possível explorarmos similaridades entre diferentes classes de
objetos, fato este que pode reduzir a complexidade do código produzido.
2.2 – Python e seu framework Django
A grande motivação para o uso do Python no projeto desenvolvido foi o fato da
linguagem ser de alto nível e funcionar bem com o paradigma da orientação a objetos
[11]. A biblioteca padrão do Python é muito extensa e isso também é de grande ajuda,
pois com isso é possível evitar a instalação de bibliotecas externas para dar mais
robustez a aplicação.
Somado a isso, o Python possui alguns bons frameworks que auxiliam na
criação de projetos com certa complexidade, como o projeto desenvolvido neste
trabalho. O framework escolhido para o projeto foi o Django.
O Django é um framework escrito em Python, que segue o padrão MVC (model,
view, controller), que é uma boa prática de arquitetura de software [12], bastante
11
comum na área de computação. Possuí nove anos de existência e tem uma comunidade
muito ativa e que auxilia na criação de novos recursos e na melhoria de alguns já
existentes.
Utilizar o Django como framework [13] para o trabalho traz uma série de
vantagens e agiliza em muito na construção de aplicações web. Primeiramente, ele
auxilia muito na criação de formulários. A sobrescrita do método clean para validar
formulários, assim como a criação de validações específicas para cada atributo de uma
classe torna simples a criação e gestão de formulários como um todo.
O Django também possui uma estrutura simples de ser implementada para o uso
de um administrador, que é caso do projeto. É facilmente customizável, tanto na parte
visual como em certas funcionalidades. É bastante simples escolher quais campos dos
objetos serão exibidos, quais poderão ser editados. Além disso, os filtros e buscas são
fáceis de serem usados e podem ser totalmente customizados, de acordo com o critério
escolhido para cada funcionalidade específica.
Também vale ressaltar o funcionamento de templates, views, contextos e rotas
do framework. É possível criar marcações HTML e utilizar extensões para reaproveitar
blocos em comum a várias páginas. Além disso, cada página pode ser acessada por
rotas, determinadas por padrões definidos pelo desenvolvedor, que executam códigos
em views e que utilizam do conceito de contexto, que nada mais é do que dados que vão
preencher as páginas com conteúdos.
Existem algumas formas de organizar um projeto web feito com Python e
Django. Neste projeto tomou-se a liberdade de utilizar um estilo de organização que
visa o reuso de pequenas partes do projeto para demais projetos que poderiam surgir no
futuro. Com isso o projeto dos cursos de extensão é uma app Django com pequenas
apps dentro, conforme podemos ver na figura 2.1.
12
Figura 2.1 – Estrutura base do projeto dos cursos de extensão.
A app "core" é a responsável por agrupar arquivos estáticos e algumas regras de
negócio do projeto. Isso é uma prática de projeto relativamente comum e auxilia na
organização e na escalabilidade de projetos inicialmente.
A app "pessoa" é responsável pelos modelos de Pessoas, que é a classe base do
projeto. Além disso nessa app também temos as definições de classes de Contato e
Documentos Pendentes, que tem ligação direta com a classe base Pessoa.
Já na app "disciplina" foram criadas as classes Disciplina e Avaliação, que
possuem ligação com a classe base Pessoa, mas podem ser tratadas como classes
independentes e, portanto, a escolha de segregar esta parte da aplicação das demais.
A app "portal" é a responsável por muitas rotas do portal de fato. Diversos
fluxos como login, logout, histórico, acesso ao perfil de um usuário, redefinição de
senhas são tratados dentro desta parte do projeto. Uma vasta camada do
13
permissionamento do projeto está centralizado na app portal, e isso auxilia no
tratamento e correção de bugs relacionados a este tópico, o que veio a ser de extrema
utilidade ao longo do desenvolvimento do projeto.
Por fim, a app "downloads" que trata da modelagem das monografias e do
histórico de downloads dos arquivos, que também são classes no projeto. A pasta
"media" é o caminho para o qual os arquivos que são realizados os downloads são
encaminhados. Ela não possui outra função, além de organizacional.
As demais pastas da estrutura do projeto são para o auxílio do provisionamento,
que será assunto do capítulo 4.
2.3 – Banco de dados e modelagem relacional
No início do projeto não era claro qual seria o melhor banco de dados para o
cenário proposto. Algumas opções, previamente utilizadas, foram levantadas, como o
SQLite [14], MySQL, PostgreSQL [15], MongoDB [16] e Redis [17]. Logo de início foi
descartado o uso de Redis e MongoDB, pois não são bancos relacionais e,
provavelmente, não seria preciso um banco de dados que suportasse tanta escrita quanto
estes são preparados para suportar. Além disso, não é tão simples encontrar servidores
que suportem esses bancos em específico.
Com isso restou a realização de um estudo sobre os três bancos restantes [18]. O
SQLite é bastante famoso para o uso de testes e aplicações de tamanho bem pequeno, e
talvez esse fosse o caso do projeto desenvolvido. Porém, tanto o MySQL e o
PostgreSQL são bancos que suportam um volume um pouco maior de escrita de forma
bastante confiável e a aplicação desenvolvida, apesar de não ser uma aplicação que teria
um banco com um volume de dados imenso, precisaria atender a possíveis cenários em
que múltiplos usuários realizam consultas e alterações simultaneamente.
Depois de um estudo mais aprofundado sobre as duas opções restantes [19],
chegou-se a algumas conclusões. O PostgreSQL é otimizado para aplicações mais
complexas do que a exigida no projeto desenvolvido. A utilização do PostgreSQL, no
projeto, seria desnecessária no ponto de visto de consumo de recursos de máquinas, sem
contar o fato de ser um pouco mais difícil encontrar servidores que suportem esse banco
de dados. Já o MySQL é mais focado na agilidade. Em aplicações web que não tenham
consultas complexas, o tempo de resposta é alto e exige menos do hardware dos
servidores. Obviamente, o MySQL não é tão otimizado para gerenciar recursos tão
14
avançados como o PostgreSQL é capaz, mas para o projeto desenvolvido isso seria
desnecessário e, então, o banco de dados relacional escolhido para os portais dos cursos
de extensão foi o MySQL.
Com o banco escolhido, iniciou-se o trabalho de modelagem de dados do projeto
(ver figura 2.2). Conforme apresentado anteriormente, a classe base do projeto foi a
classe Pessoa. A classe possui os atributos nome, data_nascimento, cpf, email,
data_criacao, data_nascimento, tipo, bloqueado e is_active (que são flags do sistema) e
também possuem um registro de last_login e a password.
Figura 2.2 – Base de dados relacional do projeto dos cursos de extensão.
Os tipos de Pessoa são Aluno, Professor e Funcionário. De acordo com o tipo da
instância ela possui relações únicas, acessos únicos e permissão de visualizações únicas.
Além disso o valor dos campos bloqueado e is_active também alteram algumas
permissões do sistema, como acesso a notas e acessos ao administrador.
É importante destacar que alguns destes atributos são preenchidos de forma
automática pelo sistema, e outros são preenchidos ao se adicionar uma nova pessoa ao
sistema. O login de cada novo usuário, por exemplo, é o seu CPF, que é uma chave
única e que possuí um validador para números de CPF e a data de nascimento da
pessoa. Após o primeiro login é possível alterar esta senha.
15
Temos duas outras classes que possuem fortes relações com a classe Pessoa.
Essas classes são DocumentosPendentes e Contato. A classe Contato possui apenas um
tipo e a descrição do contato e tem referência com uma instância de Pessoa. Os tipos de
contatos são telefone e email (emails adicionais, não obrigatórios). A classe
DocumentosPendentes também se relaciona com Pessoa, mas apenas Pessoa do tipo
Aluno. Possui os atributos documentos e outros, além da relação um para um com
algum Aluno no sistema.
Seguindo a modelagem, foram criadas duas classes para tratar as disciplinas e
avaliações dos alunos. A classe Disciplina possui uma data_atualização, data_criação,
data_inicio, data_termino, limite_abonos, limite_faltas, nome, turma e professor
relacionado. A classe Avaliação possui abonos, faltas, nota, situação e relacionamento
com uma instância de Disciplina e uma instância de Aluno.
A situação do aluno é uma flag que indica se um aluno está aprovado ou
reprovado por média, frequência ou por ambos. O sistema consegue aferir a situação do
aluno caso os dados da Avaliação e da Disciplina estejam preenchidos. Para um aluno
ser aprovado ele precisa ter uma média superior a 7,0 e estar dentro do limite de faltas
para aquela disciplina. Existe também o conceito de abono de faltas, mas cada disciplina
possui uma quantidade máxima de faltas que podem ser abonadas, portanto este atributo
é customizável pelo administrador. Então, caso o aluno consiga ter a frequência
necessária para obter aprovação por frequência, incluindo o cálculo do abono, e tiver
média superior a média exigida, o sistema identifica que o aluno foi aprovado, de forma
automática.
Por fim, existe também a modelagem dos downloads do projeto. A classe
Monografia, que possui atributos arquivo, autor, descrição, downloads, nome e slug
(que é automático). E a classe ArquivoHistorico, que serve para fazer um mapeamento
dos downloads realizados. Essa classe possui os atributos data, ip, usuário, além do
relacionamento com uma instância de Monografia.
2.4 – Casos de uso do projeto
Com o intuito de tornar clara as especificações do sistema desenvolvido é
importante realizar uma descrição completa dos fluxos do mesmo, assim como expor os
casos de uso do projeto, de acordo com o tipo de permissão de cada usuário.
16
O fluxo mais complexo do projeto é o fluxo do funcionário, no caso, o
administrador do sistema. Como é possível ver na figura 2.3, o funcionário é capaz de
fazer a gestão de pessoas, arquivos e a gestão de disciplinas e avaliações.
Figura 2.3 – Casos de uso para funcionários
A gestão de pessoas é o local onde o administrador poderá criar novas contas,
assim como definir contatos, documentos pendentes e até mesmo criar novos
administradores para o sistema. Além disso, é possível editar qualquer pessoa já
existente, alterar seu tipo e permissões e remover uma pessoa do banco de dados do
sistema.
A gestão de arquivos é a mais simples. A única responsabilidade do
administrador é criar, ou remover, novos registros no banco de dados de arquivos que
serão disponíveis para downloads. O acesso ao histórico de downloads é automático e
atualizado conforme novos registros são inseridos no banco, ou seja, quanto mais
downloads forem ocorrendo, mais informações o administrador possuirá nesta seção.
Vale ressaltar que o funcionário também pode efetuar o download de arquivos, fora do
administrador do sistema.
A gestão de disciplinas e avaliações é a mais complexa do sistema. O
administrador pode criar, editar e remover disciplinas e realizar associações de alunos a
elas. Para cada aluno associado a uma disciplina, registros de avaliações são criados, de
17
forma automática, pelo sistema. De forma individualizada, o administrador pode alterar
a nota, as faltas e abonos de cada avaliação, para cada aluno, em cada disciplina.
Existem uma série de filtros disponíveis para facilitar o trabalho do administrador. Após
as notas e faltas preenchidas, é possível gerar os status destes alunos, por meio de uma
ação.
Um segundo fluxo do sistema é o fluxo do aluno registrado no sistema.
Conforme é possível ver na figura 2.4, o aluno pode realizar o login e logout do sistema,
assim como alterar a sua senha, ou tentar recuperá-la, caso tenha esquecido.
Além dessas funcionalidades básicas do sistema, o aluno logado é capaz de
consultar as suas avaliações em todas as disciplinas já cursadas e possui uma série de
filtros para auxiliar nessas consultas. Também existe uma área do sistema dedicada a
consulta de documentos pendentes. Por fim, existe uma área dedicada às buscas e
downloads de monografias. Nessa área o aluno consegue procurar e efetuar o download
das monografias disponíveis no sistema.
Figura 2.4 – Casos de uso para aluno.
18
O último fluxo do sistema é o fluxo de um usuário anônimo (ver figura 2.5). A
única possibilidade deste usuário é consultar a aba de busca e download de
monografias, que é idêntica para qualquer pessoa.
Figura 2.5 – Casos de uso para usuário anônimo.
2.5 – Javascript, JQuery e Bootstrap para alterações na aplicação e
responsividade dos templates
Ao longo do desenvolvimento do projeto foram necessárias uma série de
alterações no administrador padrão do Django, assim como na forma de renderizar
certos templates gerados pelo mesmo.
O Django nos permite sobrescrever os seus templates padrões, assim como
injetar novos estilos e fazer manipulações mais avançadas via injeção de Javascript.
As principais alterações que foram feitas no administrador do projeto foram a
alteração de textos padrões que o framework inseria, assim como a remoção de alguns
elementos visuais que eram desnecessários serem exibidos, seja por duplicidade ou por
estarem fora do contexto para certos fluxos que um administrador precisaria passar.
O Django possuí algumas variáveis de configurações que injetam contextos ao
projeto. Muitas dessas variáveis, por padrão, se encontram em arquivos de Settings.
19
Uma dessas variáveis, "LANGUAGE_CODE", é o idioma que o projeto vai respeitar, no
nosso caso, a língua portuguesa. Entretanto, o tratamento de artigos automáticos do
Inglês para o Português sempre é conflitante. No caso das classes Disciplina e Pessoa,
as mensagens da ação de exclusão era "Remover disciplinas selecionados" e "Remover
pessoas selecionados", o que, obviamente, está incorreto. Com base nisso foi criada
uma função (ver figura 2.6), em Javascript, que era capaz de encontrar a palavra
"selecionados" dentro de certo elemento da página do administrador e, caso encontrado,
alterar para "selecionadas".
Figura 2.6 – Função em Javascript para ajuste de texto selecionados para
selecionadas.
Ao longo do projeto outra alteração foi necessária. Em formulários de edição de
uma instância de um objeto qualquer, no administrador, existia um campo chamado
"Histórico", que exibia as alterações efetuadas desde a criação até o dado momento de
qualquer instância do projeto . Esse campo foi alterado para exibir a palavra "Log", que
tornava mais precisa a mensagem ao usuário administrador do projeto. Novamente foi
desenvolvido uma função em Javascript para contornar o problema.
Essa função buscava um elemento na página e alterava o seu texto, de forma
semelhante a função criada para alteração do gênero, porém um pouco mais simples,
visto que não era necessário alterar apenas uma parte do texto, e sim o texto "Histórico"
inteiro.
20
Alguns ajustes feitos via CSS foram necessários. Alguns botões de exclusão e
edição não faziam sentido serem exibidos em certos contextos, e era necessário remover
a sua exibição, para que o administrador não sofresse com algumas redundâncias
geradas pelo Django. Com isso optou-se pela remoção visual dos botões, via estilização
de seus elementos na própria página, em cima de um template sobrescrito do Django
(ver figura 2.7).
Figura 2.7 – Template modificado para inclusão de estilo de remoção de botões.
Por fim, foi necessário mais um ajuste na seção de downloads. Era preciso
alterar a mensagem padrão do Django em relação a quantidade de elementos de uma
lista, assim como o texto do cabeçalho da página. Uma função, um pouco mais
complexa foi criada (ver figura 2.8), com o intuito de alterar o cabeçalho da área
específica de downloads, assim como exibir uma mensagem clara ao usuário de quantos
downloads haviam sido feitos. A lógica criada era, baseado na quantidade de elementos
entregues, expor pro usuário final as mensagens "Nenhum download realizado.", "1
download realizado." ou "X downloads realizados.", neste caso, X sendo o número de
elementos da lista sendo X maior que 1. Com isso a mensagem padrão foi sobrescrita.
21
Figura 2.8 – Função em Javascript para tratar seção de downloads no
administrador.
Foi utilizado o JQuery para a criação de uma funcionalidade do projeto. O
JQuery é uma biblioteca do Javascript, amplamente utilizada por empresas no mundo e
que reduz a complexidade de código com diversas funções que para serem
implementadas via Javascript gastariam muitas linhas de código.
A funcionalidade em questão, que foi criada via JQuery, foi a manipulação de
download e históricos de um arquivo, fora do administrador. Foi criada uma pequena
função que trata as paginações e exibe para o usuário comum alguns dados da
monografia (ver figuras 2.9 e 2.10), e para os usuários com permissão necessária,
exibem outros dados, como IP das máquinas que efetuaram downloads dos arquivos,
por exemplo (ver figura 2.11).
22
Figura 2.9 – Download de monografia na visão de usuário não logado, ou aluno
logado.
Figura 2.10 – Download de monografia na visão de administrador logado.
23
Figura 2.11 – Histórico de download de uma monografia para administrador.
O sistema também faz o tratamento para quando existe uma entrada de uma
monografia, mas o upload não é feito. Como vemos na figura 2.12, os dados da
descrição continuam sendo exibidos, assim como o nome e a quantidade de downloads,
que será sempre zero, até o arquivo ser lançado no sistema, e o botão de download não
fica disponível para o usuário.
24
Figura 2.12 – Dados de uma monografia sem arquivo no servidor.
Por fim, o Bootstrap foi utilizado para tratar a responsividade das páginas do
site, com exceção do administrador, que não é responsivo.
Primeiramente, o conceito de Responsive Web Design [20] é muito abrangente.
De forma geral, criar páginas com o design responsivo é você ter a responsabilidade de
desenvolver não apenas para o usuário com telas de apenas um tamanho, e sim para
telas de diversos tamanhos. Seja um smartphone, que por si só já possuem uma gama de
tamanhos de telas bastante significativa, como um tablet e até mesmo um watchphone,
que ainda é pouquíssimo explorado, mas em breve soluções para eles serão
desenvolvidas.
A escolha do uso do Bootstrap, como framework, se deu baseado no fato de ser
um projeto com uma comunidade ativa, que sempre busca novas soluções para diversos
tipos de problemas, além de ser bastante simples de usar e possuir uma arquitetura de
arquivos bem organizada e atender a maioria dos problemas comuns de qualquer página
na Internet. Uma outra opção seria o Foundation [21], que também é um framework
bastante profissional, utilizado por diversas empresas do mundo inteiro, porém acabei
25
optando pelo Bootstrap para este projeto em específico, principalmente, pela existência
de um projeto chamado django-bootstrap3 [22], que facilita o uso do Bootstrap em
templates do Django.
2.6 – Programa Witty dentro do escopo do projeto
A última demanda do projeto em si era incluir uma rota para ter acesso a um
aplicativo para Windows, chamado Witty, de dentro do projeto desenvolvido. Esse
aplicativo possui uma série de elementos particulares e interações que não cabem a este
projeto exemplificar.
A ideia inicial, para a solução deste problema, era inserir o arquivo executável
na mesma máquina aonde o portal estaria hospedado. O primeiro problema era que a
máquina possuía o sistema operacional Linux, que não consegue executar arquivos
executáveis do Windows de forma padrão. A solução de contorno a isso seria executar o
arquivo por meio da aplicação Wine [23], porém as empresas de hospedagens não
gostam dessa prática, visto que muitas pessoas utilizam disso para rodar aplicações
nocivas e prejudicar diversos usuários da Internet pelo mundo.
Então, a segunda ideia para a solução do problema era hospedar o arquivo em
um outro servidor, e optei pelos servidores da Amazon, que são bem simples de
administrar e possuem máquinas com Windows a disposição de um usuário comum.
Entretanto surgiu o grande problema: o acesso via o portal desenvolvido seria
por meio de um iframe, que trabalha com o protocolo HTTP. Para se conseguir uma
comunicação com o aplicativo rodando na máquina Windows, não poderia utilizar o
protocolo HTTP. A princípio, ainda se cogitou a utilização de alguma forma de
comunicação via VNC, mas de uma forma geral, a melhor solução seria a
implementação da aplicação Witty em um ambiente web, por exemplo, com a
linguagem Python, ou PHP, e incluir esse app dentro do escopo do projeto.
A conclusão que pode ser tirada do insucesso de implementar a aplicação Witty
no projeto é que trabalhar com comunicações entre protocolos pode ser difícil, ainda
mais quando um dos protocolos é o HTTP em um ambiente web. Como dito antes, a
solução mais simples seria adaptar o Witty para um ambiente web, mas isso é custoso e
foge do escopo deste projeto. Possivelmente alguma técnica poderia ter sido utilizada
26
para garantir o funcionamento entre os dois serviços envolvidos, mas em tempo de
desenvolvimento deste projeto em questão isto não foi possível
27
Capítulo 3
Qualidade de Software
É de vital importância a produção de códigos seguros na área da computação
como um todo. A facilidade pelo acesso a informação torna muito simplória a tarefa de
algum leigo, mal intencionado, buscar brechas em um sistema que sofra de problemas
básicos de criação e estruturação, seja pelo lado do servidor tanto pelo lado do cliente.
Existem diversas precauções que um bom desenvolvedor pode tomar para se
resguardar e antecipar problemas comuns. A maioria delas gira em torno de criar
cenários possíveis, e implementar soluções em resposta à esses cenários, antes mesmo
de colocar seu código em produção.
O que este capítulo explica para o leitor é a importância de testes automatizados
[24]. Testes estes que podem garantir uma maior segurança para qualquer aplicação,
independente do tamanho, sua importância, quantidade de acessos e quaisquer fatores
externos que podem ser simulados em ambientes controlados e evitar transtornos
simples, como uma página não renderizar por um pequeno erro de sintaxe, como um
transtorno grave, como um portal inteiro ficar inacessível por um mal planejamento de
quantidade de acesso suportado ou algum erro de configuração em pontos críticos de
um sistema.
3.1 – Qualidade
Ao falar de qualidade de software [25], podemos nos referir a qualidade do
processo de criação do software ou da qualidade do produto desenvolvido.
No que tange qualidade do produto em si, vale ressaltar alguns qualificadores
normativos acerca deste tópico. A norma ISO 9126, define um conjunto de seis
características de qualidade e sub-características associadas a essas.
A primeira característica citada pela norma é funcionalidade. Por definição é o
conjunto de atributos que evidenciam a existência de um conjunto de funções e suas
propriedades especificadas. As sub-características associadas a esta são adequação,
acurácia, interoperabilidade, conformidade e segurança de acesso.
28
A segunda característica citada é a confiabilidade. Por definição é o conjunto de
atributos que evidenciam a capacidade do software de manter seu nível de desempenho
sob condições estabelecidas durante um período de tempo estabelecido. As sub-
características associadas a esta são maturidade, tolerância a falhas e recuperabilidade.
A terceira característica citada pela norma é a usabilidade. Por definição é o
conjunto de atributos que evidenciam o esforço necessário para se poder utilizar o
software, bem como o julgamento individual deste uso, por um conjunto explícito ou
implícito de usuários. Suas sub-características são inteligibilidade, apreensibilidade e
operacionalidade.
Eficiência é o quarto pilar citado pela norma. Sua definição cita o conjunto de
atributos que evidenciam o relacionamento entre o nível de desempenho do software e a
quantidade de recursos usados, sob condições estabelecidas. Podem destacar outras
características ligadas a eficiência como o comportamento em relação ao tempo e o
comportamento em relação aos recursos disponíveis e aplicados.
A quinta característica é a manutenibilidade, que por definição é o conjunto de
atributos que evidenciam o esforço necessário para que se façam modificações
específicas no software. Suas sub-características são a analisabilidade, modificabilidade,
estabilidade e testabilidade.
Por fim, a sexta característica, segundo a norma, é a portabilidade, que traz
consigo a definição dos conjuntos de atributos que evidenciam a capacidade do software
ser transferido de um ambiente para o outro. Sub-características como adaptabilidade,
capacidade para ser instalado, conformidade e a capacidade para substituir são alguns
pontos desta última característica.
Vale ressaltar alguns tópicos específicos de qualidade de software web, como é
o caso do projeto desenvolvido. Características como usabilidade, funcionalidade,
eficiência, confiabilidade e manutenibilidade são realçadas no cenário web,
principalmente pela preocupação necessária em atender certos pontos para os usuários.
Podemos citar como exemplo a importância de se pensar no tempo de resposta
de uma página, assim como a velocidade de geração da mesma. A capacidade do
usuário navegar de forma clara, com aspectos estéticos e interface simples e intuitiva e a
facilidade de manutenção e correção de eventuais erros. Também a garantia da
integridade dos dados do sistema, assim como a proteção de informações confidenciais
para cada usuário.
29
3.2 – Testes Automatizados
A atividade chamada "Testes Automatizados" é uma prática de tornar testes de
software independentes da intervenção do homem. O grande objetivo de criar testes
automatizados, assim como os testes manuais, é melhorar a qualidade do sistema por
meio de validações, porém a automação dos testes veio a auxiliar os desenvolvedores
nesse aspecto.
Testes manuais sempre foram eficazes, mas possuem problemas claros em seu
conceito. De forma resumida, desenvolver uma funcionalidade se baseava em estudar
um problema, pensar em uma solução e então implementá-la. Após esse ciclo
desenvolvedores realizava uma bateria de testes manuais e caso algum problema fosse
encontrado, o ciclo se repetia até o produto estar sem erros, ou o prazo do projeto se
encerrar. O problema desta técnica é que realizar esta bateria de testes manualmente
requer tempo, dedicação humana e por possuir intervenção humana no processo, é
passivo de falhas geradas pelo próprio homem, que realiza os testes, e isso tudo pode
causar demoras, transtornos ou gerar erros pequenos ou graves em uma aplicação em
produção.
As metodologias ágeis como o Scrum [26], XP [27], Kanban [28], visam uma
integração continua dos envolvidos no projeto em manter um controle de qualidade do
produto diariamente, pois acredita na ideia de que prevenir problemas é mais fácil e
barato do que corrigi-los em produção. A partir desse conceito surge a popularização
dos testes automatizados. Estes são scripts que simulam funcionalidades do sistema e
realizam uma série de testes de forma automática. Seja em busca de problemas simples
de sintaxe, como testes em que ferramentas abrem algum navegador em páginas de
testes e simulam ações e fluxos de usuários, com o intuito de garantir que a experiência
do mesmo esteja funcionando conforme o planejado, mesmo após uma alteração de
código. O grande ganho da automatização de testes é que, se feita com as ferramentas
certas, é possível executá-los facilmente, quantas vezes forem necessárias e garantir que
novas funcionalidades não irão alterar cenários que já estão funcionando, por exemplo.
3.3 – Tipos de Testes Automatizados
Ter o conhecimento do que é qualidade de software e das principais diferenças e
motivações de se aplicar testes automatizados ao invés de testes manuais é de vital
30
importância para quem está buscando expandir e aprimorar a forma de escrever e
planejar um software.
Entretanto, é necessário entender cada tipo de testes e o seu real sentido dentro
da aplicação, para não se cometer um grande erro que é utilizar uma ferramenta de um
tipo de teste específico para outros objetivos, reduzindo a qualidade dos testes criados e
atrasando o processo como um todo [29]. Portanto, as próximas seções vão descrever de
forma resumida os principais tipos de testes existentes, seus casos de uso mais normais
e explicar algumas ferramentas que podem ser usadas em alguns tipos de testes.
3.3.1 – Teste de Unidade
Testes unitários são os testes mais comuns em sistemas. São os testes que tem
como objetivo verificar pequenos trechos de código, funções e métodos bem definidos e
nomeados. Como exemplo, um método que verifica se um número é múltiplo de dois,
retornado True caso seja e False caso não seja. Um script poderia ser criado e verificar
se este método chamado com o número 4 realmente retorna True e o mesmo método
chamado com o número 21 retornaria False.
Uma boa ferramenta, inclusive utilizada no projeto desenvolvido foi o unittest,
incluído na biblioteca padrão do Python.
Vale ressaltar que todos os testes criados para o projeto foram testes unitários.
Eles ajudaram a garantir o bom funcionamento dos métodos implementados e também
auxiliam em eventuais refatorações que venham a ser necessárias, garantindo que
alterações, grandes ou pequenas, mantenham as funcionalidades esperadas inicialmente.
3.3.2 – Teste de Integração
Testes de integração são os testes que verificam relacionamentos entre módulos
da aplicação e módulos externos, como bibliotecas, APIs, banco de dados, servidores.
Muitas vezes trechos de códigos estão corretos, porém serviços estão fora do ar,
ou alteram alguma regra de negócio e então os testes de integração entram em ação para
indicar esses tipos de erros e auxiliar o desenvolvedor a melhorar o tratamento para
quando estes serviços ficarem indisponíveis por um tempo.
3.3.3 – Teste de Interface de Usuário
31
Testes de interface são testes que simulam as ações do usuário, como o uso do
mouse e do teclado em ações no portal de fato.
Este tipo de teste é muito importante para garantir a usabilidade, acessibilidade e
portabilidade da aplicação, pois ela simulará ações e fluxos que um usuário comum
pode fazer, e espera respostas dos navegadores de acordo com as ações realizadas.
Uma das ferramentas mais comuns para testes de interface de usuário é o
Selenium [30], que envia comandos para o navegador para interagir com certas páginas
de um sistema.
3.3.4 – Teste de Aceitação
Testes de aceitação, também conhecidos como testes funcionais, são testes de
correção e validação. São idealmente especificados por clientes ou usuários finais do
sistema para a verificação e validação de algum modulo funciona conforme o
especificado.
Estes testes não só identificam erros de programação, como também erros de
interpretação dos requisitos do sistema.
3.3.5 – Teste de Desempenho
Testes de desempenhos nada mais são do que testes que executam certos trechos
do sistema e armazenam os tempos de duração obtidos.
Obviamente os resultados obtidos dependem de hardware, rede e coisas do tipo,
porém os seus resultados servem como parâmetro para indicar possíveis gargalos na
aplicação, se feitos corretamente, ou seja, todo o sistema testado com o mesmo
hardware e condições, a fim de obter resultados dentro da mesma escala de tempo.
3.3.6 – Teste de Carga
Testes de carga são fundamentais para grandes aplicações de grandes empresas.
É impensável um projeto como o Facebook, Twitter, ou um portal do tamanho da
globo.com não realizar testes de carga para entenderem como o seu produto vai reagir
com grande volume de acesso. Diferente da maioria dos testes automatizados, os testes
de carga exigem um tempo para serem executados, e não podem rodar a cada alteração
de código, pois o seu conceito é analisar o sistema sobre um grande estresse, o que
requer um certo tempo.
32
Basicamente testes de carga exercita o sistema sob condições de uso intenso.
Múltiplos acessos simultâneos em uma página, múltiplos acessos simultâneos em
diversas rotas, logins, consultas. É importantíssimo a compreensão de como os
servidores vão reagir a todos os cenários possíveis. Uso de CPU, cache, memória.
Após a coleta de dados, os desenvolvedores precisam interpretar os dados
coletados e aplicar melhorias aos sistemas. Seja evitar o uso de loopings em alguns
trechos de código, como melhorar a consulta a um banco de dados, ou, até mesmo,
aumentar a capacidade computacional dos servidores, em caso que a aplicação já é
otimizada o suficiente.
3.3.7 – Teste de Longevidade
Testes de longevidade tem como objetivo principal encontrar erros que não são
visíveis no dia a dia, e só podem ser notados conforme o sistema é usado. Os principais
problemas que testes de longevidade podem detectar são problemas relacionado ao
cache, replicação, serviços agendados, como por exemplo matérias a serem publicadas,
postagens em blogs, e, o principal, vazamento de memória, conhecido como Memory
Leak.
Memory Leak é um problema bastante comum em diversas aplicações que
trabalham com destrutores, como o C++, ou a criação de objetos que nunca se apagam e
ficar guardados em memória por mal implementação. Eventualmente, o problema pode
ser mínimo a curto prazo, mas a longo prazo ser fatal ao sistema como um todo.
3.3.8 – Testes de Segurança
Testes de seguranças são extremamente cruciais para aplicações de grande porte.
Estes testes verificam aspectos de confiabilidade, integridade, autenticação, permissões
e qualquer software pode ser vulnerável a múltiplos destes aspectos.
Existem algumas ferramentas especializadas para testes de seguranças que
simulam ataques comuns. Além disso é possível realizar testes unitários que simulam
entradas de dados fora de padrões, assim como injeção de scripts maliciosos pela
entrada de um sistema.
33
Capítulo 4
Automação do processo de
provisionamento
Os processos de subida de códigos para produção tendem a ser bastante
traumáticos em diversas aplicações, se não realizados de forma correta. Primeiramente,
em vários projetos, esse procedimento só ocorre ao seu término, e uma série de erros de
configurações e scripts ainda podem existir, atrasando ainda mais a entrega final do
software em questão.
Para evitar estes tipos de problemas existem recursos que podem simular um
ambiente de um servidor e antecipar uma série de problemas ao desenvolvedor. Uma
das principais ferramentas para a criação de máquinas virtuais é o Vagrant [31], que
falaremos ao longo do capítulo de forma mais aprofundada.
Além disso, ao longo do capítulo citaremos ferramentas utilizadas para
automatizar o provisionamento da aplicação, assim como as tecnologias utilizadas para
tratar as requisições do servidor.
4.1 – Nginx e Gunicorn
O Nginx [32] é um servidor HTTP e proxy reverso que é amplamente utilizado
no mundo. Em condições de igualdade, tem desempenho melhor do que o Apache pois
não precisa criar novos processos ou threads para cada requisição, como o Apache.
Também consume menos memória das máquinas.
O Gunicorn [33], ou Green Unicorn, é um servidor web Python, que é bastante
usado com aplicações Django, e também foi utilizado neste projeto.
Basicamente, o Nginx é responsável por cuidar das requisições de imagens e
estáticos no geral, como por exemplo Javascripts e CSS. E as requisições que precisam
ser geradas dinamicamente, como as páginas que precisam de códigos para serem
executadas e entregues são gerenciadas pelo Gunicorn.
Juntos, o Nginx e o Gunicorn, configurados de maneira correta [34 e 35], são
capazes de gerenciar as requisições e fazer tratamentos de cache, algo que a aplicação
34
Django em si não deve atuar. As requisições feitas via HTTP são recebidas pelo
Gunicorn e pelo Nginx, porém este só trata requisições que não forem dinâmicas, como
citado anteriormente. As requisições dinâmicas são resolvidas pelo Gunicorn com a
aplicação e então entregues ao Nginx que encaminha a resposta ao cliente.
4.2 – Fabric, Chef-Solo e Vagrant
O Fabric é uma biblioteca do Python que é utilizada para criar e executar
comandos locais. Com essa biblioteca é possível gerar um código capaz de instalar
pacotes, rodar comandos dentro de servidores e é usado com foco na automatização de
provisionamento de máquinas. De forma geral, é uma ferramenta que pode criar script
em Python para utilizar comandos via protocolo SSH.
A princípio, o Fabric é completo o suficiente para realizar boa parte da
automação de um processo de provisionamento, ou até o processo como um todo, mas
exigindo bastante conhecimento do desenvolvedor e, possivelmente, muitas linhas de
código.
Porém, ao longo do desenvolvimento do projeto descobriu-se uma ferramenta
denominada Chef-Solo [36]. De uma forma geral, o conceito que o Chef trás é de um
repositório, que possui uma arquitetura bem simples. Basicamente, a ferramenta
trabalha com uma noção de cookbooks, que são scripts escritos em Ruby [37], que são
auto suficientes para instalar algum pacote em um processo de subida de código. Cada
cookbook possui um arquivo com variáveis que podem ser editadas, para alterar certas
configurações, como a versão do MySQL que se deseja instalar, por exemplo.
Com todos os cookbooks que a aplicação necessita bastam algumas linhas de
comando, que foram criadas via Fabric, para que o Chef-Solo consiga iniciar a
instalação dos pacotes e gerir boa parte dos custos de um processo de provisionamento
automatizado (ver figura 4.1).
Entretanto, utilizar o Fabric e Chef-Solo direto em produção seria bastante
custoso. Ao longo da produção de um script de automatização de código muitos erros
são gerados e colocar esses erros em produção não é a melhor solução. Para criar um
ambiente semelhante ao de produção, utilizamos o Vagrant. O Chef-Solo é facilmente
configurável por meio do Vagrant e com isso é possível criar um ambiente de testes
para a checagem do script de automação.
35
Com o script criado, validado na máquina virtual e o projeto funcionando de
forma perfeita em um ambiente interno, sem acesso ao mundo real, então era possível
realizar a subida de código para produção. O comando fabric criado para executar o
primeiro deploy foi "fab prod deploy:setup=True". O fabric entende, com esse
comando, que é preciso realizar o script de deploy, com a variável setup com valor
True, que diz para o script que é a primeira execução do deploy, portanto é necessário
fazer a configuração completa do ambiente. E ainda vemos a flag "prod" que indica que
estamos subindo o código para o ambiente de produção. A outra flag criada para o
projeto foi "dev" que subia o código para o Vagrant.
Figura 4.1 – Script via Fabric para execução do Chef-solo
O deploy com setup True realizava o download do Ruby e algumas
dependências e então realizava o download do chef. Após isso eram criadas algumas
pastas do projeto, ajustando os permissionamentos de escrita e leitura. Logo a seguir são
feitos os uploads dos arquivos locais para a máquina de produção e, a partir disso, é
executado o chef-solo. Ao término da execução do chef-solo, todas as dependências,
como Nginx, Gunicorn, MySQL e Python eram instaladas. Os bancos então eram
criados, o usuário administrador inicial era criado no banco, os arquivos de
configuração do Nginx e Gunicorn eram rodados e as dependências do Python eram
instaladas. Por fim, os bancos eram preenchidos com as tabelas e colunas necessárias,
os arquivos estáticos eram gerados e os serviços eram reiniciados.
Com isso, após um comando, todo o processo de deploy havia sido feito. A
aplicação já pode ser acessada e o usuário administrador pode entrar no projeto e iniciar
a criação dos outros usuários, criar disciplinas e fazer qualquer ação que necessitar.
Caso o comando executado fosse "fab prod deploy", o script do Fabric
entenderia que não é o primeiro deploy e só alguns passos são realizados. Obviamente,
o upload dos arquivos, a instalação das dependências do Python, pois podem ter novas
36
dependências, a criação de novas tabelas e colunas para o projeto, a geração de novos
arquivos estáticos e a reinicialização dos serviços.
37
Capítulo 5
Conclusões
Reservar um bom tempo para pesquisar ferramentas e tecnologias para
desenvolver uma aplicação web é fundamental. No caso específico deste trabalho, onde
o principal objetivo era desenvolver um portal web para os alunos dos cursos de
extensão, é fundamental garantir que a experiência dos usuários, como por exemplo
garantir uma acessibilidade multi telas, seja posta em primeiro lugar e que as
ferramentas e técnicas corretas sejam utilizadas para garantir o sucesso da aplicação.
Além disso, é importante ressaltar o cuidado na escolha de um excelente banco
de dados para a demanda do projeto, assim como o trabalho de modelagem de dados,
que permitiu a criação de um software facilmente escalável e de fácil manutenção.
Este projeto utilizou testes unitários para garantir uma melhor qualidade do
software produzido, porém foram realizados uma série de estudos aprofundados sobre a
teoria de testes automatizados como um todo, com o intuito de informar o leitor a
importância de entender os tipos de testes existentes, assim como os melhores cenários
para a implementação de cada um deles.
Por fim, viu-se que a automação do provisionamento, assim como a busca por
tecnologias para o mesmo, traz grandes benefícios para qualquer tipo de projeto, não
apenas para este projeto desenvolvido. Tornar a tarefa de manter uma integração quase
que continua entre ambiente local e ambiente de produção, com apenas um comando
separando os dois ambientes, e, somado a isso, a garantia de possuir uma boa cobertura
de testes do projeto, gera uma segurança muito grande aos desenvolvedores de um
sistema e se provou ser um dos grandes acertos deste projeto.
Vale ressaltar que nem todos os objetivos iniciais conseguiram ser cumpridos.
Futuramente, seria fundamental buscar uma solução para a integração da aplicação
Witty ao sistema desenvolvido neste projeto, ou, caso se entenda necessário, tornar a
aplicação Witty uma aplicação web, que aí sim, seria facilmente integrável ao portal
criado, assim como a qualquer outro portal.
Dentro do escopo de sugestões, poderíamos sugerir um trabalho inteiro com
base na teoria dos testes automatizados, explicando e exemplificando todos os tipos de
38
testes e ferramentas disponíveis de forma bastante profunda e prática. Com isso futuros
engenheiros poderiam possuir uma literatura bem embasada e fundamentada sobre o
assunto que é de vital importância para qualquer profissional que queira trabalhar na
área da computação. Além disso um trabalho inteiro aprofundado na área de qualidade
de software também seria válido.
Por fim, uma possível evolução do projeto com técnicas de integração contínua,
deploy contínuo e a criação de novas funcionalidades no projeto em si, podem ser
sugeridas como trabalhos a serem realizados no futuro.
39
Bibliografia
[1] “The Web framework for perfectionists with deadlines” -
https://www.djangoproject.com/, 2014, (Acesso em 07 Setembro 2014).
[2] “Fabric Documentation” - http://www.fabfile.org, 2014, (Acesso em 26 Agosto
2014).
[3] “About the chef-repo - Chef Docs” - https://docs.chef.io/chef_repo.html, 2014,
(Acesso em 11 Outubro 2014).
[4] “Python 2.7.9 documentation” - https://docs.python.org/2.7/, 2014, (Acesso em 26
Agosto 2014).
[5] “MySQL 5.5 Reference Manual” -
http://dev.mysql.com/doc/refman/5.5/en/index.html, 2014, (Acesso em 20 Setembro
2014).
[6] “JavaScript reference” - https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference, 2014, (Acesso em 28 Agosto 2014).
[7] “jQuery API Documentation” - http://api.jquery.com/, 2014, (Acesso em 29 Agosto
2014).
[8] GABBRIELLI, Maurizio, MARTINI, Simone, “Programming Languages:
Principles and Paradigms (Undergraduate Topics in Computer Science)”. Springer,
2nd ed, 2010.
[9] MEYER, Bertrand, “Object-Oriented Software Construction”. Prentice Hal,l 2nd
ed, 1997.
[10] COAD, Peter, YOURDON, Edward, “Object Oriented Analysis”. Prentice Hall
PTR, 2nd ed, 1990.
[11] LUTZ, Mark. “Learning Python”. O'Reilly Media, 4th ed, 2009.
[12] GAMMA, Erich, HELM, Richard, JOHNSON, Ralph, VLISSIDES, John, “Design
Patterns: Elements of Reusable Object-Oriented Sofware”. Addison-Wesley
Professional, 1994.
40
[13] HOLOVATY, Adrian, KAPLAN-MOSS, Jacob, “The Definitive Guide to Django:
Web Development Done Right (Expert's Voice in Web Development)”. Apress, 2nd
ed, 2009.
[14] “SQLite Documentation” - https://sqlite.org/docs.html, 2014, (Acesso em 20
Setembro 2014).
[15] “PostgreSQL: Documentation” - http://www.postgresql.org/docs/, 2014, (Acesso
em 20 Setembro 2014).
[16] “The MongoDB 3.0 Manual” - http://docs.mongodb.org/manual/, 2014, (Acesso
em 20 Setembro 2014).
[17] “Redis” - http://redis.io/documentation, 2014, (Acesso em 20 Setembro 2014).
[18] “SQLite vs MySQL vs PostGreSQL: A Comparison of Relational Database
Managent Systems” - https://www.digitalocean.com/community/tutorials/sqlite-vs-
mysql-vs-postgresql-a-comparison-of-relational-database-management-systems,
2014, (Acesso em 20 Setembro 2014).
[19] “Banco de dados MySQL e PostgreSQL” -
http://www.infowester.com/postgremysql.php, 2014, (Acesso em 20 Setembro
2014).
[20] “Responsive Web Design A list apart article” -
http://alistapart.com/article/responsive-web-design, 2014, (Acesso em 13 Setembro
2014).
[21] “Foundation Docs” - http://foundation.zurb.com/docs/, 2014, (Acesso em 26
Agosto 2014).
[22] “Welcome to django-bootstrap3’s documentation” - http://django-
bootstrap3.readthedocs.org/en/latest/, 2014, (Acesso em 29 Agosto 2014).
[23] “WineHQ - Documentation” - https://www.winehq.org/documentation, 2014,
(Acesso em 10 Janeiro 2015).
[24] BERNARDO, P. C., KON, F., “A Importância dos Testes Automatizados”,
Controle ágil, rápido e confiável de qualidade, pp. 54–57, 2008.
[25] ROCHA, A. R. C. da, MALDONADO, J. C., WEBER, K. C. “Qualidade de
software - Teoria e prática”, Prentice Hall, São Paulo, 2001.
41
[26] “The home of Scrum” - https://www.scrum.org/, 2014, (Acesso em 20 Setembro
2014).
[27] “Extreme Programming: A Gentle Introduction” -
http://www.extremeprogramming.org/, 2014, (Acesso em 20 Setembro 2014).
[28] “A Brief Introduction to Kanban” - https://www.atlassian.com/agile/kanban, 2014,
(Acesso em 20 Setembro 2014).
[29] BERNARDO, P. C., Padrões de testes automatizados. M.Sc. dissertation,
Universidade de São Paulo, Junho 2011.
[30] “Selenium Documentation” - http://www.seleniumhq.org/docs/, 2014, (Acesso em
19 Setembro 2014).
[31] “Vagrant Documentation” - https://docs.vagrantup.com/v2/, 2014, (Acesso em 17
Novembro 2014).
[32] “nginx documentation” - http://nginx.org/en/docs/, 2014, (Acesso em 17 Novembro
2014).
[33] “Gunicorn - WSGI server 19.3.0 documentation” -
http://docs.gunicorn.org/en/19.3/, 2014, (Acesso em 17 Novembro 2014).
[34] “Setting up Django with Nginx, Gunicorn, virtualenv, supervisor and PostgreSQL -
Michał Karzyński” - http://michal.karzynski.pl/blog/2013/06/09/django-nginx-
gunicorn-virtualenv-supervisor/ , 2014, (Acesso em 17 Novembro 2014).
[35] “Minimal Nginx and Gunicorn configuration for Django projects - Agiliq Blog |
Django web app development” - http://agiliq.com/blog/2013/08/minimal-nginx-and-
gunicorn-configuration-for-djang/ , 2014, (Acesso em 19 Novembro 2014).
[36] “How to Understand the Chef Configuration Environment on a VPS” -
https://www.digitalocean.com/community/tutorials/how-to-understand-the-chef-
configuration-environment-on-a-vps, 2014, (Acesso em 10 Outubro 2014).
[37] “Documentação” - https://www.ruby-lang.org/pt/documentation/, 2014, (Acesso
em 11 Outubro 2014).