DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS …fateclins.edu.br/v4.0/trabalhoGraduacao/mXNIfr3... · DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS ETSCHEID UM ESTUDO SOBRE A PERSISTÊNCIA

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS

DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS ETSCHEID

UM ESTUDO SOBRE A PERSISTÊNCIA POLIGLOTA E SUA APLI CAÇÃO EM UMA PLATAFORMA WEB

LINS/SP

1º SEMESTRE/2014

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS

DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS ETSCHEID

UM ESTUDO SOBRE A PERSISTÊNCIA POLIGLOTA E SUA APLI CAÇÃO EM UMA PLATAFORMA WEB

Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo em Banco de Dados. Orientador: Prof. Me. Anderson Pazin

LINS/SP

1º SEMESTRE/2014

(folha de aprovação)

Dedicamos este trabalho às nossas famílias, bases das nossas existências, que nos incentivaram e acreditaram na nossa capacidade.

Deise Aparecida Pizo da Silva

Dominik Matthias Etscheid

AGRADECIMENTOS

Ao final de mais uma etapa de nossas vidas e início de grandes

oportunidades, agradecemos a Deus, nosso criador, que nos capacitou e que nos

fortaleceu nos momentos mais difíceis.

Agradecemos à Faculdade de Tecnologia de Lins Prof. Antônio Seabra pela

oportunidade e a todos os funcionários e companheiros de classe.

Também agradecemos a todos os professores que nos passaram com tanta

dedicação os seus nobres conhecimentos, e pelos ensinamentos que levaremos por

toda vida.

Em especial agradecemos ao nosso orientador Prof. Me. Anderson Pazin, que

pacientemente abnegou de seu tempo para nos orientar e acompanhar em todas as

fases deste trabalho.

Deise Aparecida Pizo da Silva

Dominik Matthias Etscheid

“O que fazemos para nós, morre conosco. O que

fazemos pelos outros e pelo mundo, continua e é

imortal.”

Albert Bigelow Paine

RESUMO

Devido à elevada quantidade de dados existentes nas transações on-line, principalmente em sites de relacionamentos sociais, de buscas e de vendas pela internet, observou-se a necessidade do emprego de sistemas de banco de dados com alta performance, capazes de fornecer respostas rápidas nas buscas e consultas. Após a realização de diversas pesquisas bibliográficas para identificar os tipos de tecnologias que podem ser usadas na otimização dos sistemas de vendas on-line, concluiu-se que os banco de dados NoSQL, que são bancos não relacionais, possibilitam respostas muito mais rápidas que os bancos de dados relacionais. Isso ocorre devido às consultas realizadas de maneira simples e operações com processamento rápido. Nos bancos de dados relacionais, utiliza-se o conceito de Atomicidade, Consistência, Isolamento e Durabilidade (ACID), que garante uma consistência de alto nível ao dados armazenados; já na maioria dos não relacionais, o conceito principal é a Consistência Eventual. Um protótipo de site de comércio eletrônico para venda de comida para entrega em domicílio foi desenvolvido para o estudo da utilização de bancos de dados relacionais e não relacionais juntos no mesmo sistema. Para armazenar dados dos restaurantes, dos produtos, dos usuários e os CEPs, foi utilizado um banco de dados relacional, o MySQL, indicado por suas características ACID; para pesquisas, utilizou-se um banco não relacional do tipo chave/valor, chamado Redis. A aplicação de bancos de dados relacionais e não relacionais juntos no mesmo sistema é denominado de persistência poliglota, esta prática pode trazer resultados bastante satisfatórios, uma vez que tira proveito das vantagens dos diferentes tipos de bancos. Palavras-chave: Banco de dados. Persistência poliglota. Redis. NoSQL.

ABSTRACT

Due to the high amount of data used in online transactions, especially on social networking, search and e-commerce sites, there is a need to employ high-performance database systems that are able to provide fast responses on incoming requests. After execution of various literature researches to identify some kinds of technologies that can be used for optimizing online sales systems, it was concluded that NoSQL databases, which are non-relational databases, allow much faster responses than relational databases. This occurs because of the simple way how the requests are performed and beacause of the existence of fast processing operations. In relational databases, is used the concept of Atomicity, Consistency, Isolation and Durability (ACID), which ensures a high level of consistency to the stored data; in most of the non-relational databases, the main concept is the Eventual Consistency. An e-commerce site for the sale of delivered food was developed to study the use of relational and non-relational databases together on the same system. To store data of restaurants, products, users, and zip codes the relational database MySQL with ACID characteristics was used; for responding requests, was used a non-relational database of the type key/value, called Redis. The usage of relational and non-relational databases together in the same system is called polyglot persistence; this practice can bring satisfactory results, as it takes advantage of the benefits of different types of stores. Keywords: Database. Polyglot persistence. Redis. NoSQL.

LISTA DE ILUSTRAÇÕES

Figura 1.1 - Crescimento em milhões dos e-consumidores no Brasil por ano........... 19

Figura 1.2 - Quantidade de transações por renda familiar ........................................ 20

Figura 1.3 - Quantidade de transações por faixa etária ............................................ 20

Figura 1.4 - Quantidade de transações por escolaridade .......................................... 21

Figura 1.5 - Página inicial do portal Restaurante Web .............................................. 25

Figura 1.6 - Página inicial do portal iFood ................................................................. 26

Figura 1.7 - Página inicial do portal Entrega Delivery ................................................ 27

Figura 1.8 - Página inicial do portal Janamesa.......................................................... 27

Figura 1.9 - Página inicial do portal Comernaweb ..................................................... 28

Figura 1.10 - Página inicial do portal Peixeurbano .................................................... 28

Figura 1.11 - Página inicial do portal Diskcook.......................................................... 29

Figura 2.1 - Arquitetura JSF baseada no modelo MVC ............................................. 31

Figura 2.2 - Ciclo de vida do JavaServer Faces ........................................................ 33

Figura 2.3 - Diagrama de estado de uma transação ................................................. 37

Figura 2.4 - Escolha das propriedades do Teorema CAP ......................................... 38

Figura 2.5 - Agregado no UI é conjunto de várias tuplas de várias tabelas .............. 42

Figura 2.6 - Bancos de dados relacionais x não relacionais ..................................... 44

Figura 2.7 - Par chave/valor ou chave/documento .................................................... 46

Figura 2.8 - Modelo de dados de uma família de colunas ......................................... 49

Figura 2.9 - Exemplo de duas linhas de uma família de colunas .............................. 49

Figura 2.10 - Modelo de uma super coluna ............................................................... 50

Figura 2.11 - Entidades com relacionamentos com propriedades ............................. 51

Figura 2.12 - Estrutura de dados tipo string .............................................................. 53

Figura 2.13 - Estrutura de dados tipo hash ............................................................... 53

Figura 2.14 - Estrutura de dados tipo list ................................................................... 54

Figura 2.15 - Estrutura de dados tipo set .................................................................. 55

Figura 2.16 - Estrutura de dados tipo sorted set ....................................................... 55

Figura 2.17 - Uso de um BD relacional para todos os requisitos de armazenagem .. 56

Figura 2.18 - Exemplo de implementação de persistência poliglota .......................... 57

Figura 3.1 - Modelo de ciclo de vida em cascata ...................................................... 59

Figura 3.2 - Modelo de ciclo de vida incremental e iterativo ...................................... 60

Figura 3.3 - Diagrama de Caso de Uso ..................................................................... 64

Figura 3.4 - Diagrama de Classe ............................................................................... 65

Figura 3.5 - Diagrama de Atividade Pesquisar Restaurante ..................................... 66

Figura 3.6 - Diagrama de Sequência Pesquisar Restaurante ................................... 67

Figura 3.7 - MVC Pesquisar Restaurante .................................................................. 67

Figura 3.8 - Diagrama de Atividade Fazer Login ....................................................... 68

Figura 3.9 - Diagrama de Sequência Fazer Login ..................................................... 69

Figura 3.10 - Diagrama MVC Fazer Login ................................................................. 69

Figura 3.11 - Padrão de sincronização MySQL/Redis ............................................... 72

Figura 4.1 - Arquivo context.xml ................................................................................ 75

Figura 4.2 - Arquivo persistence.xml ......................................................................... 75

Figura 4.3 - Classe entidade Produto ........................................................................ 76

Figura 4.4 - Classe EntityManagerUtil ....................................................................... 77

Figura 4.5 - Classe EntityManagerFilter .................................................................... 78

Figura 4.6 - Implementação OpenTransactionInPhaseListener ................................ 79

Figura 4.7 - Trecho do arquivo faces-config.xml ....................................................... 79

Figura 4.8 - Arquitetura em camadas ........................................................................ 80

Figura 4.9 - Template padrão do site ........................................................................ 80

Figura 4.10 - Código-fonte do template padrão ......................................................... 81

Figura 4.11 - Página Cadastro de Restaurante ......................................................... 82

Figura 4.12 - Página Alterar Dados do Restaurante .................................................. 83

Figura 4.13 - Código applicationContext.xml ............................................................. 83

Figura 4.14 - Código applicationContext-security.xml ............................................... 84

Figura 4.15 - Página de Login ................................................................................... 85

Figura 4.16 - Página Manter Cardápio ...................................................................... 85

Figura 4.17 - Página Pesquisar Restaurante ............................................................ 86

Figura 4.18 - Página dos restaurantes encontrados .................................................. 86

Figura 4.19 - Página do cardápio do restaurante ...................................................... 87

Figura 4.20 - Estruturas set e chave/valor ................................................................. 88

Figura 4.21 - Estrutura hash ...................................................................................... 89

Figura 4.22 - Implementação entidade auxiliar CrudEvent ........................................ 90

Figura 4.23 - Método save() utilizado para persistir o evento CRUD ........................ 91

Figura 4.24 - Trecho da implementação da classe RestauranteRN .......................... 92

Figura 4.25 - Implementação do método de sincronização MySQL/Redis ................ 93

Figura 4.26 - Implementação do método que processa um evento CRUD ............... 94

Figura 4.27 - Memória RAM ocupada pelo Redis ...................................................... 95

Figura 4.28 - Comparativo de tempo de resposta MySQL x Redis ........................... 96

LISTA DE QUADROS

Quadro 1.1 - Produtos mais vendidos no varejo on-line do Brasil em 2011 .............. 19

Quadro 1.2 - Classificação dos canais de distribuição de food service ..................... 23

LISTA DE ABREVIATURAS E SIGLAS

ABIA – Associação Brasileira das Indústrias de Alimentos

ABRASEL – Associação Brasileira de Bares e Restaurantes

ACID – Atomicidade, Consistência, Isolamento, e Durabilidade

ACM – Association for Computing Machinery

API – Application Programming Interface

BASE – Basically Available Soft Eventually Consistent

BD – Banco de Dados

BSON – Binary JSON

CAP – Consistency, Availability and Partition tolerancy

CEP – Código de Endereçamento Postal

CRUD – Create, Read, Update and Delete

DAO – Data Access Object

FURPS – Functionality, Usability, Reliability, Performance e Supportability

HTML – Hypertext Markup Language

IBGE – Instituto Brasileiro de Geografia e Estatísticas

IDE – Integrated Development Environment

JAR – Java Archive

JAVA EE – Java Enterprise Edition

JDBC – Java DataBase Connectivity

JNDI – Java Naming and Directory Interface

JPA – Java Persistence API

JPQL – Java Persistence Query Language

JSF – JavaServer Faces

JSON – JavaScript Object Notation

LAN – Local Area Network

MB – Megabyte

MVC – Model View Controller

OEMV – OpenEntityManagerInView

ORM – Object-Relational Mapping

OTAPL – OpenTransactionInApplicationPhaseListener

PDF – Portable Document Format

POF – Pesquisas de Orçamento Familiar

PPR – Partial Page Rendering

RAM – Random Access Memory

SEBRAE – Serviço Brasileiro de Apoio às Micro e Pequenas Empresas

SINDRIO – Sindicato de Hotéis, Bares e Restaurantes do Rio de Janeiro

SMS – Short Message Service

SOR – System Of Record

SQL – Structured Query Language

UI – User Interface

WYSIWYG – What you see is what you get

XML – eXtensible Markup Language

SUMÁRIO

INTRODUÇÃO ..................................................................................... 17

1 ANÁLISE DE MERCADO .................................................................. 19

1.1 PERFIL DOS CONSUMIDORES DO COMÉRCIO ELETRÔNICO ..................... 19

1.2 USO DE DISPOSITIVOS MÓVEIS ..................................................................... 21

1.3 VENDA ON-LINE DE PRODUTOS ALIMENTÍCIOS ........................................... 22

1.4 PERFIL DOS BARES E RESTAURANTES DO BRASIL..................................... 22

1.5 PORTAL DE VENDAS PARA ESTABELECIMENTOS COMERCIAIS ................ 24

1.6 ANÁLISE DOS PORTAIS PRESTADORES DE SERVIÇOS .............................. 25

2 TECNOLOGIAS ................................................................................. 30

2.1 JAVASERVER FACES ........................................................................................ 30

2.2 PRIMEFACES ..................................................................................................... 33

2.3 SPRING FRAMEWORK E SPRING SECURITY ................................................. 34

2.4 JAVA PERSISTENCE API (JPA) ........................................................................ 34

2.5 BANCOS DE DADOS.......................................................................................... 35

2.5.1 Processos de transações ACID ........................................................................ 35

2.5.2 O Teorema CAP ............................................................................................... 37

2.5.3 Basically Available Soft Eventually Consistent (BASE) .................................... 39

2.5.4 Agregados ........................................................................................................ 40

2.5.5 Tipos de Bancos de Dados .............................................................................. 41

2.5.6 Bancos de Dados Relacionais .......................................................................... 41

2.5.7 NoSQL .............................................................................................................. 43

2.5.7.1 Key/Value stores ........................................................................................... 45

2.5.7.2 Document stores ........................................................................................... 47

2.5.7.3 Column family stores ..................................................................................... 48

2.5.7.4 Graph database ............................................................................................. 50

2.5.8 Redis ................................................................................................................ 52

2.5.8.1 String ............................................................................................................. 52

2.5.8.2 Hash .............................................................................................................. 53

2.5.8.3 List ................................................................................................................. 54

2.5.8.4 Set ................................................................................................................. 54

2.5.8.5 Sorted Set ..................................................................................................... 55

2.5.9 Persistência Poliglota ....................................................................................... 56

3 REQUISITOS DO SISTEMA ............................................................. 58

3.1 LEVANTAMENTO DE REQUISITOS .................................................................. 60

3.1.1 Requisitos funcionais........................................................................................ 61

3.1.2 Requisitos não funcionais ................................................................................. 62

3.1.3 As restrições ..................................................................................................... 63

3.2 ANÁLISE DE REQUISITOS FUNCIONAIS ......................................................... 63

3.2.1 Caso de uso: Pesquisar Restaurante ............................................................... 66

3.2.2 Caso de uso: Fazer Login ................................................................................ 68

3.2.3 Caso de uso: Manter Usuário Restaurante ...................................................... 70

3.2.4 Caso de uso: Manter Cardápio ......................................................................... 70

3.3 ANÁLISE DE REQUISITOS NÃO FUNCIONAIS ................................................ 70

3.3.1 Usabilidade ....................................................................................................... 70

3.3.2 Performance ..................................................................................................... 71

3.3.3 Confiabilidade ................................................................................................... 71

3.3.4 Suportabilidade ................................................................................................ 73

4 IMPLEMENTAÇÃO DO SISTEMA ..................................................... 74

4.1 PREPARAÇÃO DO AMBIENTE DE DESENVOLVIMENTO ............................... 74

4.2 CONFIGURAÇÃO JPA E IMPLEMENTAÇÃO DAS CLASSES ENTIDADES ..... 74

4.3 PADRÕES DE CONTROLE DE TRANSAÇÃO ................................................... 76

4.4 ACESSO AOS DADOS ....................................................................................... 79

4.5 LEIAUTE DAS PÁGINAS DO SITE ..................................................................... 80

4.6 IMPLEMENTAÇÃO DOS CASOS DE USO ........................................................ 81

4.6.1 Implementação do caso de uso Manter Usuário Restaurante .......................... 82

4.6.2 Implementação do caso de uso Fazer Login .................................................... 83

4.6.3 Implementação do caso de uso Manter Cardápio ............................................ 85

4.6.4 Implementação do caso de uso Pesquisar Restaurante .................................. 86

4.7 IMPLEMENTAÇÃO DA PERSISTÊNCIA POLIGLOTA ....................................... 87

4.7.1 Modelagem de dados para o banco de dados Redis ....................................... 88

4.7.2 Realização do padrão de sincronização entre MySQL e Redis ........................ 90

4.7.3 Teste de viabilidade da persistência poliglota .................................................. 94

CONCLUSÃO ....................................................................................... 97

REFERÊNCIAS BIBLIOGRÁFICAS ..................................................... 99

APÊNDICE A – Comandos Básicos do Redis .................................... 103

17

INTRODUÇÃO

A internet está cada vez mais presente nas atividades cotidianas das pessoas

nos últimos anos. As pessoas fazem uso da web com objetivos diversos, entre os

quais: profissionais, educativos, comunicação e entretenimento e compras on-line.

Os sites de buscas e os inúmeros anúncios digitais confirmam que a tendência atual

do mercado é o comércio eletrônico. Segundo notícias publicadas pelo Serviço

Brasileiro de Apoio às Micro e Pequenas Empresas do Estado de São Paulo

(SEBRAESP), em 2011, cerca de 76 milhões de brasileiros de alguma forma

estiveram conectados à internet, e mais de 31 milhões de pessoas compraram em

lojas virtuais (SEBRAESP, 2013). No primeiro semestre de 2012, o Brasil faturou R$

10,2 bilhões nas vendas on-line, isto significou um acréscimo de 21% em relação ao

mesmo período do ano anterior (E-COMMERCEBRASIL, 2013). Isto comprova que

as empresas estão investindo cada vez mais nessa modalidade de comércio. Alguns

fatores contribuíram para o crescimento do e-commerce no Brasil, como: maior

segurança e confiança no momento da compra, reformas governamentais de

incentivo ao comércio virtual e o aumento do uso de pagamentos eletrônicos.

(SEBRAE, 2011)

Pesquisas feitas pela E-COMMERCESCHOOL (2011) relatam a existência de

23 mil lojas virtuais no Brasil. Atraídas pela facilidade de obtê-las, as pessoas

montam suas lojas, entretanto, apenas 30% estão ativas, justificado pela falta de

conhecimento e planejamento. Também há empreendedores que não investem no

comércio eletrônico por possuírem algumas dificuldades para implantarem a venda

virtual. Pode-se afirmar isso através da notícia publicada em BRASIL (2013).

Mas a oportunidade do empreendedorismo online é tão atrativa quanto complexa e exige empreendedores bem preparados e dispostos a assumir riscos. Para quem quer montar uma loja virtual, por exemplo, é preciso ter um site funcional, encontrável em mecanismos de busca, com meios de pagamento confiáveis e logística de entrega eficiente. O empreendedor também deve saber usar ferramentas de marketing digital para divulgar seus produtos a ações estratégicas nas redes sociais. (BRASIL, 2013)

Para os consumidores, poder escolher com privacidade produtos e serviços,

pagá-los e recebê-los no conforto, comodidade e segurança de sua casa, sem

enfrentar filas, sem gastar com locomoção, comparar preços, são algumas das

18

vantagens de se fazer compras on-line, basta possuir um dispositivo com conexão à

internet.

Um sistema de plataforma web, direcionado aos estabelecimentos do ramo

alimentício, em que as empresas interessadas cadastram seus produtos e os

consumidores acessam este site para fazer suas compras com serviço de delivery é

uma excelente opção para as empresas, pois não precisam possuir sites próprios

nem investir em desenvolvimento de software.

Um estudo sobre tecnologias e técnicas que possibilitem desenvolver um

sistema eficiente e que ofereça respostas rápidas nas buscas de estabelecimentos e

de produtos desejados foi realizado. Descobriu-se que utilizar um banco de dados

relacional, para armazenar os dados, juntamente com um banco de dados não

relacional, para acelerar as consultas, seria uma solução interessante para obter-se

o resultado esperado.

O uso de mais de um tipo de banco de dados juntos em uma mesma

aplicação é chamado de persistência poliglota, para aplicação deste estudo, foi

desenvolvido um protótipo de plataforma web.

As pesquisas realizadas sobre sites que prestam serviços similares ao portal

a ser desenvolvido estão descritas no primeiro capítulo, no qual constam as

informações de dados levantados na análise de mercado. Compreende alguns

pontos fortes e fracos observados e quais recursos estão sendo utilizados. Neste

capítulo encontram-se ainda as características das empresas, possíveis contratantes

desses serviços, e o perfil dos prováveis consumidores das mesmas.

O segundo capítulo descreve detalhadamente as tecnologias empregadas e

como as mesmas são aplicadas no desenvolvimento do sistema em questão.

A análise de requisitos está descrita no terceiro capítulo, baseada na análise

de negócios, detalhando o funcionamento e o modelo de negócio. Essa análise está

representada pelos Casos de Uso, Diagrama de Sequência, Diagrama de Atividade

e Model View Controller (MVC).

O quarto capítulo contém detalhes de como foram implementadas as

funcionalidades necessárias para o estudo do uso de persistência poliglota, alguns

trechos dos códigos utilizados no desenvolvimento do protótipo e comentários,

seguido das considerações finais e proposta para trabalhos futuros.

19

1 ANÁLISE DE MERCADO

O comércio eletrônico cresceu cerca de 30% ao ano na última década,

conforme estudo realizado pela E-bit, com apoio da Câmara Brasileira de Comércio

Eletrônico, que atribui a essa evolução o aumento do número de e-consumidores e a

maior confiança do meio internet. (BRASIL, 2012)

Os empreendedores digitais devem estar atentos às tendências como

mobilidade, nichos de consumo, redes sociais e perfil dos e-consumidores.

Dados levantados pela E-bit indicam que os eletrodomésticos lideraram as

vendas on-line no Brasil em 2011, mas vários outros produtos são comercializados

no mercado virtual brasileiro, conforme demonstrado no Quadro 1.1. (E-

COMMERCEORG, 2012)

Quadro 1.1 - Produtos mais vendidos no varejo on-line do Brasil em 2011 Produtos mais vendidos %

Eletrodomésticos 15 Informática 12 Eletrônicos 8 Saúde e Beleza 7 Moda e Acessórios 7 Fonte: E-Commerceorg, 2012

1.1 PERFIL DOS CONSUMIDORES DO COMÉRCIO ELETRÔNICO

Pesquisas realizadas pela E-bit apresentaram informações sobre o perfil dos

consumidores que compram on-line no Brasil.

Figura 1.1 - Crescimento em milhões dos e-consumidores no Brasil por ano Fonte: E-Commerceorg, 2012 (adaptada pelos autores)

20

A Figura 1.1 representa o crescimento em milhões dos e-consumidores por

ano, com um comparativo do ano de 2001 até 2012.

Sessenta por cento dos e-consumidores brasileiros possuem uma renda

mensal entre 1000 e 5000 reais, conforme representado graficamente na Figura 1.2.

Na classificação dada pelo Instituto Brasileiro de Geografia e Estatística

(IBGE) esta faixa salarial corresponde às classes sociais C, D e E.

Figura 1.2 - Quantidade de transações por renda familiar Fonte: E-Commerceorg, 2012 (adaptada pelos autores)

Figura 1.3 - Quantidade de transações por faixa etária Fonte: E-Commerceorg, 2012 (adaptada pelos autores)

21

Quanto à faixa etária dos consumidores on-line, a maior percentagem deles,

representando 70%, está entre 25 e 49 anos, conforme demonstrado na Figura 1.3.

Os consumidores que mais compram pela internet possuem curso superior

completo e os que menos compram possuem apenas o ensino fundamental, isso

está representado na Figura 1.4. (E-COMMERCEORG)

Figura 1.4 - Quantidade de transações por escolaridade Fonte: E-Commerceorg, 2012 (adaptada pelos autores)

1.2 USO DE DISPOSITIVOS MÓVEIS

No primeiro semestre de 2012, o Brasil faturou R$ 10,2 bilhões no mercado

on-line, de acordo com dados levantados pelo SEBRAE e publicados pelo E-

COMMERCEBRASIL (2013). As vendas realizadas apenas por meio de dispositivos

móveis movimentaram aproximadamente R$ 132 milhões, segundo a Câmara

Brasileira de Comércio Eletrônico, este segmento está em alta no Brasil, com

estimativa de movimentar cerca de dois bilhões de reais em 2013.

(EBRICKSDIGITAL, 2012)

A empresa M.Sense, especialista em estudos sobre o mercado digital,

realizou uma série de pesquisas no Brasil sobre o mercado mobile. Foram

entrevistadas 1796 pessoas de cinco regiões do país no período de maio e junho de

2012, 45% dos entrevistados possuem smartphones e 16% possuem tablets, a

22

maioria mora na região sudeste do Brasil e possui entre 30 e 39 anos. A pesquisa

aponta que um em cada três usuários de smartphones ou tablets já realizou

compras usando seus dispositivos móveis. (EBRICKSDIGITAL, 2012)

1.3 VENDA ON-LINE DE PRODUTOS ALIMENTÍCIOS

De acordo com dados publicados em abril de 2013 pela Associação Brasileira

de Bares e Restaurantes (ABRASEL), o mercado de alimentação fora de casa

faturou aproximadamente 230 bilhões de reais em 2012, tendo uma taxa de

crescimento de 13% em relação a 2011. As vendas realizadas pelos serviços de

delivery estão inclusas nesta estatística, sendo responsável por 8 bilhões de reais.

(ABRASEL, 2013)

Os serviços pela web e aplicativos móveis complementam o serviço

tradicional das chamadas telefônicas para realização de pedidos de comida pronta.

Os serviços on-line já são utilizados por dois milhões de consumidores no Brasil,

representando 2% do faturamento deste mercado no país. (ABRASEL, 2013)

Apesar de não estar na lista dos produtos mais vendidos pela internet, o

serviço de entrega de comida está cada vez mais presente no comércio virtual. A

revista on-line Hotelnews publicou uma matéria em 2011 explicando a preferência do

consumidor em pedir comida pela internet e não por telefone. As principais

justificativas dessa escolha são as várias tentativas de discagem a um número

bastante ocupado ou a possibilidade de o atendente não compreender corretamente

a solicitação do consumidor e enviar o pedido errado. Uma vez que, optando pelo o

uso da internet, é possível consultar sem pressa os restaurantes, preços, cardápios

e formas de pagamento, montar o prato e ainda acompanhar o andamento do

pedido. (HOTELNEWS, 2011)

1.4 PERFIL DOS BARES E RESTAURANTES DO BRASIL

A empresa ECD Consultoria Especializada em food service define o termo

food service como a venda de alimentos e bebidas para consumo imediato,

preparados por restaurantes, padarias, lanchonetes e outros, e consumido no

próprio estabelecimento ou em outros locais. Esse mercado envolve toda cadeia de

produção, distribuição de alimentos, insumos, equipamentos e serviços que atendam

23

os fornecedores de alimentos e bebidas prontos para o consumo.

(ECDFOODSERVICE, 2010)

A Associação Brasileira das Indústrias de Alimentos (ABIA) afirma que em

2010, havia no total mais de 1,4 milhões de estabelecimentos de food service ativos

em todo território nacional, sendo que, a maioria, é de microempresas ou empresas

de pequeno porte. São definidos vários subcanais de distribuição de refeições

preparadas (ABIA, 2010). No Quadro 1.2 está representada a classificação dos

canais de distribuição mais importantes.

Quadro 1.2 - Classificação dos canais de distribuição de food service

Canal de distribuição Definição Tipo de estabelecim entos

Comercial

O objetivo principal é a geração de lucro com a venda de refeições. É o

núcleo do negócio.

Restaurantes, churrascarias, pizzarias, lanchonetes,

padarias, bares, entre outros

Comercial – serviço

A alimentação é um serviço e não a atividade principal do

negócio, mas com objetivo de lucro.

Hotéis, motéis, escolas, hospitais, catering (aéreo,

terrestre e marítimo)

Comercial – alternativo

Venda de refeições prontas para o consumo imediato ou posterior. Fonte alternativa

de lucro.

Lojas de conveniência, rotisserias e lanchonetes dentro de supermercados

Social A alimentação é um serviço. O objetivo não é o lucro.

Exército, merenda escolar, presídios,restaurantes

populares Fonte: ECDFoodservice, 2010 (adaptado pelos autores)

Os resultados das Pesquisas de Orçamento Familiar (POF), realizadas pelo

IBGE, revelam que houve um aumento de 7% no consumo de refeições fora do lar

pelas famílias brasileiras entre 2002/2003 e 2008/2009. Em 2002/2003, das

despesas totais com alimentos, foram gastos 24,1% com food service (IBGE, 2004);

já em 2008/2009, esse gasto representou 31,1% (IBGE, 2010). Isso indica uma

mudança no padrão de consumo alimentar dos brasileiros.

Dados fornecidos pela ECD demonstram o aumento do número das

transações de food service por dia e o aumento do valor per capita dessas

transações no período de 2004 até 2010. Enquanto o número de transações diárias

neste período aumentou de 56,4 milhões para 61,7 milhões, ou seja, houve um

aumento de 9,3%, o valor per capita no mesmo período aumentou de R$ 4,00 para

R$ 8,28, significando um acréscimo de 107%. Na análise desses valores deve ser

24

considerado que no período junho/2004 até junho/2010 houve uma inflação

acumulada de 38,71% (Índice IGP-10). (ECDFOODSERVICE, 2010)

1.5 PORTAL DE VENDAS PARA ESTABELECIMENTOS COMERCIA IS

Além dos restaurantes que disponibilizam cardápios em seus próprios sites

para pedidos on-line, existem estabelecimentos que optam por outros meios, como

os portais que reúnem diversos bares e restaurantes com variados tipos de comida.

Análises feitas nesses portais demonstram como eles funcionam. O consumidor

pode cadastrar-se gratuitamente preenchendo um formulário on-line com seus

dados pessoais, para concluir o cadastro, ele precisa normalmente aceitar o termo

de uso do site. Ao informar a sua localização é possível escolher os

estabelecimentos filiados que realizam a entrega no seu endereço. Em poucos

passos, o consumidor escolhe seu prato, realiza seu pedido, podendo optar por

pagar no momento do pedido ou na entrega, e ainda pode acompanhar o

andamento de sua solicitação. Também há a possibilidade de fazer agendamento

para entrega futura. Após utilizar os serviços, o consumidor pode avaliar o

estabelecimento para servir de referência para outros consumidores. Vários desses

sites oferecem ainda a opção de aplicativos para dispositivos móveis.

O estabelecimento, para filiar-se ao portal, faz um cadastro e fecha um

contrato com a empresa prestadora dos serviços. Geralmente a empresa não cobra

mensalidade nem taxa de adesão, apenas um percentual sobre cada venda

realizada pelo site, a maioria, na faixa de 10% sobre o valor do pedido. O cardápio é

enviado pelo restaurante e postado no site, assim como suas condições de entrega,

taxas, horários de funcionamento e outras regras de negócio pertinentes.

A cada pedido feito, o estabelecimento recebe uma notificação, que pode ser

enviada pelo site por meio de aviso na tela do computador, sinal sonoro,

equipamentos específicos desenvolvidos para esta finalidade ou outro dispositivo de

comunicação. O recebimento do pedido é confirmado pelo estabelecimento em

tempo real.

A revista on-line Hotelnews (2011) publicou uma entrevista feita com o

presidente do Sindicato de Hotéis, Bares e Restaurantes do Rio de Janeiro

(SINDRIO), Pedro Lamare, que cita algumas vantagens desse tipo de serviço para o

empreendedor:

25

Um dos principais veículos on-line do setor aponta que o número de sites de restaurantes no Rio de Janeiro cresceu 35% desde o início do ano. A maior parte utiliza os serviços de páginas terceirizadas para o serviço de delivery, o que reduz gastos com a implantação do sistema e fica mais cômodo para o cliente, que ganha várias opções em um só lugar. No caso das reservas, elas costumam ser feitas pelo site do próprio estabelecimento. [...] É importante o estabelecimento saber se posicionar nas redes sociais. (HOTELNEWS, 2011)

1.6 ANÁLISE DOS PORTAIS PRESTADORES DE SERVIÇOS

Os sites de maior relevância que prestam os serviços de vendas delivery para

os estabelecimentos foram analisados e foram detectadas algumas diferenças entre

eles: design, mecanismos de busca, navegabilidade, tecnologias variadas para

notificações ao estabelecimento e outras funcionalidades. As peculiaridades da área

restrita ao estabelecimento no site não puderam ser comparadas por serem de

acesso privado.

A maioria dos sites pesquisados está no mercado a menos de quatro anos,

eles possuem estabelecimentos cadastrados em poucas cidades localizadas

aleatoriamente no território nacional.

A seguir estão algumas imagens de portais analisados e as descrições de

suas características.

A página inicial do site Restaurante Web está representada na Figura 1.5.

Figura 1.5 - Página inicial do portal Restaurante Web Fonte: Restauranteweb, 2013

26

O Restaurante Web possui cerca de 20 mil estabelecimentos cadastrados em

aproximadamente 25 estados brasileiros. É um dos pioneiros desse tipo de serviço

no Brasil. Está presente em várias redes sociais. Apesar do tempo de mercado e

expansiva abrangência, o Restaurante Web apresenta dois pontos fracos: não

possui aplicativos para dispositivos móveis e a busca é realizada por meio da

informação do Código de Endereçamento Postal (CEP) ou endereço, sem a

possibilidade de descobrir o CEP e não possui cadastro de todos os endereços. Em

contrapartida, o site fornece o endereço de cada estabelecimento e sua localização

utilizando o mapa do Google.

O portal iFood está no ar desde 2011, possui aproximadamente 1000

estabelecimentos cadastrados e atende várias cidades do estado de São Paulo e

alguns outros estados do Brasil. Possui aplicativos para dispositivos móveis iOS e

Android, recebe aproximadamente 50 mil pedidos por mês, sendo 20% através

destes aplicativos. Está presente nas redes sociais e permite ao consumidor utilizar

o cadastro do Facebook para logar-se. Na Figura 1.6 está a página inicial do iFood.

Figura 1.6 - Página inicial do portal iFood Fonte: Ifood, 2013

No Entregadelivery a busca pelo CEP é direcionada ao site da Empresa

Brasileira de Correios e Telégrafos, apesar disso favorecer uma busca confiável,

pode provocar a desistência do consumidor a continuar seu pedido. Um ponto

negativo desse site é que ele não disponibiliza o uso de aplicativos para dispositivos

27

móveis. O Entregadelivey tem sua página inicial representada na Figura 1.7.

Figura 1.7 - Página inicial do portal Entrega Delivery Fonte: Entregadelivery, 2013

O site Jánamesa possui apenas 22 estabelecimentos e todos da cidade de

São Paulo em seu cadastro, portanto sua busca restringe ao consumidor em

procurar seu CEP apenas da cidade. Tem como diferencial o atendimento on-line

para contato em tempo real com o consumidor que queira dirimir suas dúvidas ou

solicitar informações. O portal também não possui aplicativos para dispositivos

móveis, mas permite o uso do cadastro do Facebook para o consumidor logar-se.

A imagem do Janamesa pode ser vista na Figura 1.8.

Figura 1.8 - Página inicial do portal Janamesa Fonte: Janamesa, 2013

28

O Comernaweb possui aplicativos para dispositivos móveis e uma

comunidade on-line para troca de informações sobre os estabelecimentos. Seu

diferencial é a opção para o consumidor poder fazer reserva nos estabelecimentos

cadastrados.

Na Figura 1.9 está a imagem do portal Comernaweb na sua página inicial.

Figura 1.9 - Página inicial do portal Comernaweb Fonte: Comernaweb, 2013

Figura 1.10 - Página inicial do portal Peixeurbano Fonte: Peixeurbano, 2013

29

No mercado desde 2010, o Peixeurbano tem em seus cadastros mais de 500

estabelecimentos localizados principalmente nas capitais São Paulo e Rio de

Janeiro. Ele possui atendimento on-line e aplicativos para iPhone, Android e

Blackberry e também conta com opção de reserva on-line. Mas o delivery do

Peixeurbano é apenas uma área desse site, ele não é exclusivo para este tipo de

serviço. A Figura 1.10 representa o portal Peixeurbano.

No ar desde 1997, o Diskcook não realiza apenas os pedidos, como também

faz o serviço de entregas e cobra a taxa de entrega diretamente dos consumidores.

Ele possui estabelecimentos localizados nas capitais São Paulo, Rio de Janeiro e

Curitiba.

A página inicial do Diskcook está demonstrada na Figura 1.11.

Figura 1.11 - Página inicial do portal Diskcook Fonte: Diskcook, 2013

No capítulo seguinte estão descritas as principais tecnologias utilizadas no

desenvolvimento do site.

30

2 TECNOLOGIAS

Algumas das tecnologias analisadas para o desenvolvimento do portal de

busca de restaurantes para entrega de comida estão abordadas neste capítulo. A

aplicação web é composta por linguagens de programação, que são usadas para

implementar a lógica do projeto; web frameworks, para facilitar a construção da

interface do usuário (User Interface - UI); bancos de dados, que armazenam todas

as informaçãos; e outras interfaces de programação de aplicativos (Application

Programming Interface - API).

Inicialmente estão relatados os frameworks e as bibliotecas para aplicações

web utilizados no desenvolvimento do portal.

2.1 JAVASERVER FACES

JavaServer Faces (JSF) 2.0 é um framework que incorpora as características

de uma tecnologia MVC para aplicações web e de um modelo de interfaces gráficas

baseada em eventos. Por seguir o padrão MVC, ele separa a visualização, o

controle e o modelo, que são as regras de negócio. No JSF, o modelo representa os

objetos do negócio e executa uma lógica de negócio ao receber os dados que vêm

da visão, esta, por sua vez, é composta pela hierarquia dos componentes UI

(Component Tree) e o controle é composto por FacesServlet, por arquivos de

configurações, e por um conjunto de manipuladores de ações e observadores de

eventos. O FacesServlet é um servlet que recebe as requisições da web e remete

uma resposta ao modelo. Os arquivos associam e mapeiam as ações e definem as

regras de navegação e os manipuladores de eventos recebem os dados da visão e

acessam o modelo e devolvem o resultado ao FacesServlet. (PITANGA, 2013)

O JSF tem duas funções principais: a primeira é gerar uma UI, normalmente

uma resposta de um documento Hypertext Markup Language (HTML), encaminhado

para um navegador e visualizado como uma página web. Essa UI é representada no

servidor por meio de uma árvore de componentes. Há um mapeamento um para um

entre os elementos da árvore e os elementos da UI. Essa separação entre a árvore

de componentes e o UI permite a JSF trabalhar com diferentes tipos de linguagens

de marcação ou ambientes alternativos de navegadores como, por exemplo, desktop

31

ou smartphones. A segunda função do JSF é responder aos eventos disparados

pelo usuário na página chamando os listeners no servidor, seguido pela geração de

outro UI ou uma atualização da UI já mostrada na tela. O JSF faz parte da

plataforma padrão do Java Enterprise Edition (Java EE), isso significa que o JSF faz

parte de todo servidor de aplicações Java EE, como por exemplo, Oracle’s Web

Logic, GlassFish Open Source Edition, ou JBoss AS. Mas ainda pode ser usado

como biblioteca em servlet containers como Tomcat e Jetty. (JAVASERVERFACES,

2013)

A arquitetura JSF no modelo MVC está demonstrada na Figura 2.1.

Figura 2.1 - Arquitetura JSF baseada no modelo MVC Fonte: Pitanga, 2013 (adaptada pelos autores)

Usar JSF como framework para desenvolver aplicações web é a certeza de

se trabalhar com os melhores elementos descobertos durante anos de experiência

no desenvolvimento web, unidos em uma única API padrão, fácil de entender,

estável e flexível. Foram implementados os melhores padrões de desenvolvimento

baseados em experiências com outros frameworks já existentes e que possuem a

mesma finalidade. (BURNS; SCHALK, 2010)

Algumas vantagens em utilizar o JSF são: facilidade na construção de uma UI

usando um conjunto de componentes reutilizáveis, simplicidade na migração de

dados da aplicação para a UI e provenientes da mesma, auxílio no gerenciamento

32

do estado da UI nas solicitações do servidor, oferta de um modelo simples de

conexão entre os eventos gerados pelo cliente e o código da aplicação do servidor e

personalização dos componentes da UI, para que sejam facilmente construídos e

reutilizados. (NETBEANS, 2013)

Segundo Gonçalves (2008), o FacesServlet faz a rota do tráfego das

requisições e administra o clico de vida do JSF, este ciclo é composto por seis fases,

cada uma tem uma importância no processo. Pode acontecer de uma requisição

passar por todas as fases, porém, pode acontecer também de não passar por

nenhuma delas, dependendo do tipo de pedido de erros em que ocorram as

validações, conversões e do tipo de resposta. As referidas fases, desde o momento

em que a requisição chega ao servidor até a renderização da página, seguem a

seguinte ordem:

• Primeira fase: restaurar a apresentação – fase de início do

processamento da requisição do ciclo de vida a partir da construção da

árvore de componentes do JSF.

• Segunda fase: aplicar os valores de requisição – é a fase em que todos

os novos valores inseridos são extraídos e armazenados por seus

apropriados componentes. Se o valor dos componentes não for uma

string é feita a conversão, se a mesma falhar, ocorrem diversas situações

de erros.

• Terceira fase: processar validações – após o valor de cada componente

ser atualizado; nesta fase, os componentes, se necessário, são validados.

O componente que precisa ser validado deve fornecer implementação da

lógica de validação.

• Quarta fase: atualizar valores do modelo – os dados do modelo do

aplicativo são atualizados após terem sido validados na fase anterior,

exceto nos casos em que a lógica de negócios determine a validação em

outra fase.

• Quinta fase: invocar a aplicação – a implementação JSF manipula

quaisquer eventos do aplicativo, como ir para outra página através de um

link. Esses eventos retornam geralmente uma string que está associada à

navegação e que se encarrega de chamar a página determinada.

• Sexta fase: renderizar a resposta – esta é a fase final em que a página é

33

renderizada, ou seja, montada e devolvida ao servidor para ser exibida.

Na Figura 2.2 está representado o ciclo de vida do JavaServer Faces.

Figura 2.2 - Ciclo de vida do JavaServer Faces Fonte: Devmedia, 2013

2.2 PRIMEFACES

O PrimeFaces é uma biblioteca de componentes JSF em um único arquivo

Java (Java Archive – JAR) e possui menos de 2 Megabytes (MB). Esta biblioteca foi

desenvolvida para facilitar o trabalho com JSF e para aumentar sua flexibilidade e

suas funcionalidades, possibilitando maior produtividade no desenvolvimento. Para

usar os componentes PrimeFaces nas páginas de um projeto JSF é necessário

apenas adicionar esse arquivo no classpath e importar o namespace da biblioteca,

sem a necessidade de fazer configurações e sem dependência externa. O

PrimeFaces é baseado nas APIs padrões do JSF 2.0 e os scripts do PrimeFaces

executados pelo cliente são baseados na biblioteca jQuery. (ÇALIŞKAN;

VARAKSIN, 2013)

A biblioteca PrimeFaces possui mais que 100 componentes

(PRIMEFACES.ORG, 2013). Cada um possui um objetivo diferente, mas é possível

realizar um projeto bem elaborado com a integração de vários desses componentes.

(LUCKOW; MELO, 2010)

34

2.3 SPRING FRAMEWORK E SPRING SECURITY

O Spring é um framework de código aberto do Java para o desenvolvimento

com Java Enterprise Edition (Java EE). O objetivo do Spring é reduzir a

complexidade do desenvolvimento, principalmente em aplicações web.

Este framework teve grande aceitação por ser adaptável às bibliotecas

padrões existentes. Sua característica principal é instanciar classes injetando

dependências. (GONÇALVES, 2008).

O Spring possui vários módulos, entre eles está o Spring Security, que é um

framework de segurança, usado para garantir a autenticação e a autorização dos

usuários, ou seja, é uma ferramenta de segurança e controle. (LUCKOW; MELO,

2010)

Segundo Scarioni (2013) o Spring Security fornece várias vantagens:

• Dá suporte para muitos modelos de autenticação;

• Fornece serviços de segurança para diferentes camadas;

• É um módulo de código aberto, assim como o Spring framework.

2.4 JAVA PERSISTENCE API (JPA)

As ferramentas de mapeamento objeto-relacional, em inglês, Object-

Relational Mapping (ORM) foram criadas para facilitar a comunicação entre as

aplicações Java e os bancos de dados que seguem o modelo entidade

relacionamento. Estas ferramentas automatizam a transição de dados entre as

aplicações e os diferentes bancos de dados. O uso das ferramentas ORM dispensa

a escrita de consultas em SQL, a própria ferramenta gera as consultas de acordo

com a sintaxe da SQL correspondente ao banco que está sendo utilizado.

Os pontos básicos de uma solução ORM são:

• Uma API para realização das operações CRUD em objetos de classes

persistentes;

• Uma linguagem ou API para especificar consultas que se referem às

classes ou às propriedades das classes;

• Facilidade de especificar o metadado de mapeamento;

• Uma técnica para que a implementação ORM interaja com objetos

35

transacionais para fazer verificações. (LUCKOW; MELO, 2010)

Segundo Gonçalves (2007) o JPA é uma especificação, que não depende de

um container para funcionar e foi criada para padronizar as ferramentas ORM para

aplicações Java facilitando o desenvolvimento.

O JPA especifica um conjunto de classes e métodos que as ferramentas de

ORM devem implementar. As implementações mais conhecidades do JPA são:

Hibernate, EclipseLink, OpenJPA e Batoo. O JPA criou uma linguagem de consulta

chamada Java Persistence Query Language (JPQL) para realizar as consultas no

banco; a vantagem é que a mesma consulta pode ser feita em todos os bancos de

dados. (OLIVEIRA, 2012)

2.5 BANCOS DE DADOS

Um banco de dados (BD) pode ser definido como uma coleção de dados

relacionados. Dados são fatos que possuem um significado subentendido e que

podem ser gravados, como nomes, números de documentos, valores. Um conjunto

desses dados formam as informações, portanto, um banco de dados. Entretanto,

esta definição é muito ampla, o termo banco de dados é geralmente utilizado de

maneira mais específica, pois possui implicitamente as seguintes propriedades:

representa aspectos do mundo real, é uma coleção lógica de dados que possuem

um sentido próprio e é projetado e preenchido com dados para atender uma

necessidade específica. O tamanho e a complexidade do banco de dados pode ser

variável, desde que ele atenda as necessidades dos interessados em seu conteúdo.

(ELMASRI; NAVATHE, 2005)

Bancos de dados relacionais e não relacionais tratam assuntos como

transações e integridade de dados de formas diferentes. Para melhor compreensão

dessas diferenças e o que elas significam para a aplicação é recomendável que se

compreenda os conceitos a seguir sobre as propriedades dos bancos de dados.

(TIWARI, 2011)

2.5.1 Processos de transações ACID

O processamento de transação é uma unidade de execução do programa que

acessa e atualiza os dados, normalmente escrita em uma linguagem de

36

manipulação de dados. O programador define, de forma apropriada, diversas

transações, para que o banco de dados garanta sua integridade. Essas transações

possuem um conjunto de propriedades: Atomicidade, Consistência, Isolamento e

Durabilidade (ACID). Em seguida estão alguns detalhes sobre cada propriedade

ACID (SILBERSCHATZ; KORTH; SUDARSHAN, 2006):

• Atomicidade – todas as ações das transações são refletidas

corretamente no banco de dados ou nenhuma delas. O banco acompanha

os dados, se ocorrerem falhas, as informações não são atualizadas e os

dados voltam ao estado anterior.

• Consistência – para preservar a consistência do banco, a execução de

uma transação é feita do início ao fim sem a interferência de outras

transações, o banco de dados é levado de um estado de consistência

para outro.

• Isolamento – embora aceite a execução de transações simultâneas,

garante que para cada par de transações pareça que uma apenas iniciou

quando a outra terminou ou vice versa, fazendo com que uma transação

não saiba o que acontece com as outras, mesmo sendo executada

simultaneamente, isso, para evitar que as transações possam intercalar,

provocando resultados indesejáveis. Essa propriedade é garantida por um

componente do banco de dados, chamado Componente de Controle de

Concorrência.

• Durabilidade – após uma transação ser completada com sucesso, há

uma persistência das mudanças feitas por ela no banco, ainda que

ocorram falhas no sistema.

Ainda de acordo com Silberschatz, Korth, Sudarshan (2006), quando não

encontram falhas, as transações são completadas com sucesso, quando isso ocorre,

a transação é considerada confirmada (commited). Após a transação ser

confirmada, não se pode desfazer seus efeitos no banco, a não ser que se faça uma

transação de compensação, mas isso é responsabilidade do usuário. Uma transação

precisa estar em um dos seguintes estados:

• Ativa: é o estado inicial, enquanto estiver executando, a transação

permanece neste estado;

• Parcialmente confirmada: após a instrução final ser executada;

37

• Falha: depois de verificado que a instrução normal não pode mais

prosseguir;

• Abortada: depois que a transação foi revertida, o banco retoma seu

estado anterior de antes do início da transação;

• Confirmada: depois de terminada com sucesso.

Na Figura 2.3 está representada uma transação passando por todos os seus

estados, ela é considerada terminada quando abortada ou confirmada.

Figura 2.3 - Diagrama de estado de uma transação Fonte: Silberschatz; Korth; Sudarshan, 2006, p.412 (adaptada pelos autores)

2.5.2 O Teorema CAP

O teorema de Consistência, Alta disponibilidade e Partição tolerável (CAP),

em inglês CAP Theorem (Consistency, Availability and Partition tolerancy) de acordo

com Tiwari (2011) são os três pilares do teorema de Brewer, no qual é

fundamentada a recente geração de ideias sobre integração de transações em

grandes sistemas distribuídos escaláveis. De acordo com esse teorema é impossível

que sejam aplicadas as três propriedades ao mesmo tempo, uma sempre será

sacrificada a favor das outras duas. A seguir estão cada uma das propriedades do

teorema de CAP e seus significados segundo Tiwari (2011):

• Consistência – esse termo não é muito bem definido, mas no contexto

para o CAP refere-se à atomicidade e isolamento. Quando se trata de

apenas um servidor a consistência dos dados pode ser atingida pela

38

semântica ACID, mas fica bem mais complexo quando se trata de

sistemas distribuídos.

• Alta disponibilidade – significa que o sistema está disponível para servir

no momento em que for necessário, se o sistema estiver ocupado, pouco

comunicativo ou indiferente quando acessado ele é considerado

indisponível.

• Partição tolerável – os modelos de processamentos paralelos e de

escalas são métodos comprovados e estão sendo utilizados para fornecer

desempenho superior em supercomputadores. A partição tolerável mede

a capacidade de o sistema continuar em serviço caso alguns dos nós do

cluster fique indisponível.

Tiwari (2011) afirma ainda que, uma vez que não é possível beneficiar-se das

três propriedades juntas, as mesmas podem ser escolhidas de acordo com o

objetivo que se pretenda atingir, da seguinte forma:

• Primeira opção – A alta disponibilidade é comprometida, a consistência e

a partição tolerável têm a preferência (C/P);

• Segunda opção – O sistema terá pouca ou nenhuma partição tolerável, a

preferência é pela consistência e alta disponibilidade (C/A);

• Terceira opção – A consistência é comprometida, mas os sistemas estão

sempre disponíveis e podem trabalhar quando há partição, ou seja, as

partes são divididas (D/P).

Na Figura 2.4 está o exemplo de como ocorrem as opções de escolhas dos

quesitos do Teorema CAP, tomando como exemplos alguns diferentes tipos de BDs.

Figura 2.4 - Escolha das propriedades do Teorema CAP Fonte: Sousa, 2010

39

Os bancos de dados relacionais, nas transações tradicionais, optam sempre

pela primeira opção em circunstâncias de escalonamento horizontal, caso em que a

alta disponibilidade é afetada por vários fatores, como: atraso na rede, gargalos na

comunicação, esgotamento de recursos, entre outros. (TIWARI, 2011)

2.5.3 Basically Available Soft Eventually Consistent (BASE)

Tiwari (2011) afirma que Eric Brewer e outros criaram o termo Basically

Available Soft Eventually Consistent (BASE) para denominar o caso de consistência

eventual no banco de dados. Este termo surgiu para combater o ACID, entretanto,

BASE e ACID não são opostos, porém, retratam diferentes pontos de vista de

consistência.

O ACID foi explicado anteriormente, tornando assim mais simples o

entendimento de como funciona a consistência eventual (BASE) e as diferenças

entre os dois conceitos.

Conforme Tiwari (2011) há situações em que é possível comprometer a

consistência forte, no caso, por exemplo, da disponibilidade não poder ser

comprometida e o sistema ser tão distribuído que a partição tolerável seja

necessária. A inconsistência de dados provavelmente não é uma escolha para um

sistema sério, entretanto, a consistência eventual pode ser uma opção aceitável,

pois ela significa que mais cedo ou mais tarde a consistência vai acontecer. A

consistência eventual acontece quando uma atualização é feita e após isso todos os

nós do cluster aparecem no mesmo estado, eventualmente. Essa eventualidade

acontece dentro de certos limites, logo, o modelo de consistência eventual pode

funcionar.

Tiwari (2011) utiliza como exemplo prático de consistência eventual um

sistema de vendas, em que um carrinho de compras pode permitir pedidos, mesmo

não sendo capaz de confirmar com o sistema de estoque sobre a disponibilidade do

produto. Há possibilidades de o estoque do produto estar zerado, então o pedido

pode ficar reservado para ser atendido assim que o estoque for reabastecido.

São apresentados por Tiwari (2011) três critérios, e a partir de diferentes

combinações entre eles são demonstradas situações que podem causar efeitos

diversos na consistência, os critérios são:

R – Número de nós de leitura

40

W – Número de nós de escrita

N – Número total de nós do cluster

Mantendo R<N e W<N permite-se maior disponibilidade, porém, podem

ocorrer situações em que:

• R+W>N – pode ser estabelecido um estado consistente, pois há uma

intersecção entre nós de leitura e de escrita, quando R=N e W=N, ou seja,

R+W=2N, o sistema fica absolutamente consistente, podendo

proporcionar segurança ACID.

• R=1, W=N – o sistema tem mais leituras que escritas, pode-se permitir

que todos os nós do cluster de leitura recebam e respondam requisições

de leitura, se R=1, os nós atuam independentes uns dos outros. W=N

quer dizer que se deve confirmar a escrita em todos os nós para fazer

uma atualização, se houver uma falha em pelo menos algum nó, o

sistema fica indisponível para escrita/gravação.

• R=N, W=1 – se a escrita para um nó for suficiente, é elevada a chance de

inconsistência, e se R=N, a leitura somente é permitida se todos os nós

do cluster estiverem disponíveis.

• R=W=ceiling((N+1)/2) – isso proporciona uma estatística efetiva para

permitir consistência eventual.

É possível implementar a consistência eventual de várias formas, podendo

envolver sistemas orientados a mensagens, em que se propaga uma atualização

usando uma fila de mensagens ou simplesmente usando identificações exclusivas

sequenciais, ou um consenso baseado em estatísticas. (TIWARI, 2011)

Logo a seguir, descreve-se sobre outro conceito que ajudará na compreensão

de como funciona o armazenamento de dados nos bancos de dados relacionais e

não relacionais.

2.5.4 Agregados

As informações a serem armazenadas em bancos de dados relacionais

precisam ser divididas em várias tuplas, pois uma tupla respresenta uma estrutura

de dados limitada. Elas são conjuntos de valores, não é possível aninhar uma tupla

dentro de outra nem registrar uma lista de valores dentro de uma tupla. Essa

simplicidade reforça o modelo relacional, pois fornece a possibilidade de imaginar

41

que todas as operações são realizadas em tuplas e retornam tuplas. (SADALAGE;

FOWLER, 2012)

Segundo Sadalage; Fowler (2012), outro conceito de organizar as

informações é a orientação a agregados. Reconhecendo que muitas vezes é

desejado operar em unidades de dados mais complexas que tuplas, podendo conter

outras estruturas dentro dela. Os bancos de dados NoSQL dos tipos key/value,

document stores e column family, que serão apresentados logo mais, fazem uso

desses registros de dados mais complexos. Por não ter um termo definido para este

tipo de unidade de dado, neste trabalho está sendo usado o termo agregado de

acordo com a definição dada por muitos autores nesse sentido, um termo com raiz

no Domain-Driven-Design, um método de desenvolvimento de software complexo.

(SADALAGE; FOWLER, 2012)

2.5.5 Tipos de Bancos de Dados

A escolha do banco de dados a ser utilizado em uma aplicação é uma decisão

importante que deve ser tomada na fase de planejamento de um projeto, pois

determina várias características da futura aplicação, entre elas, a integridade dos

dados, os tratamentos de concorrência de acesso de diferentes usuários, os meios

de acesso aos dados, as possibilidades de fazer consultas no banco, a performance

e a escalabilidade. Portanto, esta decisão deve ser muito bem analisada, baseando-

se no tipo de aplicação e no ambiente de produção a serem utilizados.

Além dos bancos de dados relacionais, que é o modelo de BD mais utilizado,

existem vários outros conceitos de BDs, que são os não relacionais. A seguir, estão

demonstrados os principais conceitos de BDs, abordando suas principais

características, com o objetivo de facilitar a escolha de um BD para a aplicação a ser

desenvolvida.

2.5.6 Bancos de Dados Relacionais

O modelo relacional de BDs foi introduzido em 1970, por Edgar Frank Codd,

em uma publicação com o título: "A relational model of data for large shared data

banks", na revista da Association for Computing Machinery (ACM). Essa publicação

revolucionária demonstrou como tabelas podem ser usadas para representar objetos

42

do mundo real e como os dados podem ser armazenados para os objetos. A

integridade dos dados nesse conceito foi levada mais a sério que em qualquer

modelo de BDs antes visto. Desde esta publicação surgiram muitos BDs utilizando

esse conceito e conquistaram um status quase padrão para uso no desenvolvimento

de aplicações. (MATTHEW; STONES, 2005)

O conceito é baseado na teoria relacional da matemática, por isso há uma

grande flexibilidade para o acesso e a manipulação de dados gravados no BD.

Usando técnicas simples, como normalização na modelagem do BD, criam-se várias

tabelas relacionadas, as quais servem como base para consultas usando uma

linguagem de consulta quase padronizada, a Structured Query Language - SQL. Um

BD relacional, basicamente, contém relações (tabelas) com atributos (colunas) e

tuplas (linhas). Todo atributo tem um tipo de dado definido, uma tupla representa um

conjunto de dados com um valor para cada atributo da linha e as tabelas são

relacionadas através de chaves. (MATTHEW; STONES, 2005)

Figura 2.5 - Agregado no UI é conjunto de várias tuplas de várias tabelas Fonte: Sadalage; Fowler, 2013, p.29

O uso de BDs relacionais torna necessário dividir agregados utilizados na

aplicação em várias relações conforme as regras da normalização. Para recuperar o

mesmo agregado são necessárias consultas utilizando joins, uma operação que

dependendo da quantidade e do tamanho das relações pode ser muito custosa no

43

sentido de necessidade de processamento. Nos casos em que se deseja uma

resposta rápida de um sistema isso pode ser uma desvantagem. (SADALAGE;

FOWLER, 2013)

Na Figura 2.5 está ilustrado um exemplo de divisão de agregado e as

relações resultantes.

2.5.7 NoSQL

A expressão NoSQL é um termo não definido claramente, a primeira vez que

surgiu foi em 1998 como um nome para o banco de dados relacional de Carlo

Strozzi, que assim o nomeou por não fornecer uma SQL-API. O mesmo termo foi

usado na formação do nome do evento NoSQL Meetup em 2009, o qual teve como

objetivo a discussão sobre sistemas de banco de dados distribuídos. Como nessa

reunião somente foi discutido sobre BDs não relacionais, o termo começou a ser

usado para o movimento de BDs não relacionais em geral. (EDLICH, S. et al., 2010)

NoSQL-database (2013) fornece a seguinte definição, livremente traduzida:

Sob NoSQL entende-se uma nova geração de BDs, os quais na maioria das vezes

atendem algumas das características abaixo (NOSQL-DATABASE, 2013):

• O modelo de dados não é relacional;

• Os sistemas são projetados para escalabilidade distribuída e horizontal;

• O sistema NoSQL é de código aberto (open-source);

• O sistema é livre de esquemas ou somente tem restrições fracas de

esquemas;

• Devido à arquitetura distribuída o sistema possibilita uma fácil replicação

de dados;

• O sistema fornece uma API simples;

• O sistema na maioria das vezes é baseado num modelo de consistência

diferente: Eventually Consistent e BASE, mas não ACID.

Parece que a força dos BDs relacionais motivou todos os sistemas não

relacionais quererem entrar na categoria dos BDs NoSQL. O arquivo NOSQL-

DATABASE recebeu até maio de 2013, mais de 150 solicitações de sistemas não

relacionais para serem colocados na listagem. Entre os solicitantes, empresas como

Oracle e IBM, duas das empresas mais fortes no campo dos BDs relacionais.

Na Figura 2.6 está

com suas respectivas categorias.

Figura 2.6 - Bancos de dados relacionais x não relacionaisFonte: Edlich, et al., 2010, p.6 (adapatada pelos autores)

Os principais motivos para o sucesso dos BDs relacionais são: grande

flexibilidade de consultas, facilidade de modelagem seguindo regras

padronização), fundamento na matemática relacional e a garantia de fornecer dados

consistentes. Entretanto, desde o ano 2000, o crescimento rápido de algumas

empresas da web, o surgimento de enormes quantidades de dados, as novas fontes

de dados como: redes sociais, comportamento de usuários da internet, fóruns e

muitos outros, provocaram a necessidade de mais recursos de computação. Para

aumentar a capacidade de processamento existem duas possibilidades: servidores

mais potentes ou um conjunto de v

algumas vantagens sobre a primeira

servidores pequenos do que em um bastante potente e maior resistência

pois se houver problema com um servidor, o serviço pode continuar disponível.


Por outro lado, caso seja utilizado um BD com custo de licença, o custo pode

ser muito grande utilizando

único servidor, multiplicando, assim, o custo. Mas o maior problema é que os BDs

está ilustrada a divisão dos grupos de BDs existentes de acordo

com suas respectivas categorias.

Bancos de dados relacionais x não relacionais , 2010, p.6 (adapatada pelos autores)


flexibilidade de consultas, facilidade de modelagem seguindo regras




mo: redes sociais, comportamento de usuários da internet, fóruns e



mais potentes ou um conjunto de vários servidores (cluster). A segunda opção traz

algumas vantagens sobre a primeira, como: mais economia na aquisição de vários

servidores pequenos do que em um bastante potente e maior resistência




ser muito grande utilizando cluster, pois normalmente uma licença


44

a divisão dos grupos de BDs existentes de acordo


flexibilidade de consultas, facilidade de modelagem seguindo regras simples (quase




mo: redes sociais, comportamento de usuários da internet, fóruns e



). A segunda opção traz

: mais economia na aquisição de vários

servidores pequenos do que em um bastante potente e maior resistência a erros,



, pois normalmente uma licença é válida para um


45

relacionais não são projetados para funcionar em cluster. BDs relacionais para

cluster, como Oracle RAC ou Microsoft SQL Server, utilizam o conceito de um

subsistema de disco compartilhado (shared disk subsystem), porém esse

subsistema é o ponto de risco, pois havendo erro, o serviço completo ficará

indisponível. (SADALAGE; FOWLER, 2013)

Essa necessidade de bancos de dados serem projetados para cluster e de

trabalhar com grandes quantidades de dados motivou a utilização de outros

conceitos, cada vez mais presentes.

Os sistemas NoSQL são divididos em dois grupos:

O grupo de NoSQL-núcleo, incluindo os BDs que se encaixam nas seguintes

categorias:

• Key/Value stores (Armazenamento chave/valor)

• Document stores (Armazenamento de documento)

• Column Family stores (Armazenamento em famílias de colunas)

• Graph database (BDs de grafos)

E o grupo dos BDs não relacionais, que não são do tipo de bancos acima, por

exemplo, os BDs orientados a objetos, como o BDs XML ou outros. (EDLICH, S. et

al., 2010)

A seguir estão detalhadas as quatro categorias do NoSQL-núcleo com alguns

exemplos.

2.5.7.1 Key/Value stores

Os sistemas de armazenamento chave/valor pertencem a um dos grupos de

BDs mais antigos. Eles já foram utilizados nos anos 70, porém apenas ganharam

popularidade com o crescimento exponencial de dados a serem computados na era

da Web 2.0, ou seja, com o surgimento de empresas que tiveram de distribuir os

dados coletados em milhares de instâncias computacionais. Muitos desses dados

não são relacionados e por isso não há necessidade de representá-los em modelos

relacionais, os quais são muito difíceis de escalar e distribuir. (EDLICH, S. et al.,

2010)

Esses sistemas são os NoSQL BDs mais fáceis do ponto de vista de uso da

API, pois um agregado de qualquer tipo, representado por um binary large object

(BLOB), pode ser inserido, lido ou excluído do BD. Cada chave de acesso a um

46

valor trata-se sempre de acesso de chave primária, por isso, sistemas com esse

princípio são muito rápidos e fáceis de escalar. O valor associado a uma chave não

pode ser analisado pelo BD, assim, restringindo muito a capacidade de se fazer

consultas. O BD somente pode retornar o valor como um total, a responsabilidade

de saber o que esse valor representa e como ele deve ser interpretado é da

aplicação. (SADALAGE; FOWLER, 2013)

Na prática, muitos sistemas chave/valor fornecem recursos um pouco mais

avançados, como permitir que os valores sejam hashes1, sets ou listas. Dessa

forma, aumentam principalmente os recursos de consultas. Sistemas com essas

funcionalidades já se parecem bastante com os sistemas de famílias de colunas, os

quais serão abordados posteriormente. A maioria desses sistemas fornece a

possibilidade de agrupar pares de chave/valor. Comparado com sistemas

relacionais, podemos interpretar um grupo de chave/valores como uma tabela com

duas colunas, sendo uma para a chave e outra para o valor. No sistema Riak, que é

um dos sistemas chave/valor, esses grupos são chamados de bucket (balde).


Na Figura 2.7 está a estrutura de par chave/valor.

Figura 2.7 - Par chave/valor ou chave/documento Fonte: Sadalage; Fowler, 2013 (adaptada pelos autores)

1 Hashes – tipo específico de tabelas indexadas (SAWAYA M., 1999)

47

Convém lembrar que o objeto valor em sistemas comuns normalmente não

pode ser interpretado pelo banco de dados.

Sistemas chave/valor podem ser divididos em dois subgrupos: sistemas in-

memory e sistemas on-disk. Em sistemas da categoria in-memory, todos os dados

permanecem no Random Access Memory (RAM), a memória volátil. Os dados são

persistidos periodicamente na memória não volátil. Essa característica resulta em

uma alta performance, porém, gera o problema de, em caso de uma falha, os dados

não persistidos serem perdidos. Os sistemas on-disk não trazem esse risco, pois os

dados são persistidos diretamente, em contrapartida, a performance é muito menor.

(HEISE, 2013)

Alguns exemplos de sistemas chave/valor conhecidos são Redis, Riak,

BerkeleyDB, HamsterDB e Chordless, porém, existem muitos mais, e o número é

crescente. (NOSQL-DATABASE, 2013)

Como cada um desses sistemas trata assuntos como consistência,

escalabilidade e funcionalidades para consultas de formas diferentes, não basta

somente escolher um banco de dados chave/valor, é necessário também analisar

bem os recursos dos sistemas disponíveis e baseando-se nisto tentar fazer a melhor

opção.

2.5.7.2 Document stores

Os sistemas que usam o conceito de armazenamento de documentos são

bem parecidos com os de armazenamento chave/valor. Eles trabalham com o

mesmo conceito: para cada chave existe um valor, porém esse valor está

representado por um arquivo em formato de coleção de dados, como por exemplo,

JavaScript Object Notation (JSON), binary JSON (BSON), XML, entre outros. Esses

formatos representam estruturas de árvore hierárquica, as quais auto se explicam e

podem conter mapas, coleções ou valores escalares. Pela obrigação de gravar os

valores em formatos específicos, perde-se um pouco da liberdade de se trabalhar

sem esquemas, porém, em troca recebe um sistema de banco de dados com a

capacidade de examinar os documentos. Com isso, as consultas mais complexas do

que em sistemas chave/valor são possíveis. Pode-se ilustrar um par

chave/documento com a Figura 2.7, que também pode representar um par

chave/valor. A diferença é que se for interpretado como documento, pode-se

48

acessá-lo diretamente através de consultas, por exemplo, um “CartItem” e retorná-lo.


Os sistemas de armazenamento de documentos não fornecem relações entre

documentos, esse é um dos motivos pelo qual eles são candidatos perfeitos para

serem escalados horizontalmente. A maioria desses bancos de dados usam

sharding, que é uma forma de escalar quando os dados são divididos em nós

diferentes. Essa divisão de dados deve ser levada em consideração no

desenvolvimento da aplicação. (ROBINSON; WEBBER; EIFREM, 2013)

Alguns dos sistemas de armazenamento de documentos são: MongoDB,

CouchDB, RavenDB e Terrastore. (NOSQL-DATABASE, 2013)

Todos eles têm características específicas, as quais podem trazer vantagens

ou desvantagens para um projeto, por esta razão devem ser bem analisados

previamente.

2.5.7.3 Column family stores

A estrutura de dados armazenados em sistemas que trabalham com o

conceito de column families é parecida com a estrutura de tabelas dos bancos de

dados relacionais.

Uma família de colunas representa uma tabela com linhas, cada linha obtém

uma chave de acesso e cada coluna dessa linha recebe um par chave/valor. Ao

contrário das tabelas conhecidas no conceito relacional, cada linha tem as suas

próprias colunas, podendo ter diferentes tipos de valor e quantidade. Não existe um

esquema predefinido e é possível incluir ou excluir colunas em cada linha. (EDLICH;

S. et al., 2010)

Famílias de colunas representam grupos de dados relacionados que

normalmente são acessados em conjunto. Pode, por exemplo, fazer sentido

armazenar os dados pessoais de um cliente junto com o endereço dele, assim

sendo, é viável criar para esses dados uma família de colunas. Os pedidos

efetuados por um cliente, normalmente, não são consultados ao mesmo tempo em

que os seus dados, assim, os pedidos podem representar outra família de colunas.


Na Figura 2.8 está representado o conceito básico do modelo column family

stores.

49

Figura 2.8 - Modelo de dados de uma família de colunas Fonte: Sadalage; Fowler, 2013 (adaptada pelos autores)

Alguns sistemas de armazenamento em famílias de colunas também

fornecem o conceito de supercoluna (super column), que é uma ferramenta para

organizar as colunas de uma linha em grupos. Famílias de colunas contendo super

colunas também são chamadas famílias de super colunas (EDLICH, S. et al., 2010)

O desempenho de consultas para esse tipo de BDs depende muito da

modelagem dos dados. Cassandra, um BD do conceito de famílias de colunas, foi

projetado para funcionar muito bem em grandes clusters. Para otimizar consultas

nesse banco é recomendado criar uma família de colunas para cada tipo de consulta

que pode ser feita, desta maneira, uma desnormalização é provocada, porém, é

garantido que cada consulta possa ser respondida muito rapidamente. (FH KÖLN,

2013)

Figura 2.9 - Exemplo de duas linhas de uma família de colunas Fonte: FH Köln, 2013

50

A Figura 2.9 contém um exemplo de duas linhas de uma família de colunas,

das quais se diferenciam em número de colunas e tipo de valor armazenado,

mostrando a flexibilidade do conceito de famílias de colunas.

Alguns sistemas que fazem parte desse grupo de NoSQL BDs são:

Cassandra, HBase, Hypertable e AmazonSimple DB, todos possuem características

específicas.

O conceito de uma supercoluna está representado na Figura 2.10.

Figura 2.10 - Modelo de uma super coluna Fonte: FH Köln, 2013 (adaptada pelos autores)

2.5.7.4 Graph database

O conceito de BDs de grafos é bem diferente dos tipos de BDs do movimento

NoSQL discutidos até agora. Primeiramente, a maioria deles não permite uma

distribuição dos dados em servidores diferentes. Em contrapartida, existem BDs de

grafos, como Neo4J, que realizam transações ACID quando são executados em um

único servidor. (SADALAGE; FOWLER, 2013)

A representação de entidades e a relação entre elas podem ser realizadas de

uma maneira muito eficiente e representativa com os BDs de grafos. Basicamente

existem nós (entidades) que possuem propriedades e relações entre os nós

chamados edges, os quais também podem possuir propriedades; uma propriedade

nada mais é que um par chave/valor. A relação edges conecta duas entidades em

que a direção é significativa, desta maneira é possível criar modelos que mapeiam

uma rede complexa de relações. Quase todo tipo de problema pode ser

51

representado com grafos, porém, por se tratar de uma tecnologia de modelagem

recente, não é conveniente substituir plataformas bem entendidas e estabelecidas. A

introdução dessa tecnologia deve trazer benefícios significativos e há vários casos

de usos em que essa utilização deve ser estudada. (ROBINSON; WEBBER;

EIFREM, 2013)

A teoria dos grafos não é recente, ela foi introduzida no século XVIII por

Leonhard Euler, e estudada por matemáticos, sociólogos, antropólogos e muitos

outros desde aquela época, por isso é bem fundamentada e compreendida. Porém,

somente nos últimos anos ela entrou na realidade do gerenciamento de

informações. Desde então, BDs de grafos ajudam resolver problemas importantes,

como por exemplo, nas áreas de redes sociais, geografia, recomendações, finanças,

pesquisas e outros. A empresa Gartner Inc., que é uma empresa de pesquisas na

área de tecnologia de informação, define cinco grafos principais no mundo dos

negócios: grafos sociais, de intenção, de consumo, de interesse e de movimentação.

As empresas que pretendem ser altamente competitivas em um futuro próximo

devem ter mecanismos para capturar esses grafos e mecanismos e aproveitar essas

informações. (ROBINSON; WEBBER; EIFREM, 2013)

Figura 2.11 - Entidades com relacionamentos com propriedades Fonte: Sadalage; Fowler, 2013

A principal vantagem de banco de dados de grafos é o modo como os dados

são modelados, permitindo que consultas das quais os relacionamentos façam parte

52

possam ser efetuadas muito rapidamente. A princípio, uma entidade aponta

fisicamente para outra a qual está relacionada através, por exemplo, de ponteiros,

assim sendo, é possível atravessar o grafo rapidamente. Ao contrário dos modelos

relacionais em que uma relação pode ser recuperada por meio de joins e filtros, um

método lento, principalmente se o volume de dados for grande. (EDLICH, S. et al.,

2010)

Os BDs de grafos mais usados e conhecidos são: Neo4J, FlockDB, OrientDB,

InfoGris, HyperGraphDB, InfiniteGraph e Sones. (NOSQL-DATABASE, 2013)

Um exemplo simples de um grafo está representado na Figura 2.11.

2.5.8 Redis

Redis é um BD open source do tipo chave/valor, muitas vezes considerado

um servidor de estruturas de dados, por ter características bastante avançadas. Os

valores referenciados pelas chaves podem ter uma das estruturas: string, hash, list,

set ou sorted set. (REDIS, 2013)

O Redis é um BD muito rápido, principalmente por trabalhar com todos os

dados in-memory e porque a maioria de suas operações possui processamento

rápido. As operações realizadas pelo Redis são atômicas. (REDIS, 2013)

O BD Redis fornece vários recursos, entre eles: fácil replicação master/slave,

chaves com tempo de vida limitado, persistência de dados no disco seguindo

parâmetros livres e, principalmente, transações, uma característica incomum em

BDs não relacionais. A transação permitida pelo Redis garante que uma sequência

de operações será totalmente executada, ou que não se execute nenhuma das

operações. Além disso, é garantido que nenhum outro cliente será servido no meio

da transação. Porém, se comparadas às transações do BDs relacionais, as

realizadas no Redis são limitadas, mesmo porque no Redis não existe o comando

rollback, muito utilizado nos BDs relacionais. (REDIS, 2013)

A seguir estão as principais estruturas de dados do Redis e suas respectivas

características.

2.5.8.1 String

String é a estrutura de dados mais básica do Redis, podendo representar

53

qualquer tipo de dado, já que uma string é uma sequência de caracteres. Dessa

forma, esta estrutura de dados pode ser usada para armazenar uma instância de um

objeto por meio de uma chave, utilizando JSON, por exemplo. (SEGUIN, 2012)

Na Figura 2.12 está representado um par chave/valor do tipo string.

Figura 2.12 - Estrutura de dados tipo string Fonte: Carlson, 2013, p.9 (adaptada pelos autores)

2.5.8.2 Hash

A estrutura de dados hash é parecida com a string, porém, em vez de

armazenar uma sequência de caracteres para cada chave, a hash armazena pares

de subchave/valor, os quais serão acessíveis por meio de uma chave, ou seja, o

próprio valor é composto por pares do tipo chave/valor. Dessa forma, atinge-se uma

granularização menor e isso pode resultar em um melhor desempenho. O valor de

cada subchave pode ser ou uma string ou um valor numérico. Esta estrutura, em

muitas linguagens de programação, é conhecida como map. (CARLSON, 2013)

Na Figura 2.13 está representada uma hash com dois pares subchave/valor.

Figura 2.13 - Estrutura de dados tipo hash Fonte: Carlson, 2013, p.12 (adaptada pelos autores)

54

2.5.8.3 List

List é uma estrutura de dados para armazenar e manipular valores referentes

a uma chave, ou seja, uma lista. É possível adicionar elementos nesta lista (push),

recuperar o primeiro ou último elemento (pop) ou ainda manipular um elemento de

uma posição qualquer. As listas sempre mantêm a ordem dos elementos

armazenados. (SEGUIN, 2012)

Entre os BDs do tipo chave/valor, Redis é o único que fornece a estrutura de

dados do tipo list. (CARLSON, 2013)

O exemplo de uma lista pode ser visto na Figura 2.14.

Figura 2.14 - Estrutura de dados tipo list Fonte: Carlson, 2013, p.10 (adaptada pelos autores)

As listas podem ser muito bem utilizadas em vários cenários, por exemplo, no

armazenamento dos cinquenta usuários mais recentes de um site ou do caminho

que um usuário percorre em um site (usertracking) ou, ainda, no caso de um jogo,

no registro das ações dos jogadores. (SEGUIN, 2012)

2.5.8.4 Set

Um set é uma estrutura de dados que representa um conjunto de elementos.

O Redis fornece para esta estrutura de dados operações de conjuntos eficientes. Os

sets não são ordenados. Um exemplo típico para a utilização de sets é a lista de

amigos de um usuário. A operação para descobrir se um amigo pertence ou não a

um usuário tem um tempo de processamento independente da quantidade de

amigos armazenados, isto quer dizer que, mesmo se um usuário tiver um milhão de

55

amigos, o tempo para descobrir se um usuário é amigo ou não, é o mesmo, como

ele tivesse somente dez amigos. Operações com essa característica são

denominadas O(1)-operações. Outra operação bastante útil é a intersecção, com

ela, facilmente descobre-se, por exemplo, quais são os amigos em comum entre

dois ou mais usuários (SEGUIN, 2012). Na Figura 2.15 está um set em Redis.

Figura 2.15 - Estrutura de dados tipo set Fonte: Carlson, 2013, p.11 (adaptada pelos autores)

2.5.8.5 Sorted Set

Sorted set é a estrutura de dados mais poderosa do Redis, são conjuntos

ordenados, ou seja, cada elemento deste conjunto está armazenado juntamente

com um valor numérico a fim de classificá-lo. Nesta estrutura é possível recuperar os

elementos referentes a uma chave de certo intervalo de números inteiros.

Retomando o exemplo da lista de amigos, poderia utilizar-se sorted set,

armazenando um número entre um e dez para cada amigo, classificando-os. Desta

forma, pode-se, por exemplo, solicitar ao Redis retornar os amigos com uma

classificação maior que oito ou coisa parecida. (SEGUIN, 2012)

A Figura 2.16 contém a estrutura de dados sorted set com dois elementos.

Figura 2.16 - Estrutura de dados tipo sorted set Fonte: Carlson, 2013, p.11 (adaptada pelos autores)

56

A combinação de mais de um tipo de BD em um único projeto é possível e

pode trazer algumas vantagens, como demonstra o conceito de persistência

poliglota demonstrado a seguir.

2.5.9 Persistência Poliglota

Diferentes BDs são projetados para atender diversas necessidades e resolver

problemas distintos. Escolher um único BD para atender todos os requisitos de uma

aplicação pode resultar em uma solução com baixo desempenho em alguns

aspectos. (SADALAGE; FOWLER, 2013)

Na Figura 2.17 está ilustrado o uso de um BD relacional para todos os

requisitos de um e-commerce, como por exemplo, dados do carrinho de compras, da

sessão, pedidos completos entre outros.

Figura 2.17 - Uso de um BD relacional para todos os requisitos de armazenagem Fonte: Sadalage; Fowler, 2013 (adaptada pelos autores)

É possível usar um BD específico para cada requisito, aproveitando as

características de cada um. Soluções que envolvam mais que um BD são chamadas

de sistemas com persistência poliglota (polyglot persistence). (SADALAGE;

FOWLER, 2013)

A Figura 2.18 contém o exemplo de uma plataforma e-commerce utilizando

57

quatro tipos de BDs. (SADALAGE; FOWLER, 2013)

Obviamente, uma solução envolvendo vários bancos de dados não traz

somente vantagens, a complexidade de programação e operação aumenta com a

utilização deles. Pode ser difícil achar profissionais para um certo tipo de banco, por

se tratar de tecnologias novas, por isso deve se avaliar muito bem se a utilização de

múltiplos bancos de dados vai trazer vantagens suficientes para valer a pena

aumentar o risco de um projeto. (SADALAGE; FOWLER, 2013)

Figura 2.18 - Exemplo de implementação de persistência poliglota Fonte: Sadalage; Fowler, 2013 (adaptada pelos autores)

Este capítulo abordou algumas tecnologias utilizadas para o desenvolvimento

do portal, no próximo capítulo estão os requisitos levantados e as etapas do

desenvolvimento.

58

3 REQUISITOS DO SISTEMA

O desenvolvimento de um software possui algumas fases, chamadas de

atividades, que são organizadas de alguma maneira com o objetivo de obter-se um

resultado de qualidade, ou seja, um software que atenda as necessidades propostas

inicialmente.

Bezerra (2007) descreve essas atividades da seguinte forma:

• Levantamento de requisitos: esta atividade define as necessidades reais

do sistema, também chamadas de requisitos, que são compreendidas por

meio da análise do negócio baseada no mundo real.

• Análise de requisitos: é o estudo detalhado dos requisitos levantados com

a finalidade de entender como o sistema funciona e como seus

componentes interagem. A análise de requisitos não se preocupa com o

ambiente tecnológico, ela foca na estratégia a ser utilizada e não na

maneira como será realizada, nessa fase é construído um modelo para

representar o sistema.

• Projeto: nesta fase é definido como o sistema deve funcionar para atender

os requisitos, atendendo o modelo construído na fase anterior. São

realizadas duas atividades: projeto da arquitetura, de alto nível, em que os

componentes são distribuídos fisicamente de acordo com os recursos de

hardware disponíveis; e projeto detalhado, de baixo nível, trata-se das

funcionalidades do módulo, projeto da interface com o usuário e projeto

de banco de dados.

• Implementação: fase de codificar o sistema, em que se utiliza uma ou

mais linguagens de programação. A descrição computacional da fase de

projeto é traduzida em códigos executáveis.

• Testes: realiza-se diversos testes para verificação do funcionamento do

sistema, emitindo relatórios de erros detectados, após os testes os

módulos do sistema são integrados gerando o produto final.

• Implantação: o sistema é implantado no ambiente do usuário.

As fases apresentadas podem ser organizadas de várias maneiras, cada

modelo de organização dessas fases determina um modelo de ciclo de vida de um

sistema, foram escolhidos dois destes modelos, que serão demonstrados logo mais:

59

o modelo em cascata e o modelo iterativo e incremental. (BEZERRA, 2007)

No modelo de ciclo de vida em cascata as atividades são executadas em

sequência, isso facilita a gestão do projeto, contudo, as atividades de requisitos e

análises devem ser muito bem dominadas, pois não são permitidos erros. O cliente

só tem visão do projeto após sua conclusão, ou seja, ele não acompanha as fases

do projeto em desenvolvimento. (PAULA, 2008)

Na Figura 3.1 está ilustrado o modelo de ciclo de vida em cascata.

Figura 3.1 - Modelo de ciclo de vida em cascata Fonte: Bezerra, 2007, p.32

Modelo em cascata é atualmente pouco utilizado devido à grande

complexidade dos sistemas, pois há algumas desvantagens em sua utilização,

como: os requisitos precisam ser detalhadamente definidos antes do início do

projeto, podendo gerar futuros desperdícios de recursos; podem ocorrer erros que

só serão detectados no momento em que o usuário começar utilizar o sistema, e a

falha pode propagar por todas as fases seguintes e como o sistema não estará

pronto enquanto o ciclo do projeto não chegue ao final, o tempo para término do

sistema pode ser muito longo. (BEZERRA, 2007)

O ciclo de vida iterativo e incremental foi proposto para sanar as falhas do

modelo em cascata. O conceito de ciclo de vida iterativo e incremental divide o

desenvolvimento do sistema em ciclos, e cada fase é identificada em cada ciclo.

(BEZERRA, 2007)

O incremental é um modelo que, em geral, é escolhido para atender a

60

necessidade de oferecer rapidamente um conjunto limitado de funcionalidades e

posteriormente refinar e expandir cada funcionalidade em versões subsequentes do

sistema. Este modelo combina elementos do modelo em cascata de maneira

iterativa. Cada sequencia de elementos produz incrementos que podem ser

entregues ao usuário. Os primeiros incrementos são versões simplificadas do

sistema e podem servir para avaliações, o modelo incremental é bastante útil

quando não há mão de obra disponível para implementação completa do software

dentro do prazo estabelecido (PRESSMAN, 2011). Por esse motivo este foi o

modelo de ciclo de vida escolhido para o desenvolvimento do sistema resultante

deste trabalho.

Na Figura 3.2 está representado um modelo incremental e iterativo de ciclo de

vida de um sistema.

Figura 3.2 - Modelo de ciclo de vida incremental e iterativo Fonte: Bezerra, 2007, p.33

Em seguida estão as primeiras fases do desenvolvimento do sistema

proposto neste trabalho. As atividades estão descritas na mesma ordem em que

foram sendo realizadas.

3.1 LEVANTAMENTO DE REQUISITOS

Os requisitos levantados no desenvolvimento de um software podem ser

classificados em funcionais ou não funcionais. Robert Grady da Hewlett Packard

desenvolveu uma classificação para os requisitos funcionais e não funcionais,

61

utilizando o termo em inglês functionality para classificar os requisitos funcionais, e

para os requisitos não funcionais, os termos também em inglês, reliability,

performance e supportability, formando o acrônimo FURPS. Ele utilizou também o

sinal de “+” no final da palavra FURPS para referenciar-se a outras restrições, como

concepção, implementação, interface e limitações físicas do sistema. (EELES, 2004)

Logo a seguir os requisitos estão abordados mais detalhadamente de acordo

com a classificação feita por Robert Grady:

3.1.1 Requisitos funcionais

Os requisitos funcionais, que de acordo com a classificação FURPS é o “F” de

functionality, significa funcionalidade (EELES, 2004). Esse tipo de requisito

representa o comportamento que o sistema apresenta devido às ações dos

usuários; os tipos de transações suportadas pelo sistema é um exemplo de requisito

funcional. Estes requisitos são capturados por uma ferramenta chamada caso de

uso, cada caso de uso representa uma parte de funcionalidade do sistema, os

relacionamentos dos casos de uso com os grupos de usuários e entre si são

descritos dentro da visão (diagrama) de casos de uso. O fluxo em que as funções

são executadas obedece a um padrão dentro da especificação dos requisitos.

(PAULA, 2008)

O sistema proposto neste trabalho tem o objetivo de fazer a intermediação

entre estabelecimentos que vendam comida pronta para entrega em domicílio e

seus consumidores. De acordo com a análise realizada para definição das

necessidades do mesmo, definiu-se que a plataforma deverá ser acessível por meio

da internet, em que o consumidor poderá, utilizando seu CEP ou endereço,

pesquisar os restaurantes que atendam a sua região, consultar o cardápio e fazer

seu pedido. O sistema será o responsável pela comunicação entre o restaurante e o

consumidor.

Também foram identificados os seguintes tipos de usuários: visitante,

consumidor, restaurante e administrador. A sequência a seguir mostra as etapas de

um pedido a ser realizado através do sistema:

1. O consumidor faz um pedido no site;

2. O sistema envia o pedido para o restaurante, que pode ser por meio de e-

mail, fax, Short Message Service (SMS) e outros;

62

3. O restaurante confirma o recebimento do pedido e atualiza o status do

mesmo no site (pedido pronto, a caminho, entrega realizada);

4. O sistema envia um e-mail ao consumidor com um link que direciona para

o site permitindo a avaliação da compra;

5. O consumidor faz a avaliação no site.

3.1.2 Requisitos não funcionais

Os requisitos não funcionais do sistema quantificam as características

comportamentais do sistema e não capturadas pelos casos de uso. São exemplos

de requisitos não funcionais: a facilidade de uso do sistema, o tempo de resposta e o

tempo entre as falhas no sistema. Ou seja, os requisitos não funcionais descrevem

os requisitos de desempenho e outros aspectos que diz respeito à qualidade que se

deseja atingir do sistema. (PAULA, 2008)

Logo a seguir estão os tipos de requisitos não funcionais segundo a

classificação já mencionada FURPS (EELES, 2004):

• Usability – que significa usabilidade: baseia-se em torno da interface de

usuário, como acessibilidade, design e consistência da interface.

• Reliability – que significa confiabilidade: trata de aspectos como a

disponibilidade do sistema, como precisão ou capacidade de recuperação

no caso de falhas.

• Performance – que significa atuação: envolve tempo de resposta do

sistema, tempo de recuperação e inicialização, ou seja, o desempenho

transferência de informações através do sistema .

• Supportability – que significa suportabilidade: outros requisitos, como

testabilidade, adaptabilidade, facilidade de manutenção, compatibilidade,

configuração, escalabilidade e outros são considerados requisitos de

suporte. (EELES, 2004)

A seguir estão os requisitos não funcionais levantados para o sistema a ser

desenvolvido.

Para os requisitos de usabilidade, pretende-se criar uma interface gráfica

simples e atrativa e que funcione perfeitamente nos navegadores mais utilizados. As

permissões de acesso ao sistema serão baseadas em papeis de usuários e

controladas por meio de autenticações de usuário e senha.

63

Quanto à confiabilidade do sistema, espera-se que o mesmo esteja disponível

sempre que requisitado e que seus dados sejam consistentes.

Espera-se que a performance do sistema seja a melhor possível, com tempo

curto de resposta, principalmente para requisições de busca, e suportar requisições

de grandes quantidades de usuários simultaneamente sem que seu desempenho

seja afetado.

Para os requisitos de suportabilidade, pretende-se que o sistema seja de fácil

manutenção e alta escalabilidade.

3.1.3 As restrições

As outras restrições citadas anteriormente podem definir a adequação de

custos e prazos para o desenvolvimento de um projeto, a plataforma tecnológica, as

licenças de uso e os componentes de hardware e software entre outros. (BEZERRA,

2007)

No subitem a seguir está a apresentação da análise dos respectivos

requisitos levantados.

3.2 ANÁLISE DE REQUISITOS FUNCIONAIS

Os requisitos funcionais como já mencionado anteriormente são moldados

pelos casos de uso. O diagrama de caso de uso possui uma notação gráfica simples

e uma linguagem natural, facilitando o entendimento e a comunicação entre

desenvolvedores e usuários. (BEZERRA, 2007)

Como foi escolhido o ciclo de vida incremental e iterativo para o

desenvolvimento do sistema proposto neste trabalho, inicialmente serão

incrementadas apenas algumas das funcionalidades do diagrama de caso de uso,

as quais estão relacionadas a seguir:

• Pesquisar Restaurante;

• Fazer Login;

• Manter Usuário Restaurante;

• Manter Cardápio.

Na Figura 3.3 está representado o diagrama de caso de uso das

funcionalidades do sistema.

Figura 3.3 - Diagrama de Caso de UsoFonte: Elaborada pelos autores

Na Figura 3.4 está representado o

Diagrama de Caso de Uso autores, 2014.

está representado o diagrama de classe.

64

Figura 3.4 - Diagrama de CFonte: Elaborada pelos autores

Em seguida estão as histórias e os diagramas

MVC referentes a cada caso de uso das funcionalidades escolhidas.

Diagrama de Classe Fonte: Elaborada pelos autores, 2014.

Em seguida estão as histórias e os diagramas de atividades, sequência e

cada caso de uso das funcionalidades escolhidas.

65

de atividades, sequência e

cada caso de uso das funcionalidades escolhidas.

3.2.1 Caso de uso: Pesquisar Restaurante

O consumidor/visitante do site informa um CEP e o sistema mostrará uma

lista de restaurantes cadastrados que atendam àquela região. A lista mostrará as

informações principais de cada restaurante, como nome, endereço, tipo de comida,

horário de atendimento, tempo e taxa de entrega. Após a escolha do restaurante, o

sistema apresenta o car

cadastrado que atenda o CEP informado, o sistema exibirá uma mensagem.

O diagrama de atividades referente ao caso de uso Pesquisar Restaurante

está demonstrado na Figura

Figura 3.5 - Diagrama de Atividade Pesquisar RestauranteFonte: Elaborada pelos autores

Na Figura 3.6 e

Pesquisar Restaurante.

Caso de uso: Pesquisar Restaurante


staurantes cadastrados que atendam àquela região. A lista mostrará as



sistema apresenta o cardápio do mesmo. Caso não haja nenhum restaurante



Figura 3.5.

Diagrama de Atividade Pesquisar Restaurante Fonte: Elaborada pelos autores, 2014.

está ilustrado o diagrama de sequência do caso de uso

66


staurantes cadastrados que atendam àquela região. A lista mostrará as



dápio do mesmo. Caso não haja nenhum restaurante



o diagrama de sequência do caso de uso

Figura 3.6 - Diagrama de SFonte: Elaborada pelos autores

O diagrama MVC Pesquisar Restaurante está demonstrado na

Figura 3.7 - MVC Pesquisar RestauranteFonte: Elaborada pelos autores

Diagrama de Sequência Pesquisar Restaurante Fonte: Elaborada pelos autores, 2014.

O diagrama MVC Pesquisar Restaurante está demonstrado na

MVC Pesquisar Restaurante Fonte: Elaborada pelos autores, 2014.

67

O diagrama MVC Pesquisar Restaurante está demonstrado na Figura 3.7.

3.2.2 Caso de uso: Fazer Login

O login pode ser realizado por qualquer um dos usuários:

restaurante e administrador.

cadastrados e o sistema faz a verificação dos dados. Se estiverem corretos, o

usuário acessa o sistema de acordo com seus privilégios, caso os dados informados

não estejam corretos, o usuário opta por

sistema.

Na Figura 3.8 está

Figura 3.8 - Diagrama de Atividade Fazer LoginFonte: Elaborada pelos autores

Na Figura 3.9 est

Fazer Login, demonstrando a permissão de cada usuário.

O diagrama MVC do caso de uso Fazer Login está demonstrado na

3.10.

Como os casos de uso Manter Usuário Restaurante e Manter Cardápio são

bastante comuns, não serão mostrados neste trabalho, apenas uma breve descrição

de cada um deles pode ser lida logo em seguida aos diagramas referentes ao caso

de uso Fazer Login.

Caso de uso: Fazer Login

O login pode ser realizado por qualquer um dos usuários:

restaurante e administrador. O usuário digita seu e-mail e sua senha anteriormente

sistema faz a verificação dos dados. Se estiverem corretos, o


não estejam corretos, o usuário opta por retornar à opção fazer

á o diagrama de atividades do caso de uso Fazer

Diagrama de Atividade Fazer Login Fonte: Elaborada pelos autores, 2014.

tá representado o diagrama de sequência

Fazer Login, demonstrando a permissão de cada usuário.

O diagrama MVC do caso de uso Fazer Login está demonstrado na


erão mostrados neste trabalho, apenas uma breve descrição


68

O login pode ser realizado por qualquer um dos usuários: consumidor,

senha anteriormente

sistema faz a verificação dos dados. Se estiverem corretos, o


fazer login ou sair do

o diagrama de atividades do caso de uso Fazer Login.

o diagrama de sequência do caso de uso

O diagrama MVC do caso de uso Fazer Login está demonstrado na Figura


erão mostrados neste trabalho, apenas uma breve descrição


Figura 3.9 - Diagrama de SFonte: Elaborada pelos autores

Figura 3.10 - Diagrama MVC Fazer LoginFonte: Elaborada pelos autores

Diagrama de Sequência Fazer Login Fonte: Elaborada pelos autores, 2014.

Diagrama MVC Fazer Login Fonte: Elaborada pelos autores, 2014.

69

70

3.2.3 Caso de uso: Manter Usuário Restaurante

O Manter Usuário Restaurante é a atividade de cadastrar, alterar ou excluir o

usuário do restaurante. Nesta atividade, o usuário do restaurante ainda não

cadastrado terá acesso a uma tela para cadastrar o estabelecimento com os dados

solicitados pelo sistema, informando inclusive e-mail e senha para acesso futuro. O

cadastro será analisado pelo administrador do sistema, caso seja aprovado, será

ativado pelo administrador, permitindo ao usuário do restaurante o acesso ao

sistema.

Um usuário já cadastro tem a permissão nesse caso de uso de fazer

alterações para atualizar seus dados ou excluí-los.

Como o caso de uso do tipo Manter é bastante comum, neste trabalho não

serão mostrados todos os diagramas de caso uso deste tipo.

3.2.4 Caso de uso: Manter Cardápio

No caso de uso Manter Cardápio, o usuário restaurante tem a possibilidade

cadastrar, alterar ou excluir itens do próprio cardápio.

Como dito anteriormente, o diagrama desse caso de uso não será mostrado.

3.3 ANÁLISE DE REQUISITOS NÃO FUNCIONAIS

Com a pretensão de atender os requisitos não funcionais, citados no

levantamento de requisitos, foram pesquisadas algumas técnicas e definidas

algumas metodologias, que estão descritas logo a seguir.

3.3.1 Usabilidade

Para garantir que o sistema tenha compatibilidade com a maioria dos

navegadores, serão utilizadas as tecnologias JavaServer Faces com PrimeFaces.

Quanto ao design do site, as páginas terão uma navegabilidade simples, com no

máximo quatro cliques será possível acessar as suas principais funcionalidades.

Para o controle de autenticação da senha do usuário e de suas permissões de uso

será utilizado o framework Spring Security.

71

3.3.2 Performance

Tomando por base um dos conceitos de persistência poliglota, apresentado

por Chris Richardson, autor, desenvolvedor e palestrante renomado, surgiu a ideia

de utilizar o banco de dados chave/valor Redis para garantir a obtenção de

respostas rápidas para as principais requisições feitas ao sistema. O Redis será o

responsável por responder às requisições de busca do site. As principais

características do banco de dados Redis já foram abordadas no segundo capítulo

deste trabalho.

As consultas realizadas em um banco de dados chave/valor são restritas, não

havendo a possibilidade de se realizar pesquisas complexas. As respostas

desejadas devem ser armazenadas no Redis de uma forma desnormalizada,

evitando joins e outros comandos SQL mais pesados, utilizados nos bancos de

dados relacionais. A utilização da forma desnormalizada contribui para o alcance de

respostas mais rápidas.

Para descobrir quais informações devem ser armazenadas de forma

desnormalizada, é necessário identificar as requisições feitas ao sistema.

Duas requisições principais foram identificadas neste sistema para a primeira

fase do desenvolvimento, suas respectivas respostas devem retornar:

• A lista de restaurantes que atendam determinado CEP;

• O cardápio do restaurante escolhido.

As informações podem ser armazenadas no Redis de maneira adequada e

consideravelmente fácil. A modelagem de dados para o Redis e a forma de

armazenamento de dados no mesmo serão abordadas detalhadamente no próximo

capítulo.

3.3.3 Confiabilidade

Segundo Chris Richardson, as vantagens oferecidas pelos bancos relacionais

e pelos bancos chave/valor podem ser usufruídas ao mesmo tempo, se essas

tecnologias forem combinadas em uma solução de persistência poliglota. Um

exemplo apresentado pelo autor em suas palestras é uma aplicação utilizando

MySQL como sistema de armazenamento, em inglês System Of Record - SOR e

Redis, um banco chave/valor, para atender as requisições de busca feitas ao

sistema. As principais vantagens que essa solução traz são: respos

requisições, fácil replicação e

Para garantir a consistência entre os dois

necessário abrir mão das características ACID e trabalhar com consistência

eventual.

Na Figura 3.11 e

garantia da consistência

Figura 3.11 - Padrão de sincronização MySQL/RedisFonte: Elaborada pelos autores,

Descrição dos passos da

1. Transação ACID no MySQL:

• Começar MySQL transação

• Fazer create/update/delete

sistema. As principais vantagens que essa solução traz são: respos

requisições, fácil replicação e sharding. (RICHARDSON, 2012)

Para garantir a consistência entre os dois tipos de bancos de dados é


estão representados os dois passos necessários

eventual sincronizando Redis e MySQL.

Padrão de sincronização MySQL/Redis Fonte: Elaborada pelos autores, 2014.

Descrição dos passos da Figura 3.11:

Transação ACID no MySQL:

Começar MySQL transação;

create/update/delete no MySQL;

72

sistema. As principais vantagens que essa solução traz são: respostas rápidas para

tipos de bancos de dados é


passos necessários para a

sincronizando Redis e MySQL.

73

• Gravar evento Create, Read, Update and Delete (CRUD) no MySQL;

• Terminar transação (commit).

2. Alterar dados no Redis:

• Começar laço para cada evento CRUD não processado;

• Pegar próximo evento CRUD;

• Se o evento ainda não foi atualizado no Redis, atualizar;

• Marcar evento em MySQL como processado;

• Ir para próximo evento CRUD.

A transação ACID garante que somente aconteçam alterações no BD MySQL

caso seja gravado um evento registrando estas alterações. Em intervalos de tempo

predefinidos os eventos são verificados, os não processados são utilizados para

fazer a atualização no Redis, se esta atualização for realizada com sucesso, o

evento é marcado como processado. Este processo garante que os dados nos

bancos sejam eventualmente consistentes. (RICHARDSON, C., 2012)

3.3.4 Suportabilidade

Será utilizado o padrão MVC para tentar assegurar que a manutenção do

sistema seja mais simples possível. A arquitetura do sistema deverá ser bem

estruturada, a cada classe será atribuída uma única responsabilidade.

Deseja-se ainda atingir uma alta escalabilidade, principalmente horizontal,

aproveitando-se de um recurso fornecido pelo Redis, que facilita a replicação do tipo

master/slave e sharding .

No próximo capítulo estão as fases de implementação das funcionalidades

principais do sistema, a descrição das técnicas utilizadas, a sincronização dos

bancos de dados MySQL e Redis e as imagens das telas finais do protótipo do

sistema desenvolvido.

74

4 IMPLEMENTAÇÃO DO SISTEMA

Neste capítulo são apresentados os principais passos para o desenvolvimento

do protótipo do sistema e as técnicas utilizadas. Logo em seguida estão as imagens

das telas com as funcionalidades implementadas e a conexão dos bancos de dados

utilizando a persistência poliglota.

4.1 PREPARAÇÃO DO AMBIENTE DE DESENVOLVIMENTO

A preparação do ambiente de desenvolvimento do sistema foi o primeiro

passo necessário para a realização do projeto.

O ambiente integrado para o desenvolvimento de software (IDE) escolhido foi

o NetBeans versão 7.3. Para a construção de interfaces de usuário foi utilizado o

framework MVC chamado JavaServer Faces na versão 2.2. Este framework foi

usado em conjunto com o PrimeFaces versão 4.0, que é uma biblioteca de

componentes para JSF.

O Apache Tomcat versão 7.0 foi utilizado como servidor web. A

implementação EclipseLink versão 2.5 do JPA foi utilizada para realizar o

mapeamento objeto relacional com o banco de dados MySQL 5.6.13.

Para realizar o controle da autenticação e da autorização dos usuários do

sistema foi utilizado o framework Spring Security 3.0 com suas respectivas

bibliotecas.

Foi criado um projeto Java web em que foram inclusas as bibliotecas citadas

anteriormente.

4.2 CONFIGURAÇÃO JPA E IMPLEMENTAÇÃO DAS CLASSES EN TIDADES

Para realizar a conexão com o banco de dados MySQL foi escolhido o

método Java Naming and Directory Interface (JNDI), que define a fonte de dados.

Esta conexão será utilizada pelo JPA e pelo Spring Security, já mencionados nos

subtítulos 2.3 e 2.4 do segundo capítulo.

A fonte de dados JNDI foi definida no arquivo context.xml, criado na pasta

META-INF.

75

Na Figura 4.1 está a implementação deste arquivo de configuração.

Figura 4.1 - Arquivo context.xml Fonte: Elaborada pelos autores, 2014.

A Figura 4.2 contém o arquivo persistence.xml, que é o arquivo de

configuração para a implementação EclipseLink do JPA criado na pasta

Configuration Files do projeto.

Figura 4.2 - Arquivo persistence.xml Fonte: Elaborada pelos autores, 2014.

Após a configuração da conexão com o banco de dados MySQL foram

implementadas todas as classes de entidades com as respectivas anotações JPA

para o mapeamento objeto-relacional automático.

76

Na Figura 4.3 está representada a classe entidade Produto, escolhida para

exemplificar as anotações JPA.

Figura 4.3 - Classe entidade Produto Fonte: Elaborada pelos autores, 2014.

Como o EclipseLink está configurado para criar tabelas automaticamente,

todas as tabelas referentes às entidades criadas no banco de dados MySQL são

encontradas após um deploy do projeto.

4.3 PADRÕES DE CONTROLE DE TRANSAÇÃO

Para garantir um melhor aproveitamento dos recursos disponíveis no servidor

web e reduzir a responsabilidade do desenvolvedor sobre o controle das transações

foram combinados dois padrões, para serem usados em conjunto:

OpenEntityManagerInView (OEMV) e OpenTransactionInApplicationPhaseListener

(OTAPL).

77

O padrão de controle OEMV garante que para cada requisição seja fornecido

um único EntityManager, que está disponível para os beans da aplicação.

(PATRICIO, 2009)

Este padrão foi alcançado utilizando um Servlet Filter chamado

EntityManagerFilter juntamente com uma classe utilitária chamada

EntityManagerUtil. A única função da classe EntityManagerUtil é o fornecimento do

EntityManager criado para cada thread (requisição) utilizando um atributo do tipo

ThreadLocal<EntityManager>.

O padrão de controle OEMV traz algumas vantagens:

• A existência de um único ponto na aplicação para a criação e fechamento

do EntityManager para cada requisição, que é o método doFilter() no

EntityManagerFilter. Isso ocorre automaticamente, sem a necessidade da

interferência do desenvolvedor;

• O aproveitamento de uma única EntityManagerFactory para toda a

aplicação, pois este objeto está sendo instanciado no momento da

inicialização do EntityManagerFilter (no método init() do filtro) e destruído

quando o filtro está sendo destruído (no método destroy() do filtro). Além

de facilitar o desenvolvimento, isto poupa recursos, pois a criação de uma

EntityManagerFactory é relativamente custosa;

• O EntityManager para um thread pode ser recuperado por qualquer

classe da aplicação chamando o método estático getEntityManager() da

classe utilitária EntityManagerUtil.

Figura 4.4 - Classe EntityManagerUtil Fonte: Elaborada pelos autores, 2014.

78

Na Figura 4.4 está a implementação da classe EntityManagerUtil, que

disponibiliza o EntityManager para a aplicação.

Os métodos init(), destroy() e doFilter() do EntityManagerFilter estão

representados na Figura 4.5.

Figura 4.5 - Classe EntityManagerFilter Fonte: Elaborada pelos autores, 2014.

O padrão OTAPL é responsável por abrir e fechar transações, aproveitando o

ciclo de vida do JSF. Antes de entrar na fase Invoke Application é aberta uma

transação utilizando o EntityManager, fornecido pela classe EntityManagerUtil; ao

sair desta fase, a transação é fechada. Desta forma, é garantido que somente sejam

abertas transações caso a aplicação esteja sendo invocada e garantindo também

que as transações estejam sempre sendo fechadas. (SPRING, 2007).

Para a realização deste padrão, foi implementado um PhaseListener chamado

OpenTransactionInPhaseListener.

Na Figura 4.6 está representada a implementação do PhaseListener.

Para a aplicação tratar dos eventos de entrada e saída da fase foi inserido no

arquivo faces-config.xml um trecho de código, que pode ser observado na Figura

4.7.

79

Figura 4.6 - Implementação OpenTransactionInPhaseListener Fonte: Elaborada pelos autores, 2014.

Figura 4.7 - Trecho do arquivo faces-config.xml Fonte: Elaborada pelos autores, 2014.

4.4 ACESSO AOS DADOS

Para realizar a comunicação entre a aplicação e os bancos de dados foi

seguido um padrão, garantindo que nenhuma classe de controle tenha acesso direto

aos bancos. Foi criada uma camada de regras de negócio, responsável pela

intermediação da aplicação com as classes Data Access Object (DAO), esta camada

80

fornece as mesmas funcionalidades das DAOs, porém possibilita o tratamento ou a

validação dos dados antes de executar qualquer busca no BD; isso aumenta a

flexibilidade e a segurança da aplicação final.

As regras de negócio podem ser implementadas em um único local e, caso

elas sofram alterações, podem ser adaptadas centralizadamente.

A arquitetura em camadas está representada pela Figura 4.8.

Figura 4.8 - Arquitetura em camadas Fonte: Luckow; Melo, 2010, p. 180 (adaptada pelos autores)

4.5 LEIAUTE DAS PÁGINAS DO SITE

Na Figura 4.9 está representado o leiaute padrão do sistema.

Figura 4.9 - Template padrão do site Fonte: Elaborada pelos autores, 2014.

81

Foi definido um leiaute padrão para todas as páginas do site, composto por

logotipo (localizado na área superior da página) seguido por um menu dinâmico, em

seguida vem o corpo da página e abaixo deste está o rodapé dinâmico. Este

template foi desenvolvido com o Facelets do JavaServer Faces utilizando,

principalmente, os componentes composition, define, insert e include.

O código-fonte do template padrão pode ser conferido na Figura 4.10.

Figura 4.10 - Código-fonte do template padrão Fonte: Elaborada pelos autores, 2014.

4.6 IMPLEMENTAÇÃO DOS CASOS DE USO

A seguir está a explicação de como foram implementados os casos de uso

necessários para o estudo da aplicação da persistência poliglota em um protótipo de

um sistema de venda de comida para entrega em domicílio.

Os casos de uso demonstrados foram definidos anteriormente, sendo: Manter

Usuário Restaurante, Fazer Login, Manter Cardápio e Pesquisar Restaurante.

82

4.6.1 Implementação do caso de uso Manter Usuário R estaurante

Para implementar o caso de uso Manter Usuário Restaurante foram criadas

duas páginas JSF utilizando, entre outras, a biblioteca de componentes PrimeFaces.

O leiaute da primeira página, que possibilita cadastrar um novo restaurante, contém

o componente wizard do PrimeFaces para organizar as informações solicitadas para

o cadastro do restaurante. O wizard possui quatro abas, para solicitação dos

seguintes dados:

• Primeira aba: dados principais do restaurante;

• Segunda aba: endereço do restaurante;

• Terceira aba: cadastro do usuário responsável pelo restaurante;

• Quarta aba: confirmação dos dados, mostrando o cadastro completo para

que o usuário confirme os dados informados.

Na Figura 4.11 está representada a tela da primeira página do caso de uso

Manter Usuário Restaurante, que é o cadastro do restaurante.

Figura 4.11 - Página Cadastro de Restaurante Fonte: Elaborada pelos autores, 2014.

A segunda página do Manter Usuário Restaurante fornece a funcionalidade

de alteração dos dados cadastrais do restaurante. Para realizar alterações dos

dados cadastrados, o usuário escolhe na página os dados a ser alterados e o

sistema abre uma caixa de diálogo para efetuar a atualização.

83

A Figura 4.12 é a imagem da segunda página Manter Usuário Restaurante,

que permite realizar alterações dos dados cadastrados do restaurante.

Figura 4.12 - Página Alterar Dados do Restaurante Fonte: Elaborada pelos autores, 2014.

4.6.2 Implementação do caso de uso Fazer Login

A funcionalidade Fazer Login foi desenvolvida utilizando o framework Spring

Security para garantir maior segurança do sistema e facilitar o controle de

autenticação e autorização na aplicação. Além da importação dos arquivos .jar,

referente a este framework no projeto, foi necessário a inclusão de dois arquivos de

configuração, sendo eles: applicationContext.xml e applicationContext-security.xml.

Figura 4.13 - Código applicationContext.xml Fonte: Elaborada pelos autores, 2014.

84

Na Figura 4.13 está representado o código do arquivo applicationContext.xml,

no qual está contida a informação da conexão da aplicação com a fonte de dados,

que contém os dados de acessos e permissões dos usuários.

O arquivo de configuração applicationContext-security.xml determina o

comportamento principal do framework, definindo, entre outras ações, as páginas

que podem ser acessadas de acordo com as permissões, qual será a página de

login, define também como recuperar usuário e senha e as respectivas permissões

de acesso.

Na Figura 4.14 pode-se conferir o código que contém o arquivo

applicationContext-security.xml na aplicação.

Figura 4.14 - Código applicationContext-security.xml Fonte: Elaborada pelos autores, 2014.

A página de Login do sistema está representada na Figura 4.15.

85

Figura 4.15 - Página de Login Fonte: Elaborada pelos autores, 2014.

4.6.3 Implementação do caso de uso Manter Cardápio

Manter cardápio é uma funcionalidade em que o usuário administrador do

restaurante pode incluir, alterar ou excluir os produtos pertencentes ao cardápio do

estabelecimento. Este caso de uso foi implementado por meio de uma página JSF

cujo componente principal é um dataTable que contém os produtos cadastrados e os

botões de ação para alterar ou excluir um produto já cadastrado. Para cadastrar um

novo produto há um botão chamado Novo Produto.

A Figura 4.16 é a imagem da página da funcionalidade Manter Cardápio.

Figura 4.16 - Página Manter Cardápio Fonte: Elaborada pelos autores, 2014.

86

4.6.4 Implementação do caso de uso Pesquisar Restau rante

A página com a funcionalidade Pesquisar Restaurante é a página principal do

sistema, pois será a mais utilizada, já que o objetivo do site é a busca por

estabelecimentos que atendam um CEP informado. No corpo desta página há

apenas o campo para informação do CEP e um botão para inicializar a busca.

Na Figura 4.17 está a página Pesquisar Restaurante.

Figura 4.17 - Página Pesquisar Restaurante Fonte: Elaborada pelos autores, 2014.

O exemplo de uma página que mostra os restaurantes encontrados que

atendem o CEP informado pode ser verificado na Figura 4.18.

Figura 4.18 - Página dos restaurantes encontrados Fonte: Elaborada pelos autores, 2014.

Ao selecionar um restaurante da lista fornecida, é apresentada ao usuário

uma página contendo o cardápio do restaurante escolhido, conforme se verifica na

87

Figura 4.19.

Figura 4.19 - Página do cardápio do restaurante Fonte: Elaborada pelos autores, 2014.

As páginas foram testadas em três navegadores diferentes, são eles: Mozilla

Firefox 29, Microsoft Internet Explorer 11 e Google Chrome 34; não foi notado

nenhum problema de visualização ou funcionamento das páginas.

4.7 IMPLEMENTAÇÃO DA PERSISTÊNCIA POLIGLOTA

Após a implementação de todas as funcionalidades, foi preparado o ambiente

para a implementação da persistência poliglota. Houve a necessidade da instalação

de uma máquina virtual, pois o sistema fora desenvolvido em um ambiente Microsoft

Windows 7 e o BD Redis requer um sistema operacional Linux. A distribuição Linux

CentOS 6.4 foi instalada como máquina virtual no Oracle VM VirtualBox 4.2 para

atender a este requisito do Redis. O Redis versão 2.8 foi instalado e configurado

para ser executado como serviço.

Para possibilitar uma comunicação entre a aplicação e BD Redis foi

necessário configurar uma Local Area Network (LAN), que é uma rede local. Além

disso, houve a necessidade de importar a biblioteca referente à API Jedis versão

2.4, que é um cliente Redis para Java.

A seguir estão as principais etapas que foram realizadas para obtenção da

persistência poliglota.

88

4.7.1 Modelagem de dados para o banco de dados Redi s

No capítulo anterior foi citado que o Redis será encarregado em atender as

duas requisições principais do sistema, cujas respostas retornam respectivamente a

lista de restaurantes que atendam um CEP e o cardápio dos estabelecimentos

listados.

Para o atendimento à requisição que retorna a lista de restaurantes, foram

utilizadas duas estruturas de dados suportadas pelo Redis, são elas:

• Estrutura par key/value: para armazenar informações sobre os

restaurantes, em formato JSON. A chave de acesso (key) é composta por

“rest:{código do restaurante}”;

• Estrutura set: para fornecer todas as chaves dos restaurantes que

atendem um CEP. A chave de acesso é composta por “cep:{número do

CEP}”.

A Figura 4.20 contém exemplos de como os dados estão armazenados

utilizando essas duas estruturas no Redis.

Figura 4.20 - Estruturas set e chave/valor Fonte: Elaborada pelos autores, 2014.

A utilização das estruturas possibilita uma recuperação dos dados dos

restaurantes que atendem um CEP informado de maneira eficiente. Com apenas

três passos rápidos consegue-se obter a resposta da requisição. Os passos são:

• Buscar todos os membros do set com a chave “cep:{CEP informado}”;

89

• Buscar os JSONs de todos os restaurantes referenciados pelos membros

do set;

• Transformar lista de JSONs em lista de restaurantes.

A requisição que retorna o cardápio do restaurante escolhido é atendida

utilizando uma terceira estrutura de dados suportados pelo Redis, o hash. Todos os

produtos de um restaurante podem ser acessados por meio de uma chave do hash

composta por “rest:{código do restaurante}:produtos”. O JSON que representa cada

produto pode ser acessado dentro do hash com uma sub chave composta por

“prod:{código do produto}”.

Na Figura 4.21 pode-se observar um exemplo de hash que contém os

produtos de um restaurante.

Figura 4.21 - Estrutura hash Fonte: Elaborada pelos autores, 2014.

Para atender a requisição que retorna o cardápio são necessários dois

passos:

• Buscar todos os valores dos campos (JSONs) de um hash da chave

“rest:{código do restaurante}:produtos”;

• Transformar lista de JSONs em lista de produtos.

Mais um set foi criado no BD Redis, para fazer o controle de quais os eventos

CRUDs que foram processados. A chave do set é “crudsProcessados” e os

membros são os códigos de todos os eventos CRUD já processados.

A próxima etapa da implementação é a sincronização entre os dois bancos.

90

4.7.2 Realização do padrão de sincronização entre M ySQL e Redis

A sincronização entre MySQL e Redis deste sistema segue um fluxo para

garantir a consistência (BASE) na persistência poliglota. No capítulo anterior, na

Figura 3.11, podem ser observados os dois passos deste fluxo. Foi implementada

uma entidade auxiliar chamada CrudEvent, que é utilizada nos passos definidos no

fluxo. Esta entidade contém as informações necessárias de cada evento CRUD para

alterar os dados no Redis, conforme o evento ocorrido. As informações são as

seguintes:

• O código do evento;

• O tipo de entidade que disparou o evento;

• O código da entidade que disparou o evento;

• Uma string que fornece os principais detalhes do novo estado da entidade

fonte do evento no formato JSON;

• O tipo de evento CRUD que ocorreu;

• Um valor booleano, para indicar se o evento CRUD já foi ou não

processado no Redis.

A Figura 4.22 contém o código da implementação da entidade CrudEvent.

Figura 4.22 - Implementação entidade auxiliar CrudEvent Fonte: Elaborada pelos autores, 2014.

Foi implementado um método chamado save(), que deve ser invocado pela

91

camada de regras de negócio para criar e persistir o evento CRUD de maneira

simples, conforme verifica-se na Figura 4.23.

Figura 4.23 - Método save() utilizado para persistir o evento CRUD Fonte: Elaborada pelos autores, 2014.

Após a criação da classe CrudEvent e de seus métodos de persistência para

o BD MySQL, é possível a realização do primeiro passo do fluxo, sendo suficiente

persistir o evento CRUD dentro da mesma transação atômica que realiza o CRUD

da entidade disparadora. Na prática, significa a inclusão de apenas uma linha de

código em cada método CRUD (na camada de regras de negócio), de cada classe

que se deseja persistir futuramente no BD Redis.

Na Figura 4.24 pode ser notada a facilidade para realizar o primeiro passo do

fluxo no exemplo da classe RestauranteRN.

92

Figura 4.24 - Trecho da implementação da classe RestauranteRN Fonte: Elaborada pelos autores, 2014.

O segundo passo do fluxo, que é a sincronização do Redis com o MySQL, foi

implementado com um método que é executado automaticamente utilizando um

timer, que é inicializado no método contextInitialized() em uma classe que

implementa a interface ServletContextListener.

Na Figura 4.25 está o código com o método que faz a sincronização do Redis

com o MySQL tratando os eventos CRUD ainda não processados.

Na Figura 4.26 verifica-se um exemplo de um método utilizado na

sincronização dos bancos que realiza o processamento de um evento CRUD. Este

método é invocado pelo método da Figura 4.25.

93

Figura 4.25 - Implementação do método de sincronização MySQL/Redis Fonte: Elaborada pelos autores, 2014.

94

Figura 4.26 - Implementação do método que processa um evento CRUD Fonte: Elaborada pelos autores, 2014.

Após todo processo de implementação o banco de dados MySQL foi povoado

para possibilitar a realização de alguns testes, cujos resultados estão mostrados a

seguir.

4.7.3 Teste de viabilidade da persistência poliglot a

Sabendo-se que o BD Redis possui uma limitação relevante de que todos os

dados no Redis devem caber na RAM do servidor, notou-se a importância de testar

a ocupação do espaço da memória em função do volume de dados armazenados.

Foram realizados testes empíricos no protótipo para verificar como os bancos

de dados se comportariam nesta aplicação.

Para povoar o banco de dados MySQL foi criado um algoritmo, que define

que cada restaurante atenderá em média duzentos CEPs, possuirá cem produtos e

95

terá um administrador. Após o povoamento do MySQL, com diferentes quantidades

de dados, foi feita a sincronização com o banco de dados Redis.

A evolução do tamanho do BD Redis em função com a quantidade de

restaurantes armazenados está representada pelo gráfico da Figura 4.27.

Figura 4.27 - Memória RAM ocupada pelo Redis Fonte: Elaborada pelos autores, 2014.

O teste revelou que o espaço ocupado na memória RAM pelo BD Redis é

diretamente proporcional com a quantidade de restaurantes armazenados. Calculou-

se que para armazenar cem mil estabelecimentos são necessários

aproximadamente 2,5 GB de memória RAM, uma quantidade considerada pequena

em custo de hardware, portanto, o uso da persistência poliglota com o BD Redis no

quesito custo de memória necessário é viável.

Também foi efetuado um teste para comparar o tempo de resposta de uma

mesma requisição utilizando Redis e MySQL. Para fazer a comparação foi

implementado um filtro, que cronometra o tempo percorrido entre o momento em

que o filtro repassa a requisição até o momento em que ele recebe a resposta.

Na Figura 4.28 estão os gráficos com os resultados que comprovam que o BD

Redis possui um tempo de resposta constante, independente da quantidade de

restaurantes existentes nele e no BD MySQL o tempo de resposta aumenta

96

significativamente em função da quantidade de restaurantes que este armazena.

Frisando que não foi aplicado nenhum tipo de otimização nos bancos e que foi

realizada uma requisição por vez. Em um sistema em produção espera-se que

várias requisições sejam realizadas paralelamente, o que provavelmente

influenciaria ainda mais o resultado.

Figura 4.28 - Comparativo de tempo de resposta MySQL x Redis Fonte: Elaborada pelos autores, 2014.

Vale ressaltar que não foram aplicadas técnicas de análise de desempenho

para tais verificações, portanto, as afirmações anteriores passariam a ter maior e

melhor valor científico se passassem por metodologias específicas para estes

testes.

97

CONCLUSÃO

Existem atualmente várias opções de bancos de dados relacionais e não

relacionais no mercado. Entretanto, é importante ressaltar que cada tipo possui

características particulares.

Os bancos de dados relacionais possuem as características ACID, o que os

torna vantajosos pelo alto nível de consistência dos dados armazenados; ao passo

que os bancos de dados não relacionais possibilitam respostas rápidas às buscas e

fácil escalabilidade.

O uso em conjunto de diferentes tipos de bancos de dados pode trazer

grandes vantagens ao projeto, mas para isso, a escolha dos bancos deve ser

definida mediante avaliação prévia e cuidadosa da necessidade real do sistema.

Para um sistema de vendas on-line em que predomina a ação de buscas e

pesquisas essa miscigenação de tipos de bancos de dados permite que sejam

aproveitadas as vantagens oferecidas pelos dois tipos.

A utilização de um banco de dados relacional com outro não relacional recebe

a denominação de persistência poliglota.

Para o desenvolvimento do protótipo em questão foi decidido utilizar um

banco de dados relacional, o MySQL, e um banco de dados não relacional, que foi

escolhido mediante análise bastante minuciosa e estudada, pois dos tipos de bancos

de dados não relacionais que existem, sendo eles: Armazenamento chave/valor,

Armazenamento de documento, Armazenamento de família de colunas e Bancos de

grafos, procurou-se optar pelo tipo que atendesse à necessidade do sistema

proposto, ou seja, que fornecesse respostas rápidas e suportasse grande número de

acessos de usuários ao mesmo tempo. Nesse protótipo de um sistema web foram

criadas apenas algumas funcionalidades para testar a celeridade das respostas às

buscas aplicando a persistência poliglota.

Decidiu-se utilizar o banco não relacional denominado Redis, do tipo

chave/valor, que de acordo com as pesquisas realizadas seria o modelo indicado

para ser aplicado no projeto juntamente com o MySQL.

Conclui-se que o uso da persistência poliglota, apesar da complexidade de

sua aplicação, no projeto em questão foi exequível e até vantajoso, considerando a

98

rapidez na obtenção das respostas às requisições. Porém, os resultados podem

variar de acordo com o tipo de aplicação, convém fazer uma pré-análise para

verificar-se qual a real necessidade do sistema e identificar se o uso da persistência

poliglota pode ser vantajoso e suficiente para atender as requisições, caso decida-se

usá-la, definir os tipos de banco de dados mais adequados a serem utilizados de

acordo com suas características.

Foram aplicados testes empíricos, porém já indicam a vantagem em relação

às soluções tradicionais, que utilizam apenas bancos de dados relacionais.

Nos testes realizados no prótotipo foi observado que o espaço ocupado na

memória RAM pelo banco de dados Redis foi diretamente proporcional à quantidade

de dados armazenados. Verificou-se também que a quantidade de dados

armazenados no Redis não influenciou o tempo de resposta para as requisições; já

no MySQL, quanto maior a quantidade de dados armazenados maior foi o tempo de

resposta para as mesmas requisições.

Como sugestão para trabalhos futuros:

• Realização de testes para comparar as consultas utilizando MySQL ou

Redis; principalmente observando as alterações em um ambiente em que

são feitas inúmeras requisições ao servidor web paralelamente;

• Análise da otimização das consultas ao MySQL e verificação do impacto

no resultado dos testes;

• Análise da otimização da modelagem dos dados para o Redis com ênfase

na economicidade de espaço na memória e melhor aproveitamento das

particularidades do Redis;

• Adaptação do protótipo desenvolvido usando bancos não relacionais do

tipo grafos ou documentos em substituição ao BD chave/valor Redis;

• Desenvolvimento de outras funcionalidades do sistema (como carrinho de

compras, acompanhamentos de pedidos, emissão de relatórios, entre

outros) fazendo análise do aproveitamento das vantagens da persistência

poliglota.

99

REFERÊNCIAS BIBLIOGRÁFICAS

ABIA. Mercado de Food Service . 2010. Disponível em: <http://www.abia.org.br/cfs2012/mercado.asp> Acesso em: 13 abr. 2013. ABRASEL. Delivery online de comida deve crescer 100% ano até 2015, 05 abr. 2013. Disponível em: <http://www.abrasel.com.br/index.php/component/ content/article/7-noticias/2050-050413-delivery-online-de-comida-deve-crescer-100-ao-ano-ate-2015.html> Acesso em: 06 abr. 2013. BEZERRA, E. Princípios de análise e projetos de sistemas com UM L. 2. ed. Rio de Janeiro: Elsevier, 2007. BRASIL. Empreendedorismo online. 2013. Disponível em: <http://www.brasil.gov.br/empreendedor/estrutura-da-empresa/empreendedoris mo-online> Acesso em: 24 fev. 2013. BURNS, E.; SCHALK, C. JavaServer Faces 2.0: The Complete Reference . 1. ed. New York: Mc Graw Hill, 2010. ÇALIŞKAN, M.; VARAKSIN O. PrimeFaces Cookbook . 1. ed. Birmingham: Packt Publishing, 2013. CARLSON, J. L. Redis in Action . 1. ed. Shelter Island: Manning Publications Co., 2013. CODD, E. F. A relational model of data for large shared data Banks. Comunications of the ACM. San Jose, v.13, n.6, p. 377-387, jun. 1970. COMERNAWEB. Gastronomia delivery reservas. 2013. Disponível em: <http://www.comernaweb.com.br> Acesso em: 16 abr. 2013. DEVMEDIA. Passo a passo para o mundo de JavaServer Faces . Disponível em: < http://www.devmedia.com.br/passo-a-passo-para-o-mundo-de-javaserver -faces-parte-01/14815> Acesso em: 11 mai 2013. DISKCOOK. Os melhores restaurantes na sua casa. 2013. Disponível em: <http://www.diskcook.com.br/delivery> Acesso em: 16 abr. 2013. EBRICKSDIGITAL. Pesquisa analisa o mercado mobile e de e-commerce no Brasil, 30 abr. 2012. Disponível em: <http://www. ebricksdigital.com.br/ pesquisas-de-mercado/pesquisa-analisa-o-mercado-mobile-e-de-e-commerce-no-brasil> Acesso em: 13 abr. 2013. ECDFOODSERVICE. Introdução ao Mercado Food Service . 2010. Disponível em: <http://ecdfoodservice.com.br/downloads/01.pdf> Acesso em: 14 abr. 2013. ECOMMERCEBRASIL. Comércio Eletrônico: um universo de oportunidades, 24

100

jan. 2013. Disponível em: <http://www.ecommerce brasil.com.br/artigos/comercio-eletronico-um-universo-de-oportunidades> Acesso em: 13 mar. 2013. E-COMMERCEORG. Evolução da internet e do e-commerce . 2012. Disponível em: <http://www.e-commerce.org.br/stats.php> Acesso em: 02 abr. 2013. ECOMMERCESCHOOL. Pesquisas Profissionais de Ecommerce . 2011. <http://www.ecommerceschool.com.br/Pesquisa-Profissionais-de-Ecommerce-Ecommerce-School-2011.pdf> Acesso em: 13 mar. 2013. EDLICH, S. et al. NoSQL – Einstieg in die Welt nichtrelationaler Web 2.0 Databanken . 1. ed. München: Hanser, 2010. EELES, P. What, no supplementary specification ? Disponível em: <http://www.ibm.com/developerworks/rational/library/3975.html> Acesso em: 26 jun. 2013. ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 1. ed. São Paulo: Pearson, 2005. ENTREGADELIVERY. Delivery de comida pela internet. 2013. Disponível em: <http://comida.entregadelivery.com.br> Acesso em: 12 abr. 2013. FH KÖLN. Datenbanken Online Lexikon . Disponível em: <http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/Cassandra> Acesso em: 12 abr 2013. GONÇALVES, E. Desenvolvendo Aplicações Web com JSP, Servlets, JavaServer Faces , Hibernate, EJB 3 Persistence e AJAX. 1. ed. Rio de Janeiro: Ciência Moderna, 2007. GONÇALVES, E. Dominando JavaServer Faces e Facelets Utilizando Spring 2.5, Hibernate e JPA. 1. ed. Rio de Janeiro: Ciência Moderna, 2008. HEISE. NoSQL im Überblick . Disponível em: <http://www.heise.de/ open/artikel/NoSQL-im-Ueberblick-1012483.html> Acesso em: 12 abr 2013. HOTELNEWS. Indústria do food service invade a internet. 2011. Disponível em:<http://www.revistahotelnews.com.br/2009/na_revista.php?id_revista=18&ano=2011> Acesso em: 13 abr. 2013. IBGE. Pesquisa de Orçamentos Familiares – POF 2002-2003. 2004. Disponível em: <http://www.ibge.gov.br/home/estatistica/populacao/condicaodevida/pof/2002/ pof200220032aed.pdf> Acesso em: 14 abr. 2013. IBGE. Pesquisa de Orçamentos Familiares – POF 2008-2009. 2010. Disponível em: <http://www.ibge.gov.br/home/estatistica/populacao/condicaodevida/pof/2008_ 2009/POFpublicacao.pdf> Acesso em: 14 abr. 2013. IFOOD. O delivery dos deliveries . 2013. Disponível em: <http://www.ifood.com.br/delivery> Acesso em: 16 abr. 2013.

101

JANAMESA. Nunca foi tão fácil comer bem. 2013. Disponível em: <http://www.janamesa.com.br> Acesso em: 16 abr. 2013. JAVASERVERFACES. JSF in a nutshell . 2013. Disponível em: <http://www.javaserverfaces.org> Acesso em: 05 mai 2013. LUCKOW, D. H.; MELO, A. A. Programação Java para Web. 1. ed. São Paulo: Novatec, 2010. MATTHEW, N.; STONES, R. Beginning Databases with PostgreSQL - From novice to Professional . 2. ed. New York: Apress, 2005. NETBEANS. Introdução ao JavaSever Faces 2.x. 2013. Disponível em: <https://netbeans.org/kb//docs/web/jsf20-intro_pt_BR.html> Acesso em: 11 mai 2013. OLIVEIRA, H. C. JPA Mini Livro - Primeiros passos e conceitos detal hados. 23 out. 2012. Disponível em: < http://uaihebert.com/sample-page/> Acesso em: 18 jan. 2014. PATRICIO, A. Open Session in View. 11 ago. 2009 Disponível em: <https://community.jboss.org/wiki/OpenSessioninView> Acesso em: 18 jan. 2014. PAULA, W. P. F. Engenharia de Software: Fundamentos, Métodos e Padr ões. 3. ed. Rio de Janeiro: LCT, 2008. PEIXEURBANO. Explore a cidade. 2013. Disponível em: <http://delivery.peixeurbano.com.br> Acesso em: 10 abr. 2013. PITANGA, T. JavaServer Faces : A mais nova tecnologia Java para desenvolvimento web. Disponível em: <http://www.guj.com.br/ content/articles/jsf/jsf.pdf> Acesso em: 11 mai 2013. PRESSMAN, R. S. Engenharia de software. 7. ed. Porto Alegre: AMGH, 2011. REDIS. Site Oficial. Disponível em:< http://redis.io/> Acesso em: 21 ago 2013. RESTAURANTEWEB. Peça delivery online nos melhores restaurantes. 2013. Disponível em: <http://www.restauranteweb.com.br> Acesso em: 10 abr. 2013. RICHARDSON, C. POJOs in action . 1. ed. Greenwich: Manning Publications Co., 2006. RICHARDSON, C. Polyglot persistence talk . Disponível em: <http://plainoldobjects.com / 2013/06/19 / polyglot-persistence-talk-at-gluecon/> Acesso em: 01 jul 2013. ROBINSON, I.; WEBBER, J.; EIFREM, E. Graph Databases . 1. ed. Sebastopol: O’Reilly Media, 2013.

102

SADALAGE, P. J.; FOWLER, M. NoSQL Distilled - A Brief Guide to the Emerging World of Polyglot Persistence. 1. ed. New Jersey: Pearson Education, 2013. SADALAGE, P. J.; FOWLER, M. NoSQL Essencial – Um Guia Conciso para o Mundo Emergente da Persistência Poliglota. Tradução Acauan Fernandes. 1. ed. São Paulo: Novatec, 2013. SAWAYA M. Dicionário de Informática e Internet. 1. ed. São Paulo: Nobel, 1999. SEBRAE. Comércio Eletrônico. 2013. Disponível em: <http://www.sebrae.com.br/setor/comercio-eletronico/o-setor/mercado> Acesso em: 13 mar. 2013. SEBRAESP. Jornal de Negócios, São Paulo, mar. 2013. Disponível em: <http://www.sebraesp.com.br / arquivos_site / noticias / jornal_negocios / 226> Acesso em: 13 mar. 2013. SEGUIN, K. The Little Redis book . Disponível em: <http://openmymind.net/2012/1/23/The-Little-Redis-Book/> Acesso em: 17 dez 2012. SCARIONI, C. Pro Spring Security. 1. ed. New York: Apress, 01 abr. 2013. SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio de Janeiro: Elsevier, 2006. SOUSA, P. O teorema CAP. Disponível em: <http://unrealps.wordpress.com/2010/12/28/o-teorema-cap/> Acesso em: 17 mai 2013. SPRING. Code contribution: JPA support for JSF - OpenEntityManagerViewPhaseListener. Disponível em: <https://jira.spring.io/browse/SPR-3179> Acesso em: 18 jan. 2014. TIWARI, S. Professional NoSQL. 1. ed. Indianapolis: John Wiley & Sons, 2011.

103

APÊNDICE A – Comandos Básicos do Redis

O Redis fornece um número razoável de operações. A seguir será

apresentado um resumo dos comandos básicos para cada estrutura de dados do

Redis, com nome, breve descrição e complexidade de tempo de cada um deles.

Comandos aplicáveis em valores do tipo string

Comando Descrição Complexidade de tempo

GET Busca valor referente uma chave específica O(1)

SET Grava valor referente uma chave específica O(1)

DEL Deleta chave e valor referente, funciona para todas estruturas de dados O(1), para strings

Comandos aplicáveis em valores do tipo hash


HGET Busca valor referente uma sub-chave específica O(1)

HSET Armazena o valor referente uma sub-chave O(1)

HGETALL Busca todos pares sub-chave/valor armazenado em um hash

O(N), onde N é o tamanho do hash

HDEL Deleta um ou mais pares sub-chave/valor do hash

O(N), onde N é o número de pares a ser removidos

Comandos aplicáveis em valores do tipo list


RPUSH Adiciona um elemento ao final de uma lista O(1)

LRANGE Busca todos elementos de uma lista dentro de um intervalo específico informado

O(S+N), onde S é o start offset e N o número de elementos no intervalo

LINDEX Busca elemento em uma posição específico O(N), onde N é a distância

do elemento para um extremo da lista

RPOP Busca e deleta o último elemento da lista O(1)

104

Comandos aplicáveis em valores do tipo set


SADD Adiciona um ou mais elementosao conjunto O(N), onde N é o número de elementos a adicionar

SMEMBERS Busca todos elementos de um conjunto O(N), onde N é o tamanho do conjunto

SINTER Retorna todos elementos existentes em todos conjuntos informados (intersecção)

O(N*M), onde N é o número do menor conjunto e M o

número de conjuntos

SISMEMBER Determina se valor informado é elemento do conjunto O(1)

SREM Deleta um ou mais elementos de um conjunto

O(N), onde N é o número de elementos a remover

Comandos aplicáveis em valores do tipo sorted set


ZADD Adiciona um elemento com um valor numérico para classificação

O(log*N), onde N é o número de elementos

existentes

ZRANGE Busca um número específico de

elementos de um sorted set, partindo de um valor de classificação informado

O(log(N)+M), onde N é o número de elementos

existentes e M o número de elementos a retornar

ZRANGEBYSCORE Busca todos elementos cuja

classificação está dentro de um intervalo informado

O(log(N)+M), onde N é o número de elementos

existentes e M o número de elementos a retornar

ZREM Remove todos elementos especificadas

O(M*log(N)), onde N é o número de elementos do

sorted set e M o número a ser removido

Documents

DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS …fateclins.edu.br/v4.0/trabalhoGraduacao/mXNIfr3... · DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS ETSCHEID UM ESTUDO SOBRE A PERSISTÊNCIA