DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS ETSCHEID UM ESTUDO SOBRE A PERSISTÊNCIA POLIGLOTA E SUA APLICAÇÃO EM UMA PLATAFORMA WEB

Tamanho: px
Começar a partir da página:

Download "DEISE APARECIDA PIZO DA SILVA DOMINIK MATTHIAS ETSCHEID UM ESTUDO SOBRE A PERSISTÊNCIA POLIGLOTA E SUA APLICAÇÃO EM UMA PLATAFORMA WEB"

Transcrição

1 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 APLICAÇÃO EM UMA PLATAFORMA WEB LINS/SP 1º SEMESTRE/2014

2 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 APLICAÇÃ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

3 (folha de aprovação)

4 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

5 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

6 O que fazemos para nós, morre conosco. O que fazemos pelos outros e pelo mundo, continua e é imortal. Albert Bigelow Paine

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

8 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 highperformance 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 nonrelational 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.

9 LISTA DE ILUSTRAÇÕES Figura Crescimento em milhões dos e-consumidores no Brasil por ano Figura Quantidade de transações por renda familiar Figura Quantidade de transações por faixa etária Figura Quantidade de transações por escolaridade Figura Página inicial do portal Restaurante Web Figura Página inicial do portal ifood Figura Página inicial do portal Entrega Delivery Figura Página inicial do portal Janamesa Figura Página inicial do portal Comernaweb Figura Página inicial do portal Peixeurbano Figura Página inicial do portal Diskcook Figura Arquitetura JSF baseada no modelo MVC Figura Ciclo de vida do JavaServer Faces Figura Diagrama de estado de uma transação Figura Escolha das propriedades do Teorema CAP Figura Agregado no UI é conjunto de várias tuplas de várias tabelas Figura Bancos de dados relacionais x não relacionais Figura Par chave/valor ou chave/documento Figura Modelo de dados de uma família de colunas Figura Exemplo de duas linhas de uma família de colunas Figura Modelo de uma super coluna Figura Entidades com relacionamentos com propriedades Figura Estrutura de dados tipo string Figura Estrutura de dados tipo hash Figura Estrutura de dados tipo list Figura Estrutura de dados tipo set Figura Estrutura de dados tipo sorted set Figura Uso de um BD relacional para todos os requisitos de armazenagem.. 56 Figura Exemplo de implementação de persistência poliglota Figura Modelo de ciclo de vida em cascata... 59

10 Figura Modelo de ciclo de vida incremental e iterativo Figura Diagrama de Caso de Uso Figura Diagrama de Classe Figura Diagrama de Atividade Pesquisar Restaurante Figura Diagrama de Sequência Pesquisar Restaurante Figura MVC Pesquisar Restaurante Figura Diagrama de Atividade Fazer Login Figura Diagrama de Sequência Fazer Login Figura Diagrama MVC Fazer Login Figura Padrão de sincronização MySQL/Redis Figura Arquivo context.xml Figura Arquivo persistence.xml Figura Classe entidade Produto Figura Classe EntityManagerUtil Figura Classe EntityManagerFilter Figura Implementação OpenTransactionInPhaseListener Figura Trecho do arquivo faces-config.xml Figura Arquitetura em camadas Figura Template padrão do site Figura Código-fonte do template padrão Figura Página Cadastro de Restaurante Figura Página Alterar Dados do Restaurante Figura Código applicationcontext.xml Figura Código applicationcontext-security.xml Figura Página de Login Figura Página Manter Cardápio Figura Página Pesquisar Restaurante Figura Página dos restaurantes encontrados Figura Página do cardápio do restaurante Figura Estruturas set e chave/valor Figura Estrutura hash Figura Implementação entidade auxiliar CrudEvent Figura Método save() utilizado para persistir o evento CRUD Figura Trecho da implementação da classe RestauranteRN... 92

11 Figura Implementação do método de sincronização MySQL/Redis Figura Implementação do método que processa um evento CRUD Figura Memória RAM ocupada pelo Redis Figura Comparativo de tempo de resposta MySQL x Redis... 96

12 LISTA DE QUADROS Quadro Produtos mais vendidos no varejo on-line do Brasil em Quadro Classificação dos canais de distribuição de food service... 23

13 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

14 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

15 SUMÁRIO INTRODUÇÃO ANÁLISE DE MERCADO PERFIL DOS CONSUMIDORES DO COMÉRCIO ELETRÔNICO USO DE DISPOSITIVOS MÓVEIS VENDA ON-LINE DE PRODUTOS ALIMENTÍCIOS PERFIL DOS BARES E RESTAURANTES DO BRASIL PORTAL DE VENDAS PARA ESTABELECIMENTOS COMERCIAIS ANÁLISE DOS PORTAIS PRESTADORES DE SERVIÇOS TECNOLOGIAS JAVASERVER FACES PRIMEFACES SPRING FRAMEWORK E SPRING SECURITY JAVA PERSISTENCE API (JPA) BANCOS DE DADOS Processos de transações ACID O Teorema CAP Basically Available Soft Eventually Consistent (BASE) Agregados Tipos de Bancos de Dados Bancos de Dados Relacionais NoSQL Key/Value stores Document stores Column family stores Graph database Redis String Hash List Set... 54

16 Sorted Set Persistência Poliglota REQUISITOS DO SISTEMA LEVANTAMENTO DE REQUISITOS Requisitos funcionais Requisitos não funcionais As restrições ANÁLISE DE REQUISITOS FUNCIONAIS Caso de uso: Pesquisar Restaurante Caso de uso: Fazer Login Caso de uso: Manter Usuário Restaurante Caso de uso: Manter Cardápio ANÁLISE DE REQUISITOS NÃO FUNCIONAIS Usabilidade Performance Confiabilidade Suportabilidade IMPLEMENTAÇÃO DO SISTEMA PREPARAÇÃO DO AMBIENTE DE DESENVOLVIMENTO CONFIGURAÇÃO JPA E IMPLEMENTAÇÃO DAS CLASSES ENTIDADES PADRÕES DE CONTROLE DE TRANSAÇÃO ACESSO AOS DADOS LEIAUTE DAS PÁGINAS DO SITE IMPLEMENTAÇÃO DOS CASOS DE USO Implementação do caso de uso Manter Usuário Restaurante Implementação do caso de uso Fazer Login Implementação do caso de uso Manter Cardápio Implementação do caso de uso Pesquisar Restaurante IMPLEMENTAÇÃO DA PERSISTÊNCIA POLIGLOTA Modelagem de dados para o banco de dados Redis Realização do padrão de sincronização entre MySQL e Redis Teste de viabilidade da persistência poliglota CONCLUSÃO... 97

17 REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Comandos Básicos do Redis

18 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

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

20 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 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, 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 Crescimento em milhões dos e-consumidores no Brasil por ano Fonte: E-Commerceorg, 2012 (adaptada pelos autores)

21 20 A Figura 1.1 representa o crescimento em milhões dos e-consumidores por ano, com um comparativo do ano de 2001 até 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 Quantidade de transações por renda familiar Fonte: E-Commerceorg, 2012 (adaptada pelos autores) Figura Quantidade de transações por faixa etária Fonte: E-Commerceorg, 2012 (adaptada pelos autores)

22 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 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 (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

23 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 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

24 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 Classificação dos canais de distribuição de food service Canal de distribuição Definição Tipo de estabelecimentos Comercial Comercial serviço Comercial alternativo Social O objetivo principal é a geração de lucro com a venda de refeições. É o núcleo do negócio. A alimentação é um serviço e não a atividade principal do negócio, mas com objetivo de lucro. Venda de refeições prontas para o consumo imediato ou posterior. Fonte alternativa de lucro. A alimentação é um serviço. O objetivo não é o lucro. Fonte: ECDFoodservice, 2010 (adaptado pelos autores) Restaurantes, churrascarias, pizzarias, lanchonetes, padarias, bares, entre outros Hotéis, motéis, escolas, hospitais, catering (aéreo, terrestre e marítimo) Lojas de conveniência, rotisserias e lanchonetes dentro de supermercados Exército, merenda escolar, presídios,restaurantes populares 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é 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

25 considerado que no período junho/2004 até junho/2010 houve uma inflação acumulada de 38,71% (Índice IGP-10). (ECDFOODSERVICE, 2010) PORTAL DE VENDAS PARA ESTABELECIMENTOS COMERCIAIS 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:

26 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 Página inicial do portal Restaurante Web Fonte: Restauranteweb, 2013

27 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 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

28 27 móveis. O Entregadelivey tem sua página inicial representada na Figura 1.7. Figura 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 Página inicial do portal Janamesa Fonte: Janamesa, 2013

29 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 Página inicial do portal Comernaweb Fonte: Comernaweb, 2013 Figura Página inicial do portal Peixeurbano Fonte: Peixeurbano, 2013

30 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 Figura Página inicial do portal Diskcook Fonte: Diskcook, 2013 No capítulo seguinte estão descritas as principais tecnologias utilizadas no desenvolvimento do site.

31 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

32 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 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

33 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 é

34 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 Ciclo de vida do JavaServer Faces Fonte: Devmedia, 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)

35 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

36 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) 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

37 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;

38 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 Diagrama de estado de uma transação Fonte: Silberschatz; Korth; Sudarshan, 2006, p.412 (adaptada pelos autores) 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

39 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 Escolha das propriedades do Teorema CAP Fonte: Sousa, 2010

40 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) 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

41 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 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

42 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) 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, baseandose 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 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

43 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 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

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

45 44 Na Figura 2.6 está ilustrada a divisão dos grupos de BDs existentes de acordo com suas respectivas categorias. Figura Bancos de dados relacionais x não relacionais Fonte: 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 simples (quase 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á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 a erros, pois se houver problema com um servidor, o serviço pode continuar disponível. (SADALAGE; FOWLER, 2013) Por outro lado, caso seja utilizado um BD com custo de licença, o custo pode ser muito grande utilizando cluster,, pois normalmente uma licença é válida para um único servidor, multiplicando, assim, o custo. Mas o maior problema é que os BDs

46 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 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

47 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 hashes 1, 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). (SADALAGE; FOWLER, 2013) Na Figura 2.7 está a estrutura de par chave/valor. Figura Par chave/valor ou chave/documento Fonte: Sadalage; Fowler, 2013 (adaptada pelos autores) 1 Hashes tipo específico de tabelas indexadas (SAWAYA M., 1999)

48 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 inmemory 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 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

49 48 acessá-lo diretamente através de consultas, por exemplo, um CartItem e retorná-lo. (SADALAGE; FOWLER, 2013) 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 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. (SADALAGE; FOWLER, 2013) Na Figura 2.8 está representado o conceito básico do modelo column family stores.

50 49 Figura 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 Exemplo de duas linhas de uma família de colunas Fonte: FH Köln, 2013

51 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 Figura Modelo de uma super coluna Fonte: FH Köln, 2013 (adaptada pelos autores) 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

52 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 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

53 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 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 String String é a estrutura de dados mais básica do Redis, podendo representar

54 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 Estrutura de dados tipo string Fonte: Carlson, 2013, p.9 (adaptada pelos autores) 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 Estrutura de dados tipo hash Fonte: Carlson, 2013, p.12 (adaptada pelos autores)

55 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 Figura 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) 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

56 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 Estrutura de dados tipo set Fonte: Carlson, 2013, p.11 (adaptada pelos autores) 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 Estrutura de dados tipo sorted set Fonte: Carlson, 2013, p.11 (adaptada pelos autores)

57 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 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 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

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

59 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:

60 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 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

61 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 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,

62 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: 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;

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

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

65 64 Figura Diagrama de Caso de Uso Fonte: Elaborada pelos autores, Na Figura 3.4 está representado o diagrama de classe.

66 65 Figura Diagrama de Classe Fonte: Elaborada pelos autores, Em seguida estão as histórias e os diagramas de atividades, sequência e MVC referentes a cada caso de uso das funcionalidades escolhidas.

67 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 cardápio do mesmo. Caso não haja nenhum restaurante 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 3.5. Figura Diagrama de Atividade Pesquisar Restaurante Fonte: Elaborada pelos autores, Na Figura 3.6 está ilustrado o diagrama de sequência do caso de uso Pesquisar Restaurante.

68 67 Figura Diagrama de Sequência Pesquisar Restaurante Fonte: Elaborada pelos autores, O diagrama MVC Pesquisar Restaurante está demonstrado na Figura 3.7. Figura MVC Pesquisar Restaurante Fonte: Elaborada pelos autores, 2014.

69 Caso de uso: Fazer Login O login pode ser realizado por qualquer um dos usuários: consumidor, restaurante e administrador. O usuário digita seu e sua senha anteriormente 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 retornar à opção fazer login ou sair do sistema. Na Figura 3.8 está o diagrama de atividades do caso de uso Fazer Login. Figura Diagrama de Atividade Fazer Login Fonte: Elaborada pelos autores, Na Figura 3.9 está representado o diagrama de sequência do caso de uso Fazer Login, demonstrando a permissão de cada usuário. O diagrama MVC do caso de uso Fazer Login está demonstrado na Figura 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.

70 69 Figura Diagrama de Sequência Fazer Login Fonte: Elaborada pelos autores, Figura Diagrama MVC Fazer Login Fonte: Elaborada pelos autores, 2014.

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

72 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 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

73 72 sistema. As principais vantagens que essa solução traz são: respostas rápidas para requisições, fácil replicação e sharding. (RICHARDSON, 2012) Para garantir a consistência entre os dois tipos de bancos de dados é necessário abrir mão das características ACID e trabalhar com consistência eventual. Na Figura 3.11 estão representados os dois passos necessários para a garantia da consistência eventual sincronizando Redis e MySQL. Figura Padrão de sincronização MySQL/Redis Fonte: Elaborada pelos autores, Descrição dos passos da Figura 3.11: 1. Transação ACID no MySQL: Começar MySQL transação; Fazer create/update/delete no MySQL;

74 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) 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.

75 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 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 ENTIDADES 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.

76 75 Na Figura 4.1 está a implementação deste arquivo de configuração. Figura Arquivo context.xml Fonte: Elaborada pelos autores, 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 Arquivo persistence.xml Fonte: Elaborada pelos autores, 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.

77 Na Figura 4.3 está representada a classe entidade Produto, escolhida para exemplificar as anotações JPA. 76 Figura Classe entidade Produto Fonte: Elaborada pelos autores, 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).

78 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 Classe EntityManagerUtil Fonte: Elaborada pelos autores, 2014.

79 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 Classe EntityManagerFilter Fonte: Elaborada pelos autores, 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.

80 79 Figura Implementação OpenTransactionInPhaseListener Fonte: Elaborada pelos autores, Figura Trecho do arquivo faces-config.xml Fonte: Elaborada pelos autores, 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

81 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 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 Template padrão do site Fonte: Elaborada pelos autores, 2014.

82 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 Figura Código-fonte do template padrão Fonte: Elaborada pelos autores, 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.

83 Implementação do caso de uso Manter Usuário Restaurante 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 Página Cadastro de Restaurante Fonte: Elaborada pelos autores, 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.

84 A Figura 4.12 é a imagem da segunda página Manter Usuário Restaurante, que permite realizar alterações dos dados cadastrados do restaurante. 83 Figura Página Alterar Dados do Restaurante Fonte: Elaborada pelos autores, 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 Código applicationcontext.xml Fonte: Elaborada pelos autores, 2014.

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

Leia mais

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS Pablo dos Santos Alves Alexander Roberto Valdameri - Orientador Roteiro da apresentação Introdução Objetivos Motivação Revisão bibliográfica

Leia mais

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES Hugo Henrique Rodrigues Correa¹, Jaime Willian Dias 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil hugohrcorrea@gmail.com, jaime@unipar.br Resumo.

Leia mais

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS Rodrigo das Neves Wagner Luiz Gustavo Galves Mählmann Resumo: O presente artigo trata de um projeto de desenvolvimento de uma aplicação para uma produtora de eventos,

Leia mais

Este livro é dedicado a minha esposa Edna e a todos os desenvolvedores que fizeram do software livre um meio profissional levado a sério.

Este livro é dedicado a minha esposa Edna e a todos os desenvolvedores que fizeram do software livre um meio profissional levado a sério. EDSON GONÇALVES Este livro é dedicado a minha esposa Edna e a todos os desenvolvedores que fizeram do software livre um meio profissional levado a sério. AGRADECIMENTOS Primeiramente gostaria de agradecer

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Pollyanna Gonçalves. Seminário da disciplina Banco de Dados II

Pollyanna Gonçalves. Seminário da disciplina Banco de Dados II Pollyanna Gonçalves Seminário da disciplina Banco de Dados II Web 2.0 vem gerando grande volume de dados Conteúdo gerado por redes sociais, sensores inteligentes, tecnologias de colaboração, etc. Novas

Leia mais

UNIVERSIDADE ESTADUAL DO CENTRO-OESTE UNICENTRO CURSO DE ESPECIALIZAÇÃO EM MÍDIAS EM EDUCAÇÃO

UNIVERSIDADE ESTADUAL DO CENTRO-OESTE UNICENTRO CURSO DE ESPECIALIZAÇÃO EM MÍDIAS EM EDUCAÇÃO UNIVERSIDADE ESTADUAL DO CENTRO-OESTE UNICENTRO CURSO DE ESPECIALIZAÇÃO EM MÍDIAS EM EDUCAÇÃO Jader dos Santos Teles Cordeiro Orientador Prof. Paulo Guilhermeti PERSISTÊNCIA EM OBJETOS JAVA: UMA ANÁLISE

Leia mais

CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE

CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE NoSQL Banco de Dados Não Relacional ALUNO: Heitor Oliveira Silva PROFESSOR ORIENTADOR:

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

Uma Breve Introdução. Andréa Bordin

Uma Breve Introdução. Andréa Bordin Uma Breve Introdução Andréa Bordin O que significa? NoSQL é um termo genérico que define bancos de dados não-relacionais. A tecnologia NoSQL foi iniciada por companhias líderes da Internet - incluindo

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente 1. Quais os componentes de um sistema cliente-servidor? Clientes e servidores 2. Na visão do hardware, defina o que é cliente e o que é servidor: Clientes. Qualquer computador conectado ao sistema via

Leia mais

Disciplina: Tecnologias de Banco de Dados para SI s

Disciplina: Tecnologias de Banco de Dados para SI s Curso de Gestão em SI Disciplina: Tecnologias de Banco de Dados para SI s Rodrigo da Silva Gomes (Extraído do material do prof. Ronaldo Melo - UFSC) Banco de Dados (BD) BD fazem parte do nosso dia-a-dia!

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

WebApps em Java com uso de Frameworks

WebApps em Java com uso de Frameworks WebApps em Java com uso de Frameworks Fred Lopes Índice O que são frameworks? Arquitetura em camadas Arquitetura de sistemas WEB (WebApps) Listagem resumida de frameworks Java Hibernate O que são frameworks?

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC

DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC Felipe Moreira Decol Claro 1, Késsia Rita da Costa Marchi 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil felipe4258@hotmail.com, kessia@unipar.br

Leia mais

Sistema de Ordens de Serviço HDA Soluções em Informática

Sistema de Ordens de Serviço HDA Soluções em Informática UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO Curso Superior de Graduação em ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Sistema de Ordens de Serviço HDA Soluções em Informática Por AUGUSTO CARRICONDE

Leia mais

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas Linguagem de Programação JAVA Professora Michelle Nery Nomeclaturas Conteúdo Programático Nomeclaturas JDK JRE JEE JSE JME JVM Toolkits Swing AWT/SWT JDBC EJB JNI JSP Conteúdo Programático Nomenclatures

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS Emanuel M. Godoy 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil godoymanel@gmail.com,

Leia mais

1 Criar uma entity a partir de uma web application que usa a Framework JavaServer Faces (JSF)

1 Criar uma entity a partir de uma web application que usa a Framework JavaServer Faces (JSF) Sessão Prática II JPA entities e unidades de persistência 1 Criar uma entity a partir de uma web application que usa a Framework JavaServer Faces (JSF) a) Criar um Web Application (JPAsecond) como anteriormente:

Leia mais

Engenharia de software 2011A. Trabalho sobre

Engenharia de software 2011A. Trabalho sobre Engenharia de software 2011A Trabalho sobre NOSQL Not only SQL NoSQL Not only SQL GRUPO - 9 Cléverton Heming Jardel Palagi Jonatam Gebing Marcos Wassem NOSQL O Termo NoSQL, foi utilizado pela primeira

Leia mais

O que é comércio eletrônico?

O que é comércio eletrônico? COMÉRCIO ELETRÔNICO O que é comércio eletrônico? O comércio eletrônico ou e-commerce é a compra e venda de mercadorias ou serviços por meio da Internet, onde as chamadas Lojas Virtuais oferecem seus produtos

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 04 SGBD Sistemas Gerenciadores de Bancos de Dados Prof. MSc. Edilberto Silva edilms@yahoo.com Conceitos Básicos DADOS: são fatos em sua forma primária. Ex: nome do funcionário,

Leia mais

DIFERENCIAIS SERVIÇOS. 1. Desenvolvimento De Sites Personalizados

DIFERENCIAIS SERVIÇOS. 1. Desenvolvimento De Sites Personalizados DIFERENCIAIS Acredito que o desenvolvimento de soluções para Internet não é um trabalho qualquer, deve-se ter certa experiência e conhecimento na área para projetar sistemas que diferenciem você de seu

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação. ANEXO 11 O MATRIZ Para o desenvolvimento de sites, objeto deste edital, a empresa contratada obrigatoriamente utilizará o framework MATRIZ desenvolvido pela PROCERGS e disponibilizado no início do trabalho.

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais Computação em Nuvem Computação em nuvem: gerenciamento de dados Computação em nuvem (Cloud Computing) é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia da Informação

Leia mais

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44 Armazenando Dados em Aplicações Java Parte 2 de 3: Apresentando as opções Hua Lin Chang Costa, hualin@cos.ufrj.br, COPPE/UFRJ. Leonardo Gresta Paulino Murta, leomurta@ic.uff.br, IC/UFF. Vanessa Braganholo,

Leia mais

Desenvolvimento de aplicação web com framework JavaServer Faces e Hibernate

Desenvolvimento de aplicação web com framework JavaServer Faces e Hibernate Desenvolvimento de aplicação web com framework JavaServer Faces e Hibernate Tiago Peres Souza 1, Jaime Willian Dias 1,2 ¹Universidade paranaense (Unipar) Paranavaí PR Brasil tiagop_ti@hotmail.com 2 Universidade

Leia mais

Desenvolvendo para WEB

Desenvolvendo para WEB Nível - Básico Desenvolvendo para WEB Por: Evandro Silva Neste nosso primeiro artigo vamos revisar alguns conceitos que envolvem a programação de aplicativos WEB. A ideia aqui é explicarmos a arquitetura

Leia mais

Bem-vindo à apresentação do SAP Business One.

Bem-vindo à apresentação do SAP Business One. Bem-vindo à apresentação do SAP Business One. Neste tópico, responderemos à pergunta: O que é o Business One? Definiremos o SAP Business One e discutiremos as opções e as plataformas disponíveis para executar

Leia mais

AUTOR(ES): VINICIUS RUIZ PONTES SILVA, JAQUELINE CRISTINA DA SILVA, JOÃO PAULO DE OLIVEIRA HONESTO

AUTOR(ES): VINICIUS RUIZ PONTES SILVA, JAQUELINE CRISTINA DA SILVA, JOÃO PAULO DE OLIVEIRA HONESTO Anais do Conic-Semesp. Volume 1, 2013 - Faculdade Anhanguera de Campinas - Unidade 3. ISSN 2357-8904 TÍTULO: IMPLEMENTAÇÃO DE UM SISTEMA PARA INTERCÂMBIOS ESTUDANTIS CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 10 Persistência de Dados

Leia mais

Frameworks para criação de Web Apps para o Ensino Mobile

Frameworks para criação de Web Apps para o Ensino Mobile 393 Frameworks para criação de Web Apps para o Ensino Mobile Lucas Zamim 1 Roberto Franciscatto 1 Evandro Preuss 1 1 Colégio Agrícola de Frederico Westphalen (CAFW) Universidade Federal de Santa Maria

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

AUTOR(ES): CARLOS ANTONIO PINHEIRO PINTO, ERMÍNIO PEDRAL SANTANA, GUILHERME CASSIANO DA SILVA

AUTOR(ES): CARLOS ANTONIO PINHEIRO PINTO, ERMÍNIO PEDRAL SANTANA, GUILHERME CASSIANO DA SILVA Anais do Conic-Semesp. Volume 1, 2013 - Faculdade Anhanguera de Campinas - Unidade 3. ISSN 2357-8904 TÍTULO: SISTEMA MÓVEL DE COMPRAS POR QR CODE CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS E TECNOLOGIAS SUBÁREA:

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais

Introdução aos Bancos de Dados Não-Relacionais. Mauricio De Diana (mestrando) Marco Aurélio Gerosa (orientador)

Introdução aos Bancos de Dados Não-Relacionais. Mauricio De Diana (mestrando) Marco Aurélio Gerosa (orientador) Introdução aos Bancos de Dados Não-Relacionais Mauricio De Diana (mestrando) Marco Aurélio Gerosa (orientador) Conteúdo Histórico de BDs não-relacionais na Web 4 Categorias de bancos NoSQL Exemplos de

Leia mais

Bleez Agência Digital... 3. Quem sou eu... 4. Introdução... 5. Quanto o ecommerce cresceu no Brasil... 7. Quem está comprando no ecommerce...

Bleez Agência Digital... 3. Quem sou eu... 4. Introdução... 5. Quanto o ecommerce cresceu no Brasil... 7. Quem está comprando no ecommerce... Sumário Bleez Agência Digital... 3 Quem sou eu... 4 Introdução... 5 Quanto o ecommerce cresceu no Brasil... 7 Quem está comprando no ecommerce... 10 Por que os brasileiros estão comprando mais... 12 O

Leia mais

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Tecnologia Java Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Origem da Tecnologia Java Projeto inicial: Oak (liderado por James Gosling) Lançada em 1995 (Java) Tecnologia

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA. Informatização de farmácias publicas utilizando software livre.

UNIVERSIDADE FEDERAL DE SANTA CATARINA. Informatização de farmácias publicas utilizando software livre. UNIVERSIDADE FEDERAL DE SANTA CATARINA Informatização de farmácias publicas utilizando software livre. MURILO NUNES ELIAS FLORIANÓPOLIS SC 2007/2 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE

Leia mais

Número de pessoas com acesso à internet passa de 120 milhões

Número de pessoas com acesso à internet passa de 120 milhões MÍDIA KIT INTERNET Número de pessoas com acesso à internet passa de 120 milhões Segundo pesquisa da Nielsen IBOPE, até o 1º trimestre/2014 número 18% maior que o mesmo período de 2013. É a demonstração

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

SISTEMA PARA AGENDAMENTO DE SERVIÇOS DE BELEZA ON-LINE

SISTEMA PARA AGENDAMENTO DE SERVIÇOS DE BELEZA ON-LINE FURB UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO SISTEMA PARA AGENDAMENTO DE SERVIÇOS DE BELEZA ON-LINE APARECIDA CEZERINO ORIENTADOR:

Leia mais

ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS

ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS Este anexo apresenta uma visão geral das seguintes plataformas: 1. Plataforma Microsoft.NET - VB.NET e C#; 2. Plataforma JAVA; 3. Plataforma Android, ios e Windows

Leia mais

GUIA ATS INFORMÁTICA: GESTÃO DE ESTOQUE

GUIA ATS INFORMÁTICA: GESTÃO DE ESTOQUE GUIA ATS INFORMÁTICA: GESTÃO DE ESTOQUE SUMÁRIO O que é gestão de estoque...3 Primeiros passos para uma gestão de estoque eficiente...7 Como montar um estoque...12 Otimize a gestão do seu estoque...16

Leia mais

PROJETO PEDAGÓGICO DE CURSOS

PROJETO PEDAGÓGICO DE CURSOS 1 de 6 PROJETO PEDAGÓGICO DE CURSOS BURITREINAMENTOS MANAUS-AM MARÇO / 2015 2 de 6 PACOTES DE TREINAMENTOS BURITECH A Buritech desenvolveu um grupo de pacotes de treinamentos, aqui chamados de BuriPacks,

Leia mais

Banco de Dados de Músicas. Andre Lima Rocha Campos Osório Pereira Carvalho

Banco de Dados de Músicas. Andre Lima Rocha Campos Osório Pereira Carvalho Banco de Dados de Músicas Andre Lima Rocha Campos Osório Pereira Carvalho Definição Aplicação Web que oferece ao usuário um serviço de busca de músicas e informações relacionadas, como compositor, interprete,

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

JPA Passo a Passo. Henrique Eduardo M. Oliveira henrique@voffice.com.br. Globalcode Open4Education

JPA Passo a Passo. Henrique Eduardo M. Oliveira henrique@voffice.com.br. Globalcode Open4Education JPA Passo a Passo Henrique Eduardo M. Oliveira henrique@voffice.com.br 1 Palestrante Henrique Eduardo M. Oliveira (henrique@voffice.com.br) > Trabalha: Arquiteto JEE / Instrutor Java > Formação: Ciências

Leia mais

Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano

Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano Programação Servidor para Sistemas Web 1 Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano Objetivo: Apresentar a teoria por trás dos padrões na construção de aplicações Web. INTRODUÇÃO Nas aulas anteriores

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Guia definitivo de ferramentas de Planejamento para Micro Empreendedores Individuais

Guia definitivo de ferramentas de Planejamento para Micro Empreendedores Individuais Guia definitivo de ferramentas de Planejamento para Micro Empreendedores Individuais Introdução O Brasil já tem 4,7 milhões de microempreendedores individuais, segundo dados de janeiro de 2015 da Receita

Leia mais

TECNOLOGIAS E FRAMEWORKS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS GERENCIAIS

TECNOLOGIAS E FRAMEWORKS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS GERENCIAIS TECNOLOGIAS E FRAMEWORKS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS GERENCIAIS Janderson Fernandes Barros ¹, Igor dos Passos Granado¹, Jaime William Dias ¹, ² ¹ Universidade Paranaense (UNIPAR) Paranavaí

Leia mais

JAVA ENTERPRISE EDITION: PERSISTÊNCIA DE BANCO DE DADOS

JAVA ENTERPRISE EDITION: PERSISTÊNCIA DE BANCO DE DADOS COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO JAVA ENTERPRISE EDITION: PERSISTÊNCIA DE BANCO DE DADOS FOZ DO IGUAÇU 2013 SUMÁRIO 1. PERSISTÊNCIA

Leia mais

SISTEMA PARA COMPOSIÇÃO E CORREÇÃO DE LISTAS DE QUESTÕES DE MÚLTIPLA ESCOLHA

SISTEMA PARA COMPOSIÇÃO E CORREÇÃO DE LISTAS DE QUESTÕES DE MÚLTIPLA ESCOLHA UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ROBERTO ROSIN SISTEMA PARA COMPOSIÇÃO E CORREÇÃO DE LISTAS DE QUESTÕES DE MÚLTIPLA ESCOLHA

Leia mais

Introdução a Banco de Dados

Introdução a Banco de Dados Introdução a Banco de Dados O modelo relacional Marta Mattoso Sumário Introdução Motivação Serviços de um SGBD O Modelo Relacional As aplicações não convencionais O Modelo Orientado a Objetos Considerações

Leia mais

COMPARAÇÃO ENTRE OS FRAMEWORKS DE DESENVOLVIMENTO DE SOFTWARE ENTITY FRAMEWORK E NHIBERNATE : ESTUDO DE CASO EM UM SISTEMA

COMPARAÇÃO ENTRE OS FRAMEWORKS DE DESENVOLVIMENTO DE SOFTWARE ENTITY FRAMEWORK E NHIBERNATE : ESTUDO DE CASO EM UM SISTEMA 73 COMPARAÇÃO ENTRE OS FRAMEWORKS DE DESENVOLVIMENTO DE SOFTWARE ENTITY FRAMEWORK E NHIBERNATE : ESTUDO DE CASO EM UM SISTEMA Daniel José Angotti Analista de Negócio, Repom S/A djangotti@gmail.com Carlos

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO UTILIZANDO O HIBERNATE Rafael Laurino GUERRA, Dra. Luciana Aparecida Martinez ZAINA Faculdade de Tecnologia de Indaiatuba FATEC-ID 1 RESUMO Este artigo apresenta

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Engenharia de Software Aplicações de Internet

Engenharia de Software Aplicações de Internet Engenharia de Software Aplicações de Internet Eduardo Santos eduardo.edusantos@gmail.com eduardo.santos@planejamento.gov.br www.softwarepublico.gov.br Histórico Por que existe a Internet? Por que existe

Leia mais

TECNOLOGIAS E FRAMEWORKS PARA O DESENVOLMENTO DE INTERFACES WEB

TECNOLOGIAS E FRAMEWORKS PARA O DESENVOLMENTO DE INTERFACES WEB TECNOLOGIAS E FRAMEWORKS PARA O DESENVOLMENTO DE INTERFACES WEB Marcelo Rodrigo da Silva Ribeiro 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil marcelo.rodrigo@live.com,

Leia mais

7 Passos Para a Criação de Uma Boa Loja Virtual. Índice

7 Passos Para a Criação de Uma Boa Loja Virtual. Índice 2 Índice Introdução... 3 Passo 1 Entender o que é Venda Online e E-commerce... 4 Passo 2 Entender o Mercado de Comércio Eletrônico... 5 Passo 3 Canais de Venda... 6 Passo 4 Como identificar uma Boa Plataforma

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

COMO CONQUISTAR CLIENTES COM APLICATIVOS PARA CELULAR

COMO CONQUISTAR CLIENTES COM APLICATIVOS PARA CELULAR COMO CONQUISTAR CLIENTES COM APLICATIVOS PARA CELULAR CONTEÚDO 1 2 3 4 5 6 Por que as empresas precisam estar conectadas ao mundo mobile Como os aplicativos mobile podem atrair mais clientes. Como os aplicativos

Leia mais

INTRODUÇÃO E CONCEITOS BÁSICOS. Prof. Ronaldo R. Goldschmidt

INTRODUÇÃO E CONCEITOS BÁSICOS. Prof. Ronaldo R. Goldschmidt INTRODUÇÃO E CONCEITOS BÁSICOS Prof. Ronaldo R. Goldschmidt Hierarquia Dado - Informação - Conhecimento: Dados são fatos com significado implícito. Podem ser armazenados. Dados Processamento Informação

Leia mais

Persistência de Dados em Java com JPA e Toplink

Persistência de Dados em Java com JPA e Toplink Persistência de Dados em Java com JPA e Toplink Vinicius Teixeira Dallacqua Curso de Tecnologia em Sistemas para Internet Instituto Federal de Educação, Ciência e Tecnologia - IFTO AE 310 Sul, Avenida

Leia mais

TECNOLOCIA JAVA WEB PARA DESENVOLVIMENTO DE SISTEMAS DE LEILÃO

TECNOLOCIA JAVA WEB PARA DESENVOLVIMENTO DE SISTEMAS DE LEILÃO TECNOLOCIA JAVA WEB PARA DESENVOLVIMENTO DE SISTEMAS DE LEILÃO Danilo Alves Verone de Oliveira ¹, Jaime William Dias ¹ ² ¹ Universidade Paranaense (UNIPAR) Paranavaí - PR - Brasil dan.verone@hotmail.com

Leia mais

INTRODUÇÃO E CONFIGURAÇÃO DO PRIMEFACES MOBILE EM APLICAÇÕES JSF

INTRODUÇÃO E CONFIGURAÇÃO DO PRIMEFACES MOBILE EM APLICAÇÕES JSF INTRODUÇÃO E CONFIGURAÇÃO DO PRIMEFACES MOBILE EM APLICAÇÕES JSF Guilherme Macedo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil guilhermemacedo28@gmail.com, jaime@unipar.br Resumo.

Leia mais

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1 Descritivo Técnico 16/02/2011 Página 1 1. OBJETIVO O SLAview é um sistema de análise de desempenho de redes IP por meio da monitoração de parâmetros de SLA (Service Level Agreement, ou Acordo de Nível

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

ShoeSystem 1.0 Sistema para loja de calçados

ShoeSystem 1.0 Sistema para loja de calçados Artigo apresentado ao UNIS, como parte dos requisitos para obtenção do título de tecnólogo em Análise e Desenvolvimento de Sistemas 1 ShoeSystem 1.0 Sistema para loja de calçados André Luis dos Reis Revair,

Leia mais

Prezado Futuro Cliente

Prezado Futuro Cliente Prezado Futuro Cliente É com grade satisfação que encaminhamos nossa apresentação institucional e certos de estabelecermos uma parceria de sucesso e duradoura. Ela foi desenvolvida com objetivo de mostrar

Leia mais

MÓDULO Programação para Web 2

MÓDULO Programação para Web 2 MÓDULO Programação para Web 2 Sistemas Web na JEE OBJETIVO DO MÓDULO Arquitetura Web em aplicações JEE Conceitos iniciais Desenvolvimento Web Aplicações web tornam-se mais e mais importantes Mais e mais

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

Fatos e Mitos do Java EE. Fernando Lozano Consultor 4Linux lozano@4linux.com.br

Fatos e Mitos do Java EE. Fernando Lozano Consultor 4Linux lozano@4linux.com.br Fatos e Mitos do Java EE Fernando Lozano Consultor 4Linux lozano@4linux.com.br O Que É o Java EE? É um padrão de bibliotecas e componentes (APIs) para a criação de aplicações corporativas Também é um padrão

Leia mais

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior Arquitetura de SGBD Prof. Antonio Almeida de Barros Junior Agenda Caracterização de SGBDs SGBDs Centralizados SGBDs Cliente-Servidor SGBDs Distribuídos Homogêneos Multi-SGBDs Heterogêneos SGBDs Paralelos

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

Serviços de Ecommerce

Serviços de Ecommerce Amen ecommerce 1 Serviços de Ecommerce Ideal para iniciar o seu negócio on-line; ou Complementar as vendas da sua loja física; Os Serviços Ecommerce são soluções poderosas fáceis e acessíveis para criar

Leia mais

DESENVOLVIMENTO DE UM APLICATIVO DO TIPO SECRETÁRIO VIRTUAL PARA A PLATAFORMA ANDROID

DESENVOLVIMENTO DE UM APLICATIVO DO TIPO SECRETÁRIO VIRTUAL PARA A PLATAFORMA ANDROID DESENVOLVIMENTO DE UM APLICATIVO DO TIPO SECRETÁRIO VIRTUAL PARA A PLATAFORMA ANDROID Maik Olher CHAVES 1 ; Daniela Costa Terra 2. 1 Graduado no curso de Tecnologia em Análise e Desenvolvimento de Sistemas

Leia mais

Estudo de Viabilidade

Estudo de Viabilidade Universidade Federal de Pernambuco Ciência da Computação Especificação de Requisitos e Validação de Sistemas Professora: Carla Taciana Lima Lourenço Silva Schuenemann Estudo de Viabilidade Clínica médica

Leia mais

Persistência. 2004 Fernando Lozano, http://www.lozano.eti.br Persistência Objeto-Relacional com Java Pag. 1

Persistência. 2004 Fernando Lozano, http://www.lozano.eti.br Persistência Objeto-Relacional com Java Pag. 1 Persistência Objeto-Relacional com Java Fernando Lozano http://www.lozano.eti.br Consultor Independente Prof. Faculdades UniABEU Prof. SENAC Editor Adjunto da Revista Java Magazine 2004 Fernando Lozano,

Leia mais

Documento de Projeto de Sistema

Documento de Projeto de Sistema Documento de Projeto de Sistema 1 IFES / Serra Projeto: Gerenciador de Pelada - Oasis Registro de Alterações: Versão Responsável Data Alterações 0.1 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda,

Leia mais

Faculdade de Tecnologia Senac Goiás. Alunos: Erik de Oliveira Douglas Ferreira, Raphael Beghelli, João Victor Alves. Professor : Diogo Ananias

Faculdade de Tecnologia Senac Goiás. Alunos: Erik de Oliveira Douglas Ferreira, Raphael Beghelli, João Victor Alves. Professor : Diogo Ananias Faculdade de Tecnologia Senac Goiás. Alunos: Erik de Oliveira Douglas Ferreira, Raphael Beghelli, João Victor Alves. Professor : Diogo Ananias CONSULTORIA COMÉRCIO ELETRÔNICO CONSULTORIA PARA IMPLANTAÇÃO

Leia mais

Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI

Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI Fundamentos de Banco de Dados Aula 01 Introdução aos Sistemas de Bancos de Dados Introdução aos Sistemas de BD Objetivo Apresentar

Leia mais

Banco de Dados I. Introdução Conceitos

Banco de Dados I. Introdução Conceitos Banco de Dados I Introdução Conceitos Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Apresentação Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Ementa Conceitos Fundamentais de Banco de Dados; Características

Leia mais

Banco de Dados I. Quantidade de informação gerada em um dia. Aula 1. 59 milhões de clientes ativos; Mais de 42 terabytes de dados; Salários na área

Banco de Dados I. Quantidade de informação gerada em um dia. Aula 1. 59 milhões de clientes ativos; Mais de 42 terabytes de dados; Salários na área Banco de Dados I Aula 1 Quantidade de informação gerada em um dia E-mails Compras Bate-papo Notícias Blogs Transações bancárias Etc... 59 milhões de clientes ativos; Mais de 42 terabytes de dados; 100

Leia mais