Universidade Federal Fluminense rio de Rio das Ostras Polo Universita ncia e Tecnologia Instituto de Cie ncia da Computa

a o Bacharelado em Cie ca

Gabriel Givigier Guimara es

Pechincha Colaborativa - Um Sistema Para Manuten c ao Colaborativa De Pre cos

Rio das Ostras-RJ 2012

ii GABRIEL GIVIGIER GUIMARAES

COLABORATIVA DE PECHINCHA COLABORATIVA - UM SISTEMA PARA MANUTENC AO PRECOS

Monograa

apresentada

ao

Curso

de

Bacharelado em Ci encia da Computa c ao do Polo Universit ario de Rio das Ostras da Universidade Federal Fluminense, como

requisito parcial para obten c ao do Grau de Bacharel. Area de Concentra c ao: Sistemas

Colaborativos

Orientador: Prof. D.Sc. CARLOS BAZILIO MARTINS

Rio das Ostras-RJ 2012

iii GABRIEL GIVIGIER GUIMARAES

COLABORATIVA DE PECHINCHA COLABORATIVA - UM SISTEMA PARA MANUTENC AO PRECOS

Monograa

apresentada

ao

Curso

de

Bacharelado em Ci encia da Computa c ao do Polo Universit ario de Rio das Ostras da Universidade Federal Fluminense, como

requisito parcial para obten c ao do Grau de Bacharel. Area de Concentra c ao: Sistemas

Colaborativos.

Aprovada em 10 de 2012.

BANCA EXAMINADORA

Prof. D.Sc. CARLOS BAZILIO MARTINS - Orientador UFF

Profa. D.Sc. ADRIANA PEREIRA DE MEDEIROS UFF

Prof. M.Sc. EDUARDO MARQUES UFF

Rio das Ostras-RJ 2012

iv

Dedico esse trabalho aos meus pais, por toda a aten c ao, compreens ao e suporte ao longo da exaustiva jornada acad emica. Tamb em dedico o trabalho ao professor Bazilio, que apesar das in umeras reuni oes de departamento e dos 10 trilh oes de e-mails n ao lidos, encontrou tempo para auxiliar no desenvolvimento desse trabalho.

Lista de Figuras
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 UID Cadastrar Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Atualizar Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14 15 15 16 16 17 17 18 18 19 20 22 22 23 24 25 26 26 28 28 29 31

UID Cadastrar Estabelecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Atualizar Estabelecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Cadastrar Endere co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Atualizar Endere co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Informar Oferta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Pesquisar Oferta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UID Criar Lista de Compras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10 UID Editar Lista de Compras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Diagrama de Classes de An alise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 Diagrama de Classes de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13 P agina principal do Pechincha Colaborativa . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 P agina com os resultados da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 P agina com as listas de compras de um usu ario . . . . . . . . . . . . . . . . . . . . . . . . 3.16 P agina com os itens de uma lista de compras . . . . . . . . . . . . . . . . . . . . . . . . . 3.17 P agina para informar uma oferta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18 P agina principal do Pechincha Colaborativa adaptada para dispositivos m oveis . . . . . . 3.19 P agina com os resultados da pesquisa adaptada para dispositivos m oveis . . . . . . . . . . 4.1 4.2 4.3 4.4 Modelo Cliente x Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura do Pechincha Colaborativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura Modelo-Vis ao-Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bot oes para divulga c ao do Pechincha Colaborativa . . . . . . . . . . . . . . . . . . . . . .

Sum ario
Lista de Figuras Resumo 1 Introdu c ao 2 Pechincha Colaborativa 2.1 2.2 Motiva c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas Colaborativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.3 Introdu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caracter sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v viii 1 2 2 3 3 4 5 8 8 8 14 18 19 20 21 21 25 27 27 30 31 32 33 33 34

Descri c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Modelagem do Sistema 3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.2 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramas de Intera c ao do Usu ario . . . . . . . . . . . . . . . . . . . . . . . . . . .

Esquema Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 Diagrama de Classes de An alise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Classes de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

Projeto de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 Interface Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Arquitetura do Sistema 4.1 4.2 4.3 4.4 Descri c ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pechincha Colaborativa como Servi co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Servi cos Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliotecas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Conabilidade das Informa c oes 5.1 5.2 Introdu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Algoritmos Para o C alculo de Reputa c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

vii 5.3 Nossa Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 5.4 Introdu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formata c ao da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36 38 41 43 45

Sistemas Semelhantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Conclus ao Refer encias Bibliogr acas

Resumo
O Pechincha Colaborativa(http://pechincha.pagodabox.com) e uma ferramenta para manuten c ao colaborativa de pre cos. Utilizamos o modelo de uma aplica c ao colaborativa, dessa forma n ao temos uma unidade que centraliza a a c ao de atualizar os pre cos. Esse modelo e o mais adequado porque temos uma innidade de produtos a serem mantidos atualizados e uma abordagem centralizada seria invi avel. O sistema conta com a colabora c ao dos usu arios para manter os pre cos atualizados, portanto, quanto maior o n umero de usu arios e o envolvimento dos mesmos, os pre cos ser ao atualizados mais rapidamente. H a tamb em a preocupa c ao com a veracidade desses pre cos informados, para tentar controlar essa situa c ao haver a a cria c ao de um sistema de reputa c ao dos usu arios, bonicando ou penalizando de acordo com as contribui c oes. Nossa proposta e que a qualica c ao dos usu arios tamb em seja colaborativa e autom atica, para que isso ocorra, devemos considerar diversas vari aveis como: frequ encia de utiliza c ao, antiguidade no sistema, n umero de atualiza c oes corretas, etc. N ao conhecemos uma aplica c ao que utilize um modelo eciente de classica c ao colaborativa de usu arios. Possu mos informa c oes de que h a aplica c oes tentando desenvolver modelos semelhantes, por em, ainda sem sucesso.

Palavras-chave: sistema colaborativo, buscador, comparador de pre cos.

viii

Cap tulo 1

Introdu c ao
Tudo que ofende o consumidor recebe a penalidade m axima, que e o desprezo do consumidor. Nizan Guanaes

Este trabalho apresenta um sistema que surgiu para solucionar a d uvida que muitas fam lias encontram ao fazer compras em um supermercado, qual estabelecimento possui os melhores pre cos? Essa pergunta e v alida pois segundo a Funda c ao Get ulio Vargas, a compara c ao dos pre cos de diferentes supermercados pode proporcionar at e 40% de economia na lista de compras. Podemos notar que essa pergunta se estende a outras empresas do varejo. Pensando nisso, constru mos uma aplica c ao que permite a pesquisa de produtos em qualquer tipo de estabelecimento. Al em disso, o sistema tamb em permite a cria c ao de listas de compras, que visa facilitar as compras dos consumidores. Apesar desse problema ser de simples descri c ao, sua solu c ao n ao e t ao simples. O grande n umero de estabelecimentos e produtos, impede que a atualiza c ao dos pre cos seja centralizada. No sistema que implementamos, n os utilizamos uma abordagem colaborativa que conta com os usu arios para manter os pre cos atualizados. Dessa forma, o sucesso dessa aplica c ao depende de um grande n umero de colaboradores. Para apoiar a abordagem colaborativa proposta, n os desenvolvemos uma aplica c ao Web. Essa aplica c ao foi desenvolvida seguindo o padr ao MVC e utilizou dados de outros webservices com o intuito de enriquecer a aplica c ao. Al em disso, tamb em foi desenvolvido o nosso pr oprio webservice para que outros desenvolvedores utilizem os dados da nossa aplica c ao. A constru c ao de um sistema colaborativo n ao e simples. Ao permitir que os usu arios informem os dados, deve-se levar em considera c ao a possibilidade dos usu arios n ao colaborarem com informa c oes corretas, ou seja, deles n ao serem con aveis. Para solucionar esse problema, n os estudamos alguns algoritmos para o c alculo da reputa c ao de usu arios. N os estudamos esses algoritmos a m de encontrar um que se adaptasse ao nosso problema ou que permitisse modica c oes para a nossa utiliza c ao. Por m, n os modicamos o SocialTrust para que o mesmo pudesse ser utilizado na manuten c ao colaborativa de pre cos.

Cap tulo 2

Pechincha Colaborativa
A coopera c ao e a convic c ao plena de que ningu em pode chegar ` a meta se n ao chegarem todos. Virginia Burden

2.1

Motiva c ao
A ideia de construir o Pechincha Colaborativa surgiu quando um dos autores encontrou grande

diculdade em manter planilhas de compras atualizadas. Devido a grande varia c ao dos pre cos, as planilhas rapidamente tornavam-se obsoletas. Visando facilitar a atualiza c ao das planilhas de compras, os autores propuseram a cria c ao de um sistema que mantivesse os pre cos atualizados e permitisse a cria c ao de listas de compras. Entretanto, essa ideia esbarrava em como as atualiza c oes seriam realizadas. Devido ao grande n umero de estabelecimentos e produtos, um sistema que centralize a atualiza c ao dessas ofertas torna-se praticamente invi avel. Para contornar essa situa c ao chegamos a conclus ao de que a abordagem mais adequada seria a constru c ao de um sistema colaborativo. Nossa proposta prev e que o usu ario colabore com o cadastro de estabelecimentos e ofertas, e ainda contribua com a atualiza c ao de pre cos das ofertas. A ideia inicial era manter atualizadas apenas ofertas de supermercados. Entretanto, vimos que seria poss vel generalizar o sistema para qualquer tipo de estabelecimento. Constatamos tamb em que iniciativas como a do PROCON(Programa de Orienta c ao e Prote c ao ao Consumidor), que compara pre cos de materiais escolares, s ao de grande import ancia para o consumidor, por em, s ao espor adicas. Atualmente n ao h a um meio de se comparar ofertas em diferentes supermercados, ou ent ao em diversas papelarias. Os meios que possu mos para consulta s ao revistas, panetos e an uncios em televis ao e r adio. As ferramentas de compara c ao de pre cos online como o BuscaP e e o BoaDica s ao um esfor co no sentido de facilitar a pesquisa por pre cos. O fato de serem ferramentas online torna o servi co ainda mais interessante, uma vez que os consumidores n ao precisam se deslocar sicamente para realizar a compara c ao de pre cos. Entretanto, em ambos a divulga c ao de pre cos de produtos est a vinculada a um acordo pr evio onde os lojistas pagam para que seus produtos sejam listados nas buscas. Esta forma

3 de cobran ca varia entre as ferramentas, mas s ao equivalentes na ess encia. Al em disso, tanto o Buscap e quanto o BoaDica n ao atendem a qualquer tipo de produto. O Buscap e permite a consulta de produtos em lojas que trabalhem com vendas online e o BoaDica a consulta de eletr onicos.

2.2
2.2.1

Sistemas Colaborativos
Introdu c ao
A utiliza c ao da coopera c ao para a realiza c ao de tarefas n ao e novidade na intera c ao humana.

Desde a Pr e-Hist oria h a relatos de formas rudimentares de coopera c ao entre humanos. Atrav es do trabalho colaborativo havia a possibilidade da ca ca de animais de grande porte e da constru c ao de moradias em menor tempo. Colaborar, ou seja, trabalhar em conjunto a m de atingir uma meta, era, e continua sendo, imprescind vel para possibilitar a realiza c ao de tarefas complexas. Caminhando em uma frente contr aria, Adam Smith armou em A Riqueza das Na c oes[34]: Num ambiente competitivo, as ambi c oes individuais servem ao bem comum. Ou seja, quando um indiv duo faz o que e melhor para si, todo o grupo e beneciado. Adam Smith julgava que a colabora c ao n ao seria ben eca para um grupo. Para ele o pensamento individual era muito mais importante. Para John Nash, que futuramente receberia o pr emio Nobel por causa desse modelo, o pensamento de Adam Smith n ao estava incorreto, por em, incompleto. Segundo Nash[31], o melhor resultado seria alcan cado caso todos os indiv duos zessem o que e melhor para si e para o grupo. Essa ideia cou conhecida como Equil brio de Nash e se destacou por apoiar o uso da colabora c ao. O conceito de colabora c ao e t ao importante que pode revolucionar a forma como entendemos a evolu c ao das esp ecies. A Teoria da Sele c ao Natural criada por Charles Darwin e bem aceita pela comunidade acad emica como uma explica c ao para a evolu c ao da vida no planeta Terra. Essa teoria diz que os indiv duos mais propensos ` a adapta c ao tinham mais chances de sobreviver, ou seja, os mais fortes possu am vantagem na corrida pela sobreviv encia. Por em, da mesma forma que John Nash complementou a teoria de Adam Smith, h a um bi ologo que arma que a teoria de Darwin est a incompleta e prop oe um complemento para a mesma. Edward Wilson e um sociobiologista professor da Universidade de Harvard e armou em seu livro(A Conquista Social da Terra[35]) que o processo evolutivo e mais bem sucedido em comunidades onde h a a colabora ca o. Portanto, a teoria de Wilson arma que a sele c ao natural e importante, embora n ao explique tudo, pois tamb em h a o perl das comunidades colaborativas. Naturalmente, houve a necessidade de se utilizar esse conceito de colabora c ao no ambito da Computa c ao. A necessidade dessa utiliza c ao surgiu quando compreendeu-se que o ambiente de trabalho envolvia a realiza c ao de tarefas atrav es da coopera c ao entre pessoas[22]. Essa compreens ao do ambiente de trabalho possibilitou que equipes separadas geogracamente e com diferentes hor arios, pudessem trabalhar em um mesmo projeto[23]. Para apoiar esses projetos, foram elaborados sistemas colaborativos que permitiam essa intera c ao de usu arios em diferentes locais operando sobre diferentes hor arios. A utiliza c ao dos sistemas colaborativos facilitou a realiza c ao de algumas tarefas. Por em, cou evidente que a constru c ao de sistemas desse tipo deveria ser melhor estudada. Isso ocorreu porque esses sistemas possuem conceitos espec cos quando comparados com sistemas que n ao permitem o trabalho

4 colaborativo. Dentre esses, temos a intera c ao entre usu arios. A intera c ao entre usu arios e uma atividade complexa devido a riqueza de sinais corporais, protocolos sociais, comportamento e outros detalhes. Num cen ario ideal n ao haveria distin c ao entre a intera c ao virtual e a intera c ao f sica. Entretanto, a interface entre os sistemas e os usu arios ainda e pobre em detalhes[24]. Os problemas encontrados serviram de motiva c ao para a cria c ao de grupos espec cos. Dentre os grupos podemos destacar o CSCW(Computer-Supported Cooperative Work ). O CSCW contempla o desenvolvimento de sistemas colaborativos em diversas areas de conhecimento[23], envolvendo a participa c ao de prossionais como desenvolvedores de software, antrop ologos, comunicadores, dentre outros[25]. Por m, podemos resumir o CSCW como uma area de pesquisa interdisciplinar que utiliza tecnologias de computa ca o e telecomunica c ao para auxiliar o trabalho de grupos de usu arios.

2.2.2

Caracter sticas
Conforme citamos, o objetivo do CSCW e dar suporte ao trabalho colaborativo. Para apoiar esse

trabalho s ao utilizados os groupware [26]. Groupware e a jun c ao das palavras group e software, e pode ser descrito como sistemas que utilizam computa c ao para apoiar a execu c ao de uma tarefa por um grupo de usu arios[28]. A combina c ao dessas diferentes ferramentas groupware d a origem ao que chamamos de ambiente colaborativo. Um ambiente colaborativo deve apoiar a comunica c ao, a coopera c ao e a coordena c ao de usu arios. A comunica c ao permite a intera c ao dos usu arios. Esse conceito e essencial, pois se trata de um sistema colaborativo, logo, fomentar a troca de ideias e um dos principais objetivos. Essa comunica c ao pode ser s ncrona, na qual os usu arios se comunicam ao mesmo tempo, ou ass ncrona, onde a comunica c ao e feita em tempos diferentes. Outro aspecto que um ambiente colaborativo deve possuir e a coopera c ao. Para isso, o ambiente deve apoiar o compartilhamento de informa c oes entre os usu arios, fornecer o contexto atual aos usu arios e noticar cada altera c ao realizada[28]. J a a coordena c ao signica organizar os usu arios quanto ` as informa c oes. Isso e feito para colocar os usu arios cientes do andamento das tarefas no ambiente colaborativo, evitar trabalhos duplicados e para o cumprimento de tarefas nos prazos combinados. Esse modelo que combina comunica c ao, coopera c ao e coordena c ao e denominado Modelo 3C[29]. Visando apoiar a comunica c ao entre usu arios, os sistemas colaborativos utilizam Internet, Intranet e Extranet. As Intranet e Extranet visam apoiar o trabalho de equipes de uma empresa. Dessa forma, as equipes de trabalho n ao precisam necessariamente, estarem no mesmo local. Isso facilita o trabalho, pois permite o trabalho de equipes em diferentes hor arios, uma caracter stica dos sistemas colaborativos. J a a Internet pode ser utilizada para discuss ao em f oruns visando a troca de ideias, para o envio e o recebimento de e-mails, dentre outras tarefas[25]. Podemos classicar os sistemas colaborativos de acordo com suas caracter sticas espec cas. Dentre essas podemos citar as classica c oes abaixo: 1. Sistemas de Mensagens: Esses permitem a troca de mensagens, arquivos de v deo, arquivos de audio, voz e arquivos multim dia atrav es da internet, intranet ou extranet. Dentre esses podemos destacar os sistemas de e-mail e de mensagens instant aneas.

5 2. Sistemas de Supervis ao: Os sistemas em quest ao d ao suporte a realiza c ao de tarefas realizadas por mais de um usu ario. Dentre os exemplos podemos citar sistemas que controlam o cronograma de projetos e sistemas que permitem a edi c ao de documentos em conjunto. 3. Sistemas de Confer encias: S ao utilizados para que pessoas se comuniquem enquanto est ao trabalhando em conjunto. Esses sistemas s ao muito utilizados por equipes distantes geogracamente e que tem a necessidade de se reunirem para discutirem ideias. Podemos destacar os sistemas de bate-papo e os sistemas de reuni ao eletr onica como exemplos desse grupo. Entretanto, tamb em h a classica c oes mais gen ericas com respeito aos sistemas colaborativos: 1. Comunica c ao S ncrona: S ao as aplica c oes nas quais as intera c oes ocorrem na mesma hora e no mesmo local. 2. Comunica c ao S ncrona Distribu da: S ao as aplica c oes onde a intera c ao ocorre na mesma hora e a localiza c ao e distribu da, ou seja, as aplica c oes n ao est ao no mesmo local. 3. Comunica c ao Ass ncrona: S ao as aplica c oes nas quais as intera c oes n ao ocorrem na mesma hora, por em, ocorrem no mesmo local. 4. Comunica c ao Ass ncrona Distribu da: S ao as aplica c oes onde as intera c oes n ao ocorrem na mesma hora e a localiza c ao das aplica c oes e distribu da. A utiliza c ao dos sistemas colaborativos n ao e recomendada em todas as situa c oes. Entretanto, com a maior utiliza c ao da internet, esses sistemas est ao sendo cada vez mais utilizados. Esses sistemas possuem algumas vantagens de utiliza ca o em rela c ao ` a sistemas monousu ario. Podemos citar as seguintes: facilidade na solu c ao de problemas complexos em grupos, facilidade na comunica c ao, corte nos custos de viagens, forma c ao de grupos de interesses e economia de tempo e custos na coordena c ao de grupos de usu arios.

2.3

Descri c ao
O Pechincha Colaborativa[1] e um agregador de ofertas, ou seja, e um sistema que permite que

consumidores encontrem ofertas de produtos em qualquer tipo de estabelecimento cadastrado, seja ofertas em supermercados, lojas de eletr onicos, de autom oveis ou de qualquer outra categoria. Com a pesquisa de ofertas e poss vel comparar pre cos em diferentes estabelecimentos, e com isso saber se o pre co do produto e justo ou n ao. Al em disso, como o Pechincha Colaborativa n ao armazena apenas o pre co mais recente, e poss vel ter um hist orico e saber se um produto est a mais caro do que na u ltima semana, por exemplo. O sistema proposto e um sistema colaborativo de intera c ao ass ncrona centrada e distribu da[27]. Sua base de dados de ofertas e centrada, enquanto que a localiza c ao dos usu arios e distribu da. O Pechincha Colaborativa e uma combina c ao de sistema colaborativo de gerenciamento de conte udo e de gerenciamento de conhecimento[2]. Como caracter stica temos a participa c ao dos usu arios na adi c ao e

6 manuten c ao das informa c oes. O sistema permite que os usu arios cadastrem e atualizem ofertas, estabelecimentos e produtos. Dessa forma, os usu arios assumem o papel de colaboradores e s ao respons aveis por manter as informa c oes do s tio atualizadas. Tamb em vale observar que sendo um sistema colaborativo on-line, nosso objetivo e disponibilizar uma base de dados de pre cos de produtos atualizados em tempo real. Al em de contar com a colabora c ao dos usu arios para manter as informa co es atualizadas, o Pechincha Colaborativa tamb em conta com os usu arios para conrmar os pre cos das ofertas. Dessa forma podemos vericar se os pre cos informados est ao corretos. Podemos observar que usualmente o cliente prepara uma lista de compras antes de realizar a compra do supermercado. Visando facilitar essa tarefa, o Pechincha Colaborativa permite que o usu ario mantenha suas lista de compras armazenadas no sistema. Al em disso, o sistema ainda permite a utiliza c ao de ltros como ordena c ao por menor pre co e proximidade de estabelecimentos. Dessa forma, o usu ario tem a op c ao de visualizar o valor total da lista de compras e decidir em qual estabelecimento comprar. Devido ao fato de utilizarmos uma abordagem colaborativa, que conta com os usu arios para manter as informa c oes atualizadas, devemos nos atentar quanto a veracidade dessas informa c oes. Como a web n ao possui uma forma de vericar o grau de conabilidade de um usu ario, essa tarefa ca a cargo das aplica c oes. Em algumas aplica c oes essa tarefa n ao e das mais complexas, seja pelo baixo n umero de a c oes a serem qualicadas, seja pelo baixo valor dessa conabilidade ao sistema. Entretanto, h a sistemas em que a conan ca nas a c oes do usu ario e um processo primordial para o sucesso do mesmo, como e o do Pechincha Colaborativa. Esse sistema gira em torno de atualiza c oes de pre cos de produtos realizadas pelos usu arios. Caso o n umero de pre cos informados incorretamente seja alto, o usu ario perder a tempo. Isso ocorre, pois o mesmo ter a uma falsa ilus ao com rela c ao ao pre co e visitar a um estabelecimento desnecessariamente. Al em disso, isso provoca aborrecimento, devido ao deslocamento e frustra c ao quanto ao pre co, podendo ocasionar na perda de um usu ario. O problema de classicar um usu ario e complexo porque n ao h a pessoas 100% ruins ou 100% boas. Um sistema n ao pode classicar uma pessoa como ruim e n ao permitir que a mesma se torne boa. O caso contr ario tamb em e v alido, uma pessoa pode n ao ser boa para sempre. Ou seja, o sistema deve permitir a varia c ao no grau de conabilidade. Al em dessa varia c ao, o usu ario nem sempre fornece informa c oes certas ou erradas, ele tamb em comete erros, e o sistema deve estar preparado para contornar esse problema. O Pechincha Colaborativa realiza a avalia c ao da credibilidade dos colaboradores (sistema de reputa c ao). Essa avalia c ao e feita de forma indireta. Isso ocorre pois o intuito do Pechincha Colaborativa n ao e ser uma rede social, e sim um sistema para pesquisa de ofertas. An alogo ao PageRank[5], no Pechincha Colaborativa os usu arios n ao indicam explicitamente a sua opini ao a respeito da conabilidade de um usu ario. Citamos o PageRank pois o mesmo realiza a avalia c ao da qualidade de p aginas da internet sem a interven c ao de usu arios. Os crit erios para o c alculo da reputa c ao dos usu arios do Pechincha Colaborativa s ao: intensidade de participa c ao do colaborador no sistema, conrma c ao dos pre cos fornecidos pelo colaborador, antiguidade do colaborador e a rela c ao de conan ca com os demais usu arios. Durante o desenvolvimento do Pechincha Colaborativa, chegamos a conclus ao de que seria im-

portante a elabora c ao de uma forma de recupera c ao estruturada dos dados. Por isso, elaboramos a API(Application Programming Interface) do Pechincha Colaborativa e dessa forma permitimos que atrav es de uma URL previamente conhecida outros desenvolvedores solicitem ao Pechincha algum dado e o mesmo responda com um arquivo leg vel tanto para humanos quanto para m aquinas. A elabora c ao de uma API tamb em contribui para a divulga c ao do sistema. Pudemos observar esse fen omeno em outros servi cos Web como o Facebook e o Twitter. Ap os a divulga c ao de uma API p ublica esses servi cos cresceram consideravelmente. Isso pode ser explicado porque outros programadores desenvolviam aplica c oes para essas plataformas e esses aplicativos enriqueciam ainda mais os servi cos. O Pechincha Colaborativa tamb em conta uma interface espec ca para o acesso de dispositivos m oveis. Essa interface se caracteriza pela simplicidade, j a que levamos em conta que grande parte dos aparelhos m oveis n ao contam com uma internet de alta velocidade. Com isso constru mos uma interface que possui poucos detalhes e preza pela rapidez.

Cap tulo 3

Modelagem do Sistema
3.1 Requisitos
Estabelecer quais ser ao as funcionalidades do sistema e uma etapa fundamental em qualquer projeto de software. Essa etapa e conhecida como obten c ao de requisitos e visa denir quais s ao as necessidades dos clientes para ent ao desenvolver a solu c ao para o problema. Descobrir as necessidades dos clientes e uma tarefa que exige entrevistas ou conversas com os poss veis utilizadores do sistema. Entretanto, ao se desenvolver aplica c oes web costuma-se utilizar as pr oprias experi encias para se denir o conjunto de funcionalidades a ser implementado. No caso do Pechincha Colaborativa essa foi a abordagem utilizada. Al em disso, algumas funcionalidades foram denidas atrav es de conversas com poss veis utilizadores do Pechincha. As se c oes 3.1.1 e 3.1.2 s ao destinadas a descrever as funcionalidades presentes no Pechincha. A se c ao 3.1.1 descreve os casos de uso do sistema, ou seja, um passo a passo de cada funcionalidade. J a a se c ao 3.1.2 apresenta os diagramas de intera c ao do usu ario, uma representa c ao visual sobre as poss veis atividades de um usu ario no sistema. Esses diagramas de intera c ao do usu ario s ao parte do OOHDM(Object Oriented Hypermedia Design Method)[32], uma metodologia para o desenvolvimento de aplica c oes web.

3.1.1

Casos de Uso
Caso de Uso 1: Cadastrar Produto Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao cadastro de produtos. 2. O usu ario informa o nome do produto e o departamento a que ele est a associado, opcionalmente

o usu ario informa uma descri c ao e o c odigo de barras do produto. 3. O sistema verica que o produto n ao est a cadastrado e ent ao o cadastra. 4. O sistema informa que o produto foi cadastrado com sucesso e o caso de uso termina. Fluxo alternativo(Passo 3): 8

9 1. O sistema verica que o produto j a est a cadastrado, informa que n ao e poss vel cadastr a-lo novamente e o caso de uso termina.

Caso de Uso 2: Atualizar Produto Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao atualiza c ao de produtos. 2. O usu ario informa o nome do produto que deseja atualizar. 3. O sistema verica que o produto est a cadastrado e exibe as informa c oes atualmente cadastradas. 4. O usu ario informa os novos dados: nome, departamento, c odigo de barras ou descri c ao do produto. 5. O sistema verica que os campos obrigat orios(nome e departamento) foram preenchidos e que n ao h a outro produto cadastrado com o mesmo nome que o usu ario informou. 6. O sistema informa que o produto foi atualizado e o caso de uso termina. Fluxo alternativo(Passo 3): 1. O sistema verica que o produto n ao est a cadastrado, informa que n ao e poss vel atualizar um produto que n ao est a cadastrado e o caso de uso termina. Fluxo alternativo 1(Passo 5): 1. O sistema verica que o usu ario n ao informou campos obrigat orios, informa que todos os itens obrigat orios devem ser preenchidos e o caso de uso termina. Fluxo alternativo 2(Passo 5): 1. O sistema verica que j a existe outro produto cadastrado com o nome informado pelo usu ario, informa que n ao e poss vel atribuir o mesmo nome a dois produtos e o caso de uso termina.

Caso de Uso 3: Cadastrar Estabelecimento Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao cadastro de estabelecimentos. 2. O usu ario informa o nome do estabelecimento e a categoria a que ele est a associado, opcionalmente o usu ario informa uma descri c ao e a subcategoria do estabelecimento. 3. O sistema verica que o estabelecimento n ao est a cadastrado e ent ao o cadastra. 4. O sistema informa que o estabelecimento foi cadastrado com sucesso e o caso de uso termina. Fluxo alternativo(Passo 3): 1. O sistema verica que o estabelecimento j a est a cadastrado, informa que n ao e poss vel cadastr a-lo novamente e o caso de uso termina.

10 Caso de Uso 4: Atualizar Estabelecimento Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao atualiza c ao de estabelecimentos. 2. O usu ario informa o nome do estabelecimento que deseja atualizar. 3. O sistema verica que o estabelecimento est a cadastrado e exibe as informa c oes atualmente cadastradas. 4. O usu ario informa os novos dados: nome, categoria, subcategoria ou a descri c ao do estabelecimento. 5. O sistema verica que os campos obrigat orios foram preenchidos(nome e categoria) e que n ao h a outro estabelecimento cadastrado com o mesmo nome que o usu ario informou. 6. O sistema informa que o estabelecimento foi atualizado e o caso de uso termina. Fluxo alternativo(Passo 3): 1. O sistema verica que o estabelecimento n ao est a cadastrado, informa que n ao e poss vel atualizar um estabelecimento que n ao est a cadastrado e o caso de uso termina. Fluxo alternativo 1(Passo 5): 1. O sistema verica que o usu ario n ao informou campos obrigat orios, informa que todos os itens obrigat orios devem ser preenchidos e o caso de uso termina. Fluxo alternativo 2(Passo 5): 1. O sistema verica que j a existe outro estabelecimento cadastrado com o nome informado pelo usu ario, informa que n ao e poss vel atribuir o mesmo nome a dois estabelecimentos e o caso de uso termina.

Caso de Uso 5: Cadastrar Endere co Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao adicionar endere co a um estabelecimento. 2. O usu ario informa o nome do estabelecimento que deseja adicionar um novo endere co. 3. O sistema verica que o estabelecimento est a cadastrado e solicita que o usu ario informe os dados do novo endere co. 4. O usu ario informa o estado, a cidade, o bairro e a rua obrigatoriamente e o telefone e site opcionalmente. 5. O sistema verica que o endere co n ao est a cadastrado para o estabelecimento informado, o cadastra, informa que o endere co foi cadastrado com sucesso e o caso de uso termina. Fluxo alternativo(Passo 3): 1. O sistema verica que o estabelecimento n ao est a cadastrado, informa que o estabelecimento deve estar cadastrado para adicionar um endere co e o caso de uso termina. Fluxo alternativo(Passo 5):

11 1. O sistema verica que o endere co j a est a cadastrado para o estabelecimento informado, informa que n ao e poss vel cadastrar duas vezes o mesmo endere co em um estabelecimento e o caso de uso termina.

Caso de Uso 6: Atualizar Endere co Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao atualiza c ao de endere cos. 2. O usu ario informa o nome do estabelecimento e o bairro e a rua do endere co que deseja atualizar. 3. O sistema verica que o endere co est a cadastrado e exibe as informa c oes atualmente cadastradas. 4. O usu ario informa os novos dados: estado, cidade, bairro, rua, telefone ou site do estabelecimento. 5. O sistema verica que os campos obrigat orios(estado, cidade, bairro e rua) foram preenchidos e que n ao h a um endere co cadastrado com os mesmos dados que o usu ario informou. 6. O sistema informa que o endere co foi atualizado com sucesso e o caso de uso termina. Fluxo alternativo(Passo 3): 1. O sistema verica que o endere co n ao est a cadastrado no estabelecimento, informa que n ao e poss vel atualizar um endere co que n ao est a cadastrado no estabelecimento informado e o caso de uso termina. Fluxo alternativo 1(Passo 5): 1. O sistema verica que o usu ario n ao informou campos obrigat orios, informa que todos os itens obrigat orios devem ser preenchidos e o caso de uso termina. Fluxo alternativo 2(Passo 5): 1. O sistema verica que j a existe outro endere co cadastrado no estabelecimento com os mesmos dados informados pelo usu ario, informa que n ao e poss vel atribuir duas vezes o mesmo endere co a um estabelecimento e o caso de uso termina.

Caso de Uso 7: Informar Oferta Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao informar ofertas. 2. O usu ario informa o nome do produto, o nome do estabelecimento, o bairro, a rua e o pre co da oferta que deseja informar. 3. O sistema verica que o produto est a cadastrado, que o estabelecimento est a cadastrado, que h a um endere co com o bairro e rua informados cadastrado no estabelecimento e que o pre co foi informado. 4. O sistema verica que a oferta est a cadastrada, armazena o pre co atual no hist orico e ent ao a atualiza com o novo pre co fornecido pelo usu ario.

12 5. O sistema informa que a oferta foi informada com sucesso e o caso de uso termina. Fluxo alternativo 1(Passo 3): 1. O sistema verica que o produto n ao est a cadastrado, informa que n ao e poss vel informar a oferta de um produto n ao cadastrado e o caso de uso termina. Fluxo alternativo 2(Passo 3): 1. O sistema verica que o estabelecimento n ao est a cadastrado, informa que n ao e poss vel informar a oferta de um estabelecimento n ao cadastrado e o caso de uso termina. Fluxo alternativo 3(Passo 3): 1. O sistema verica que o endere co n ao est a cadastrado no estabelecimento informado, informa que n ao e poss vel informar a oferta de um endere co n ao cadastrado e o caso de uso termina. Fluxo alternativo 4(Passo 3): 1. O sistema verica que o pre co n ao foi informado, informa que o preenchimento do pre co e obrigat orio e o caso de uso termina. Fluxo alternativo(Passo 4): 1. O sistema verica que a oferta n ao est a cadastrada e ent ao a cadastra.

Caso de Uso 8: Pesquisar Oferta Descri c ao: 1. O usu ario informa obrigatoriamente o nome do produto e opcionalmente o estabelecimento, estado, cidade ou bairro da oferta que deseja pesquisar. 2. O sistema verica que o campo obrigat orio foi preenchido, exibe a(s) oferta(s) com os seguintes itens: produto, pre co, estabelecimento e endere co. 3. Sistema verica que o usu ario est a autenticado e exibe as op c oes de adicionar um produto ` a lista de compras e conrmar o pre co de uma oferta. 4. Se desejar, o usu ario pode adicionar um produto ` a lista de compras, tamb em pode conrmar o pre co de uma oferta e o caso de uso termina. Fluxo alternativo(Passo 2): 1. O sistema verica que o campo obrigat orio n ao foi preenchido e solicita que o usu ario o informe. Fluxo alternativo(Passo 3): 1. O sistema verica que o usu ario n ao est a autenticado e n ao exibe as op c oes de adicionar um produto ` a lista de compras e conrmar o pre co de uma oferta.

Caso de Uso 9: Criar Lista de Compras Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a op c ao criar listas de compras. 2. O usu ario informa o nome da lista que deseja criar.

13 3. O sistema verica que o usu ario n ao possui outra lista com o mesmo nome informado, cadastra a lista, informa que a lista foi criada com sucesso e o caso de uso termina. Fluxo alternativo(Passo 3): 1. O sistema verica que o usu ario j a possui uma lista com o mesmo nome informado, informa que j a existe uma lista criada com o mesmo nome e o caso de uso termina.

Caso de Uso 10: Editar Lista de Compras Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario informa o nome da lista de compras que deseja editar. 2. O sistema verica que o usu ario possui uma lista com o nome informado e exibe os dados atuais da lista. 3. O usu ario informa os novos dados: nome da lista de compras. 4. O sistema verica que o campo obrigat orio foi preenchido(nome da lista), atualiza os dados da lista de compras, informa que os dados foram atualizados com sucesso e o caso de uso termina. Fluxo alternativo(Passo 2): 1. O sistema verica que o usu ario n ao possui uma lista cadastrada com o nome informado, informa que a lista de compras n ao existe e o caso de uso termina. Fluxo alternativo(Passo 4): 1. O sistema verica que o campo obrigat orio n ao foi preenchido, informa que o campo obrigat orio deve ser preenchido e o caso de uso termina.

Caso de Uso 11: Remover Lista de Compras Precondi c oes: O usu ario deve estar autenticado no sistema. Descri c ao: 1. O usu ario seleciona a lista de compras que deseja remover. 2. Sistema remove a lista de compras e o caso de uso termina.

14

3.1.2

Diagramas de Intera c ao do Usu ario

Figura 3.1: UID Cadastrar Produto

Figura 3.2: UID Atualizar Produto

15

Figura 3.3: UID Cadastrar Estabelecimento

Figura 3.4: UID Atualizar Estabelecimento

16

Figura 3.5: UID Cadastrar Endere co

Figura 3.6: UID Atualizar Endere co

17

Figura 3.7: UID Informar Oferta

Figura 3.8: UID Pesquisar Oferta

18

Figura 3.9: UID Criar Lista de Compras

Figura 3.10: UID Editar Lista de Compras

3.2

Esquema Conceitual
O diagrama de classes de an alise e uma representa c ao mais abstrata do dom nio do problema.

Esse diagrama foi u til para que n os pud essemos compreender melhor o nosso sistema. Al em disso, esse diagrama tamb em foi u til na cria c ao do diagrama de classes de projeto, no qual n os j a levamos em considera c ao a linguagem de programa c ao utilizada, o PHP. Nesse diagrama n os modelamos a aplica c ao segundo o padr ao MVC, pois o framework que n os utilizamos utiliza esse padr ao.

19

3.2.1

Diagrama de Classes de An alise

Figura 3.11: Diagrama de Classes de An alise O Pechincha Colaborativa tem como objetivo exibir ofertas oferecidas por estabelecimentos comerciais. Em raz ao disso, nosso dom nio possui estabelecimentos e endere cos. Esses estabelecimentos possuem lojas, que s ao caracterizadas pela classe Endere co. A classe Endere co por sua vez est a associada com a classe Oferta, o que indica que um estabelecimento pode trabalhar com diferentes valores para o mesmo produto, por em em endere cos diferentes. Essa oferta tamb em e composta por um produto que pode estar em uma lista de compras.

20

3.2.2

Diagrama de Classes de Projeto

Figura 3.12: Diagrama de Classes de Projeto

21 Podemos notar nesse diagrama uma clara separa c ao entre as classes de modelo, vis ao e controle. Isso e fruto da utiliza c ao do Zend Framework, que imp oe o uso desse padr ao. Esse framework tamb em possui como caracter stica, o tratamento das requisi c oes ser realizado pelos controladores. Dessa forma, as classes de vis ao cam respons aveis apenas por exibir as telas para o usu ario. Al em disso, n os adicionamos uma nova camada de classes, que s ao as classes representadas ap os a camada de modelo. Essas classes s ao utilizadas para que os modelos retornem um objeto e n ao um vetor, o padr ao do framework. Essa escolha se justica, pois a utiliza c ao desses vetores torna o c odigo muito dependente do esquema do banco de dados. J a a utiliza c ao dos objetos fornece mais uma camada de abstra c ao. N os utilizamos essas classes como parte da camada de modelo, por isso essas classes n ao constituem uma nova camada propriamente dita. As classes apresentadas no diagrama acima, s ao baseadas no diagrama de classes de an alise da se c ao anterior. Podemos notar a presen ca da classe Usu ario, que n ao estava no diagrama de classes de an alise. Essa classe representa um utilizador do sistema. Outra classe que pode causar d uvida e a classe FavoritoModel. Essa classe e respons avel pela persist encia de um produto em uma lista de compras. Tamb em vale ressaltar que n os tivemos que reduzir a gura acima, pois a mesma n ao coube nessa p agina. Entretanto, n os disponibilizamos em um CD uma vers ao completa do diagrama, incluindo m etodos e seus atributos.

3.3
3.3.1

Projeto de Interface
Interface Desktop
Denir uma interface atrativa e um dos principais requisitos para alcan car um grande n umero

de usu arios. Podemos observar que aplica c oes Web cuja interface possui boa usabilidade e um design atrativo, tem mais chances de sucesso quando comparadas ` a aplica c oes cuja interface e mal projetada. Em fun c ao disso, n os denimos uma interface cujo design e simples, por em, bem organizado. Tamb em levamos em considera c ao como p ublico alvo base, usu arios que n ao possuam tanta familiaridade com inform atica. Por isso, projetamos a interface para que a intera c ao entre o usu ario e a aplica c ao fosse simples e exigisse poucos passos.

22

Figura 3.13: P agina principal do Pechincha Colaborativa Iniciamos nosso estudo denindo como o usu ario realizaria a pesquisa de ofertas. Para isso, n os utilizamos um formul ario na p agina principal do site, como podemos ver na gura 3.13. Dessa forma essa funcionalidade caria bem evidente para quem estivesse visitando a p agina pela primeira vez.

Figura 3.14: P agina com os resultados da pesquisa Como resposta ` a pesquisa do usu ario, n os exibimos as ofertas correspondentes ao termo utilizado.

23 Nessa p agina n os exibimos os produtos e pre cos encontrados, bem como em quais estabelecimentos os produtos podem ser encontrados. Tamb em oferecemos as op c oes de adicionar um produto ` a lista de compras e conrmar se o pre co de uma oferta est a correto ou n ao. Como cone para representar a lista de compras n os optamos por utilizar uma cesta de compras. Para representar a conrma c ao de que o pre co de uma oferta est a correto, n os optamos por um cone check em verde. J a representa c ao de que o pre co de uma oferta est a incorreto e feito atrav es de um x em vermelho. Al em dessas op c oes, n os tamb em exibimos o qu ao con avel e a oferta. Essa representa c ao e feita atrav es de uma barra juntamente com o percentual de conabilidade ao lado dessa barra.

Figura 3.15: P agina com as listas de compras de um usu ario Uma das principais raz oes para se ter uma interface desktop e a possibilidade do cliente criar sua lista de compras antes de ir at e o estabelecimento. Dessa forma, esse usu ario pode, antes de sair de casa, saber qual estabelecimento possui os melhores pre cos. Por isso, uma das principais p aginas do nosso site e a p agina de listas de compras. Nessa p agina, n os exibimos todas as listas de um usu ario. Cada lista possui alguns cones associados, os mesmos s ao: mais, lixeira e ir para. Esses cones servem para, respectivamente, exibir os itens da lista, excluir a lista de compras e exibir as ofertas da lista.

24

Figura 3.16: P agina com os itens de uma lista de compras Apesar de exibirmos os itens de uma lista de compras, como na p agina da gura 3.15, e necess ario oferecer um meio para o usu ario comparar ofertas em diversos estabelecimentos. Essa necessidade e atendida quando o usu ario seleciona a op c ao ir para a lista. Na p agina de uma lista de compras n os temos duas colunas. Na coluna da esquerda, n os exibimos os produtos da lista, tal como os pre cos nos estabelecimentos que possuem esses produtos. Na coluna da direita, n os exibimos os estabelecimentos que possuem os itens da lista. Essa e uma forma mais simples do usu ario saber qual o valor total da lista de compras em cada estabelecimento.

25

Figura 3.17: P agina para informar uma oferta Outra p agina importante do Pechincha e a p agina que permite que o usu ario informe uma oferta. Nessa p agina o usu ario informa um produto, um estabelecimento, o endere co desse estabelecimento e o pre co da oferta.

3.3.2

Interface Mobile
Uma das possibilidades que percebemos durante o desenvolvimento do Pechincha Colaborativa,

foi a utiliza c ao do sistema durante a compra do usu ario. Ou seja, o usu ario pode querer saber se o pre co do estabelecimento que ele est a no momento, e um pre co justo. Devido ao fato desse acesso ser, em grande parte, atrav es de dispositivos com uma tela reduzida, devemos nos preocupar com a interface para esses dispositivos. Para atender aos diversos tipos de dispositivos existentes, n os desenvolvemos uma interface que se adapta ao tamanho da tela do aparelho. Essa interface e mais simples e mais leve do que a interface desktop, por em, possui menos funcionalidades.

Figura 3.18: P agina principal do Pechincha Colaborativa adaptada para dispositivos m oveis

Figura 3.19: P agina com os resultados da pesquisa adaptada para dispositivos m oveis

Cap tulo 4

Arquitetura do Sistema
4.1 Descri c ao Geral
A populariza c ao da Internet permitiu que diversas aplica c oes se tornassem acess veis por milhares de usu arios. Dentre as aplica c oes da Internet, podemos citar a Web como a mais popular. A Web torna documentos acess veis para usu arios que possuam um web browser [30]. Al em disso, a Web tamb em facilita a coopera c ao entre pessoas em diferentes localiza c oes geogr acas e em diferentes hor arios. O Pechincha Colaborativa e uma aplica c ao Web, ou seja, necessita que o usu ario possua acesso ` a Internet e ` a um web browser para exibi c ao do seu conte udo. A escolha por uma aplica c ao Web, ao inv es de uma aplica c ao Desktop, se deu porque um dos fatores mais importantes para o sucesso do sistema ea utiliza c ao por um grande n umero de usu arios. Isso pode ser explicado pelo fato do n umero de usu arios ser essencial para gerar conte udo no Pechincha. O Pechincha Colaborativa e um sistema colaborativo e conta com a participa c ao dos usu arios para manter as informa c oes do site atualizadas. Reduzir a burocracia para que o usu ario adote o sistema e de suma import ancia. Quest oes como instala c ao de um aplicativo e a preocupa c ao quanto a vers ao do sistema operacional poderiam impedir a utiliza c ao do sistema. Como a maioria dos computadores que possuem acesso ` a Internet possuem um web browser, as aplica c oes Web possuem um empecilho a menos para sua utiliza c ao. Al em disso, uma aplica c ao Web permite que os usu arios estejam distribu dos geogracamente, um fator importante em um sistema colaborativo. As aplica c oes Web utilizam um modelo computacional amplamente utilizado, o modelo cliente x servidor. O modelo cliente x servidor caracteriza-se pela divis ao entre clientes e servidores[30]. Os clientes s ao os respons aveis por iniciarem a comunica c ao, ou seja, os mesmos realizam a requisi c ao. J a os servidores aguardam pela comunica c ao, ou seja, respondem ` as requisi c oes. Os servidores possuem endere cos bem conhecidos, pois os clientes precisam solicitar requisi c oes dos mesmos. Por outro lado, os clientes n ao precisam ter o endere co bem conhecido, pois os mesmos iniciam a conex ao. No caso das aplica c oes Web, o web browser comp oe o lado cliente enquanto que o lado servidor e composto pelo servidor Web. A requisi c ao nesse caso, e a solicita c ao de uma p agina Web. Podemos ver uma demonstra c ao desse exemplo na gura 4.1.

27

28

Figura 4.1: Modelo Cliente x Servidor Esse modelo computacional tamb em pode ser utilizado para explicar a estrutura de uma aplica c ao Web. No caso do Pechincha Colaborativa, o lado servidor conta com o servidor Web Apache[36], o PHP[37] como linguagem base da aplica c ao e o PostgreSQL[38] como sistema gerenciador de bancos de dados. J ao lado cliente da aplica c ao, conta com a linguagem JavaScript[39], que visa oferecer maior interatividade da aplica c ao com o usu ario. O JavaScript e utilizado como base para a constru c ao do jQuery[40] e do Dojo Toolkit[41]. Ambos s ao bibliotecas que simplicam a utiliza c ao do JavaScript no lado cliente. O Google Chart[42] tamb em utiliza o JavaScript para a constru c ao das fun c oes internas. Entretanto, o objetivo dessa biblioteca e a cria c ao de gr acos. Tamb em s ao utilizadas as APIs do Google+[43], Twitter[44], Facebook[45] e Google Maps[46], as quais tamb em utilizam JavaScript. Na gura 4.2 n os apresentamos as pilhas de software(bolo de noiva) dos m odulos que constituem o Pechincha Colaborativa, tanto no lado cliente quanto no lado servidor. Essas estruturas ser ao descritas ao longo dessa se c ao e das se c oes seguintes.

Figura 4.2: Estrutura do Pechincha Colaborativa Conforme citamos acima, a linguagem de programa c ao escolhida foi o PHP(PHP: Hypertext muito utilizada na constru Preprocessor ). Essa linguagem e uma linguagem livre e de c odigo aberto. E c ao de aplica c oes Web e possui um vasto n umero de artigos criados pela comunidade. Apesar de ser uma linguagem inicialmente limitada e de natureza simples, a mesma tem evolu do com o intuito de contemplar as principais caracter sticas de uma linguagem orientada ` a objetos. Optamos pela utiliza c ao do PHP, pois

29 um dos autores possu a maior familiaridade com essa linguagem. Al em disso, o PHP e uma linguagem j a consolidada, tendo como exemplo de sucesso o n ucleo do Facebook escrito nessa linguagem. Ao construirmos o Pechincha Colaborativa, um dos objetivos era o da cria c ao de uma aplica c ao organizada o suciente, e que permitisse f acil modica c ao, caso fosse necess ario. Para isso, optamos por seguir a arquitetura MVC (Modelo-Vis ao-Controle), como podemos observar na gura 4.3. Essa arquitetura e caracterizada por isolar a l ogica da aplica c ao das camadas de exibi c ao de conte udo e de persist encia de dados. A m de seguirmos ` a risca essa arquitetura, passamos a utilizar um framework PHP. A utiliza c ao de um framework n ao permite apenas uma maior organiza c ao da aplica c ao, mas tamb em maior reutiliza c ao de c odigo. Como o framework possui diversos componentes prontos, o desenvolvimento de uma aplica c ao utilizando essas ferramentas, torna-se mais r apido devido a reutiliza c ao de c odigo j a existente. Como exemplos de componentes prontos podemos citar o m odulo de autentica c ao de usu arios, o m odulo de acesso ` a banco de dados, dentre outros. Em nosso projeto, optamos por utilizar o Zend Framework[47]. Escolhemos esse framework, pois o mesmo e comprovadamente discutido e testado por prossionais capacitados, al em de ser de c odigo livre. O Zend Framework e mantido pela Zend Technologies, atual mantenedora do PHP.

Figura 4.3: Arquitetura Modelo-Vis ao-Controle A utiliza c ao de todas as ferramentas descritas at e o momento permite a constru c ao de uma aplica c ao rica em detalhes. Entretanto, at e o momento n ao citamos um mecanismo para persist encia dos dados informados pelos usu arios ou gerados pela pr opria aplica c ao. Ou seja, ainda n ao h a uma forma de armazenar os dados. A solu c ao desse problema est a na utiliza c ao de um sistema gerenciador de bancos de dados(SGBD), que permite salvar os dados da aplica c ao e torn a-los acess veis quando forem necess arios. A vantagem de se utilizar um SGBD e que o desenvolvedor n ao precisa se preocupar de que forma os dados ser ao organizados, ou de que forma esse sistema recuperar a as informa c oes. Essas tarefas s ao realizadas de maneira segura e eciente pelo SGBD. Utilizamos como SGBD no Pechincha Colaborativa, o PostgreSQL. Essa ferramenta e um SGBD objeto relacional de c odigo aberto. Ou seja, o PostgreSQL permite a cria c ao de bancos de dados utilizando o modelo objeto-relacional. Esse modelo permite a constru c ao de bancos de dados que combinam caracter sticas do modelo relacional com a programa c ao orientada a objetos[33].

30 Al em das tecnologias citadas acima, n os tamb em utilizamos o Apache HTTP Server. O Apache e um servidor Web livre e e utilizado por grande parte dos servidores ativos no mundo. Ao utilizar esse servidor, n os objetivamos ter um ambiente para o teste do Pechincha Colaborativa.

4.2

Pechincha Colaborativa como Servi co

Atualmente as aplica c oes tem se preocupado cada vez mais em fornecer dados estruturados. Essa

preocupa c ao se d a porque muitas aplica c oes tem como clientes n ao somente web browsers, mas tamb em outras aplica c oes[30]. Casos recentes de sucesso s ao as redes sociais Twitter e Facebook. Essas aplica c oes iniciaram suas atividades oferecendo acesso aos usu arios apenas atrav es do web browser. Ap os algum tempo, as mesmas disponibilizaram uma API p ublica. Esse fator contribuiu positivamente para o sucesso das mesmas. Al em disso, pode-se observar o crescimento no n umero de acessos, gra cas aos aplicativos constru dos com base nas informa c oes desses servi cos. Aplica c oes como o Twitter e o Facebook podem funcionar como web services. D a-se esse nome, pois as mesmas fornecem um servi co ` a outras aplica c oes(clientes). Esse servi co e o dado que a aplica c ao origem fornece para quem estiver interessado em utilizar aquela informa c ao. S o e poss vel utilizar essa informa c ao, pois al em do dado estar bem estruturado, seu formato e bem conhecido. Para que isso ocorra, os web services fornecem detalhes de como esse dado ser a recuperado e uma descri c ao de como ele est a formatado. Um dos principais obst aculos para se obter os dados dos servi cos Web, de forma que os mesmos sejam facilmente process aveis, e o formato. Para solucionar isso, utiliza-se com frequ encia o XML(Extensible Markup Language ). O XML e um formato que permite a cria c ao de documentos bem formatados e com o seu conte udo organizado de forma hier arquica. Tamb em pode-se utilizar o JSON(JavaScrip Object Notation ), que tamb em permite a cria c ao de documentos bem estruturados e e considerado mais simples do que o XML. Apesar de possuir o JavaScript no nome, esse formato n ao e exclusivo do JavaScript e pode ser processado por diversas linguagens de programa c ao. O esfor co em utilizar esses formatos e v alido, pois esses formatos s ao facilmente processados pela maioria das linguagens de programa c ao. O mesmo n ao ocorre com o HTML. Para processar esse formato, e necess ario um grande esfor co do desenvolvedor a m de descobrir qual o formato utilizado por quem construiu o documento. No caso do Pechincha Colaborativa, houve a preocupa c ao em disponibilizar as informa c oes do nosso banco de dados de forma estruturada. Essa iniciativa e importante, pois permite que outros desenvolvedores construam novos aplicativos com base no nosso sistema. Dessa forma, esses aplicativos enriquecem ainda mais o conte udo do Pechincha Colaborativa e contribuem na divulga c ao do sistema. Para constru c ao da API n os optamos por disponibilizar o conte udo no formato JSON. Al em disso, n os tamb em disponibilizamos uma p agina informando o funcionamento do servi co.

31

4.3

Servi cos Utilizados

Al em de disponibilizar os dados do Pechincha Colaborativa publicamente, n os tamb em utilizamos

outros servi cos com o intuito de enriquecer o nosso sistema. Dentre esses servi cos podemos citar o Google+, o Twitter e o Facebook. Utilizamos as APIs n ao para obter dados desses servi cos, e sim com o intuito de divulgar o Pechincha Colaborativa. Utilizamos o bot ao do Google+ para que o usu ario possa compartilhar o conte udo em sua conta desse servi co. Tamb em utilizamos o bot ao curtir para que o usu ario promova o conte udo em sua conta do Facebook. Por m utilizamos o bot ao tweetar, que permite que o usu ario poste uma mensagem previamente fornecida em sua conta do Twitter. A utiliza c ao desses bot oes pode ser visualizada na gura 4.4. Dentre os servi cos utilizados, tamb em podemos citar o Google Maps. Utilizamos esse servi co para indicar visualmente a localiza c ao de um estabelecimento. Para isso, n os obtemos o endere co de um estabelecimento e ent ao o marcamos no mapa fornecido pelo Google Maps. Abaixo apresentamos uma breve descri c ao dos servi cos utilizados pelo Pechincha Colaborativa. 1. Google+: O Google+ e uma rede social desenvolvida pelo Google e permite a intera c ao entre usu arios. Esse servi co possui uma API p ublica que permite que desenvolvedores tenham acesso aos dados do Google+, dentre eles os dados dos usu arios desse servi co. Esses dados s ao disponibilizados no formato JSON e exigem que usu ario possua uma chave de acesso fornecida pelo Google. 2. Twitter: O Twitter e um servi co de microblog que permite que os usu arios postem mensagens de at e 140 caracteres. A API desse servi co permite que o desenvolvedor poste mensagens em sua conta e obtenha mensagens de outros usu arios. O formato utilizado pelo Twitter para disponibilizar esses dados tamb em e o JSON e e necess ario uma chave de acesso para obter os dados desse servi co. 3. Facebook: O Facebook e a rede social mais utilizada do mundo e permite a intera c ao entre usu arios, cria c ao de grupos de interesse, agrega ferramentas como o chat e tamb em permite o compartilhamento de informa c oes. Esse servi co disponibiliza al em de informa c oes dos usu arios, tamb em informa c oes que permite aos desenvolvedores construir jogos e outros aplicativos baseados no Facebook. 4. Google Maps: O Google Maps e um servi co de mapas do Google. Esse servi co permite que os desenvolvedores construam mapas personalizados. Al em dessa funcionalidade, o Google Maps tamb em fornece servi cos de geolocaliza c ao que permite o c alculo de dist ancias por exemplo. Para utilizar esse servi co e necess ario a obten ca o de uma chave espec ca para utiliza c ao da API.

Figura 4.4: Bot oes para divulga c ao do Pechincha Colaborativa

4.4

Bibliotecas Utilizadas
A utiliza c ao de algumas bibliotecas nos proporcionou economia de tempo, al em de oferecermos

uma interface mais atrativa aos usu arios. N os utilizamos o jQuery para fornecer algumas funcionalidades que utilizavam o AJAX(Asynchronous Javascript and XML). As fun c oes fornecidas pelo jQuery para utiliza c ao do AJAX s ao muito simples quando comparadas ` a utiliza c ao somente do JavaScript. O Dojo Toolkit tamb em foi bastante utilizado na constru c ao dos formul arios. Essa biblioteca possui algumas fun c oes que nos permitiram implementar facilmente o autocompletar em alguns campos do formul ario. Al em das bibliotecas j a citadas, n os utilizamos a biblioteca Google Chart. Essa biblioteca nos permitiu fornecer gr acos que exibiam a varia c ao do pre co de uma oferta. Dessa forma, os usu arios podem perceber como o estabelecimento alterou o pre co de um produto nos u ltimos 30 dias. Abaixo apresentamos uma breve descri c ao das bibliotecas utilizadas pelo Pechincha Colaborativa. 1. jQuery: O jQuery e uma biblioteca de c odigo aberto escrita em JavaScript e que tem como objetivo tornar mais simples a cria c ao de c odigos JavaScript. Dentre as funcionalidades podemos citar manipula c ao de objetos DOM(Document Object Model ), fun c oes AJAX e resolu c ao de incompatibilidades entre web browsers. 2. Dojo Toolkit: O Dojo Toolkit e uma biblioteca JavaScript de c odigo fonte aberto. A utiliza c ao dessa biblioteca permite a constru c ao de interfaces de aplica c oes Web ricas em detalhes. O objetivo do Dojo Toolkit e permitir a constru c ao dessas interfaces sem grande esfor co por parte dos desenvolvedores. 3. Google Chart: O Google Chart e uma biblioteca para constru c ao de gr acos desenvolvida pelo Google. Essa biblioteca permite a constru c ao de gr acos como gr acos de barras, gr acos de colunas, gr acos de linhas, entre outros.

Cap tulo 5

Conabilidade das Informa c oes

O mundo n ao est a amea cado pelas pessoas m as, e sim por aquelas que permitem a maldade. Albert Einstein

5.1

Introdu c ao
Podemos denir conan ca como a f e que se deposita em algu em, ou seja, a partir de experi encias

pr evias, deixamos de julgar se um fato e verdadeiro ou n ao, n os apenas conamos. A conan ca tamb em est a relacionada ` a previsibilidade[14]. Por mais con avel que uma pessoa seja, n ao e garantido que a mesma agir a conforme o esperado. Em fun c ao disso, quando analisamos o conceito de conan ca tamb em levamos em considera c ao a incerteza existente. H a sistemas em que avaliar a conabilidade das informa c oes e um processo desej avel. Em outros, esse processo e imprescind vel. Devido a ` alta necessidade de se vericar essas informa c oes, caso a mesma n ao seja feita, podemos ter como resultado situa c oes catastr ocas[15]. N ao e o nosso caso, mas isso n ao quer dizer que a conan ca deva ser negligenciada. Apesar de informa c oes err oneas em nosso sistema n ao provocarem acidentes, as mesmas podem provocar situa c oes desagrad aveis, como o deslocamento desnecess ario at e um estabelecimento. Essas situa c oes podem ser potencializadas devido ao fato de utilizarmos um sistema Web. Esse grande meio de comunica c ao pode levar informa c oes incorretas ` a milhares de pessoas e causar frustra c ao nesse grande n umero de usu arios. Ignorar essa situa c ao seria assumir que a conabilidade e irrelevante para o sistema ou que os usu arios s ao sucientemente con aveis, o que n ao e o caso. As situa c oes descritas acima est ao se tornando cada vez mais comuns em sistemas Web. Com o advento da Web 2.0, os usu arios deixaram de ser apenas consumidores e passaram a ser produtores de conte udo. Essa grande intera c ao dos usu arios com as aplica c oes gerou incertezas quanto a conabilidade das informa c oes fornecidas. Com o intuito de contornar essa situa c ao, tem-se realizado estudos com rela c ao ` a constru c ao de modelos que permitam calcular a reputa c ao de usu arios e, assim, inferir a conabilidade de um dado. Uma das diculdades em rela c ao a esse c alculo e que a conan ca e um

33

34 conceito subjetivo, e a subjetividade n ao e empregada em algoritmos. No decorrer desta se c ao utilizaremos com frequ encia as palavras reputa c ao e conan ca para indicar o grau de conabilidade que um usu ario possui. A utiliza c ao dessas palavras como sin onimo nesse contexto, signica que dependendo da reputa c ao de uma pessoa, outro usu ario pode decidir se ela e con avel ou n ao, e assim pode decidir se cona nela.

5.2

Algoritmos Para o C alculo de Reputa c ao

Os algoritmos para o c alculo de reputa c ao s ao u teis quando h a a necessidade de se vericar a

veracidade de alguma informa c ao. Um ponto importante a ser considerado e a natureza dessa informa c ao. Informa c oes adquiridas de forma direta, ou seja, diretamente da fonte, s ao mais con aveis do que informa c oes obtidas a partir de terceiros[10]. Isso e natural porque esses podem inserir alguma imprecis ao nessas informa c oes. No estudo desses algoritmos, pudemos observar algumas classica c oes espec cas. Por exemplo, os algoritmos mais simples fazem uma m edia das avalia c oes, ou seja, a raz ao entre os votos positivos e o total de votos. Tamb em h a algoritmos mais complexos que utilizam modelos estat sticos a m de obter maior precis ao no c alculo da reputa c ao. Apesar de oferecer uma grande precis ao, esses algoritmos tem como desvantagem a alta complexidade. Outra classica c ao encontrada foi a de algoritmos que utilizam valores discretos de conabilidade. Esses valores podem ser por exemplo: baixo, m edio ou alto. Um argumento a favor desse modelo e que seres humanos lidam melhor com valores discretos do que com valores cont nuos[10]. Al em dos citados acima, temos os algoritmos que lidam com grandes redes. Devido ao tamanho dessas redes, muitas vezes n ao e poss vel calcular o valor de conabilidade diretamente. Para resolver esse problema, os algoritmos fazem uso de rela c oes transitivas entre os n os e ent ao calculam indiretamente o qu ao con avel e um usu ario. 1. TidalTrust [3]: O TidalTrust e um algoritmo para o c alculo de reputa c ao. Esse algoritmo e simples e de baixa complexidade. Por ser simples e altamente escal avel. Esse algoritmo utiliza um grafo direcionado para representar os participantes da rede e cada aresta possui um valor cont nuo entre 0 e 10, sendo 10 o valor de m axima conan ca e 0 o de m nima conan ca. Esse valor indica a conan ca que um n o A possui no n o B. A estrat egia do TidalTrust e, caso um n o fonte A n ao conhe ca o valor de conan ca de um n o B, o n o fonte pergunta aos seus vizinhos o qu ao con avel B e. Caso os vizinhos tamb em n ao saibam, esses perguntam aos seus vizinhos e o processo e repetido. Ou seja, o algoritmo varre os n os a frente e volta at e o n o fonte calculando uma m edia ponderada dos valores de conabilidade. Os dados utilizados para esse c alculo s ao os valores presentes nas arestas do grafo. Esse algoritmo considera apenas a topologia da rede, ou seja, n ao e levado em considera c ao o hist orico de a c oes de um usu ario, apenas o valor atual de conan ca. 2. Advogato Trust Metric [4]: O Advogato e uma comunidade online dedicada ao desenvolvimento de software livre. Nessa comunidade e utilizada uma m etrica de conan ca cujo nome e o mesmo da comunidade. Utiliza-se grafos para representar a rede, na qual as contas de usu arios s ao os n os

35 e a especializa c ao e vista como arestas. Podemos destacar tr es tipos de especializa c ao: aprendiz, visitante e mestre. Diferentemente do Pechincha Colaborativa, em que todos os n os s ao tratados de maneira similar, o Advogato assume a exist encia de alguns n os con aveis. Por serem con aveis, h a a garantia de que esses n os fornecem informa c oes corretas. Partindo-se dessa premissa, o valor de conan ca e calculado com rela c ao a esses n os. O Advogato calcula esse valor de conan ca identicando n os desonestos e n os que se relacionam a esses n os desonestos. 3. SocialTrust [7]: O SocialTrust e um algoritmo que permite inferir a conan ca de um usu ario a partir da sua intera c ao na rede e a partir dos relacionamentos que o mesmo possui. Esse algoritmo leva em considera c ao alguns fatores importantes quando estamos estudando a rela c ao entre pessoas numa rede social. Alguns desses fatores s ao: hist orico de reputa c ao, qualidade dos contatos e o feedback. O hist orico de reputa ca o permite analisar as a c oes do usu ario ao longo do tempo e n ao apenas no momento atual. Com esse fator podemos rastrear o comportamento do usu ario e ser mais justos no julgamento. Esse algoritmo tamb em considera a qualidade dos contatos. Ao levar em considera c ao esse fator, n os dizemos que um usu ario e fruto do meio, ou seja, seus contatos podem ter inu encia em suas decis oes. O u ltimo fator a ser descrito e o feedback, esse mecanismo e utilizado para descobrir qual a vis ao que alguns usu arios t em de determinado usu ario da rede. Al em dos fatores citados, o SocialTrust tamb em conta com coecientes que potencializam a sua utiliza c ao. Esses coecientes podem potencializar fatores como o valor moment aneo de reputa c ao e o hist orico de a c oes ao longo do tempo. 4. FuzzyTrust Algorithm [8]: O FuzzyTrust e um algoritmo que estabelece n veis discretos de conabilidade: low, medium e high [12]. Os autores defendem que esses valores s ao mais facilmente interpretados pelos usu arios. Por utilizar esses valores discretos, h a a perda de precis ao no c alculo da reputa c ao. A estrat egia utilizada para obten c ao desses valores de conabilidade e utilizar uma busca em largura a m de encontrar o menor caminho entre a origem e o n o destino. Essa abordagem e parecida com a utilizada pelo algoritmo TidalTrust. Ao utilizar essa tentativa de encontrar o menor caminho, estamos introduzido mais uma perda de precis ao no processo de obten c ao do valor de conabilidade. 5. SUNNY [9]: O SUNNY e um algoritmo que utiliza t ecnicas de amostragem probabil stica para estimar a conan ca de um usu ario. Diferentemente de algoritmos que consideram apenas o menor caminho entre o n o fonte e o n o alvo do c alculo da reputa c ao, o SUNNY considera caminhos de qualquer tamanho[12]. O objetivo dessa abordagem e aumentar a precis ao do algoritmo. Al em disso, o mapeamento dos contatos e dos valores de coabilidade e realizado sobre redes bayesianas. Esse algoritmo tem a pesquisadora Jennifer Goldbeck como uma das autoras. A mesma arma que o SUNNY possui maior precis ao quando comparado ao TidalTrust, tamb em desenvolvido por ela. 6. PageRank [5]: O PageRank foi proposto por Sergey Brin e Lawrence Page com o intuito de classicar a relev ancia de p aginas na internet. A ideia desse algoritmo e avaliar links entre p aginas como votos, ou seja, caso uma p agina A contenha um link para uma p agina B, isso signica que A deu um voto para B. Segundo os autores do PageRank, quanto mais votos uma p agina recebe, mais importante

36 ela e. Al em da quantidade de votos, tamb em h a a preocupa c ao com a qualidade do voto. Os votos dados por uma p agina importante t em maior peso e ajudam outras p aginas a terem mais import ancia na rede. Apesar de ser utilizado para denir a import ancia de p aginas na internet, esse algoritmo pode ser adaptado para o c alculo de reputa c ao em redes sociais, como podemos ver nesse artigo[6].

5.3
5.3.1

Nossa Proposta
Introdu c ao
Estabelecer o grau de conabilidade das informa c oes e um processo primordial para o sucesso do

Pechincha Colaborativa. Isso ocorre porque esse sistema e caracterizado pelo alto valor que as atualiza c oes de dados t em para os usu arios. Isso signica que quanto maior for o n umero de ofertas com pre cos incorretos, pior ser a a experi encia do usu ario no sistema. O mesmo vale para o caso contr ario, quanto menor o n umero de pre cos incorretos, melhor ser a a experi encia do usu ario. Para vericar a veracidade dos pre cos das ofertas, temos como primeira op c ao a verica c ao direta junto ao estabelecimento para descobrir se o pre co est a correto. Entretanto, isso se torna invi avel dado o grande n umero de produtos e estabelecimentos existentes. Para contornar esse problema, n os optamos por, ao inv es de avaliar a veracidade da informa c ao, avaliar o respons avel por atualizar a informa c ao. N os assumimos que quanto mais con avel for um usu ario, maior a probabilidade de uma oferta informada por ele estar correta[6]. Com o intuito de introduzir um sistema de reputa c ao no Pechincha Colaborativa, n os denimos alguns conceitos importantes no nosso estudo: 1. A rela c ao de conabilidade e assim etrica: N ao h a reciprocidade em rela c oes de conan ca. Ou seja, quando armamos que um usu ario A cona no usu ario B, n ao implica que o usu ario B cone no A[18]. Por isso, denimos que os usu arios podem ser modelados como grafos e que a rela c ao entre eles e bidirecional com valores que podem ou n ao ser iguais. 2. A rela c ao de conabilidade e transitiva: Um usu ario possui um pequeno n umero de contatos em compara c ao com o n umero total de usu arios na rede. Portanto, muitas vezes o usu ario ter a a necessidade de conhecer o grau de conabilidade de um usu ario que n ao e seu contato direto. Para contornar essa situa c ao, pode-se levar em considera c ao a rela c ao transitiva de conabilidade[10]. Ou seja, se A est a ligado a B e B est a ligado a C, podemos levar isso em considera c ao e inferir a conan ca que A possui em C. 3. O hist orico de intera c oes deve ser considerado: Conforme lidamos com o alto volume de a c oes no sistema, vamos construindo a identidade do usu ario. Essa forma de avalia c ao e mais justa com usu arios honestos, pois o sistema n ao leva em considera c ao apenas o instante atual, mas tamb em o hist orico de a c oes no sistema. 4. A conabilidade n ao possui um valor absoluto: Observando as rela c oes interpessoais, n os chegamos

37 a conclus ` ao de que a conan ca n ao est a relacionada apenas a cada usu ario, mas tamb em aos indiv duos que o julgam. Por exemplo, o usu ario A n ao possui o mesmo valor de conan ca para todos os demais da rede. Um indiv duo B, pr oximo a A, pode classic a-lo como altamente con avel, e isso n ao quer dizer que essa seja a opini ao de todos. Essa pode ser apenas a opini ao de um amigo. Tamb em e v alido analisar a conan ca que um usu ario C, distante de A, possui em A. Esse usu ario pode classicar A como n ao con avel, um valor totalmente diferente do atribu do por B. Esses valores distintos n ao signicam que o usu ario B ou C podem estar mentindo. Isso signica que devemos levar em considera c ao o contexto que a atribui c ao de conan ca est a ocorrendo. 5. A conabilidade e expressa em porcentagem: Apesar de valores discretos serem melhores aceitos e compreendidos por seres humanos[8], optamos por expressar a conabilidade em porcentagem, pois essa abordagem garante maior precis ao no c alculo da reputa c ao. Para expressar essa conabilidade, devemos utilizar um algoritmo que trabalhe com um intervalo cont nuo e retorne valores num ericos nesse intervalo. 6. A atribui c ao de um valor de conabilidade e feita de maneira indireta: Optamos por utilizar um sistema de atribui c ao de conabilidade autom atico. A u nica a c ao realizada pelo usu ario e a conrma ca o se o pre co de uma oferta est a correto ou n ao. Ap os a deni c ao desses conceitos, iniciamos a pesquisa de algoritmos para o c alculo de reputa c ao de usu arios. Dentre os algoritmos encontrados podemos destacar os apresentados na se c ao 5.2. A pesquisa desses algoritmos foi importante para analisarmos a abordagem utilizada com rela c ao aos conceitos que denimos serem importantes. Al em disso, pudemos conhecer algumas caracter sticas que os autores desses artigos consideraram importantes e n os n ao hav amos nos atentado. Essa pesquisa tamb em foi importante pois nos permitiu chegar ` a conclus ao de que n ao seria necess ario a constru c ao de um novo algoritmo de reputa c ao de usu arios. Seria necess ario apenas algumas modica c oes em um algoritmo j a existente na literatura para solucionarmos o problema de conabilidade em nosso sistema. Escolhemos o algoritmo SocialTrust[7] pois o mesmo possui caracter sticas que atendem bem ao nosso problema. Entre essas caracter sticas est ao a componente de hist orico de intera c oes, o valor de retorno num erico e a rela c ao de conabilidade assim etrica. A componente de hist orico de intera c oes e utilizado para avaliar o usu ario de acordo com a sua hist oria no sistema e n ao somente no instante atual. O valor de retorno num erico serve para representarmos a conabilidade de um usu ario em porcentagem, satisfazendo o item que denimos anteriormente. E por u ltimo, a rela c ao de conabilidade e assim etrica porque depende de quem est a atribuindo a conabilidade, ou seja, o valor n ao e o mesmo em ambos os sentidos. Al em das caracter sticas citadas anteriormente, o SocialTrust tamb em conta com revis ao din amica de conabilidade, distin c ao entre qualidade do relacionamento e conan ca, feedback personalizado e o algoritmo tamb em permite o c alculo de reputa c ao n ao somente para contatos diretos como tamb em para contatos indiretos[11]. A revis ao din amica de conabilidade signica que podemos alterar em tempo de execu c ao a forma como calculamos a conabilidade. Isso e poss vel porque o algoritmo trabalha com coecientes que permitem potencializar determinadas componentes, e assim mudar a abordagem no c alculo

38 da conabilidade. J a a distin c ao entre qualidade de relacionamento e conan ca e uma caracter stica que a maioria dos algoritmos de conabilidade n ao aborda. O SocialTrust leva em considera c ao a qualidade dos contatos para ent ao denir a qualidade de um usu ario. O feedback e uma opini ao que um grupo de usu arios tem de outro, ou seja, uma avalia c ao expl cita sobre a conabilidade. Por m, o SocialTrust contempla uma caracter stica que denimos anteriormente, por em, em outras palavras. Denimos que a rela c ao de conabilidade deve ser transitiva. Essa caracter stica tinha o intuito de calcular a conan ca entre usu arios que n ao estejam ligados diretamente. Conforme descrito, essa caracter stica e contemplada pelo algoritmo escolhido. Outro importante argumento a favor da escolha do SocialTrust foi a avalia c ao feita pelos autores. Ao projetar esse modelo, os autores levaram em considera c ao aspectos espec cos de redes sociais como a rela c ao entre pessoas, o conceito de contatos e a qualidade dos contatos. Ao nalizar a concep c ao do modelo, os autores validaram as ideias com um conjunto de dados obtido da rede social MySpace. Esse conjunto de dados possu a mais de 5 milh oes de usu arios e mais de 19 milh oes de relacionamentos[13]. Com esse extenso conjunto de dados foi poss vel avaliar o SocialTrust e chegar ` a conclus ao de que o algoritmo teve desempenho satisfat orio quando comparado a algoritmos como o PageRank por exemplo[7].

5.3.2

Formata c ao da Proposta
Conforme j a hav amos citado, nossa proposta se baseia em modicar um modelo para o c alculo

de reputa c ao j a existente, o SocialTrust. O SocialTrust possui a seguinte f ormula para o c alculo da reputa c ao: ST (i, t) = T rq (i, t) + 1 t
t

I (x)T rq (i, x)dx + T rq (i, t)

0

(5.1)

, e : Coecientes de ajuste da f ormula. T rq (i, t): Componente de qualidade de conan ca do usu ario i no tempo t.
1 t t 0

I (x)T rq (i, x)dx: Componente de hist orico de conan ca.

c ao ` a mudan ca. T rq (i, t): Componente de adapta A fun c ao que calcula a conabilidade de um usu ario e a fun c ao ST. Essa fun c ao possui como argumentos i e t, sendo i o usu ario cuja conabilidade ser a calculada e t o tempo atual. Tamb em podemos identicar tr es componentes que s ao multiplicadas pelos coecientes , e . Esses coecientes permitem otimizar o c alculo da conabilidade realizada pelo SocialTrust. Isso ocorre porque a utiliza c ao desses coecientes permite atribuir graus de import ancia ` as componentes. Utilizamos os valores de 0.2, 0.7 e 0, respectivamente. Optamos por n ao utilizar a componente T rq (i, t) no c alculo da reputa c ao, pois inicialmente a mesma n ao inuenciaria tanto no c alculo da conabilidade. A primeira componente (T rq (i, t)) e a componente de qualidade de conan ca. Essa componente indica o valor atual de conabilidade do usu ario i no tempo atual t e possui a seguinte f ormula: T rq (i, t) =
j rel(i)

L(j, t) T rq (j, t)/|rel(j )| + (1 )F (i)

(5.2)

39 : Coeciente de ajuste da f ormula. rel(i): Contatos do usu ario i, ou seja, amigos de i. L(j ): Qualidade dos contatos do usu ario j . |rel(j )|: Total de contatos do usu ario j . F (i): Feedback do usu ario i. Podemos observar novos elementos na f ormula 5.2. O primeiro elemento, rel(i), representa o conjunto formado pelos contatos de i. Ou seja, no somat orio apresentado, a vari avel j assumir a o papel de cada contato de i. Tamb em podemos ver o elemento |rel(j )|. Esse elemento e bem parecido com o apresentado anteriormente. Por em, o mesmo representa a quantidade de contatos que o usu ario j possui. J ao e denominado fator de mistura, tem como valor 0.7 e e utilizado para ajuste na f ormula. O elemento L(j, t) presente na f ormula 5.2 e denominado qualidade do link de relacionamento e tem um importante papel no c alculo da reputa c ao. Esse elemento, cuja representa c ao e dada pela f ormula 5.3, representa a qualidade dos relacionamentos do usu ario j . Esse elemento verica se os contatos do usu ario j s ao bons usu arios, ou seja, verica se eles fornecem boas informa c oes no sistema. A presen ca da qualidade do relacionamento indica que usu arios com bons contatos possuem uma boa reputa c ao. O caso contr ario tamb em vale, ou seja, usu arios com maus contatos possuem uma m a reputa c ao.

L(i, t) = F (i, t)
j rel(i)

F (j, t)/|rel(i)|

(5.3)

J a o F (i, t) e denominado feedback do grupo de conan ca e indica uma avalia c ao expl cita do grupo de contatos do usu ario i. O grupo de contatos do usu ario i indica se cona ou n ao nesse usu ario i. O feedback e dado pela f ormula 5.4 e o voto indicando se um usu ario e con avel ou n ao e dado por I (v ). O voto I (vi (j )+ ) representa um voto positivo do usu ario i para o usu ario j , enquanto I (vi (j ) ) indica um voto negativo. Visando garantir que cada usu ario tenha direito a apenas um voto, foi inserido o elemento ij . Esse elemento garante que independente da quantidade de votos dados por um usu ario, o peso desse voto no somat orio e sempre 1. Como no nosso sistema a manipula c ao expl cita de reputa c oes n ao e adequada, tendo em vista a natureza principal deste sistema de manuten c ao de pre cos de produtos por usu arios cadastrados, optamos por implementar esta manipula c ao de maneira indireta, autom atica. Por exemplo, o c alculo de feedback e feito em fun c ao de grupo de contatos de um usu ario, o qual tamb em e calculado indiretamente. Caso um usu ario B tenha conrmado 50% ou mais pre cos de ofertas informadas por A como corretas, o usu ario A se torna um contato de B, ou seja, passa a fazer parte do grupo de contatos de B. O feedback dado pelo usu ario B para A ser a positivo se B pertencer ao grupo de contatos de A e 60% das conrma c oes que B zer em ofertas informadas por A forem conrma c oes positivas, ou seja, os pre cos informados por A forem corretos. Caso contr ario, esse feedback ser a negativo. Os percentuais utilizados s ao emp ricos e podem ser encarados como par ametros de ajuste para o c alculo de reputa c ao proposto. ST (i, t)ij I (vi (j )+ ) + i ST (i, t)ij I (vi (j ) ) + ST (i, t)ij I (vi (j ) )
i

F (j, t) =

(5.4)

40 vi (j )+ : Voto positivo de i para j . vi (j ) : Voto negativo de i para j . As duas componentes restantes na f ormula 5.1 s ao:
t 0

I (x)T rq (i, x)dx e T rq (i, t). Essas compo-

nentes s ao denominadas componente de hist orico de conan ca e componente de adapta c ao ` a mudan ca, respectivamente. A componente de hist orico de conan ca e utilizada para denir a conabilidade do usu ario i ao longo do tempo t, ou seja, seu hist orico no sistema, que tamb em pode ser interpretado como a m edia das reputa c oes desde que o usu ario entrou no sistema. Essa componente possui uma nova fun c ao I (x), a qual e utilizada a cargo do respons avel pela implementa c ao do SocialTrust. Um poss vel exemplo, e a utiliza c ao dessa fun c ao para atribuir maior peso ` as atividades mais recentes de um usu ario. J a a componente de adapta c ao ` a mudan ca e uma fun c ao dada pela derivada da componente de qualidade de conan ca. O intuito dessa fun c ao e impedir que usu arios comecem agindo corretamente no sistema e, de repente alterem seus comportamentos. Ap os realizarmos uma an alise das componentes j a existentes no SocialTrust, inclu mos uma nova componente P(i,t) que adapta o modelo adotado ao nosso problema, a manuten c ao colaborativa de pre cos. Al em disso, inclu mos um novo coeciente que possui o mesmo prop osito dos coecientes apresentados anteriormente e tem o valor de 0.1: 1 t
t

ST (i, t) = T rq (i, t) +

I (x)T rq (i, x)dx + T rq (i, t) + P (i, t)

0

(5.5)

Como podemos ver na f ormula 5.6, essa componente possui um formato baseado na f ormula para o c alculo do feedback: ST (i, t)I (ci (j )+ ) + i ST (i, t)I (ci (j ) ) + ST (i, t)I (ci (j ) )
i

P (j, t) =

(5.6)

ci (j )+ : Usu ario i indica que o pre co de uma oferta informada pelo usu ario j est a correto. ci (j ) : Usu ario i indica que o pre co de uma oferta informada pelo usu ario j est a incorreto. Nessa f ormula n os apresentamos o elemento ci (j ). Esse elemento representa uma conrma c ao do usu ario i em uma oferta atualizada pelo usu ario j . Essa conrma c ao pode ser positiva(ci (j )+ ), indicando que o pre co estava correto, ou negativaci (j ) ), indicando um pre co incorreto. Al em de calcularmos uma m edia dessas conrma c oes, n os utilizamos a fun c ao ST (i, t) para empregar pesos ` a essas conrma c oes. Ou seja, uma conrma c ao feita por um usu ario de maior reputa c ao tem maior peso no c alculo da componente P (i, t). Ao incluir essa componente, nosso objetivo e dar import ancia n ao somente aos relacionamentos que um usu ario possui, mas tamb em ` a sua participa c ao quanto a conrma c ao de pre cos. Essa caracter stica e imprescind vel em nosso sistema, pois para se ter uma boa reputa c ao e necess ario informar pre cos corretamente. Al em disso, n os vericamos que com o passar do tempo as ofertas se tornam menos con aveis, n ao pelo fato de que quem informou o pre co n ao e con avel, mas pela atualiza c ao dos pre cos por parte dos

41 supermercados ser frequente. Devido a isso, n os optamos por decrementar 1% da taxa de conan ca da oferta a cada dia que se passa. Por exemplo, caso o usu ario que atualizou a oferta possua uma reputa c ao de 70%, no dia que a oferta foi informada, a mesma e 70% con avel. Ap os 5 dias, essa oferta ser a 65% con avel. Apesar da reputa c ao do usu ario ser diferente desse valor, devido ao tempo que se passou, a oferta se torna menos con avel.

5.4

Sistemas Semelhantes
Cada vez mais sistemas tem utilizado algoritmos para o c alculo de reputa c ao de usu arios, seja

a m de vericar se o usu ario e con avel, seja para fornecer informa c oes personalizadas. Nessa se c ao descrevemos alguns sistemas que fazem o c alculo de reputa c ao com o intuito de recomendar lmes ou comunidades, ou seja, sistemas que tem o objetivo de oferecer informa c ao personalizada. Tamb em h a sistemas que calculam a reputa c ao visando descobrir qual o grau de conabilidade de um usu ario. Dessa forma, pode-se inferir se uma informa c ao fornecida por esse usu ario est a correta. 1. ActivUFRJ[16]: O ActivUFRJ e um portal que permite a reuni ao de pessoas com interesses pelos mesmos temas na UFRJ. Essas comunidades podem proporcionar dissemina c ao de conhecimento e estimular que novos integrantes se juntem ` as comunidades j a existentes. Os desenvolvedores desse sistema tinham como objetivo n ao somente possibilitar a cria c ao de comunidades, mas tamb em oferecer uma recomenda c ao de comunidades com base nos interesses de cada usu ario. Dessa forma, os usu arios estariam mais propensos a participarem de novas comunidades e aumentar o seu conhecimento. Visando solucionar esse problema foi desenvolvido o ReCoP[17]. O ReCoP tem como objetivo estimular a cria c ao de redes de conan ca, ou seja, estimular o compartilhamento de informa c oes entre usu arios que tenham conan ca entre si. Esse modelo calcula a reputa c ao de um usu ario com base no feedback dado por outros usu arios. No feedback, o usu ario A indica em quais areas de conhecimento ele cona no usu ario B, e dessa forma o sistema pode gerar recomenda c oes personalizadas em cada area de concentra c ao. 2. Moleskiing[18]: O Moleskiing e um sistema que permite que usu arios compartilhem condi c oes da neve em pistas de esqui e tem como objetivo tornar mais segura a pr atica de esqui-alpinismo. Esse site possui uma iniciativa muito interessante pois permite que acidentes sejam evitados. Isso ocorre porque ao se classicar as condi c oes de neve de uma pista de esqui como ruins, esquiadores inexperientes podem optar pelo cancelamento de um passeio e assim evitar algum problema maior. Como as informa c oes sobre as condi c oes da neve s ao informadas pelos usu arios, e importante que se verique o qu ao con avel e esse usu ario. Para vericar essa conabilidade, o Moleskiing permite que os usu arios mantenham listas de contatos, e tamb em qual o grau de conabilidade de cada contato. A partir da intera c ao entre esses usu arios, o Moleskiing calcula a reputa c ao dos mesmos e assim exibe apenas informa c oes con aveis de condi c oes da neve. 3. FilmTrust[19]: O FilmTrust e uma rede social cuja tem atica s ao os lmes. Nesse site e poss vel obter recomenda c oes de lmes e ler opini oes de outros usu arios sobre lmes que eles conhe cam. O

objetivo dos criadores desse site e oferecer aos usu arios um servi co que os permita conhecer lmes adequados ao seu perl. Para isso, os mesmos utilizam o TidalTrust[3] para calcular a reputa c ao dos usu arios e a partir dessa taxa realizar a recomenda c ao de lmes. Para calcular a relev ancia de um lme para um usu ario A, o sistema verica os usu arios que classicaram determinado lme e a classica c ao que esses usu arios atribu ram. Ap os essa etapa e realizada uma m edia entre a soma dos valores de conabilidade dos usu arios multiplicado pela classica c ao que esses usu ario deram para o lme sobre a soma dos valores de conabilidade. 4. Quora [20]: Quora e um site de perguntas e respostas. Sua abordagem e semelhante a do Yahoo! Respostas. Por se tratar de um site que soluciona d uvidas de usu arios, e importante vericar se esse conhecimento adquirido est a correto. Os criadores desse site se preocuparam com essa quest ao[21]. Segundo eles, a solu c ao da mesma e a seguinte: as respostas com mais votos, ou cujos autores possuem boas respostas em seu hist orico aparecem primeiro. J a as respostas que possuem poucos votos ou ent ao tem como autor um usu ario que n ao contribui com boas respostas, n ao aparecem em destaque. Essa reputa c ao dos usu arios e feita de maneira indireta, ou seja, os usu arios n ao indicam explicitamente em quais usu arios conam.

Cap tulo 6

Conclus ao
Podemos destacar como principal resultado desse trabalho de conclus ao de curso, o sistema cuja url e http://pechincha.pagodabox.com. Nesse sistema n os implementamos as funcionalidades que foram descritas ao longo dos cap tulos anteriores. O sistema implementado permite que os colaboradores cadastrem e atualizem produtos, estabelecimentos, endere cos e ofertas. Al em disso, tamb em e oferecido ao usu ario a possibilidade de manter listas de compras. Para apoiar a constru c ao desse sistema colaborativo, tamb em foi desenvolvido um modelo para o c alculo de reputa c ao de usu arios, e assim determinar se um usu ario e con avel ou n ao. No cap tulo 5(Conabilidade das Informa c oes), n os apresentamos essa proposta para o c alculo da reputa c ao de um usu ario no Pechincha Colaborativa. Essa proposta se baseou na modica c ao de um modelo para o c alculo de reputa c ao j a existente, o SocialTrust. Em nosso estudo, pudemos observar alguns coecientes presentes no SocialTrust. Esses coecientes foram denominados , e . Os mesmos eram utilizados para ajustar a f ormula de acordo com a necessidade do sistema a utilizar esse modelo. Por exemplo, ao atribuir maior valor para estamos dando maior import ancia ` a componente multiplicada por esse coeciente. O mesmo vale para os coecientes e . Ao implementarmos o SocialTrust, n os atribu mos valores emp ricos para esses coecientes. Essa pr atica n ao e recomendada. Por em, a falta de usu arios para o teste do Pechincha Colaborativa e o curto espa co de tempo impediram maiores testes em rela c ao a esses valores. Al em de realizar esse estudo sobre o SocialTrust, n os realizamos algumas altera c oes nesse modelo para que o mesmo contemple as caracter sticas do nosso sistema. Dentre essas altera c oes est ao a adi c ao de uma nova componente, a altera c ao na atribui c ao do feedback e a altera c ao na forma c ao dos grupos de contatos. A adi c ao de uma nova componente foi acompanhada da adi c ao de um novo coeciente(). Esse coeciente possui o mesmo prop osito dos coecientes citados no par agrafo acima. J a o c alculo de feedback foi realizado em fun c ao de grupo de contatos de um usu ario, que e formado de forma indireta. Caso um usu ario B tenha conrmado 50% ou mais pre cos de ofertas informadas por A como corretas, o usu ario A se torna um contato de B, ou seja, passa a fazer parte do grupo de contatos de B. O feedback dado pelo usu ario B para A ser a positivo se B pertencer ao grupo de contatos de A e 60% das conrma c oes que B zer em ofertas informadas por A forem conrma c oes positivas, ou seja, os pre cos informados por

43

A forem corretos. Caso contr ario, esse feedback ser a negativo. Os percentuais utilizados s ao emp ricos e podem ser encarados como par ametros de ajuste para o c alculo de reputa c ao proposto. Como podemos observar, apesar de nossa proposta se basear em um modelo j a validado, os valores atribu dos no modelo que n os propomos s ao emp ricos. Devido a esse fato, e necess ario a realiza c ao de testes em um ambiente com um n umero razo avel de usu arios. Tamb em e necess ario realizar essa avalia c ao algumas vezes para determinar os valores dos coecientes que potencializam a utiliza c ao do modelo proposto. Uma sugest ao de trabalho futuro e a realiza c ao desses testes. Entretanto, essa e uma tarefa complicada, pois para se ter certeza que o usu ario informou o pre co de uma oferta corretamente e necess ario vericar essa oferta no estabelecimento em quest ao. Uma sugest ao para contornar essa situa c ao e realizar esses testes em um ambiente controlado, delimitando o n umero de usu arios cadastrados ou oferecendo ofertas apenas de uma cidade pequena por exemplo. Outra sugest ao de trabalho futuro, e levar a reputa c ao em considera c ao n ao somente para denir se uma oferta e con avel. Mas tamb em, para denir quando uma oferta n ao deve mais ser exibida e a ordem em que essa oferta aparece na busca. Essa conabilidade pode ser considerada como par ametro de ordena c ao, no qual ofertas mais con aveis aparecem nas primeiras posi c oes. Tamb em e necess ario analisar quando as ofertas deixam de serem v alidas. Essa a c ao e importante para n ao elevar o n umero de dados desnecess arios armazenados no banco de dados. Uma forma de avaliar se uma oferta e v alida ou n ao, e vericar se a conabilidade dessa oferta tem um valor muito pr oximo de zero. A inser c ao de uma nova componente no SocialTrust, nos levou ` a reex ao de como o algoritmo se comporta na presen ca de falsos con aveis. Esses falsos con aveis s ao mal usu arios que s ao interpretados como bons usu arios. Esse estudo ca como sugest ao de trabalhos futuros. Nesse trabalho n os utilizamos o OOHDM para modelar a intera c ao do usu ario com o sistema. Esse modelo poderia ser melhor utilizado se n os utiliz assemos um contexto para pesquisas espec cas em estabelecimentos. Dessa forma o consumidor poderia optar por navegar entre estabelecimentos e visualizar as ofertas desse estabelecimento. Tamb em podemos avaliar como positivo, n ao somente o resultado direto desse trabalho, como tamb em o resultado indireto. Atrav es da implementa c ao do sistema, adquirimos conhecimento em areas como arquitetura de aplica c oes web, boas pr aticas na constru c ao de interface visando boa performance, desenvolvimento de interface considerando diferentes dispositivos e algoritmos de reputa c ao de usu ario. Por esses e outros conhecimentos adquiridos tamb em podemos considerar o resultado desse trabalho como bem sucedido.

Refer encias Bibliogr acas

[1] Carlos Bazilio e Gabriel Givigier Guimar aes, Pechincha Colaborativa - Um Sistema para Manuten c ao Colaborativa de Pre cos, VII Simp osio Brasileiro de Sistemas Colaborativos, 2010 [2] D. Colleman, Groupware: Collaborative Strategies for Corporate LANs and Intranets., Prentice Hall, Inc., 1997 [3] Jennifer Golbeck, Computing and Applying Trust in Web-based Social Networks, Doctor of Philosophy Dissertation, University of Maryland, College Park, USA, 2005 [4] Raphael L. Levien, Attack resistant trust metrics. PhD thesis, Department of Computer Science, University of California, Berkeley, 2002 [5] S. Brin and L. Page, The Anatomy of a Large-Scale Hypertextual Web Search Engine, 1998 [6] Edith Zaida Sonco Mamani e Marco Aur elio Gerosa, C alculo de Reputa c ao em Redes Sociais, VIII Simp osio Brasileiro de Sistemas Colaborativos, 2011 [7] James Caverlee, Ling Liu and Steve Webb, SocialTrust: Tamper-Resilient Trust Establishment in Online Communities, 2008 [8] Mohsen Lesani and Saeed Bagheri, Fuzzy Trust Inference in Trust Graphs and its Application in Semantic Web Social Networks, World Automation Congress, WAC 06. Sharif University of Technology, Iran, 2006 [9] Ugur Kuter and Jennifer Golbeck, SUNNY: A New Algorithm for Trust Inference in Social Networks, using Probabilistic Condence Models, Proceedings of the Twenty-Second National Conference on Articial Intelligence (AAAI-07). Vancouver, British Columbia, 2007 [10] A. Jsang, R. Ismail and C. Boyd, A survey of trust and reputation systems for online service provision, 2007 [11] James Caverlee, Ling Liu and Steve Webb, The SocialTrust framework for trusted social information management: Architecture and algorithms, 2010 [12] Eric Wang, A Survey of Web-based Social Network Trust, Information Technology Project Unit, Sydney, 2009

45

46 [13] James Caverlee and Steve Webb, A Large-Scale Study of MySpace: Observations and Implications for Online Social Networks, 2008 [14] Susanne Lundasen, Podemos conar nas medidas de conan ca?, 2002 [15] Ana Paula Oliveira dos Santos, An alise da Conabilidade Humana para projeto de Sistemas Web, 2009 [16] Claudia C. P. Cruz e Claudia L. R. Motta, Um Modelo de Sistema de Reputa c ao para Comunidades Virtuais, 2006 [17] Claudia C. P. Cruz, Claudia L. R. Motta e Flavia Maria Santoro, ReCoP: Um Modelo para Reputa ca o em Comunidades de Pr atica, 2007 [18] Paolo Avesani, Paolo Massa and Roberto Tiella, A Trust-enhanced Recommender System application: Moleskiing, 2004 [19] Jennifer Golbeck and James Hendler, FilmTrust: Movie Recommendations using Trust in Web-based Social Networks, 2006 [20] Sharoda A. Paul, Lichan Hong, and Ed. H. Chi, Who is Authoritative? Understanding Reputation Mechanisms in Quora, 2012 [21] Quora, On Quora, what is the algorithm / formula for determining the ordering / ranking of answers on a question?, http://www.quora.com/Quora-product/On-Quora-what-is-the-algorithmformula-for-determining-the-ordering-ranking-of-answers-on-a-question, Acessado em 15 de junho de 2012 [22] Grudin, J., Computer-supported cooperative work: history and focus, 1994 [23] Leonelo Dell Anhol Almeida e Maria Cec lia Calani Baranauskas, Um Prospecto de Sistemas Colaborativos: Modelos e Frameworks, 2008 [24] Gutwin, C. and Greenberg, S., Workspace awareness for groupware, 1996 [25] Gilvan Maiochi, Sistemas de Informa c ao Colaborativos para Web, 2008 [26] Marcos Roberto da Silva Borges, Maria Cl audia Reis Cavalcanti e Maria Lu za Machado Campos, Suporte por Computador ao Trabalho Cooperativo, 1995 [27] Ronald M. Baecker, Jonathan Grudin, William Buxton and Saul Greenberg, Readings in HumanComputer Interaction: Toward the Year 2000, Second Edition (Interactive Technologies), 1995 [28] Jos e Alcir de Almeida Sim oes e Vanessa Lindemann, Editor de Textos Colaborativo Integrado ao Teleduc, 2007 [29] Mariano Pimentel, Marco Aur elio Gerosa, Denise Filippo, Alberto Raposo, Hugo Fuks, Carlos Jos e Pereira de Lucena, Modelo 3C de Colabora c ao para o desenvolvimento de Sistemas Colaborativos, 2006

47 [30] George Coulouris, Jean Dollimore e Tim Kindberg, Sistemas Distribu dos - Conceitos e Projeto, Bookman, 2008 [31] John Nash, Equilibrium Points in n-Person Games, 1950 [32] Daniel Schwabe and Gustavo Rossi, Developing Hypermedia Applications using OOHDM, 1998 [33] Elmasri, R. and Navathe, S.B. and Pinheiro, M.G. and Canhette, C.C. and Melo, G.C.V. and Amadeu, C.V. and de Oliveira Morais, R., Sistemas de Banco de Dados, Pearson Addison Wesley, 2005 [34] Adam Smith, A Riqueza das Na c oes, volume I, Nova Cultural, Cole c ao Os Economistas, 1988 [35] Edward O. Wilson, The Social Conquest of Earth, 1 edition, Liveright, 2012 [36] Apache HTTP Server, http://httpd.apache.org/, Acessado em 01 de outubro de 2012. [37] PHP: Hypertext Preprocessor, http://www.php.net/, Acessado em 01 de outubro de 2012. [38] PostgreSQL, http://www.postgresql.org/, Acessado em 01 de outubro de 2012. [39] JavaScript, https://developer.mozilla.org/en/JavaScript, Acessado em 01 de outubro de 2012. [40] jQuery, http://jquery.com/, Acessado em 01 de outubro de 2012. [41] Dojo Toolkit, http://dojotoolkit.org/, Acessado em 01 de outubro de 2012. [42] Google Chart Tools, https://developers.google.com/chart/, Acessado em 01 de outubro de 2012. [43] Google+ API, https://developers.google.com/+/api/, Acessado em 01 de outubro de 2012. [44] Twitter API, https://dev.twitter.com/, Acessado em 01 de outubro de 2012. [45] Facebook Developers, http://developers.facebook.com/, Acessado em 01 de outubro de 2012. [46] Google Maps API, https://developers.google.com/maps/, Acessado em 01 de outubro de 2012. [47] Zend Framework, http://framework.zend.com/, Acessado em 01 de outubro de 2012.