UNIVERSIDADE FEDERAL DE RORAIMA

CENTRO DE CIÊNCIA E TECNOLOGIA

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO

LILIANE DE MATOS SOARES

PROTÓTIPO DE UM REPOSITÓRIO DIGITAL DE APOIO À PESQUISA USANDO

XP EM SOFTWARE COMO SERVIÇO

Boa Vista, RR
2017
 LILIANE DE MATOS SOARES

PROTÓTIPO DE UM REPOSITÓRIO DIGITAL DE APOIO À PESQUISA USANDO

XP EM SOFTWARE COMO SERVIÇO

Projeto apresentado ao Curso de Bacharelado

em Ciência da Computação do Departamento
de Ciência da Computação da Universidade
Federal de Roraima.

Orientadora: Profº. Msc. Delfa Mercedes

Huatuco Zuasnábar.

Boa Vista, RR
2017
 LILIANE DE MATOS SOARES

PROTÓTPIO DE UM REPOSITÓRIO DIGITAL DE APOIO À PESQUISA USANDO

XP EM SOFTWARE COMO SERVIÇO

Projeto apresentado ao Curso de Bacharelado

em Ciência da Computação do Departamento
de Ciência da Computação da Universidade
Federal de Roraima. Área de concentração:
Engenharia de software. Defendido em 31 de
julho de 2017 e avaliada pela seguinte banca
examinadora:

______________________________________
Profa. MSc. Delfa Mercedes Huatuco Zuasnábar
Orientadora / Curso de Ciência da Computação – UFRR

______________________________________
Profº. MSc. Miguel Raymundo Flores Santibanez
Curso de Ciência da Computação - UFRR

______________________________________
Profº. MSc. Acauan Cardoso Ribeiro
Curso de Ciência da Computação - UFRR
 AGRADECIMENTOS

Agradeço primeiramente a Deus, pela vida e pela oportunidade.

Agradeço imensamente a minha mãe, que com todo amor, exemplo de vida e força,
mostrou-me o caminho para chegar até aqui, e sem o qual nada disso seria possível. Dedico à
minha família a concretização desse sonho, aos meus irmãos que sempre estiveram me
apoiando na longa trajetória da graduação.

Agradeço também à minha sabia orientadora que se dedicou ao meu acompanhamento

e com sua sapiência pode instruir-me.

Por fim, agradeço aos meus amigos, que na simplicidade da luz de nossa amizade me
trouxeram felizes momentos e lembranças de uma época de estudos que com muito carinho ei
de lembrar.
Algumas pessoas acham que foco
significa dizer sim para a coisa em que
você vai se focar. Mas não é nada disso.
Significa dizer não às centenas de outras
boas ideias que existem.
(Steve Jobs)
 RESUMO

Com o avanço da Internet e da Computação em Nuvem, o paradigma de desenvolvimento de

software também mudou, existe uma tendência em migrar as aplicações ou desenvolver as
mesmas no ambiente em nuvem, onde não há necessidade de instalar programas localmente,
tudo pode ser acessado pelo navegador na Internet, essa é a característica de Software como
Serviço. Os métodos ágeis também têm sido muito discutidos e utilizados pelos seus
resultados no desenvolvimento de software. Neste sentido, o presente trabalho objetivou
aplicar os métodos ágeis XP (Extreme Programming) e BDD (Behavior Driven
Development - Desenvolvimento Guiado por Comportamento) para o desenvolvimento de um
repositório bibliográfico digital com o objetivo de apoiar a pesquisa acadêmica, para
funcionar como serviço acessado pela Internet. O alcance que o software como serviço tem é
bastante superior ao software tradicional, pois é rapidamente disponibilizado para milhões de
usuários, fazendo com que sua evolução também seja maior. Podemos destacar que o melhor
benefício do software como serviço seja a melhoria continua. Pois não existe uma versão
final, sempre é possível melhorar.

Palavras-chaves: Computação em Nuvem, Software como Serviço, XP, BDD.

 ABSTRACT

With the advancement of the Internet and Cloud Computing, the paradigm of software
development has also changed, there is a tendency to migrate applications or develop them in
the cloud environment where there is no need to install programs locally, everything can be
accessed by the Internet browser, this is the Software as a Service feature. Agile methods have
also been much discussed and used for their results in software development. In this sense, the
present work aimed to apply the agile XP (Extreme Programming) and BDD (Behavior
Driven Development) methods for the development of a digital bibliographic repository with
the objective of supporting academic research, to function as a service accessed by the
Internet. The reach that the software as a service has is far superior to traditional software,
since it is quickly available to millions of users, making its evolution also greater. We can
highlight that the best benefit of software as a service is continuous improvement. Because
there is no final version, it is always possible to improve.

Keywords: Cloud computing, Software as a Service, XP, BDD.

 LISTA DE SIGLAS

BDD Behavior Driven Development

CN Computação em Nuvem
C3 Chrysler Comprehensive Compensation
CPU Central Processing Unit
IA Inteligência Artificial
IaaS Infrastructure as a Service
PaaS Platform as a Service
RUP Rational Unified Process
SaaS Software as a Service
TI Tecnologia da Informação
UML Unified Modelling Language
XP Extreme Programming
 LISTA DE FIGURAS

Figura 1 - Camadas de arquitetura da computação em nuvem. ................................................ 18

Figura 2 - Lista dos mais importantes provedores em cada área IaaS ...................................... 19
Figura 3 - Lista dos mais importantes provedores em cada área PaaS. .................................... 20
Figura 4 - Lista dos mais importantes provedores em cada área SaaS. .................................... 20
Figura 5 - Ciclo de vida do Modelo Cascata ............................................................................ 26
Figura 6 - Ciclo de vida do RUP .............................................................................................. 27
Figura 7 - Estrutura básica de um projeto em Cucumber. ...................................................... 37
Figura 8 - Arquitetura da aplicação .......................................................................................... 42
Figura 9 - Extreme Cloud Programming. ................................................................................. 46
Figura 10 - Funcionalidade para cadastrar um usuário............................................................. 48
Figura 11 – Erro ao tentar acessar a aplicação. ........................................................................ 51
Figura 12 – Teste de cadastro finalizado. ................................................................................. 53
Figura 13 - Funcionalidade para um usuário fazer login na página. ........................................ 53
Figura 14 – Passo em verde foi testado em outra funcionalidade. ........................................... 55
Figura 15 - Teste para login finalizado ..................................................................................... 56
Figura 16 - Funcionalidade para adicionar um arquivo ............................................................ 56
Figura 17 - Teste para inserir arquivo finalizado. .................................................................... 60
Figura 18 - Funcionalidade para pesquisar arquivos na página ............................................... 60
Figura 19 - Teste para pesquisar arquivo finalizado................................................................. 62
Figura 20 - Funcionalidade para a criação de uma pasta .......................................................... 63
Figura 21 - Teste para criar pasta finalizado. ........................................................................... 66
Figura 22 - Funcionalidade para compartilhar uma pasta ........................................................ 66
Figura 23 - Cenário para compartilhar pastas finalizado .......................................................... 69
Figura 24 - Tela de login. ......................................................................................................... 70
Figura 25 - Tela de cadastro. .................................................................................................... 70
Figura 26 - Página principal – Artigos públicos. ...................................................................... 71
Figura 27- Página principal – Artigos privados. ...................................................................... 71
Figura 28 - Inserindo artigos. ................................................................................................... 72
Figura 29 - Criando nova pasta................................................................................................. 72
Figura 30 - Exibição das pastas. ............................................................................................... 73
Figura 31 - Ambiente de trabalho do Cloud9. .......................................................................... 74
Figura 32 - Ambiente do projeto no Cloud9. ........................................................................... 74
Figura 33 - Detalhes de ambiente de trabalho no Cloud9. ....................................................... 75
 LISTA DE TABELAS

Tabela 1 - Vantagens do uso do SaaS para provedores ..........................................................23

Tabela 2 - Os Benefícios do SaaS para o cliente ....................................................................23
Tabela 3 - Etapas de desenvolvimento do RUP .....................................................................27
Tabela 4 - Valores dos métodos ágeis e dos métodos tradicionais .........................................28
Tabela 5 - Valores do XP .......................................................................................................31
Tabela 6 - Algumas práticas do XP ........................................................................................31
Tabela 7 - Tipos de bibliotecas ...............................................................................................44
 SUMÁRIO

1 INTRODUÇÃO ...................................................................................................... 14
1.1 MOTIVAÇÃO ......................................................................................................... 14
1.2 OBJETIVOS ............................................................................................................ 15
1.2.1 Objetivo Geral ........................................................................................................ 15
1.2.2 Objetivos Específicos ............................................................................................. 15
1.3 ORGANIZAÇÃO DO DOCUMENTO ................................................................... 15
2 FUNDAMENTOS TEÓRICOS ............................................................................ 16
2.1 COMPUTAÇÃO EM NUVEM ............................................................................... 16
2.1.1 Modelos de serviços em nuvem ............................................................................. 18
2.1.2 Modelos de implantação em nuvem ..................................................................... 24
2.2 ENGENHARIA DE SOFTWARE........................................................................... 25
2.2.1 Métodos Tradicionais ............................................................................................ 25
2.2.2 Métodos Ágeis ......................................................................................................... 28
2.2.3 Extreme Programming (XP) ................................................................................. 30
2.2.4 Requisitos ................................................................................................................ 33
2.2.5 Testes ....................................................................................................................... 34
2.2.6 Behavior-Driven Development (BDD) ................................................................. 35
2.2.7 Interface .................................................................................................................. 38
2.3 RUBY E RUBY ON RAILS .................................................................................... 38
3 TRABALHOS CORRELATOS ........................................................................... 41
3.1 ISSUES IN ADOPTING AGILE DEVELOPMENT PRINCIPLES FOR
MOBILE CLOUD COMPUTING APPLICATIONS ............................................. 41
3.2 BIBLIOTECAS NA NUVEM: O USO DA COMPUTAÇÃO EM
NUVEM EM BILIOTECAS.................................................................................... 42
3.3 IMPACT OF WEB 2.0 AND CLOUD COMPUTING PLATFORM ON
SOFTWARE ENGINEERING ................................................................................ 45
4 PROTÓTIPO DE UM REPOSITÓRIO DIGITAL DE APOIO À
PESQUISA USANDO XP EM SOFTWARE COMO SERVIÇO ..................... 47
4.1 APLICAÇÃO DO XP .............................................................................................. 47
4.2 REQUISITOS E TESTES DE ACEITAÇÃO ......................................................... 48
4.3 INTERFACE DE USUÁRIO .................................................................................. 69
4.4 CLOUD9 .................................................................................................................. 73
5 CONCLUSÃO ........................................................................................................ 76
5.1 CONSIDERAÇÕES FINAIS ................................................................................... 76
5.2 TRABALHOS FUTUROS ...................................................................................... 77
REFERÊNCIAS ..................................................................................................................... 79
 14

1 INTRODUÇÃO

1.1 MOTIVAÇÃO

A Tecnologia da Informação (TI) sempre foi considerada um ponto sensível nas

organizações, tanto em relação ao custo quanto em gestão. Porém, desde as décadas passadas
tem experimentado uma mudança dramática onde fatores como a comoditização do hardware,
software de código aberto, virtualização, globalização da força de trabalho, processos de TI
ágeis deram apoio ao desenvolvimento de novas tecnologias e modelos de negócios
(GORELIK, 2013).
A Computação em Nuvem (CN) tem sido um dos maiores avanços na história da
computação, com a capacidade de oferecer economia, facilidade de uso e maior flexibilidade
no controle de como os recursos são usados, tem potencial para transformar grande parte da
TI (MILIAN, 2014).
O Software como Serviço (Software as a Service – SaaS) é parte da computação em
nuvem e um dos seus modelos de serviço. O SaaS é um software implantado como um
serviço hospedado e acessado pela Internet e o consumidor usa os aplicativos do provedor em
execução na nuvem. Ele separa a posse e propriedade do software do seu uso. Os aplicativos
podem ser acessados a partir de qualquer dispositivo através de uma interface de usuário
(JAKONEN, 2011). Isso explica o crescimento acelerado de aplicações SaaS, e faz até que
produtos tradicionais ofereçam suas versões de software como serviço.
A facilidade em oferecer atualizações frequentes no SaaS, dado que existe apenas uma
única cópia de software, faz com que seja necessário um processo de desenvolvimento que
reaja efetivamente à natureza rápida desse tipo de aplicação. Para isso, temos o ciclo de vida
Ágil, que segundo Fox e Patterson (2015) se alinha perfeitamente a essas características.
Dentre os métodos ágeis, temos o XP (Extreme Programming), que segundo Beck e
Andres (2004) incentiva iterações curtas de modo que tenha versões sempre em
funcionamento, a escrita de testes antes de escrever o código a ser testado, e ainda revisões de
código com frequência através da programação em pares.
Nesse sentido, a realização deste trabalho visa aplicar os mais recentes métodos,
técnicas e ferramentas da Engenharia de Software para o desenvolvimento de Software como
Serviço. Dessa forma, aplicaremos os métodos ágeis XP e BDD (Behavior-Driven
Development), através das ferramentas Cucumber e Capybara, para implementar na
plataforma de desenvolvimento Cloud9, usando o framework Ruby on Rails, um repositório
 15

bibliográfico digital que funcionará como um serviço. O repositório visa agregar as diversas
bibliografias utilizadas por pesquisadores de forma organizada e centralizada.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Aplicar e analisar os métodos XP e BDD para o desenvolvimento de um repositório

bibliográfico digital como serviço.

1.2.2 Objetivos Específicos

Para alcançar o objetivo geral, os seguintes objetivos específicos devem ser

executados:

1. Pesquisar o estado da arte sobre os Métodos Ágeis, com foco nos métodos XP e
BDD;
2. Pesquisar o estado da arte sobre Computação em Nuvem, com foco em Software
como Serviço;
3. Automatizar os requisitos e testes de aceitação usando a ferramenta Cucumber;
4. Desenvolver um protótipo de repositório bibliográfico digital para apoio à pesquisa;

1.3 ORGANIZAÇÃO DO DOCUMENTO

No primeiro capítulo foram apresentados a motivação e os objetivos para o

desenvolvimento do trabalho. O segundo capítulo traz a fundamentação teórica para a
contextualização do leitor. O terceiro capítulo apresenta os trabalhos desenvolvidos por outros
pesquisadores que se relacionam a esta pesquisa. O quarto capítulo expõe a proposta de
desenvolvimento do trabalho e ideias que serão relevantes para o emprego dos métodos XP e
BDD na construção do protótipo que funcionará como serviço. O quinto capítulo trata da
conclusão obtida com os resultados. A seguir é apresentado o capítulo com referencial
teórico.
 16

2 FUNDAMENTOS TEÓRICOS

Neste capítulo abordaremos sobre a fundamentação teórica deste trabalho que inclui os
tópicos de computação em nuvem, seus modelos de serviço e implantação; sobre a engenharia
de software e suas metodologias, tradicional e ágil, especificando o método XP e os métodos
para teste BDD.

2.1 COMPUTAÇÃO EM NUVEM

Cogo (2013) relata que a primeira definição associada à computação em nuvem é a de

computação como utilidade, ou seja, ela passou ser cobrada como um serviço, assim como
água e luz o são, e não mais como um produto comprado em sua totalidade, sendo assim, o
usuário passaria a pagar somente aquilo que utilizasse.
Apesar do termo computação em nuvem ou Cloud Computing ser atual, o conceito já
existe desde a década de 60, onde o cientista norte-americano John McCarthy definiu que, se
os computadores, da forma como ele pensava, se tornassem os computadores do futuro, então
a computação poderia ser organizada como um serviço público, assim como é a telefonia. E
cada assinante pagaria apenas pelos recursos que ele realmente utilizasse e teria acesso a
todos os recursos oferecidos pelas linguagens de programação de um grande sistema. Alguns
assinantes conseguiriam oferecer serviços a outros assinantes. A computação com um serviço
público poderia ser base de uma nova e importante indústria (CARISSIMI, 2015).
Mesmo com a popularidade da ideia transmitida, o conceito não teve a oportunidade
de prosperar, porque as tecnologias facilitadoras necessárias eram incapazes de sustentar tal
modelo de computação. Então, no final de 1990 o desenvolvimento de tecnologias de
informática atingiu os níveis adequados de comercialização, dando o renascimento para a
ideia de McCarthy na forma de provedores de serviços de aplicativos e computação em
nuvem (CHURAKOVA; MIKHRAMOVA, 2010). A partir daí ela começa a revitalizar e
emergir na área da tecnologia.
Computação em nuvem se refere tanto a aplicações entregues como serviço através da
Internet, como ao hardware e aos sistemas de software nos centros de dados que fornecem
esses serviços (ARMBRUST et al, 2010). Ela revolucionou a indústria de TI (Tecnologia da
Informação) ao oferecer como um serviço grandes quantidades de recursos computacionais
(ALKMIN, CORDEIRO, 2014).
Em termos de pesquisa na área de Ciência da Computação a nuvem não é classificada
como um novo paradigma. O que houve, na verdade, foi a evolução e a convergência de
 17

pesquisas realizadas nas diversas áreas da computação, como a computação utilitária, clusters
e grids, etc, tornando-a no que é hoje. O sucesso que obteve em aplicações comerciais de
grande escala são indicadores do seu potencial nas aplicações científicas de alto desempenho
(ALKMIN, CORDEIRO, 2014).
Um dos grandes motivos do avanço da computação em nuvem foi a virtualização. Em
computação, virtualização é um termo genérico, que se refere à abstração dos recursos do
computador, mascarando as características físicas deles de forma que outros sistemas,
aplicações ou usuários finais possam interagir com tais recursos (MARTINS, 2010). Ela
melhora a utilização de recursos e eficiência energética - ajudando a reduzir substancialmente
a sobrecarga de manutenção do servidor e proporcionando rápida recuperação de desastres e
alta disponibilidade (GORELIK, 2013).
Além dos motivos anteriormente citados, a virtualização tem sido muito importante
para a computação em nuvem porque isola software de hardware e assim fornece um
mecanismo para redistribuir rapidamente aplicações em servidores com base nas demandas
computacionais (GORELIK, 2013).
O funcionamento da computação em nuvem segue um modelo de negócio onde o
usuário paga apenas pelo que consome de recursos e o provedor do serviço mantém uma
infraestrutura física, amortiza os custos de manutenção e investimentos compartilhando e
alugando seus recursos a diferentes usuários (CARISSIMI, 2015). Provedores como a
Amazon e a Microsoft permitem que as empresas evitem grandes investimentos em
infraestrutura e adquiram novos recursos de computação de forma dinâmica, conforme o
necessário. Este modelo é particularmente viável para pequenas empresas e star-tups1, que
muitas vezes não tem condições de gastar grandes somas de dinheiro no início de sua jornada
de negócios (GORELIK, 2013).
Na prática, ela é um modelo de negócio baseado no conceito de elasticidade. A
elasticidade é a capacidade de alocar recursos conforme a demanda. Se durante a execução de
uma aplicação for atingido um pico de utilização, provocando gargalos ou a degradação de
desempenho, o cliente pode solicitar mais máquinas virtuais para auxiliar o processamento
durante esse pico de demanda. Após a normalização da situação, essas máquinas virtuais
podem ser liberadas (CARISSIMI, 2015). Dessa maneira, cada cliente paga apenas pela
utilização efetiva dos recursos.

1
Startup é uma empresa de base tecnológica, com modelo de negócio repetível e escalável, que possui elementos
de inovação...(Associação Brasileira de Startups, 2017).
 18

Porém existem barreiras para a adoção da mesma. A segurança dos dados é, de longe,
a mais desafiadora. A segurança dos dados é um requisito essencial para as empresas.
Portanto, elas se sentem confiantes quando armazenam dados internamente porque têm total
controle sobre eles. Embora não haja garantia de que os dados são melhor protegidos
internamente comparando com a nuvem pública. Na verdade, há uma possibilidade de que os
dados podem estar ainda mais seguros na nuvem pública, porque os provedores de nuvem
pública podem colocar o mais elevado nível de especialização em segurança de dados em
comparação com os seus clientes (GORELIK, 2013).

2.1.1 Modelos de serviços em nuvem

Ao falar em computação em nuvem podemos pensar em camadas, ao invés de

diferentes funcionalidades. Esse pensamento dá um caráter mais arquitetural e de integração
entre os níveis, como mostra a Figura 1. Essas camadas são:
1. Infraestrutura como serviço (IaaS);
2. Plataforma com serviço (PaaS);
3. Software como serviço (SaaS).

Figura 1 - Camadas de arquitetura da computação em nuvem.

Fonte: MERIAT (2015).

O modelo IaaS consiste em oferecer ao consumidor processamento, armazenamento,

redes e outros recursos computacionais fundamentais para a implantação e execução de
 19

software arbitrário, incluindo sistemas operacionais e aplicativos, onde o consumidor não irá
gerenciar ou controlar essa infraestrutura, apenas ter o controle sobre sistemas operacionais,
armazenamento e aplicativos implantados. Além disso, o consumidor pode ser capaz de
selecionar os componentes de rede, por exemplo, hospedar firewalls e balanceadores de carga
(JAKONEN, 2011).

Figura 2 - Lista dos mais importantes provedores em cada área IaaS

Fonte: Adaptado de Gorelik (2013).

No modelo PaaS, o consumidor tem a capacidade de implantar para a infraestrutura da

nuvem aplicações criadas para o cliente usando linguagens e ferramentas (por exemplo, .NET,
Java, Python) suportadas pelo fornecedor. O consumidor não gerencia ou controla a
infraestrutura subjacente da nuvem, rede, servidores, sistemas operacionais, ou
armazenamento. No entanto o consumidor tem o controle sobre as aplicações implantadas e
possivelmente ao ambiente de configuração onde a aplicação está hospedada (JAKONEN,
2011).
 20

Figura 3 - Lista dos mais importantes provedores em cada área PaaS.

Fonte: Adaptado de Gorelik (2013).

Gorelik (2013) define Software como Serviço como um modelo de prestação de

serviços em nuvem que oferece uma assinatura de software on-line e sob demanda. Tal como
acontece com outros modelos de prestação de serviços em nuvem, o SaaS oferece às empresas
a oportunidade de reduzir os custos internos de suporte de TI e transferir a responsabilidade
de manutenção para o provedor de SaaS.

Figura 4 - Lista dos mais importantes provedores em cada área SaaS.

Fonte: Adaptado de Gorelik (2013).

Na produção tradicional de software o lançamento de novas versões provoca

necessariamente um impacto negativo nos parceiros de negócio, nos responsáveis de TI e
muitas vezes nos próprios clientes. Isso não ocorre no SaaS, pois sua essência resolve o
problema e liberta todo trabalho de distribuição e instalação dos produtos localmente nos
clientes. O SaaS está continuamente em desenvolvimento, numa lógica chamada de “eternos
 21

Beta”, sem nunca precisar chegar em uma versão terminada para entrar em produção (PINHO,
2009).
Pinho (2009) explica que o SaaS é um modelo baseado em aplicações Multi-tenant,
onde uma única instância da aplicação serve vários clientes do sistema. Porém, existem
variantes nos quais o software fica instalado na máquina do cliente e a informação é
sincronizada entre o cliente e os serviços alojados remotamente.
A hospedagem multi-tenant e a automação de serviços permite que os fornecedores de
SaaS mantenham os custos baixos. Dependendo do provedor de SaaS e do tipo de aplicação,
algumas aplicações personalizadas são disponíveis frequentemente, mas esta é tipicamente
mais limitada do que com as soluções de computação em nuvem, PaaS e IaaS (GORELIK,
2013).
Na computação em nuvem, a ideia fundamental é reutilizar diferentes tipos de serviços
baseados na Internet. Em SaaS, o software em si é alvo de reutilização e é implantado para os
consumidores de serviços através da Internet. Normalmente, relacionamentos um-para-muitos
são usados em serviços de entrega em SaaS. Por exemplo, o Google Maps é um serviço que
fornece um conjunto de operações que utiliza informações compartilhadas em um mapa, e o
serviço pode ser usado por vários clientes (JAKONEN, 2011).
Segundo Cheun (2009) o SaaS apresenta seis recursos principais:

• Reusabilidade: em SaaS, o software é objeto de reutilização e é implantado

para os consumidores do serviço através da Internet;
• Dados gerenciados pelo provedor: o provedor de serviço é responsável pela
instalação e gestão de dados do serviço no seu próprio servidor, assim levaria a
uma redução da utilização dos serviços;
• Serviço personalizado: significa que os consumidores do serviço podem
altera-lo com base em suas necessidades individuais. Esta é uma característica
que permite que um prestador de serviços atenda as diferentes necessidades de
cada cliente.
• Disponibilidade: os clientes são capazes de acessar serviços de SaaS a partir
de um navegador web através da Internet, não tendo nenhuma posse sobre o
software que está implementado e em execução no servidor do fornecedor de
serviços. Consequentemente, muitos fornecedores de SaaS centram sua atenção
em alcançar a maior disponibilidade possível dos serviços.
 22

• Escalabilidade: em engenharia de software recursos de escalabilidade

habilitam o software a manipular uma porção crescente de trabalho ou de ser
estendido facilmente. Um prestador de serviços é responsável por
redimensionando os recursos com base em pedidos do cliente, sem notificá-lo
dos detalhes.
• Custo: As despesas para SaaS são estimadas com base na utilização de
serviços, tais como o número de chamadas de serviço ou a duração da
utilização do serviço. Isso é diferente de modelo de negócio tradicional, em
que as despesas são estimadas com base na propriedade.

Segundo Churakova e Mikhramova (2010), uma das questões importantes a considerar

quanto à possibilidade de oferecer a aplicação sob a forma de um serviço em vez do software
tradicional local é que é necessário um tipo de infraestrutura, a fim de entregar com sucesso o
software para os clientes. Para tanto, três considerações fundamentais têm de ser levadas em
conta pelo fornecedor do software durante o processo de configuração da infraestrutura:

• Visto o fato de que a entrega do serviço é realizada através de uma rede, a

primeira atividade principal é a prestação de conectividade contínua entre o
prestador, o software e o cliente.
• Em segundo lugar, o provedor de software deve garantir a continuidade dos
negócios através da criação de infraestrutura de rede, servidor e
armazenamento necessário.
• Finalmente, o fornecedor SaaS é responsável pela garantia da segurança
durante o armazenamento de dados e prestação de serviços, o que implica que
medidas como backup, recuperação de desastres e políticas de autenticação
apropriados são realizadas.

As características tecnológicas do SaaS são: aumento do uso de conexão de rede,

aumento do uso de navegadores como interface e aumento do uso de processamento do lado
do servidor. O modo de entrega no SaaS é bastante diferenciado dos modelos anteriores de
negócio de software e o usuário final tem acesso local independente das capacidades do
software, enquanto que os fornecedores têm total controle sobre os aplicativos que residem
em seu datacenter (LUOMA, 2013).
Na tabela 1 a seguir estão reunidas as principais vantagens que o SaaS proporciona
para os provedores.
 23

Tabela 1 - Vantagens do uso do SaaS para provedores

Vantagens do uso do SaaS para Provedores

SaaS reduz os custos para os provedores, uma vez que é o único a lidar com as
1 necessidades de todos os clientes a partir de sua localização, incluindo
atualização e personalização de sistemas.
SaaS é completamente gerenciado por provedores; portanto, eles podem
2
atualizar e corrigir o sistema sem visitar pessoalmente os sites dos clientes.
SaaS ajuda os provedores a agilizar a atualização do software para melhorar a
sua competitividade no mercado. Devido ao fato do SaaS ser oferecido aos
clientes através de uma plataforma baseada na Web, os provedores podem
3 atualizar constantemente uma nova versão. Portanto, eles podem oferecer uma
nova versão para os clientes mais rápido que o software tradicional, que
precisam enviar uma nova versão em um disco de aplicação a todos os clientes
para atualizações.
Fonte: Adaptado de (RUCHUTRAKOOL; ZHU, 2009).

Já na tabela 2 estão reunidos os principais benefícios que ele traz para o cliente:

Tabela 2 - Os Benefícios do SaaS para o cliente

Benefícios do SaaS para o cliente

SaaS auxilia o cliente a economizar nos custos iniciais típicos, que inclui servidor,
rede, licença, software de banco de dados e os custos de sistemas operacionais
1
porque os prestadores do serviço são responsáveis por pagar os custos ao invés
disso.
SaaS reduz os riscos decorrentes da aquisição de software. Como o fato de que os
clientes não precisam implantar uma grande infraestrutura de TI local, portanto,
2 quando estão desapontados com os resultados do serviço, eles têm a opção de
abandonar este serviço e buscar um novo serviço sem ter de se preocupar com a
dispendiosa infraestrutura de TI.
Clientes de SaaS podem facilmente expandir o número de usuários, porque SaaS é
3 entregue em uma arquitetura multi-tenant. Essa arquitetura entrega mais
escalabilidade para o cliente, ou seja, o acesso de clientes pode ser dimensionado
 24

para o número de usuários de imediato, porque seus processos não afetam outros
processos quando expande.
Clientes de SaaS adquirem facilmente recursos personalizados. Uma das vantagens
4
do software orientado a serviço é a facilidade de ajuste.
SaaS ajuda os clientes a se concentrarem mais em suas competências principais de
5 negócio, porque eles não têm preocupação com qualquer infraestrutura de TI, ela é
de responsabilidade dos prestadores de serviços de SaaS.
SaaS ajuda os clientes a se concentrarem mais em suas competências principais de
6 negócio, porque eles não têm preocupação com qualquer infraestrutura de TI, ela é
de responsabilidade dos prestadores de serviços de SaaS.
SaaS auxilia os clientes para acessar os dados do aplicativo e de atualização,
independentemente de onde estiverem. Eles só precisam de Internet e um navegador,
a fim de fazer logon e usar o aplicativo. Além disso, esses recursos permitem que
7
equipes trabalhem a partir de suas localizações, como de suas casas. Portanto, não
precisa ir a sede a fim de acessar o sistema. Isso permite que trabalhe em qualquer
lugar e em qualquer hora.
Fonte: Adaptado de RUCHUTRAKOOL; ZHU (2009).

2.1.2 Modelos de implantação em nuvem

Além dos modelos de serviço existem os modelos de implantação ou estruturais de

computação em nuvem que fornecem a mesma para os usuários. São eles (COGO, 2013):

1. Público: As aplicações, armazenamento e outros recursos são

disponibilizados para o público pelo fornecedor. Os serviços, pagos ou
gratuitos são iguais para todos os usuários, todos tem uma instância dele
através da Internet. As características é que o usuário não tem domínio
sobre os dados, nem sobre a possível personalização. As empresas que
oferecem esse serviço geralmente possuem grandes capacidades de
armazenamento e processamento.
2. Privado: Desenvolvido exclusivamente para uma organização, o modelo
privado pode ser gerido pela própria empresa ou terceiros, internamente ou
não. Os serviços são usados internamente pela empresa.
3. Híbrido: É a composição entre nuvens públicas e privadas, agrupadas para
oferecerem os benefícios de ambos os modelos. A característica desse
 25

modelo é que na híbrida a infraestrutura do serviço roda na nuvem privada,

e a outra parte na pública, dando mais segurança e controle ao cliente.

Alguns autores especificam mais modelos, porém para o entendimento deste trabalho
essas definições são suficientes.

2.2 ENGENHARIA DE SOFTWARE

Desenvolver software não é uma atividade trivial, pois o mesmo se trata de algo
abstrato e intangível. Existem muitos problemas que podem ocorrer no processo de criação do
software, principalmente no que se refere ao desenvolvimento profissional, como alto custo,
alta complexidade, desproporção entre o que o cliente desejava e o produto entregue, etc.
Diante desses problemas e acreditando-se que o processo utilizado era uma das causas,
a engenharia de software surgiu com o objetivo de enfatizar o quanto era preciso que o
desenvolvimento de software fosse baseado nos princípios teóricos e nas disciplinas práticas
tradicionalmente conhecidos dos diversos ramos da engenharia (SATO, 2007).
Nas seções a seguir será apresentado como a engenharia de software evoluiu ao longo
dos anos com os métodos tradicionais e os mais recentes, métodos ágeis.

2.2.1 Métodos Tradicionais

Os métodos tradicionais de desenvolvimento têm como característica a precedência da

especificação de todos os requisitos antes de qualquer coisa. Eles surgiram da necessidade de
se organizar o processo de desenvolvimento visto que os programadores adotavam as próprias
técnicas e abordagens. Cada produto era feito sob medida para um propósito particular. Dessa
forma a manutenção, confiabilidade e a produtividade se tornavam um grande desafio de
garantir. Surgiu, então, um novo paradigma centrado no produto e na combinação de
componentes padronizados, seguindo uma linha de produção industrial (UCHÔA, 2013).
Uchôa (2013) explica que esses modelos tradicionais, orientados a planos e a
processos, foram desenvolvidos com o propósito de criar projetos grandes, caros, de
complexidade elevada e de alto risco. Nessas situações, havia grande dependência de
contratos e rigorosos procedimentos de controle, pois as condições de execução não
favoreciam a confiança entre clientes e desenvolvedores.
O processo de desenvolvimento em cascata foi um dos primeiros e surgiu na década de
70, Winston Royce é comumente citado como o primeiro autor a descrevê-lo. Era composto
 26

por fases distintas, do levantamento de requisitos até a implantação, ou seja, todas elas eram
encadeadas. Na década seguinte surge o modelo em espiral que serviu como base para os
atuais processos iterativos e incrementais como o Rational Unified Process, o RUP, e também
os Métodos Ágeis (SATO, 2007).
A figura 5 mostra os estágios do modelo em cascata e fica evidente o porquê dele ser
chamado dessa maneira.

Figura 5 - Ciclo de vida do Modelo Cascata

Fonte: Universo Projeto (2016).

O RUP foi desenvolvido com o intuito de complementar a UML (do inglês Unified
Modelling Language), método para modelagem de software. Adota uma abordagem iterativa
no desenvolvimento de sistemas. As práticas enfatizadas pelo RUP são (UCHOA, 2013):

1. Desenvolver de forma iterativa;

2. Gerenciar os requisitos;
3. Usar arquiteturas baseadas em componentes;
4. Representar visualmente;
5. Verificar continuamente a qualidade;
6. Controlar alterações.

O método do RUP é um ciclo iterativo de seis etapas, conforme é apresentado na

figura abaixo:
 27

Figura 6 - Ciclo de vida do RUP

Fonte: Adaptado de Uchôa (2013).

O método também possui etapas, que são especificadas na tabela abaixo (FOX;
PATTERSON, 2015):

Tabela 3 - Etapas de desenvolvimento do RUP

Etapas de Desenvolvimento do RUP

Etapa onde é definido o negócio do software,
1. Iniciação delimitado o escopo para definir o cronograma e
orçamento.
Nessa etapa ocorre o trabalho com as partes
interessadas para identificar os casos de uso, projetar
2. Elaboração
uma arquitetura de software, estabelecer o plano de
desenvolvimento e construir um protótipo inicial.
3. Construção Etapa da codificação e testes do produto.
É onde o produto passa do desenvolvimento para o
4. Transição ambiente real, incluindo teste de aceitação e
treinamento do usuário.
Fonte: (FOX; PATTERSON, 2015)
 28

Uchôa (2013) esclarece que o RUP pode ser usado tanto no desenvolvimento
tradicional quanto em projetos ágeis. Porém, ele não é considerado ágil, pois foi
originalmente criado para cobrir processos inteiros de desenvolvimento de software, com
orientações extensas que não são típicas de um ambiente ágil.

2.2.2 Métodos Ágeis

Em Somerville (2011) vemos como nos dias de hoje as empresas operam em um

ambiente global, onde as mudanças ocorrem de forma rápida. Em sistemas de
desenvolvimento de software que pretendem especificar completamente todos os requisitos,
projetando, construindo e testando, em seguida, não estão adaptados para o desenvolvimento
rápido de software. Esses processos convencionais, como cascata ou baseado em
especificações, não estão preparados para mudanças que podem acontecer, como nos
requisitos, no projeto, ou implementação, caso o projeto precise ser refeito ou retestado. Isso
torna o processo mais demorado, o que gera atrasos na entrega do software.
De acordo com Sommerville (2011) os métodos ágeis surgiram na década de 90 como
uma proposta dos desenvolvedores insatisfeitos com as abordagens tradicionais e pesadas da
engenharia de software. Eles se reuniram e formaram uma aliança, a Aliança Ágil, e lançaram
em fevereiro de 2001 o manifesto ágil, onde propunham um ciclo de vida de software mais
leve (FOX; PATTERSON, 2015).
Na tabela seguir é apresentado os quatro valores definidos no manifesto ágil, onde os
itens à esquerda agregam mais valor que os itens à direita, que representam as metodologias
tradicionais:

Tabela 4 - Valores dos métodos ágeis e dos métodos tradicionais

Valores: Métodos Ágeis vs Métodos Tradicionais

Métodos Ágeis
Indivíduos e interações
Software em funcionamento
Colaboração com o cliente
Responder a mudanças mais
Fonte: Adaptado de Beck et al (2001).
Métodos Tradicionais
Processos e ferramentas
Documentação abrangente
Negociação de contratos
Seguir um plano
 29

Para que entendesse o foco dos métodos ágeis foram disponibilizados 12 princípios
onde detalham a filosofia contida no manifesto e onde os métodos ágeis devem se adequar
(BECK et al, 2001):

1. A maior prioridade é satisfazer o cliente através da entrega contínua e

adiantada de software;
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente, dando aos
clientes vantagens competitivas;
3. Entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de tempo;
4. Equipes de negócio e desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto;
5. Construir projetos em torno de indivíduos motivados, dando o ambiente,
suporte necessário, confiando neles para fazer o trabalho;
6. O método mais eficiente e eficaz de transmitir informações para e entre uma
equipe de desenvolvimento é através de conversa face a face;
7. Software funcionando é a medida primária de progresso;
8. Os processos ágeis promovem desenvolvimento sustentável. Todos devem
manter um ritmo de desenvolvimento constante;
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade;
10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é
essencial;
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto
organizáveis;
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e
então refina e ajusta seu comportamento de acordo.

Fox e Patterson (2015) explicam que métodos ágeis são modelos de desenvolvimento
que incentivam a prática de abraçar as mudanças como um fato da vida, em que os
desenvolvedores devem aperfeiçoar continuamente um protótipo incompleto, mas em
funcionamento, com o feedeback do cliente em cada iteração, até que ele esteja feliz com o
resultado.
Segundo Sommerville (2011), métodos ágeis são bem-sucedidos em duas situações:
no desenvolvimento de um produto pequeno ou médio e no desenvolvimento de um sistema
 30

personalizado, em que o cliente participa ativamente, sem muitas regras e regulamentos que
afetem o software. No entanto, enfatiza que os princípios básicos dessa metodologia são,
muitas vezes, difíceis de concretizar para grandes sistemas, principalmente em sistemas
críticos, onde há a necessidade de proteção, segurança e análise de confiança, sendo que seu
uso exigiria grandes modificações nos métodos ágeis.
Sob os valores e princípios do manifesto ágil aparecem diversas abordagens mais
específicas, com diferentes ideias, comunidades e líderes, onde formam um grupo distinto,
porém seguindo os mesmos princípios (SATO, 2007).
Dentre os métodos ágeis podemos citar XP, Scrum, Família Crystal, Lean Software
Development, Feature Driven Development (FDD), Dynamic System Development Method
(DSDM), Behavior Driven Development (BDD) entre outras. O método utilizado neste
trabalho será o XP porque ela enfatiza a importância da criação de testes, além de ser uma das
mais conhecidas e usadas atualmente.

2.2.3 Extreme Programming (XP)

O Extreme Programming (XP) é um dos métodos ágeis que mais recebeu atenção na
virada do século. Seu objetivo é a excelência no desenvolvimento de software, visando o
baixo custo, poucos defeitos, alta produtividade e alto retorno de investimento (SATO, 2007).
Kent Beck é o criador do XP e um dos que lançaram o manifesto ágil. Beck foi
chamado para ajudar no projeto C3, ou Chrysler Comprehensive Compensation System, para a
empresa DaimlerCrysler, que após anos de fracassos ficou pronto em um ano, usando as
práticas que vieram a se tornar o XP (FAGUNDES, 2005).
Em sua segunda edição o XP segue um conjunto de valores, princípios e práticas para
serem adotados durante o processo de desenvolvimento. As práticas são as técnicas utilizadas
no dia-a-dia por membros da equipe de XP, que só fazem sentido no contexto da
programação; os valores são critérios mais amplos e universais usados para julgar uma
situação, eles dão razão às práticas, enquanto que as práticas colocam em evidência os
valores; os princípios funcionam como ferramentas para tradução dos valores em práticas
(SATO, 2007).
Os valores do XP expresso por Beck e Andres (2004) são explicitados na tabela
abaixo:
 31

Tabela 5 - Valores do XP

VALORES DO XP

Tem como objetivo a comunicação rápida e ao mesmo

1. Comunicação
tempo eficaz entre os membros da equipe e o cliente.

Esse objetivo expressa que o software precisa ser

2. Simplicidade
continuamente simplificado.

Todo problema deve ser evidenciado o mais rápido

3. Feedback possível tanto pela equipe quanto pelo cliente para que
possa ser corrigido.

A coragem torna-se extremamente valiosa quando usa a

4. Coragem combinação dos três valores anteriores. Precisa-se de
coragem para pedir ajuda,

Fonte: BECK; ANDRES (2004).

Em relação às práticas, Beck e Andres (2004) explicam que elas não se mantêm por si
só, o que faz elas funcionarem é a cooperação do seu conjunto. Algumas práticas são
especificadas na tabela a seguir:

Tabela 6 - Algumas práticas do XP

Prática Definição
Consiste na decisão do que deve ser feito e no que pode ser
Jogo do planejamento adiado, já que o XP se baseia em requisitos atuais e não em
requisitos futuros.
As entregas são feitas ao término de iteração, devendo ser
tão pequena quanto possível. O foco está no monitoramento
Entregas frequentes
do progresso do software tanto pelos clientes quanto pelos
programadores.
O planejamento no XP é feito com histórias escritas em
Histórias de usuário pequenos cartões, sem a utilização de termos técnicos, com
o intuito de guiar o desenvolvimento do software.
Projeto simples Manter o projeto mais simples possível o faz permanecer
 32

ágil e flexível, mas para isso é preciso uma revisão contínua.

Essa prática sugere que os testes sejam escritos antes do
Testes código. Traz como benefícios a ênfase no desenvolvimento,
confiança, ritmo e preocupação com acoplamento e coesão.
É a prática onde é possível simplificar o módulo atual sem
Refatoração perder nenhuma funcionalidade. Isso mantém o código
simples e manutenível.
Programação em A programação é feita em dupla, que trabalham em um
pares único computador.
O código do projeto pertence a todos os membros da equipe,
Propriedade coletiva
ou seja, todos assumem responsabilidade por todo o código.
O software em XP é produzido de forma iterativa e
Ciclo Semanal incremental. Essa prática sugere que uma equipe de XP deve
planejar o trabalho de cada iteração uma semana por vez.
O número de horas dedicado ao projeto deve ser realista,
não sendo recomendado fazer horas extras por períodos
Semana de 40 horas maiores que uma semana, pois o cansaço do excesso de
trabalho pode ocasionar no desenvolvimento de código com
erros que darão trabalho mais tarde.
Essa prática faz com que as pessoas que serão afetadas pelo
sistema façam parte da equipe. Os clientes devem entender
Cliente presente
as necessidades do negócio e conhecer os verdadeiros
usuários do sistema para poder escrever histórias, definir
prioridades, etc.
O repositório do código fonte é compartilhado por toda a
equipe. Qualquer um que observe uma oportunidade de
agregar valor a alguma parte do código deve fazê-lo. O time
Código compartilhado
todo se torna responsável pelo sistema inteiro. Dessa forma,
adquire-se uma visão ampla do sistema e isso facilita a
execução de refatorações.
Adaptado de FAGUNDES (2005) e SATO (2009).
 33

O XP faz uma seleção de práticas antigas levando os princípios óbvios do senso

comum para níveis extremos, por exemplo, se iterações curtas são boas, então, faça-as mais
curtas possíveis, prefira minutos, horas a dias, meses ou anos. Essas são as principais
características da metodologia XP.

2.2.4 Requisitos

Somerville (2011) define requisito de software como uma especificação do que deve
ser implementado. São descrições de como o sistema deve se comportar, os serviços que deve
oferecer e as restrições a seu funcionamento. Segundo Motta (2016) essa definição destaca a
importância de estabelecer, compreender e documentar os requisitos durante todo o processo
de desenvolvimento de software, e formam o processo denominado Engenharia de Requisitos.
O processo de Engenharia de Requisitos é iterativo, porque os requisitos mudam
regularmente durante o processo de desenvolvimento. Os requisitos muitas vezes têm de ser
refinados ou adicionados durante as próximas fases do processo de desenvolvimento. Muitas
organizações de desenvolvimento de software também estão enfrentando problemas na coleta
de requisitos adequados. Os requisitos insuficientes e exigências em mudança são as
principais razões pelas quais muitos produtos de tecnologia da informação não conseguem
entregar dentro de sua programação e orçamento limite. Os requisitos são a base tanto para o
desenvolvimento de software como para as atividades de gerenciamento de projetos (KOLLA;
BANKA, 2014).
Os requisitos podem ser uma declaração abstrata, em alto nível, de um serviço que o
sistema deve oferecer ou uma restrição, ou ainda, uma descrição detalhada e formal de uma
função que ele deve oferecer. Nessas duas definições usa-se o termo “requisitos de usuário”
para os requisitos abstratos de ato nível, e “requisitos de sistema” para a descrição detalhada
do que o sistema deve fazer (SOMMERVILLE, 2011).
Os requisitos são geralmente categorizados em funcionais e não-funcionais. Na forma
mais simples os requisitos funcionais são aqueles que definem o que o sistema ou componente
do sistema deve ser capaz de executar, enquanto que o não-funcional é usado para requisitos
que especificam como o sistema deve atuar em determinada maneira, ou seja, é um requisito
que descreve não o que o software vai fazer, mas como deve fazê-lo; esses requisitos são
geralmente descritos com termos que terminam com ‘ilidade’, como disponibilidade,
enquanto que outros não seguem esse padrão, como desempenho e facilidade de uso. Embora
os requisitos não-funcionais geralmente recebam menos atenção na concepção de muitos tipos
 34

de sistemas (por exemplo, em aplicativos de desktop) eles desempenham um papel importante

em determinados domínios; em particular, os sistemas embarcados em tempo real
(SAADATMAND, 2012).
Essas definições são uma visão tradicional de requisitos, já que para sistemas de
grande porte é necessário ter uma Engenharia de Requisitos claramente identificável antes de
se iniciar a implementação do sistema. Nos métodos ágeis, os requisitos são escritos, assim
como nos métodos tradicionais, mas diferentemente deste, os requisitos são continuamente
aprimorados para assegurar que o software desenvolvido esteja de acordo com a vontade dos
interessados. O levantamento de requisitos deve ocorrer o mais próximo possível dos clientes
(FOX; PATTERSON, 2015).
No XP os requisitos são as histórias de usuário, que são breve relatórios feitos por
usuários. Esse modelo de requisitos será mais aprofundado na seção 2.2.6 onde falamos sobre
o método BDD e na seção 5.2 onde mostramos os requisitos levantados para a aplicação.

2.2.5 Testes

A definição de qualidade de um produto é medida dependendo do quanto ele é

apropriado para o uso. Para o software, a qualidade representa atender os requisitos do cliente,
além da facilidade que o desenvolvedor tem para consertar os erros de programação e
melhora-lo. Existem dois termos que apresentam diferenças bem sutis para determinar a
qualidade do software: Verificação e Validação (FOX; PATTERSON, 2015).
A verificação tem como objetivo garantir que software implementa corretamente uma
função específica. Já a validação assegura que o software criado atende aos requisitos do
cliente (PRESSMAN, 2011).
Os testes tornam-se a principal abordagem para verificação e validação, porque quanto
mais cedo forem encontrados erros, mais barato é repará-los. Em geral, o processo de teste
envolve a mistura de testes manuais e automatizados. Nos testes manuais são executados
alguns dados de testes por um testador, que irá comparar os resultados obtidos com os
resultados esperados. Já os testes automatizados são codificados em um programa que é
executado toda vez que o sistema em desenvolvimento é executado (SOMMERVILLE, 2011).
Existem uma infinidade combinações de entrada, então os testes não podem ser
exaustivos. Uma forma de resolver isso é dividir os testes em diferentes etapas do
desenvolvimento. Segundo Fox e Patterson (2015) os testes podem ser:
 35

• Unitários, quando asseguram que um certo procedimento ou método faça o que

dele é esperado;
• De Módulo, que faz testes embarcando várias unidades de um mesmo módulo;
• De Integração, irá garantir que as interfaces entre as unidades tenham
pressupostos consistentes e se comuniquem corretamente. Esse nível não testa
a funcionalidade das unidades.
• No nível mais alto está o teste de sistema ou teste de aceitação, que verificam
se o programa integrado atende às suas especificações.

As aplicações Web tem características que bem distintas de outros tipos de aplicações.
Segundo Pressman (2011) existe uma urgência dos grupos interessados em obtê-la online,
fazendo com que atividades técnicas como os testes aconteçam mais tarde e tenham pouco
tempo no processo.
A procura de erros se torna um desafio porque esses sistemas e aplicações residem em
uma rede e interoperam com muitos sistemas operacionais diferentes, navegadores,
plataformas de hardware, etc. Por isso os testes para aplicações Web experimentam cada
dimensão de qualidade averiguando inicialmente.
Sommerville (2011) afirma que teve um aumento considerável nos últimos anos de
testes automatizados, porém estes só verificam se um programa faz aquilo a que é proposto e
não testam os sistemas que dependem de como as coisas estão, ou se a aplicação possui
efeitos colaterais indesejados.

2.2.6 Behavior-Driven Development (BDD)

O Behavior-Driven Development (BDD), ou Desenvolvimento Guiado por

Comportamento é um método de desenvolvimento ágil de software que surgiu originalmente
em 2003, criado por Dan North. Combina técnicas e princípios gerais do TDD (Teste-Driven
Development) com ideias vindas do DDD (Domain-Driven Design).
O ciclo de vida ágil foi criado para remediar vários problemas presentes em muitos
tipos de software, entre esses tipos de problemas nós podemos citar, por exemplo, quando o
software não é aquilo que o cliente esperava ou quando existem atrasos no processo e
ultrapassagem do orçamento original, etc. Por esses motivos, segundo Fox e Patterson (2015),
o BDD envolve trabalhar de maneira próxima e contínua com os stakeholders para
desenvolver requisitos e testes. Ele também envolve a manutenção de um protótipo funcional
 36

enquanto novos recursos são implantados para os stakeholders terem uma noção das próximas
funcionalidades a serem adicionadas e se o sistema é aquilo que eles estão querendo.
O BDD se refere a todo o comportamento, ou seja, tudo sobre o que um sistema deve
fazer. Todo comportamento está lá porque acrescenta concretamente um valor de negócio
para o sistema como um todo. Ele é impulsionado por valor de negócio, ou seja, pelo
benefício para o negócio que resulta uma vez que a aplicação está em produção (DUARTE;
FERNANDES, 2013). O BDD cria comportamentos testáveis e automatizados que gerem
valor de negócio para o cliente antes mesmo do código fonte e que evitem erros baseados em
comportamento, gerando um conjunto de testes de aceitção baseados nesses comportamentos
(RIBEIRO, 2012).
A prática faz questionamentos sobre o comportamento de uma aplicação antes e
durante o desenvolvimento. Dessa forma as partes interessadas estão menos inclinadas a
falhas de comunicação, os requisitos são continuamente aprimorados para ter certeza de que o
sistema esteja de acordo com o esperado por eles (FOX; PATTERSON, 2015). O objetivo dos
requisitos do BDD é, principalmente, construir a coisa certa. Logo, ao se concentrar no
comportamento da aplicação ao invés de se concentrar na sua implementação, fica mais fácil
reduzir mal-entendidos entre os stakeholders.
No BDD, os requisitos são chamados de histórias de usuários. Uma versão mais leve
dos requisitos e mais adequada aos métodos ágeis, que descrevem como se espera que a
aplicação seja usada. Elas ajudam os stakeholders a planejar e priorizar o desenvolvimento. O
BDD oferece uma estrutura para uma história, mas que não é obrigatória (FOX;
PATTERSON, 2015).
As histórias de usuário se referem a uma única funcionalidade com um ou mais
cenários que mostram diferentes maneiras de utilizá-la. As palavras-chave Funcionalidade e
Cenário identificam os respectivos componentes. Cada cenário é composto de sequências de
3 a 8 passos. Boloz (2014) fundamenta que os cenários por sua vez são escritos do ponto de
vista de um usuário. O esquema abaixo exemplifica o formato de um cenário:
Dado algum contexto inicial
Quando ocorre um evento
Então, descreve o resultado esperado.
E ou Mas
Essas palavras-chave ajudam os membros da equipe a decidir que tipo de
comportamento é necessário para ser implementado na sequência. Cada frase é um passo do
cenário e começa com sua própria palavra-chave. Os passos que começam com Dado
 37

geralmente estabelecem condições. Passos que começam com Quando geralmente representa
um usuário apertando um botão. Já os que começam com Então irão verificar se uma
condição é verdadeira. Resumindo, Dado é usado para identificar o estado atual, Quando
para identificar a ação e Então para identificar a consequência da ação. E e Mas são para
permitir versões mais complexas das palavras anteriores.
A ferramenta que será utilizada para a prática do BDD será o Cucumber, juntamente
com o Capybara, que irá simular as ações do usuário. Fox e Patterson (2015) descreve o
Cucumber como uma admirável ferramenta que transforma histórias de usuário, que clientes
podem facilmente entender, em testes de aceitação (verifica se o programa integrado atende as
especificações) que garantem que o cliente está satisfeito, e em testes de integração (garantem
que as interfaces entre as unidades tenham objetivos consistentes e se comuniquem
corretamente), que garantem que as interfaces entre os módulos seguem o mesmo conjunto de
hipóteses e se comunicaram corretamente. Essa ferramenta atua entre o cliente e o
desenvolvedor, já que as histórias de usuário são claras para o cliente, mas ao mesmo tempo
segue um padrão bem definido.
A figura 7 abaixo mostra um exemplo de uma funcionalidade feita no Cucumber:

Figura 7 - Estrutura básica de um projeto em Cucumber.

Fonte: PEREIRA (2015).

Não é obrigatório seguir essa estrutura, mas essa é uma forma comprovada para
trabalhar em diversos projetos, então uma boa história deve conter todos os elementos
descritos na Figura 7 acima, para os membros da equipe poderem ter um melhor entendimento
do que se pretende fazer.
 38

2.2.7 Interface

Na definição de Barbosa (2011), a interface é toda a parte do sistema em que o usuário

consegue manter contato físico (através do hardware e do software) ou contato conceitual, que
é a forma como ele interpreta aquilo que percebe durante o contato físico com os dispositivos
de entrada e saída. Essa interpretação possibilita a compreensão das respostas do sistema e o
planejamento dos próximos passos. A grande maioria dos usuários acredita que a interface
seja o sistema, visto que ela é o único meio de contato do usuário com a aplicação.
O contato físico é percebido e manipulado pelos usuários (teclados, mouse), ao passo
que, no contato conceitual o usuário, por exemplo, processa e interpreta as mensagens
enviadas pela aplicação ao monitor de vídeo (PEREIRA, 2011).
Ferreira, Nunes (2008), afirmam que a interface é o meio pela qual o usuário se
comunica com o sistema para realizar suas tarefas. Como exemplos de interfaces podem-se
citar as telas visíveis dos sites, as mensagens sonoras (como as dos sistemas de atendimento
em bancos), os visores e os teclados de celulares. Se bem projetada, uma grande ferramenta
para usuário; do contrário, porém, pode se transformar em fator decisivo para a rejeição dos
sistemas.
A interface do usuário é indiscutivelmente o elemento mais importante de um produto
ou sistema computacional. Se a interface for mal projetada, a capacidade de o usuário
aproveitar todo o poder computacional e conteúdo de informações de uma aplicação pode ser
seriamente afetada. Na realidade, uma interface fraca pode fazer com que uma aplicação, em
outros aspectos bem projetada e solidamente implementada, falhe (PRESSMAN, 2011).

2.3 RUBY E RUBY ON RAILS

O Ruby foi concebido em 1991 por Yukihiro Matsumoto, mundialmente conhecido

como Matz. Ela é uma linguagem de programação com suporte à orientação a objetos,
interpretada, multiparadigma, de tipagem forte e dinâmica. Também é reflexiva, permite que
o código inspecione a si mesmo em tempo de execução, e suporta metaprogramação, que
permite a geração e execução de código novo também em tempo de execução. A linguagem
suporta programação funcional, especialmente o uso de blocos, onde trechos de código
parametrizados chamados de expressões lambda carregam consigo seu escopo, fazendo com
que sejam fechamentos (FOX; PATTERSON, 2015).
 39

Como falado no parágrafo acima Ruby é uma linguagem orientada a objetos genuína,
ou seja, quando você escreve código orientado a objeto, você está normalmente modelando
conceitos do mundo real em seu código. Em Ruby, objetos são criados chamando um
construtor, que é um método especial associada a uma classe, o construtor padrão é chamado
new (MATSUMOTO, 2001).
Como Ruby possui bibliotecas ricas em funções, mas existem poucos mecanismos, ela
é considerada uma linguagem minimalista. Existem três características implícitas a esses
mecanismos (FOX; PATTERSON, 2015):

1. Tudo é um objeto. Ruby dá suporte aos tipos básicos habituais – inteiros,

números de ponto flutuante, cadeias de caracteres, vetores lineares e vetores
associativos ou tabelas de hash. Mas ao contrário do Java, Ruby é
dinamicamente tipada: o tipo de uma variável geralmente não é inferível até
o tempo de execução.
2. Toda operação é uma chamada a um método de algum objeto e devolve um
valor.
3. Toda programação é metaprogramação: o código é criado em tempo de
execução que define novos métodos, ou seja, classes ou métodos podem ser
adicionados ou modificados a qualquer momento, mesmo quando o programa
está em execução.

A sintaxe do Ruby é fortemente influenciada pela sintaxe da linguagem Eiffel. Isso

facilita a vida do programador porque a sintaxe é muito simples. Encoraja a escrever
programas mais legíveis de uma forma mais elegante e facilitando que outro programador
realize a manutenção de código posteriormente. Ela possui instruções nativas para multithread
(processo paralelo) que são independentes de plataforma e seu coletor de lixo
libera automaticamente toda a memória que foi utilizada durante a execução do programa
(OLIVEIRA et al, 2006).
O framework Ruby on Rails foi criado em 2004 por David Heinemeier Hansson. É
uma estrutura de aplicação web que inclui tudo que é preciso para criar aplicativos da web
com suporte a banco de dados de acordo com o padrão arquitetural MVC (Modelo-Visão-
Controlador ou Model-View-Controller).
No padrão MVC uma aplicação é formada por três tipos diferentes de código. Os
modelos controlam o estado da aplicação e seus dados. As visões são as interfaces gráficas
 40

para o usuário e abrange informações a respeito dos modelos que o usuário pode se relacionar
(DOURADO, 2009). Os controladores, por sua vez, são os mediadores da interação entre as
visões e os modelos: quando o usuário interage com uma visão (por exemplo, clicar em um
link na página), uma ação específica do controlador correspondente àquela atividade do
usuário é solicitada. Cada controlador está associado a um modelo e, no Rails, cada ação do
controlador é implementada por um método Ruby em particular daquele controlador. O
controlador pode pedir ao Modelo para recuperar ou modificar informações; dependendo do
resultado obtido, o controlador decide qual visão será apresentada a seguir ao usuário, e
repassa à visão todas as informações que podem ser necessárias (FOX; PATTERSON, 2015).
De modo geral, o funcionamento de aplicações que usam o padrão MVC funciona da
seguinte forma: um usuário pode submeter um formulário, clicar em links ou botões, etc.
Essas ações serão tratadas por alguma ação do controlador, que consultará os modelos para
obter as informações necessárias e gerar uma visão como resposta.
A razão do uso desta linguagem neste trabalho se deve ao fato de que a comunidade
Ruby já adotou a ciclo de vida ágil como parte do processo de desenvolvimento, conforme
explicam Fox e Patterson (2015) em seu livro “Construindo Software como Serviço”.
 41

3 TRABALHOS CORRELATOS

Neste capitulo serão apresentados alguns trabalhos relacionados que envolvem

computação em nuvem, software como serviço e métodos ágeis.

3.1 ISSUES IN ADOPTING AGILE DEVELOPMENT PRINCIPLES FOR MOBILE

CLOUD COMPUTING APPLICATIONS

Este artigo discute os problemas no desenvolvimento de aplicativos para a nuvem

móvel usando metodologias de desenvolvimento de software ágil.
Os autores relatam no artigo o desenvolvimento de uma estrutura de nuvem híbrida
chamada Sha-Mo-Cloud, aproveitando os serviços da nuvem pública para armazenar dados,
incluindo imagens e vídeos capturados em dispositivos móveis do usuário.
A pesquisa explora dois aspectos do desenvolvimento de aplicativos em nuvem móvel
(Almudarra; Qureshi, 2015):

1. Concepção e implementação de um ambiente de nuvem híbrido de

gerenciomento e compartilhamento de conteúdo de nuvem móvel, preservando
os requisitos de privacidade.
2. Estudar os vários aspectos do desenvolvimento de uma aplicação de nuvem
móvel usando a programação extrema como uma metodologia de
desenvolvimento ágil.

A Figura 8 mostra a arquitetura do Sha-Mo-Cloud, projetada em uma arquitetura de 3

camadas. A primeira camada fornece interface para o usuário, a segunda, implementa classes
para comunicação, banco de dados, gerenciamento de conteúdo, etc. E a terceira fornece
autenticação para os dados que são privados para o usuário.
 42

Figura 8 - Arquitetura da aplicação

Fonte: Adaptado de Almudarra e Qureshi (2015).

Como resultados é mostrado os problemas ocorridos no desenvolvimento, como as

atualizações frequentes nas bibliotecas móveis e na nuvem que fornecem novas
funcionalidades e exigem alterações a serem feitas no aplicativo no decorrer do
desenvolvimento. Outro problema é que existem poucas bibliotecas disponíveis para o
desenvolvimento em ambiente de nuvem móvel e muitas delas requerem modificação e
integração com o código existente.
O projeto e do software foi focado nos três níves da estrutura, preservando a segurança
e privacidade dos dados. Os autores destacam software foi comparado a projeto similares
para mostrar os ganhos e desafios no desenvolvimento e concluem que aplicativos de
computação móvel pode ser integrado com metodologias de desenvolvimento ágil que
reduzem o custo e o tempo e proveem melhoria da qualidade do software. E o ritmo acelerado
dos métodos ágeis é adequado para as mudanças frequentes de tecnologias móveis e em
nuvem.

3.2 BIBLIOTECAS NA NUVEM: O USO DA COMPUTAÇÃO EM NUVEM EM

BILIOTECAS

Neste trabalho Martins (2012) apresenta as alternativas que a computação em nuvem

pode oferecer às bibliotecas no que se refere à qualificação, modernização, preservação,
acessibilidade e atualização de seus acervos e ainda à redução de investimentos na
implantação, treinamento e manutenção dos sistemas de informática. Além de um cenário de
como o assunto se encontra na esfera brasileira.
 43

A autora faz um estudo por meio de uma pesquisa bibliográfica de análise qualitativa,
em que o problema da pesquisa consiste no rumo que as bibliotecas estão seguindo quanto ao
uso da computação em nuvem na disponibilização de seus acervos, e como a instituição se
beneficia com essa tecnologia.
A autora propõe como objetivo:

1. Investigar a computação em nuvem como uma solução consolidada no que diz

respeito aos modelos e arquiteturas.
2. Examinar as possibilidades de aplicação dos serviços em nuvem em bibliotecas se
existe motivos para o livro estar na nuvem, e quais soluções em nuvem existem para
bibliotecas. E também explorar o uso da Cloud Computing em bibliotecas, quais
existem na nuvem. Cita por exemplo, a biblioteca Municipal de Palo Alto na
Califórnia, Estados Unidos.
3. Investigar o cenário brasileiro em relação a computação em nuvem em bibliotecas,
onde apresenta uma perspectiva da mesma para o futuro do livro digital em
bibliotecas.

Apesar dos avanços tecnológicos preocuparem alguns especialistas, a autora enxerga

eles como forma de preservar e democratizar o acesso aos acervos, já que as obras podem se
apresentar em diversos formatos, como PDF, HTML, etc. O livro digital não será
desvinculado da biblioteca, pois, segundo a autora, fica evidente sua pertinência e o justifica.
Martins (2012) discute que a migração para a nuvem ainda é um processo decisivo
muito difícil e exige um bom planejamento que definirá as condições para um uso seguro da
instituição. A migração para a nuvem não deve ocorrer de forma repentina. O planejamento
inclui o estudo das necessidades da instituição, conhecer os serviços fornecidos no mercado,
assim como possibilidade de serviços gratuitos, assim como a garantia de privacidade e
segurança dos dados.
Martins (2012) explica que a computação em nuvem se apresenta como um modelo
consolidado, com modelos de serviço e de implantação bem definidos, que permitem a
criação de serviços conforme a demanda. A Cloud Computing acaba se moldando às
necessidades de qualquer instituição, isso faz com que a terceirização acabe sendo uma boa
opção para pequenas e grandes associações. Em relação aos riscos, ela ressalta que são os
mesmos como em qualquer outro serviço, e que os provedores/prestadores possuem equipes
que para garantir que a nuvem seja segura para seus clientes, a mesma com certeza apresenta
 44

mais benefícios que riscos. Mas, adverte para um bom planejamento para definir o fornecedor
e analisar os itens de segurança.
Existe um nono conceito de biblioteca, chamada biblioteca sem parede, que diferente
das convencionais facilitam a disseminação e o acesso em tempo real. Dentre os tipos de
bibliotecas temos: biblioteca eletrônica, biblioteca digital, biblioteca virtual, biblioteca híbrida
e futuramente a biblioteca na nuvem (MARTINS, 2012). A tabela 7 abaixo dá a definição de
cada uma delas:

Tabela 7 - Tipos de bibliotecas

BIBLIOTECAS SEM PAREDES

Ampla utilização de máquinas, principalmente microcomputadores,
Biblioteca eletrônica facilitando a construção de índices online, na busca de textos
completos e na recuperação e armazenagem de registros.
Diferencia-se por se construir de um acervo estritamente digital.
Biblioteca digital Dispõe de todos os recursos de uma biblioteca eletrônica, oferece
texto completo, vídeo, áudio, etc., sendo o acesso local e remoto.
A “ciberteca” conceituada como um tipo de biblioteca que, para
existir, depende da tecnologia da realidade virtual – sistemas
Biblioteca virtual
computadorizados por meio de redes – que criaria um ambiente com
salas, estantes, etc.
Agrega diferentes suportes tecnológicos, apresentando coleções
Biblioteca híbrida impressas, digitais e acessos via rede eletrônica. Seria a transição
das bibliotecas do impresso e do virtual
São acervos e aplicativos mantidos em datacenters terceirizados,
que não ocupam espaços nos terminais e servidores locais,
Biblioteca na nuvem
permitindo o aceso remoto das informações, fornecendo os serviços
de um sistema operacional interno, mas em ambiente virtual.
Fonte: Adaptado de (MARTINS, 2012).

O usuário hoje procura uma biblioteca onde possa ser atendido num ambiente virtual,
visualizar em seu equipamento eletrônico. Dessa forma as bibliotecas veem significativas
alterações em suas estruturas, como forma de armazenamento, por exemplo. Nisso a
computação em nuvem surge como uma promessa revolucionária na forma como os sistemas
 45

computacionais serão administrados e utilizados, dispersos geograficamente, etc. (MARTINS,

2012).
Como a instituição não tem o controle total de armazenamento, então existe certo
receio quanto ao serviço que envolve nuvem. A ressalva feita pela autora é que mudanças
sempre geram manifestações de medo e hoje vemos como os avanços das novas tecnologias
podem intervir na criação e ampliação das bibliotecas. Essa é a motivação para se discutir o
rumo das mesmas em tempos de Internet. Espera-se com isso promover um debate, visto que,
existe pouca discussão sobre isso no Brasil.
Como trabalhos futuros Martins (2012) sugere examinar o impacto da computação em
nuvem aliada aos e-books nas bibliotecas universitárias. Outra pesquisa seria como as
bibliotecas estão vendo as perspectivas da aplicação da cloud computing? O próximo trata-se
um estudo sobre a aplicação SaaS na redução de custos na operação e manutenção de serviços
em bibliotecas.

3.3 IMPACT OF WEB 2.0 AND CLOUD COMPUTING PLATFORM ON SOFTWARE

ENGINEERING

Neste artigo Guha (2010) analisa a forma como a computação em nuvem, tendo como
plano de fundo a web 2.0, vai impactar o processo de Engenharia de Software para o
desenvolvimento de software de qualidade. O autor faz os seguintes questionamentos: Como
o provedor de nuvem é uma entidade externa ou de terceiros, o quão difícil será a interação
com eles? Como separar os papéis de engenheiros de software e provedores de nuvem? O
artigo amplia o tradicional modelo ágil Extreme Programming (XP) e integra a interação com
o provedor de nuvem para facilitar a aceitação da computação em nuvem.
Guha (2010) explica que a economia de todos os países desenvolvidos depende de
software de qualidade, e o custo do software é maior que o do hardware. Como o
desenvolvimento de software envolve muitas partes, ele é inerentemente um processo
complexo, diante disso, a tendência é que o projeto falhe devido à falta de comunicação e
coordenação entre todas as partes envolvidas.
A tese principal do trabalho de Guha (2010) é que os modelos de processo de software
prevalentes devem envolver o provedor de nuvem em cada tomada de decisão no
desenvolvimento de ciclo de vida do software para tornar o projeto um sucesso. Então, propõe
uma versão estendida do Extreme Programming (XP), um modelo de processo ágil, para a
 46

plataforma de computação em nuvem, nomeando-o de Extreme Cloud Programming, como

mostra a figura 9.

Figura 9 - Extreme Cloud Programming.

Fonte: Guha (2010).

Concluindo seu trabalho Guha (2010) explica que a computação em nuvem é uma
mudança de paradigma sobre a forma tradicional de desenvolvimento de software, pois é
preciso interagir com um novo elemento chamado provedor de nuvem. Mesmo a quantidade
de trabalho para o desenvolvimento de software diminua, haverá a crescente exigência de
comunicação e coordenação com o provedor de nuvem que faz o projeto de desenvolvimento
de software mais complexo. Com isso os modelos prevalentes devem adicionar esse novo
modo de interação com o provedor, e separar os papeis de engenheiros de software e
provedores. Essa interação pode atenuar todos os desafios de desenvolvimento de software na
plataforma de computação em nuvem e torná-la mais vantajosa no que se refere à implantação
e desenvolvimento de software na nuvem.
 47

4 PROTÓTIPO DE UM REPOSITÓRIO DIGITAL DE APOIO À PESQUISA

USANDO XP EM SOFTWARE COMO SERVIÇO

Para aplicar os métodos e as ferramentas apresentadas nos capítulos anteriores foi

desenvolvida uma aplicação, que funcionará como um serviço na nuvem, através de uma IDE
chamada Cloud9 (Seção 4.4), que opera totalmente na web. A aplicação consiste em um
repositório bibliográfico onde cada pesquisador pode adicionar seus arquivos de forma
organizada, criando assim sua própria base bibliográfica, podendo compartilhar esses mesmos
arquivos ou não, com outros usuários do sistema.
O objetivo da aplicação é proporcionar ao usuário criar sua própria base de
bibliografias, semelhante as bases encontradas na web como, por exemplo, IEEE, google
acadêmico, etc.
A seguir apresentamos todos os detalhes referentes ao desenvolvimento da aplicação.

4.1 APLICAÇÃO DO XP

O processo de desenvolvimento seguiu algumas práticas recomendadas pelo Método

Ágil XP com algumas adequações.
As principais práticas adotadas desse método foram:

1. Histórias de usuário, que foram utilizadas para o levantamento dos requisitos

juntamente com os stakeholders. O processo de levantamento de requisitos é
aprofundado na seção 5.2;
2. Cliente presente, que estabelece a presença frequente do cliente no
desenvolvimento;
3. Jogo do planejamento, onde foram decididas as funcionalidades que seriam
implementadas e a prioridade entre elas;
4. Entregas frequentes, em que cada tarefa finalizada era entregue para mostrar o
progresso da aplicação. As entregas eram feitas a cada três semanas com
implementação incremental. Ao todo a aplicação levou cinco meses para ser
concluída, no período de dezembro de 2016 a abril de 2017;
5. Testes de aceitação automatizados, que auxiliam na implementação das
funcionalidades. O processo de testes também é aprofundado na seção 5.2;
 48

O método XP preza pela programação em pares, porém nesse trabalho apenas a autora
atuou na parte de desenvolvimento, por se tratar de um trabalho de conclusão de curso que é
feito por um único aluno.

4.2 REQUISITOS E TESTES DE ACEITAÇÃO

Nessa etapa do projeto contamos com três stakeholders, que foram a professora
orientadora deste projeto, Delfa Huatuco, o professor Miguel Santibañez e o graduando
Gleysomar Ribeiro. O graduando utilizou esta aplicação como parte do seu projeto de
conclusão de curso com o objetivo de otimizar os requisitos, dar prioridade entre eles e
reduzir seu custo.
Para o levantamento de requisitos foram utilizadas as histórias de usuário baseadas no
método BDD. E para transformar essas histórias em testes de aceitação utilizou-se nesse
trabalho a ferramenta Cucumber. No domínio do Cucumber, o termo Funcionalidade é usado
para definir uma história de usuário com um ou mais cenários que mostram diferentes
maneiras de utilizá-la.
Ficou definido entre os stakeholders que o usuário deveria se cadastrar para ter acesso
ao sistema, então foi criada uma história para mostrar esse processo, conforme apresenta a
Figura 10.

Figura 10 - Funcionalidade para cadastrar um usuário

Fonte: Elaborado pela autora (2017).

A Figura 10 acima especifica como a funcionalidade “Cadastrar” deve funcionar em

um cenário onde o usuário deseja fazer um cadastro. O texto entre Funcionalidade e Cenario é
a narrativa no formato de história de usuário. A linha “#language: pt” informa ao Cucumber
 49

que a especificação está em português. O comportamento da aplicação é especificado de fato

após o título do cenário. O texto é escrito de forma simples para a compreensão de todos os
stakeholders.
As especificações foram salvas em um arquivo com a extensão “.feature” na estrutura
de diretórios do Cucumber, conforme mostra a Listagem 01 abaixo:

Listagem 01: Estrutura de diretórios do Cucumber

Raiz_da_aplicacao
features/
cadastro.feature
step_definitions/
suport/

Antes de escrevermos o código da aplicação, por estarmos escrevendo os testes na

forma de especificações em linguagem natural, temos que primeiro dar um passo
intermediário, que é ensinar ao Cucumber como de fato executar os passos contidos no
cenário. Isso é feito traduzindo as frases em linguagem natural para comandos em linha de
programação. Então, quando a especificação é executada pela primeira vez, o Cucumber
traduz as especificações escritas em código na linguagem Ruby que precisamos, como na
Listagem 02.

Listagem 02: Resultado ao executar o Cucumber para a funcionalidade Cadastrar

$ cucumber features/cadastro.feature
Using the default profile...
# language: pt
Funcionalidade: Cadastrar
Para visitar a pagina
Como usuario
Quero poder me cadastrar

Cenario: Fazer cadastro # features/cadastro.feature:8

Dado que estou na pagina # features/cadastro.feature:9
Undefined step: "que estou na pagina" (Cucumber::Undefined)
features/cadastro.feature:9:in `Dado que estou na pagina'
Quando eu clicar em "Cadastrar" # features/cadastro.feature:10
Undefined step: "eu clicar em "Cadastrar"" (Cucumber::Undefined)
features/cadastro.feature:10:in `Quando eu clicar em "Cadastrar"'
E preencher os campos # features/cadastro.feature:11
Undefined step: "preencher os campos" (Cucumber::Undefined)
features/cadastro.feature:11:in `E preencher os campos'
 50

Então eu devo estar cadastrado na pagina # features/cadastro.feature:12

Undefined step: "eu devo estar cadastrado na pagina" (Cucumber::Undefined)
features/cadastro.feature:12:in `Então eu devo estar cadastrado na pagina'

1 scenario (1 undefined)
4 steps (4 undefined)
0m0.011s

You can implement step definitions for undefined steps with these snippets:

Dado(/^que estou na pagina$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^eu clicar em "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^preencher o formulario$/) do
pending # Write code here that turns the phrase above into concrete actions
end

Então(/^eu devo estar cadastrado na pagina$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Os últimos quatro blocos ressaltados na listagem são chamados de “step definitions”,

ou definições de passos, e foram copiados e colados em um arquivo com a extensão “.rb”, e
salvos dentro da pasta “step_definitions”, mostrada na Listagem 03.

Listagem 03: Estrutura de diretórios do Cucumber

$Raiz_da_aplicacao
features/
cadastro.feature
step_definitions/
cadastro.rb
suport/

A partir daí começamos a substituir as palavras “pending”, dentro de cada bloco, pelo
código que realmente faz o que a frase em linguagem natural está dizendo. Essa é a fase na
qual realizamos a automação dos passos. O Cucumber colore os passos de amarelo para
 51

mostrar que os passos ainda não foram implementados de verde para demonstrar que passou
no teste, e vermelho para erros. Para que cada passo fique verde é preciso escrever o código
da aplicação em si que faça ele passar. A partir daí o código da aplicação vai sendo escrito e o
teste sendo executado até que todos os passos fiquem verdes e o teste passe totalmente.
Para traduzir os passos em linguagem natural e implementa-los através de código
executável, utilizamos a ferramenta Capybara para simular as ações do usuário no sistema,
como clicar em links e botões, por exemplo. O Cucumber se adapta perfeitamente a essa
ferramenta, já que também foi implementada em Ruby.
A Figura 11 mostra o erro que ocorre quando se executa o Cucumber novamente. Esse
erro foi abordado no Capítulo 2, seção 2.2.5 falando sobre o método BDD. O método diz que
os testes devem ser feitos antes de qualquer codificação, desse modo o erro mostrado na
Figura 11 indica que não existe nenhuma aplicação para o Capybara visitar, então o próximo
passo é desenvolver o código que cria a aplicação, somente para fazer com que esse passo
fique verde.

Figura 11 – Erro ao tentar acessar a aplicação.

Fonte: Elaborado pela autora (2017).

O mesmo é feito para cada passo do cenário. Criamos o código que permite o usuário
se cadastrar baseado no passo seguinte. Na Listagem 05, temos a implementação dos passos
restantes e com Capybara é possível simular o usuário visitando a página e clicando no link
para se inscrever, logo em seguida preenchendo os campos do formulário e por fim
verificando se o usuário foi cadastrado com sucesso.

Listagem 4: Teste automatizado para realizar cadastro

# encoding: utf-8
# !/usr/bin/env ruby
 52

Dado(/^que estou na pagina$/) do

visit '/examples'
end

Quando(/^eu clicar em "([^"]*)"$/) do |link|

click_link(link)
end

Quando(/^preencher o formulario$/) do
fill_in 'Email', :with => "lily@hotmail.com"
fill_in 'user_password', :with => "123456"
fill_in 'user_password_confirmation', :with => "123456"
click_button 'Cadastrar'
end

Então(/^eu devo estar cadastrado na pagina$/) do

have_content('lily@hotmail.com')
end

Ao executar o Cucumber novamente os passos do cenário ficam verdes, indicando que

o teste passou, conforme a Listagem 05 e a Figura 12:

Listagem 05: Teste de autenticação finalizado

$ cucumber features/cadastro.feature
Using the default profile...
# language: pt
Funcionalidade: Autenticar
Para visitar a pagina
Como usuario
Quero poder me autenticar

Cenario: Fazer cadastro # features/cadastro.feature:8

Dado que estou na pagina # features/step_definitions/cadastro.rb:4
Quando eu clicar em "Cadastrar" # features/step_definitions/cadastro.rb:8
E preencher o formulario # features/step_definitions/cadastro.rb:12
Então eu devo estar cadastrado na pagina # features/step_definitions/cadastro.rb:19

1 scenario (1 passed)
3 steps (3 passed)
0m0.427s
 53

Figura 12 – Teste de cadastro finalizado.

Fonte: Elaborado pela autora (2017).

A próxima funcionalidade para o usuário fazer login no repositório está especificada

na Figura 13. O cenário do teste representa um usuário tentando fazer login, considerando que
o mesmo já se encontra cadastrado na página.

Figura 13 - Funcionalidade para um usuário fazer login na página.

Fonte: Elaborado pela autor (2017).

Executando o Cucumber, teremos as definições de passos que precisamos para

automatizar o próximo teste, como vemos na Listagem 06.

Listagem 06: Resultado ao executar o cucumber para a funcinanalidade Login

$ cucumber features/login.feature
Using the default profile...
# language: pt
Funcionalidade: Fazer login
Para visitar a pagina
Como usuario
 54

Quero fazer login

Cenario: Fazer login # features/login.feature:8

Dado que estou na pagina # features/step_definitions/cadastro.rb:4
Quando eu preencher os campos # features/login.feature:10
Undefined step: "eu preencher os campos" (Cucumber::Undefined)
features/login.feature:10:in `Quando eu preencher os campos'
Então eu devo estar logado na pagina # features/login.feature:11
Undefined step: "eu devo estar logado na pagina" (Cucumber::Undefined)
features/login.feature:11:in `Então eu devo estar logado na pagina'

1 scenario (1 undefined)
4 steps (2 undefined, 1 passed)
0m0.426s

You can implement step definitions for undefined steps with these snippets:

Quando(/^eu preencher os campos$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Então(/^eu devo estar logado na pagina$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Observa-se que o passo “Dado que estou na página” já se encontra verde (Figura 11).
Isso ocorre porque ele já foi testado anteriormente na funcionalidade de cadastro. No
Cucumber é possível escrever definições de passos que podem ser compartilhadas por todas
as funcionalidades, porque, por padrão ele vai carregar todos os arquivos que estiverem em
features/step_definitions toda vez que uma funcionalidade for executada, dessa forma, toda
vez que utilizamos o texto “Dado que estou na pagina”, o Cucumber não gera a definição de
passos porque ela já existe em outra funcionalidade.
 55

Figura 14 – Passo em verde foi testado em outra funcionalidade.

Fonte: Elaborado pela autora (2017).

A Listagem 07 mostra como os passos restantes foram implementados. A simulação

exibe o usuário preenchendo os campos e ao clicar em “Entrar” ele deve estar logado no
sistema.

Listagem 07: Teste automatizado para realizar login

# encoding: utf-8
# !/usr/bin/env ruby

Quando(/^eu preencher os campos$/) do

fill_in 'Email', :with => "lily@hotmail.com"
fill_in 'user_password', :with => "123456"
click_button 'Entrar'
end

Então(/^eu devo estar logado na pagina$/) do

have_content('lily@hotmail.com')
end

Quando executamos, o Cucumber exibe todos os passos em verde, o que significa que
o teste passou (Listagem 08 e Figura 15).

Listagem 08: Teste de login finalizado

$ cucumber features/login.feature
Using the default profile...
Funcionalidade: login
Para visitar a pagina
Como usuario
 56

Quero fazer login

Cenario: Fazer login # features/login.feature:8

Dado que estou na pagina # features/step_definitions/cadastro.rb:4
Quando eu preencher os campos # features/step_definitions/login.rb:4
Então eu devo estar logado na pagina # features/step_definitions/login.rb:10

1 scenario (1 passed)
4 steps (4 passed)
0m0.409s

Figura 15 - Teste para login finalizado

Fonte: Elaborado pela autora (2017).

A próxima funcionalidade especifica como o usuário deve inserir arquivos na base

para visualiza-los depois. A Figura 16 mostra como essa funcionalidade vai se comportar.

Figura 16 - Funcionalidade para adicionar um arquivo

Fonte: Elaborado pela autora (2017).

 57

O processo é feito da mesma forma dos testes anteriores. Executamos o Cucumber,

que irá gerar as definições de passos que precisamos para o teste (Listagem 09).

Listagem 09: Resultado ao executar o cucumber

cucumber features/addArtigo.feature
Using the default profile...
# language: pt
Funcionalidade: Adicionar artigo
Como usuario
Eu quero adicionar artigos na pagina
Para eu poder ter acesso depois

Cenario: Adicionando um artigo # features/addArtigo.feature:8

Dado que eu faça meu login # features/addArtigo.feature:9
Undefined step: "que eu faça meu login" (Cucumber::Undefined)
features/addArtigo.feature:9:in `Dado que eu faça meu login'
Quando eu clicar em "Artigos" # features/step_definitions/cadastro.rb:8
E clicar "Novo" # features/addArtigo.feature:11
Undefined step: "clicar "Novo"" (Cucumber::Undefined)
features/addArtigo.feature:11:in `E clicar "Novo"'
E preencher os campos # features/addArtigo.feature:12
Undefined step: "preencher os campos" (Cucumber::Undefined)
features/addArtigo.feature:12:in `E preencher os campos'
Entao eu devo ver os artigos na lista # features/addArtigo.feature:13
Undefined step: "eu devo ver os artigos na lista" (Cucumber::Undefined)
features/addArtigo.feature:13:in `Entao eu devo ver os artigos na lista'

1 scenario (1 undefined)
5 steps (5 undefined)
0m0.015s

You can implement step definitions for undefined steps with these snippets:

Dado(/^que eu faça meu login$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^clicar "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^preencher os campos$/) do
pending # Write code here that turns the phrase above into concrete actions
end
 58

Entao(/^eu devo ver os artigos na lista$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Copiamos as definições de passo geradas para um arquivo .rb, e após isso usamos os
recursos do Capybara para simular o usuário interagindo com o sistema. Nos passos da
listagem 10, caso o usuário deseje adicionar um arquivo na sua base, deverá preencher os
campos de login, clicar no link ‘Artigos’, selecionar a opção ‘Novo’ para inserir um novo
artigo, onde irá aparecer a página em que ele deverá adicionar o título do arquivo, escolher
alguma pasta onde ele ficará armazenado, escolher o arquivo a ser inserido, e marcar se ele
deve ser privado ou não, salvar as alterações, e por fim deverá ver o novo artigo na lista de
artigos da página inicial.

Listagem 10: Teste automatizado para inserir arquivos públicos na aplicação

# encoding: utf-8
# !/usr/bin/env ruby

Dado(/^que eu esteja na pagina inicial$/) do

visit 'examples'
end

Dado(/^que eu faça meu login$/) do

fill_in 'user_email', :with => "maria@hotmail.com"
fill_in 'user_password', :with => "1234567"
click_button 'Entrar'
end

Quando(/^eu pressionar em "([^"]*)"$/) do |link|

click_link(link)
end

Quando(/^selecionar "([^"]*)"$/) do |selec|

click_link(selec)
end

Quando(/^preencher os campos$/) do
fill_in ‘example_name’, :with => “Aprendendo Ruby”
select(‘Ruby’, from: ‘example_folder_id’)
page.attach_file(‘example_my_file’, ‘C:\Users\Liliane\Dropbox\Ruby’)
 59

click_button ‘Criar’
end

Então(/^eu devo ver o artigo na lista$/) do

have_content('Arquivo criado com sucesso')
end

Ao executar o Cucumber verificamos que todos os passos estão verdes e o cenário

“Adicionando um artigo” passa nos testes (Listagem 11 e Figura 17).

Listagem 11: Teste para adicionar um artigo passou

$ cucumber features/ addArtigo.feature
Using the default profile...
# language: pt
Funcionalidade: Adicionar artigo
Como usuario
Eu quero adicionar artigos na pagina
Para eu poder ter acesso depois

Cenario: Adicionando um artigo # features/addArtigo.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu pressionar em "Artigos" # features/step_definitions/addArtigo.rb:8
E selecionar "Novo" # features/step_definitions/addArtigo.rb:12
E preencher os campos # features/step_definitions/addArtigo.rb:16
Entao eu devo ver o artigo na lista # features/step_definitions/addArtigo.rb:20

1 scenario (1 passed)
4 steps (5 passed)
0m0.015s
 60

Figura 17 - Teste para inserir arquivo finalizado.

Fonte: Elaborado pela autora (2017).

A próxima funcionalidade trata-se do campo de busca, onde o usuário poderá realizar

uma pesquisa em vez de procurar por um artigo numa enorme lista de artigos.

Figura 18 - Funcionalidade para pesquisar arquivos na página

Fonte: Elaborado pela autora (2017).

Executamos o Cucumber e ele nos trará as definições de passos que precisamos para criar
os testes, como mostra a Listagem 12 logo abaixo:

Listagem 12. Resultado ao executar o Cucumber para um usuário pesquisar na página

cucumber features/busca.feature
Using the default profile...
# language: pt
Funcionalidade: O usuario pode pesquisar um arquivo na aplicação
Como usuario
Para que eu possa achar um arquivo mais rapido
Eu quero pesquisar por ele pelo titulo
 61

Cenario: Pesquisando por um arquivo # features/busca.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu digitar um termo no campo de busca # features/busca.feature:10
Undefined step: "eu digitar um termo no campo de busca" (Cucumber::Undefined)
features/busca.feature:10:in `Quando eu digitar um termo no campo de busca'
E pressionar em "Buscar" # features/busca.feature:11
Undefined step: "pressionar em "Buscar"" (Cucumber::Undefined)
features/busca.feature:11:in `E pressionar em "Buscar"'
Então eu devo ver os resultados # features/busca.feature:12
Undefined step: "eu devo ver os resultados" (Cucumber::Undefined)
features/busca.feature:12:in `Então eu devo ver os resultados'

1 scenario (1 undefined)
4 steps (3 undefined, 1 passed)
0m0.017s

You can implement step definitions for undefined steps with these snippets:

Quando(/^eu digitar um termo no campo de busca$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^pressionar em "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Então(/^eu devo ver os resultados para esse termo$/) do

pending # Write code here that turns the phrase above into concrete actions
end

No arquivo busca.rb, usamos o Capybara para manipular os dados na página. Na

Listagem 13 simulamos o usuário digitando um termo no campo de busca, e clicando no
botão “Buscar”, logo em seguida a aplicação deverá exibir todos os resultados com esse
termo.

Listagem 13: Teste automatizado para fazer buscas na aplicação

# encoding: utf-8
# !/usr/bin/env ruby

Quando(/^eu digitar um termo no campo de busca$/) do

fill_in 'q_name_cont', :with => ‘nuvem’
end
 62

Quando(/^pressionar em "([^"]*)"$/) do |botao|

click_button 'Buscar'
end

Então(/^eu devo ver os resultados$/) do

have_content('nuvem')
end

Executamos o Cucumber e vemos que todos os passos estão verdes, e o teste passou,
conforme mostra a Listagem 14 e a Figura 19.

Listagem 14: Teste para pesquisar passou

$ cucumber features/ busca.feature
Using the default profile...
# language: pt
Funcionalidade: O usuario pode pesquisar um arquivo na aplicação
Como usuario
Para que eu possa achar um arquivo mais rapido
Eu quero pesquisar por ele pelo titulo

Cenario: Pesquisando por um arquivo # features/busca.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu digitar um termo no campo de busca #features/step_definitions/busca.rb:4
E pressionar em "Buscar" # features/step_definitions/busca.rb:8
Então eu devo ver os resultados # features/step_definitions/busca.rb:12

1 scenario (1 passed)
4 steps (4 passed)
0m0.015s

Figura 19 - Teste para pesquisar arquivo finalizado.

Fonte: Elaborado pela autora (2017).

 63

Seguimos na próxima especificação da funcionalidade para o usuário criar a pasta e

adicionar os arquivos nela. Essa funcionalidade se faz necessária pois é um mecanismo que
ajuda os usuários a organizar seus arquivos e a compartilha-los com outros usuários do
sistema.

Figura 20 - Funcionalidade para a criação de uma pasta

Fonte: Elaborado pela autora (2017).

Executamos o Cucumber para ele gerar as definições de passos para podermos testar
essa funcionalidade, como mostra a Listagem 15.

Listagem 15. Resultado ao executar o Cucumber para um usuário criar uma pasta
cucumber features/ pasta.feature
Using the default profile...
# language: pt
Funcionalidade: Criar pasta
Como usuario
Quero criar pastas
Para eu poder organizar os arquivos inseridos

Cenario: Criando uma pasta # features/pasta.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu for em "Pastas" # features/pasta.feature:10
Undefined step: "eu for em "Pastas"" (Cucumber::Undefined)
features/pasta.feature:10:in `Quando eu for em "Pastas"'
E escolher "Nova Pasta" # features/pasta.feature:11
Undefined step: "escolher "Nova Pasta"" (Cucumber::Undefined)
features/pasta.feature:11:in `E escolher "Nova Pasta"'
E dar um nome a essa pasta # features/pasta.feature:12
 64

Undefined step: "dar um nome a essa pasta" (Cucumber::Undefined)

features/pasta.feature:12:in `E dar um nome a essa pasta'
Entao eu devo ver a pasta criada # features/pasta.feature:13
Undefined step: "eu devo ver a pasta criada" (Cucumber::Undefined)
features/pasta.feature:13:in `Entao eu devo ver a pasta criada'

1 scenario (1 undefined)
5 steps (4 undefined, 1 passed)
0m0.024s

You can implement step definitions for undefined steps with these snippets:

Quando(/^eu for em "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^escolher "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^dar um nome a essa pasta$/) do

pending # Write code here that turns the phrase above into concrete actions
end

Entao(/^eu devo ver a pasta criada$/) do

pending # Write code here that turns the phrase above into concrete actions
end

No arquivo pasta.rb, inserimos os comandos do Capybara para simular os passos do

usuário. Na listagem 16, quando clicarmos no link “Pastas” e depois em “Nova”, a aplicação
deverá abrir um formulário onde será dado um nome para a pasta e ao clicar em “Criar” a
aplicação deverá criar a pasta em questão e exibir essa pasta para o usuário.

Listagem 16: Teste automatizado para a criação de pastas

# encoding: utf-8
# !/usr/bin/env ruby

Quando(/^eu for em "([^"]*)"$/) do |pasta1|

click_link(pasta1)
end

Quando(/^escolher "([^"]*)"$/) do |novaPasta|

click_link(novaPasta)
 65

end

Quando(/^dar um nome a essa pasta$/) do

fill_in ' folder_name', :with => ‘Computação em Nuvem’
click_button 'Criar'
end

Entao(/^eu devo ver a pasta criada$/) do

have_content('Computação em Nuvem')
end

Executamos o Cucumber e todos os passos estão verdes e o cenário para criar uma pasta
na aplicação está finalizado (Listagem 17 e Figura 21).

Listagem 17: Teste para a criação de pastas passou

cucumber features/pasta.feature
Using the default profile...
# language: pt
Funcionalidade: Criar pasta
Como usuario
Quero criar pastas
Para eu poder organizar os arquivos inseridos

Cenario: Criando uma pasta # features/pasta.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu for em "Pastas" # features/step_definitions/pasta.rb:4
E escolher "Nova Pasta" # features/step_definitions/pasta.rb:8
E dar um nome a essa pasta # features/step_definitions/pasta.rb:12
Entao eu devo ver a pasta criada # features/step_definitions/pasta.rb:16

1 scenario (1 passed)
5 steps (5 passed)
0m0.016s
 66

Figura 21 - Teste para criar pasta finalizado.

Fonte: Elaborado pela autora (2017).

Para o usuário poder compartilhar seus arquivos, foi escrita uma funcionalidade que
especifica como esse processo deve ocorrer (Figura 22).

Figura 22 - Funcionalidade para compartilhar uma pasta

Fonte: Elaborado pela autora (2017).

A execução do Cucumber resulta nas especificações de passos para testar a

funcionalidade (Listagem 18). Os passos “Dado que eu faça meu login” e “Quando eu for em
Pastas” estão verdes porque já foram testados em funcionalidades anteriores.

Listagem 18. Resultado ao executar o Cucumber para um usuário criar uma pasta
$ cucumber features/compartilhar.feature
Using the default profile...
# language: pt
Funcionalidade: Compartilhar pasta
Como usuario
 67

Quero poder compartilhar pastas

Para que outro usuário também tenha acesso

Cenario: Criando uma pasta # features/compartilhar.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu for em "Pastas" # features/step_definitions/pasta.rb:4
E clicar em "Compartilhar" # features/compartilhar.feature:11
Undefined step: "clicar em "Compartilhar"" (Cucumber::Undefined)
features/compartilhar.feature:11:in `E clicar em "Compartilhar"'
E em "Novo Usuario" # features/compartilhar.feature:12
Undefined step: "em "Novo Usuario"" (Cucumber::Undefined)
features/compartilhar.feature:12:in `E em "Novo Usuario"'
E digitar o "Email" # features/compartilhar.feature:13
Undefined step: "digitar o "Email"" (Cucumber::Undefined)
features/compartilhar.feature:13:in `E digitar o "Email"'
E clicar em "Adicionar Email" # features/compartilhar.feature:14
Undefined step: "clicar em "Adicionar Email"" (Cucumber::Undefined)
features/compartilhar.feature:14:in `E clicar em "Adicionar Email"'
Então eu devo ver que a pasta foi compartilhada # features/compartilhar.feature:15
Undefined step: "eu devo ver que a pasta foi compartilhada" (Cucumber::Undefined)
features/compartilhar.feature:15:in `Então eu devo ver que a pasta foi
compartilhada'

1 scenario (1 undefined)
7 steps (5 undefined, 2 passed)
0m0.016s

You can implement step definitions for undefined steps with these snippets:

Quando(/^clicar em "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^em "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Quando(/^digitar o "([^"]*)"$/) do |arg1|

pending # Write code here that turns the phrase above into concrete actions
end

Então(/^eu devo ver que a pasta foi compartilhada$/) do

pending # Write code here that turns the phrase above into concrete actions
end
 68

No arquivo compartilhar.rb, novamente foi aplicado o Capybara para simular o

usuário interagindo com a página. Na Listagem 19 quando o usuário estiver em suas pastas e
clicar em compartilhar, inserir novo usuário e preencher o campo que aparecerá com o e-mail
do outro usuário e clicar em adicionar, ele deverá ver que a pasta foi compartilhada.

Listagem 19. Resultado ao executar o Cucumber para um usuário criar uma pasta
# encoding: utf-8
# !/usr/bin/env ruby

Quando(/^clicar em "([^"]*)"$/) do |compartilhar|

click_on(compartilhar)
end

Quando(/^em "([^"]*)"$/) do |novo_usu|

click_on(novo_usu)
end

Quando(/^digitar o "([^"]*)"$/) do |user_email |

fill_in 'user_email ', :with => 'liliane@hotmail.com'
click_button 'Adicionar'
end

Então(/^eu devo ver que a pasta foi compartilhada$/) do

have_content()
end

O código é escrito e o teste executado até que todos os passos estejam verdes,
significando que o teste passou. A listagem 20 e a figura 23 mostra que o teste passou e este
cenário está finalizado.

Listagem 20. Resultado ao executar o Cucumber para um usuário criar uma pasta
$ cucumber features/compartilhar.feature
Using the default profile...
# language: pt
Funcionalidade: Compartilhar pasta
Como usuario
Quero poder compartilhar pastas
Para que outro usuário também tenha acesso

Cenario: Compartilhando uma pasta # features/compartilhar.feature:8

Dado que eu faça meu login # features/step_definitions/addArtigo.rb:4
Quando eu for em "Pastas" # features/step_definitions/pasta.rb:4
 69

E clicar em "Compartilhar" # features/step_definitions/compartilhar.rb:4

E em "Novo Usuario" # features/step_definitions/compartilhar.rb:8
E digitar o "Email" # features/step_definitions/compartilhar.rb:12
E clicar em "Adicionar Email" # features/step_definitions/compartilhar.rb:4
Então eu devo ver que a pasta foi compartilhada #
features/step_definitions/compartilhar.rb:16

1 scenario (1 passed)
7 steps (7 passed)
0m0.009s

Figura 23 - Cenário para compartilhar pastas finalizado

Fonte: Elaborado pela autora (2017).

Essas são as funcionalidades que desejamos em nossa aplicação e para cada uma delas
apresentamos um cenário, que para esse trabalho é suficiente para demonstrar o potencial do
BDD. Mais cenários podem ser escritos para expressar como gostaríamos que a aplicação
funcionasse.

4.3 INTERFACE DE USUÁRIO

Nesta seção apresentamos as interfaces gráficas com as quais o usuário poderá

interagir na aplicação.
Logo que inicia o sistema é solicitado ao usuário a realização do login com o e-mail e
a senha (Figura 24). Caso ele tenha esquecido a senha poderá alterar a mesma clicando no link
“Mudar sua senha? ”. Se o usuário não tiver login, ele poderá criar um, clicando no link
“Inscrever” que aparece logo abaixo.
 70

Figura 24 - Tela de login.

Fonte: Elaborado pela autora (2017).

A tela de cadastro (Figura 25) está no formato padrão, consiste em inserir um e-mail,
senha e confirmação da senha.

Figura 25 - Tela de cadastro.

Fonte: Elaborado pela autora (2017).

A página inicial da aplicação apresenta ao usuário uma listagem dos artigos públicos,
que são os arquivos compartilhados com qualquer usuário do sistema. Como os arquivos são
organizados em pastas, é exibida a pasta a qual ele pertence (Figura 26). No menu principal
acima.
 71

Figura 26 - Página principal – Artigos públicos.

Fonte: Elaborado pela autora (2017).

Existe a opção de tornar os arquivos visíveis apenas para o usuário que o inseriu. Na aba
“artigos privados” temos a listagem dos artigos que o usuário não deseja compartilhar com outros
usuários da aplicação (Figura 27). Essa opção é definida na hora de inserir o arquivo (Figura 28).

Figura 27- Página principal – Artigos privados.

Fonte: Elaborado pela autora (2017).

 72

Quando o usuário desejar inserir um arquivo, ele deve clicar em “Artigos” e escolher a
opção “Novo”. Deverá aparecer um formulário com os campos onde deve inserir um título
para o artigo, escolher a pasta onde ele deve ficar, escolher o arquivo que será armazenado e
definir se ele terá público ou privado. Se o usuário não marcar a opção privado, o arquivo será
visível para os demais usuários na aba de “Artigos Públicos” (Figura 16).

Figura 28 - Inserindo artigos.

Fonte: Elaborado pela autora (2017).

Os arquivos do usuário são organizados em pastas. Para criar uma pasta ele pode ir no
menu principal e clicar em “Pastas”, e então em “Nova”, em seguida será exibido um
formulário em que ele deve dar um nome à pasta e clicar em criar.

Figura 29 - Criando nova pasta.

Fonte: Elaborado pela autora (2017).

Para visualizar as pastas o usuário pode ir em “Pastas”, e em seguida, em “Listar”.

Será exibido todas as pastas criadas por ele, o usuário que criou a pasta e as ações de inserir
 73

um novo artigo, editar a pasta, exclui-la e compartilha-la com outros usuários, conforme
mostrado na Figura (23).

Figura 30 - Exibição das pastas.

Fonte: Elaborado pela autora (2017).

Essas são as telas principais da aplicação que mostram as funcionalidades do sistema.

4.4 CLOUD9

O Cloud9 é uma IDE de desenvolvimento que funciona totalmente na nuvem. Suporta

mais de 40 idiomas, com suporte para PHP, Ruby, Python, JavaScript, Go, etc. A plataforma
combina um poderoso editor de código on-line com um espaço de trabalho do Ubuntu
completo na nuvem (CLOUD9 IDE, 2017). Não há necessidade de instalar programas, nem
configurar nenhum sistema, o próprio site controla e mantém tudo. O usuário acessa de
qualquer lugar usando apenas um navegador web.
Nos tipos de serviços oferecidos pela nuvem, o Cloud9 é classificado em plataforma
como serviço, pois oferece a infraestrutura necessária para os clientes desenvolverem suas
aplicações.
 74

Figura 31 - Ambiente de trabalho do Cloud9.

Fonte: Elaborado pela autora (2017).

No Cloud9 é possível programar, executar e depurar os programas criados na

linguagem escolhida. A aplicação do projeto foi desenvolvida nesta plataforma através da área
de trabalho disponibilizada para os desenvolvedores utilizando o framework Ruby on Rails
em sua versão 4.2.5 e a linguagem de programação Ruby na versão 2.3.0p0 e o banco de
dados SQLite3, versão 1.3.12.

Figura 32 - Ambiente do projeto no Cloud9.

Fonte: Elaborado pela autora (2017).

Todo o processo de desenvolvimento foi realizado no ambiente de trabalho do Cloud9,

inclusive os testes de aceitação, com as ferramentas Cucumber, versão 2.4.0 e Capybara,
versão 2.11.0.
 75

Figura 33 - Detalhes de ambiente de trabalho no Cloud9.

Fonte: Elaborado pela autora (2017).

A plataforma é gratuita se o desenvolvimento não necessitar de recursos avançados,

caso contrário é recomendável usar um plano pago. Para a aplicação deste projeto o plano
gratuito foi suficiente para a atingirmos o objetivo.
 76

5 CONCLUSÃO

5.1 CONSIDERAÇÕES FINAIS

O desenvolvimento do presente trabalho possibilitou uma análise de como a

engenharia de software está aplicando seus métodos e técnicas para o desenvolvimento de
software como serviço.
Pode-se observar conforme o referencial teórico e trabalhos relacionados que houve
um avanço na área de desenvolvimento de software como serviço. A área acadêmica também
vem fortemente desenvolvendo pesquisa para essa abordagem, como foi mostrado nos
trabalhos relacionados.
Assim, nesse trabalho aplicamos os métodos ágeis para auxiliar no desenvolvimento
do protótipo de um repositório bibliográfico digital que funcione como um serviço, visto que,
atualmente esse paradigma vem sendo bastante utilizados na área de desenvolvimento de
software como serviço, devido ao fato de estas metodologias estarem melhor adaptadas às
características desse tipo de aplicação, onde os requisitos podem ser mal compreendidos ou
mudarem com frequência.
O modelo de desenvolvimento iterativo e incremental do XP possibilitou a divisão do
desenvolvimento em etapas fazendo com que as preocupações de desenvolvimento fossem
totalmente divididas de acordo com as iterações e fez com que o feedback em relação a
aplicação fosse mais acelerado.
O XP com as histórias de usuário aproximou os clientes do desenvolvimento, pois o
uso da linguagem natural das histórias não intimida e permite que o levantamento de
requisitos seja mais claro e simplificado. A escrita de testes antes da aplicação permitiu
visualizar como o comportamento da aplicação deveria funcionar. Por fim, essas foram as
práticas mais utilizadas do XP.
O BDD conseguiu aprimorar as histórias de usuário com os cenários especificando
como deveria ser o comportamento da aplicação, permitindo assim, uma visualização
completa do comportamento do sistema, garantindo que ele estivesse mais próximo do que os
clientes desejavam. A estrutura do BDD para levantamento de requisitos, à princípio, é
diferente de qualquer outra já vista, mas à medida que nos acostumamos com ela, percebemos
o quanto esse método é claro e objetivo.
Ao mesmo tempo, que fazemos o levantamento dos requisitos, já conseguimos o
suporte dos testes de aceitação através dos cenários para as histórias de usuário. Os testes de
aceitação com a sua estrutura em alto nível, possibilitaram uma visão de como o software
 77

deveria se comportar antes mesmo que qualquer codificação. O fato de fazer com que os
testes sejam escritos antes do próprio código fez com que o esforço maior de validação e
desenvolvimento fosse na escrita do teste e não na depuração.
O Cucumber, ferramenta utilizada para a prática do BDD, apresenta uma estrutura
padrão fácil o suficiente para qualquer pessoa não técnica possa entender, pois a histórias de
usuários não se parecem com código-fonte, então são mais claras. O Cucumber ajudou tanto
no levantamento de requisitos quanto na definição dos testes de aceitação, permitindo que eles
pudessem ser executados automaticamente. Já o Capybara realizou muito bem as funções de
um usuário e seu navegador, clicando e preenchendo formulários e realmente permite que a
aplicação seja testada.
O alcance que o software como serviço tem é bastante superior ao software
tradicional, pois é rapidamente disponibilizado para milhões de usuários, fazendo com que
sua evolução também seja maior. Podemos destacar que o melhor benefício do software como
serviço seja a melhoria continua. Pois não existe uma versão final, sempre é possível
melhorar. Dessa forma, a criação de novas funcionalidades ajudam a garantir que os clientes
não abandonem a aplicação caso apareça outra semelhante.

5.2 TRABALHOS FUTUROS

Nesse trabalho tratamos apenas de testes de aceitação, mas podemos trabalhar outros
tipos de testes, como os unitários. Os testes unitários são importantes porque asseguram que
um procedimento ou método faça o que dele é esperado. O XP recomenda usarmos o método
TDD, através da ferramenta RSpec, para fazermos testes unitários. O TDD deve ser
trabalhado simultaneamente com o BDD.
Um recurso que tornaria a aplicação mais interessante seria permitir ao pesquisador a
inserção manual de mais informações do arquivo como a descrição, palavras-chaves, autor e
data para facilitar a identificação do mesmo. O título seria um link que quando o usuário
passar o mouse por ele poderia abrir uma janela em que ele mostraria a caixa com as
informações citadas.
Podemos sugerir também desenvolver ou pesquisar um algoritmo para automatizar as
operações acima descritas para o usuário não ter que digitar essas informações toda vez que
inserir um novo arquivo. Isso tornaria a experiência do usuário mais satisfatória.
 78

Outra sugestão relevante seria utilizar técnicas da IA para o usuário realizar buscas na
web, dentro do repositório, de algum assunto que lhe interesse e armazena os resultados
escolhidos pelo usuário automaticamente no repositório.
Sugerimos também como trabalhos futuros a melhoria da interface gráfica da
aplicação.
 79

REFERÊNCIAS

ALKMIN, Cassio P.; CORDEIRO, Daniel. SIM MYCLOUD, simulando o gerenciamento de

recursos virtualizados em plataformas de Computação em Nuvem. In: Simpósio Brasileiro De
Redes de Computadores e Sistemas Distribuidos, 32, 2014, Florianópolis. Artigo. p. 977-984.

ALMUDARRA, Fahad; QURESHI, Basiti. Issues in adopting Agile Development

Principles for Mobile Cloud Computing Applications. 2015. In: First International
Workshop on Mobile Cloud Computing Systems, Management, and Security, 52, 2015.
Artigo. p. 1133-1140.

ANICHE, Mauricio Finavaro. Como a prática do TDD influencia o projeto de classes em

sistemas em sistemas orientados a objetos. 2012. 75p. Dissertação (Mestre em Ciência da
Computação) – Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo,
2012.

ARMBRUST, Michael et al. A View of Cloud Computing. Communications of the ACM.

53, 04, p. 50-58, april 2010.

ASSOCIAÇÃO BRASILEIRA DE STARTUPS. Disponível em: < http://

https://abstartups.com.br//>. Acesso em: 01 de agosto de 2017.

BECK, Kent. et al. Manifesto para Desenvolvimento Ágil de Software. Ano 2001.
Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 23 de dezembro 2015.

BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace Change.

Massachusetts: Addison Wesley Professional, 2004. 224p.

BOLOZ, Dawid Mateusz. Improving use of Behaviour-Driven Develoment in Websphere

Commerce Projects. 2014. 42p. Thesis (Bachelor´s Thesis). Degree Programme Software
Engineering, JAMK – University of Applied Scienses, Jyväskylä, Finland, 2014.

CARISSIMI, Alexandre. Desmistificando a Computação em Nuvem. Disponível em: <

www.lbd.dcc.ufmg.br/colecoes/erad-rs/2015/002.pdf >. Acesso em: 06 de outubro de 2015.

CHEUN, Du Wan et al. A Quality Model for Evaluating Software-as-a-Service in Cloud

Computing. In: International Conference on Software Engineering Research, Management
and Applications, 07, 2009, Montreal. Artigo. p. 261-266.

CHELIMSKY, David. The RSpec Book. 1 ed. Dallas: The Pragmatic Bookshelf, 2010. 400p.

CHURAKOVA, Inna; MIKHRAMOVA, Ramilja. Software as a Service: Study and

Analysis of SaaS Business Model and Innovation Ecosystems. 2010. 151p. Thesis (Master
in Economic Sciences: Business Engineering) - Economics Faculty, Gent University,
Belgium, 2010.

CLOUD9 IDE. Disponível em: <https://c9.io/?redirect=0>. Acesso em: 16 de maio de 2017.

 80

COGO, Gabriel Silva. Análise da Intenção de Adoção da Computação em Nuvem por

profissionais da Área de TI. 2013. 109p. Dissertação (Mestre em Administração) –
Faculdade de Administração, Universidade Federal do Rio Grande do Sul, Porto Alegre,
2013.

CRESWELL, John W.; CLARK, Vicki L. Plano. Pesquisa de Métodos Mistos. Tradução de
Magda França Lopes. 2 ed. São Paulo: Penso, 2013. 288p.

DOURADO, Antonio Miguel Batista. O Uso de Metodologias Ágeis no Desenvolvimento de

Software como Serviço: Base Bibliográfica Digital. Trabalho de Conclusão de Curso
(Graduação) – Faculdade de Ciência da Computação, Marília, 2009.

DUARTE, César; FERNANDES, Amílcar. Behavior-Driven Development. Faculdade de

Engenharia da Universidade de Porto, Portugal. Disponível em: <
http://independent.academia.edu/C%C3%A9sarDuarte >. Acesso em: 27 de outubro de 2015.

FAGUNDES, Priscila Basto. Framework para comparação e análise dos métodos ágeis.
2005. 134p. Dissertação (Mestre em Ciência da Computação) – Programa de Pós-Graduação
em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, 2007.

FOX, Armando; PATTERSON, David. Engineering Software as a Service. 1. ed. Tradução

Daniel Cordeiro e Fábio Con. Berkeley: Strawberry Canyon LLC, 2015. 556p.

GORELIK, Eugene. Cloud Computing Models. 2013. 82p. Thesis (Master in Management
and Engineering) - Massachusetts Institute of Technology, Cambridge, Massachusetts, EUA,
2013.

GUHA, Radha; AL-DABASS, David. In: International Symposium on Electronic System

Design, 2010, Denton, Texas. Artigo, 2010. p. 213-218.

JAKONEN, Markus. When to Utilize Software as a Service. 2011. 121p. Thesis (Master in
Technology) - University Of Turku, Finland, 2011.

KOUDELIA, Nikolai. Acceptance Test-Driven Development. 2011. 102p. Thesis (Master in

Software Engineering) – University of Jyväskylä, Finland, 2011.

LUOMA, Eetu. Examining Business Models of Software-as-a-Service Companies. 2013.

88p. Academic Dissertation (Graduation) - Faculty of Information Technology, University of
Jyväskylä, Finland, 2013.

MARTINS, Adriano. Fundamentos de Computação Nuvem para Governos. In: Congresso da

Sociedade Brasileira de Computação, 30, 2010, Belo Horizonte. Artigo. 13p.

MARTINS, Luziane Graciano. Biblioteca em nuvem: o uso da computação em Nuvem em

bibliotecas. 2012. 121p. Trabalho de Conclusão de Curso (Graduação) – Faculdade de
Biblioteconomia e Comunicação, Universidade Federal do Rio Grande do Sul, Porto Alegre,
2012.

MATSUMOTO, Yukihiro. Programming Ruby - The Pragmatic Programmers Guide.

Disponível em: <http://ruby-doc.com/docs/ProgrammingRuby/>. Acesso em: 10 março 2016.
 81

MERIAT, Vitor. Modelos de Serviço na Nuvem: IaaS, PaaS e Saas. Disponível em: <
http://www.vitormeriat.com.br/2011/07/08/modelos-de-servio-na-nuvem-iaas-paas-e-saas/>.
Acesso em: 10 de novembo de 2015.

MILIAN, Eduardo Zied. Método de Análise para adoção de Computação em Nuvem:

Estudo de caso em organizações de grande porte. 2012. 176 p. Dissertação (Mestre em
Ciências) – Escola Politécnica da Universidade de São Paulo, São Paulo, 2014.

OLIVEIRA, Bruno G. et all. Estudo de Caso do Uso de Linguagens de Script em Jogos.

Anais SULCOMP, 02, 2006.

PEREIRA, Thiago. A arte de desenvolver testes - Cucumber + Capybara. Disponível em <

http://agiletesters.com.br/topic/103/a-arte-de-desenvolver-testes-cucumber-capybara>. Acesso
em: 05 de outubro de 2015.

PINHO, Vitor Pedro Figueiredo. SaaS: Análise de impacto na transformação da investigação

e desenvolvimento de produto para serviço. 53p. Dissertação (Mestre em Engenharia de
Gestão) – Faculdade de Engenharia, Universidade de Porto, Porto, 2009.

RAMALHO, Neilson Carlos Leite. Um estudo sobre a adoção da Computação em Nuvem

no Brasil. 2012. 158 p. Dissertação (Mestre em Ciências) – Programa de Pós-gradução em
Sistemas de Informação, Escola de Artes, Ciências e Humanidades, São Paulo, 2012.

RIBEIRO, Camilo. Entendendo BDD com Cucumber. 2012. Disponível em: <
http://www.bugbang.com.br/entendendo-bdd-com-cucumber-parte-i/>. Acesso em: 25 de
março de 2016.

RUCHUTRAKOOL, Wiphop; ZHU, Minpeng. Customer relationship management

software as a service: What is the providers’ view of advantages of CRM as a service? 2009.
84p. Thesis (Master in Informatic) - Lund University, Scania, Sueden, 2009.

SATO, Danilo Toshiaki. Uso eficaz de métricas em métodos ágeis de desenvolvimento de

software. 2007. 155p. Dissertação (Mestre em Ciências) – Instituto de Matemática e
Estatística, Universidade de São Paulo, São Paulo, 2007.

SOMMERVILLE, Ian. Engenharia de Software. Traduzido por Ivan Bosnic e Kalinka G. de

O. Gonçalves. 9ª ed. São Paulo: Pearson, 2011. 529p.

UCHÔA, Alexandre Prestes. Contratação de Desenvolvimento Ágil de Software Pelo

Governo. 2013. Dissertação (Mestre em Engenharia de Sistemas e Computação) - Programa
de Pós-graduação em Engenharia de Sistemas e Computação, Universidade Federal do Rio de
Janeiro, Rio de Janeiro, 2013.

UNIVERSO PROJETO. Qual o melhor entre o Modelo Ágil e o Tradicional. Disponível

em: < https://universoprojeto.wordpress.com/tag/cascata/>. Acesso em: 15 de janeiro de 2016.

WYNNE, Matt; HELLESOY, Aslak. The Cucumber Book: Behaviour-Driven Development

for Testers and Developers. 1 ed. Dallas: The Pragmatic Bookshelf, 2012. 315 p.