Monografia

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA
CELSO SUCKOW DA FONSECA - CEFET/RJ
Um sistema de recomendação para a base de dados

NETFLIX usando paralelismo de dados
Antonio Jose de Castro Filho

Márcio Farias Dias Rodrigues
Rômulo Deroci da Rocha
Prof. Orientador: Eduardo Bezerra da Silva
Rio de Janeiro
Agosto de 2011
CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA
CELSO SUCKOW DA FONSECA - CEFET/RJ
Um sistema de recomendação para a base de dados

NETFLIX usando paralelismo de dados
Antonio Jose de Castro Filho

Márcio Farias Dias Rodrigues
Rômulo Deroci da Rocha
Projeto final apresentado em cumprimento às

normas do Departamento de Educação Superior
do CEFET/RJ, como parte dos requisitos para obtenção
do título de Tecnólogo em Sistemas para Internet
Prof. Orientador: Eduardo Bezerra da Silva
Rio de Janeiro
Agosto de 2011
iii
Ficha catalográfica elaborada pela Biblioteca Central do CEFET/RJ

C355 Castro Filho, Antonio Jose de
Um sistema de recomendação para a base de dados NETFLIX usando
paralelismo de dados / Antonio Jose de Castro Filho, Márcio Farias Dias
Rodrigues [e] Rômulo Deroci da Rocha.-2011.
Projeto Final (Tecnólogo) Centro Federal de Educação Tecnológica

Celso Suckow da Fonseca, 2011.
Bibliografia : f. 74-75
Orientador : Eduardo Bezerra da Silva
1.Sistemas de computação 2.Comécio eletrônico 3.Base de dados

NETFLIX 4.Framework (Programa de computador) I.Silva, Eduardo
Bezerra da (orient.) II.Título.
CDD 004.33
iv
Resumo
Apoiar o usuário, permitindo-lhe uma experiência de compras mais amigável, com descobertas
agradáveis e satisfatórias, fazendo mais clientes felizes, gerando novos negócios e maiores lu-
cros. Estes são alguns dos objetivos que os Sistemas de Recomendações podem ajudar a tornar
realidade, indicando itens que talvez os clientes não conheçam, mas possuem grande probabili-
dade de estar de acordo com seus desejos e necessidades. Este trabalho aborda todo o processo
de gerar uma recomendação e apresenta uma implementação de um Sistema de Recomenda-
ções, aplicado sobre a base de dados NetFlix utilizando frameworks apoiando um sistema de
comércio eletrônico. Além disso explora tecnologias e métodos para aumentar a performance
do processo, apresentando testes que fazem uso de um cluster e implementação de um sistema
de recomendação executado de forma distribuída, utilizando paralelismo de dados.
v
Abstract
Support the user, allowing a more friendly shopping experience, with pleasant and satisfactory
discoveries, making more happy customers, generating new business and bigger profits. These
are some of the goals that the Recommendation Systems can help become reality, indicating
items that customers may not know, but have high probability to be in accordance with their
desires and needs. This work boards the entire process of generating a recommendation and
presents an implementation of a recommendation system, applied to the NetFlix database using
frameworks supporting an e-commerce system. Also explores technologies and methods to
increase process performance, with tests that make use of a cluster and implementation of a
recommendation system running in a distributed way, using data parallelism.
vi
Conteúdo
1 Introdução 1
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Metodologia de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Organização dos Capítulos Seguintes . . . . . . . . . . . . . . . . . . . . . . . 4
2 Fundamentação Teórica 5
2.1 Conceitos Relevantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Estratégias de Recomendação . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Itens Promocionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Características Desejadas . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Itens Mais Vendidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Histórico de Compras . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Tipos de Sistema de Recomendação . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Filtragem por Conteúdo . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Filtragem Colaborativa . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Filtragem Híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Entrada de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Abordagem Explícita . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Abordagem Implícita . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Abordagem Híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Passos Para Gerar a Recomendação . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 Cálculo de Similaridade . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2 Gerando a Recomendação . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Apresentação da Recomendação . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Algoritmos Para Gerar Recomendações . . . . . . . . . . . . . . . . . . . . . 14
2.7.1 Para Filtragem Colaborativa . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.2 Para Filtragem Baseada em Conteúdo . . . . . . . . . . . . . . . . . . 15
2.8 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.1 Apache Mahout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.2 Duine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Especificação do Sistema 20
3.1 Descrição do Mini Mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Especificação dos Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Especificação dos Requisitos Funcionais do Sistema . . . . . . . . . . 22
vii
3.3.2 Especificação dos Demais Requisitos do Sistema . . . . . . . . . . . . 23

3.4 Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 Descrições Textuais dos Atores . . . . . . . . . . . . . . . . . . . . . 23
3.4.3 Descrições Textuais dos Casos de Uso . . . . . . . . . . . . . . . . . . 24
3.5 Modelo de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 Diagrama de Classes Conceituais . . . . . . . . . . . . . . . . . . . . 26
3.5.2 Dicionário das Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.3 Visões de Classes Participantes . . . . . . . . . . . . . . . . . . . . . 28
3.6 Modelo de Interações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.1 Descrição Textual dos Contratos das Operações de Sistema . . . . . . . 30
3.6.2 Diagramas de Sequência de Sistema (DSS) . . . . . . . . . . . . . . . 30
3.6.3 Diagramas de Sequência (ou diagramas de comunicação) . . . . . . . . 31
3.7 Projeto de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7.1 Projeto Lógico de Banco de Dados . . . . . . . . . . . . . . . . . . . . 34
3.7.2 Projeto Físico de Banco de Dados . . . . . . . . . . . . . . . . . . . . 35
3.8 Projeto da Interface Gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8.1 Hierarquia das Telas e Mapa de Navegação . . . . . . . . . . . . . . . 39
3.8.2 Padronização de Botões, Ícones e Outros Atalhos . . . . . . . . . . . . 42
4 Aspectos de Implementação 45
4.1 Estratégia de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Descrição da Arquitetura da Aplicação . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Procedimentos de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.3 Servidor de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.4 Servidor de E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.5 Procedimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Experimentos 57
5.1 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Processamento Distribuído . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Conclusões 65
Análise Restrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Apêndices 68
A Manual do Usuário 69
A.1 Informações Relevantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 Padrões Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.3 Página Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.4 Cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.5 Carrinho de Compras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.6 Pagamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
viii
Lista de Figuras
2.1 Partes de sistema de recomendação utilizando Apache Mahout (fonte: [6]). . . 18

2.2 Recursos do framework Duine (fonte: [1]). . . . . . . . . . . . . . . . . . . . . 19
3.1 Disciplinas do projeto unificado x tempo (fonte: [19]). . . . . . . . . . . . . . 22

3.2 Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Diagrama de classes conceituais. . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 VCP 02 - Navegar no catálogo. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 VCP 02 - Efetuar pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 VCP 03 - Registrar-se. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 VCP 04 - Avaliar item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 VCP 05 - Alugar filme(s). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 DSS - Efetuar pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.10 DSS - Identificar-se + Gerar recomendação. . . . . . . . . . . . . . . . . . . . 31
3.11 DSS - Avaliar item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.12 DSS - Alugar filme(s) + Efetuar pagamento. . . . . . . . . . . . . . . . . . . . 31
3.13 DS - Efetuar pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.14 DS - Identificar-se + Gerar recomendação. . . . . . . . . . . . . . . . . . . . . 32
3.15 DS - Alugar filme(s) + Efetuar pagamento + Enviar e-mail. . . . . . . . . . . . 32
3.16 Projeto lógico do banco de dados. . . . . . . . . . . . . . . . . . . . . . . . . 35
3.17 Hierarquia de telas do site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.18 Mapa de navegação do site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Mapa mental utilizado para gerência do projeto. . . . . . . . . . . . . . . . . . 45
5.1 Arquitetura do MySQL Cluster (fonte: [4]). . . . . . . . . . . . . . . . . . . . 58

5.2 Gráfico tempo X computadores - cluster. . . . . . . . . . . . . . . . . . . . . . 60
5.3 Troca de mensagens no sistema distribuído. . . . . . . . . . . . . . . . . . . . 63
5.4 Gráfico tempo X número de computadores - processamento distribuído. . . . . 64
A.1 Tela inicial do AlugOnline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.2 Tela inicial do AlugOnline para um usuário identificado. . . . . . . . . . . . . 71
A.3 Tela referente ao cadastro de novos usuários. . . . . . . . . . . . . . . . . . . . 71
A.4 Tela referente ao carrinho de compras. . . . . . . . . . . . . . . . . . . . . . . 72
A.5 Tela referente ao carrinho de compras - usuários identificados. . . . . . . . . . 72
A.6 Tela de pagamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ix
Lista de Tabelas
2.1 Tabela usuários X itens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Tabela contendo avaliações de itens efetuadas por dois usuários. . . . . . . . . 12
3.1 Características da base de dados. . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Campos Tabela ALUGUEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Chaves Tabela ALUGUEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Campos Tabela AVALIACAO. . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Chaves Tabela AVALIACAO. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Campos Tabela CLIENTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Campos Tabela FILME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 Tabela ALUGUEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 Tabela AVALIACAO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10 Tabela CLIENTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.11 Tabela FILME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Tabela contendo tempos registrados com utilização do cluster. . . . . . . . . . 59

5.2 Resultados do processamento distribuído - em minutos. . . . . . . . . . . . . . 64
x
Lista de Algoritmos
4.1 Trecho do controlador de carrinho. . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Trecho de index.jsp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Trecho da classe FilmeRepository. . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Classe FilmeDAO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Trecho da classe Filme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 Gerando recomendações utilizando o framework Apache Mahout. . . . . . . . 59
5.2 Pseudo código - sistema de recomendações. . . . . . . . . . . . . . . . . . . . 61
1
Capítulo 1
Introdução
1.1 Contextualização
Os sites de compras online têm criado cada vez mais recursos para facilitar a vida do usuário
e aumentar as vendas. Fazendo comparação entre uma loja física e uma virtual, é possível
perceber com mais facilidade tais recursos.
A categorização de produtos, como o setor de laticínios de um supermercado, ou a seção
de comédia em uma vídeo locadora são os menus que detalham as categorias dos produtos do
site. E para quando um cliente não encontra a mercadoria que deseja, pode perguntar a algum
funcionário, nos sites são disponibilizados os sistemas de busca.
Aqueles produtos que ficam perto do caixa para chamar mais atenção, ou aqueles que apa-
recem nas propagandas de TV são os anúncios de produtos em destaque, que aparecem mesmo
sem o usuário ter se identificado no site, o mesmo para todos os usuários.
As promoções que são exibidas em grandes cartazes na parte externa dos supermercados
também aparecem em sites, em destaque ou ao se selecionar cada “setor” no menu.
Mas e as recomendações, as sugestões dos vendedores? Como conseguir esse mesmo su-
porte ao cliente no mundo virtual?
Uma possibilidade é a existência de um atendente que converse, através da Internet ou tele-
fone, com o cliente. Também é possível que, após a seleção de um produto para visualização,
logo abaixo apareça a informação de que existe um produto complementar ou correlato a este.
Para isto não é necessário dado algum do cliente, e todos os clientes receberão a mesma sugestão
de compra.
Observe que para o cliente receber a sugestão ele teve que fazer algum tipo de escolha
prévia. Teve de selecionar algum produto de uma lista ou através de uma busca. Como indicar
ao cliente algo específico a ele, que tenha a ver com o gosto dele?
O atendente da locadora de filmes que informa ao cliente, “... acabaram de devolver um
filme de ação do estilo que o senhor gosta...”, com certeza consegue alugar mais filmes. A
atendente da loja de produtos de beleza que diz para uma cliente, “... se seu cabelo é oleoso, este
condicionador é o ideal para seu tipo de cabelo...”, forneceu informações importantes, indicou
o produto que mais se adequa às necessidades, baseadas em uma especificidade do cliente.
A diferença entre os casos é que no primeiro o atendente baseou sua recomendação em
compras anteriores do cliente, uma informação que o atendente consegue obter sem ter de per-
guntar ao cliente, enquanto que o segundo se baseou em um dado que o cliente teve de fornecer.
Mas em ambos tal comportamento pode ser atingido através do que se chama de Sistema de
Recomendação.
Um Sistema de Recomendação utiliza dados já obtidos do cliente para recomendar-lhe um
2
produto ou serviço. Tal tipo de sistemas é muito utilizado em sites de comércio eletrônico como
Amazon1 , NetFlix2 , Submarino3 , Americanas4 , dentre outros.
Os dados a utilizar no processo de gerar recomendações podem ser fornecidos explicita-
mente pelo usuário. O cliente é questionado em algum momento sobre tais dados, o que na
Internet equivale ao preenchimento de um formulário. O exemplo fornecido anteriormente, o
condicionador a ser sugerido, depende do tipo cabelo, que é um dado que deve ser previamente
fornecido. Este tipo de dado em geral é bem apurado, detalhado, pode-se saber do que o usuário
gosta e do que não gosta. Contudo é difícil fazer com que o usuário forneça tais dados.
Outra abordagem é coletar dados implicitamente, levar em consideração compras anteriores
do cliente ou buscas já efetuadas. O exemplo da locadora se aplica como exemplo de coleta de
dados implícita. Os dados obtidos aqui nem sempre são apurados, por exemplo, a filha pode vir
a utilizar a conta do pai para comprar algum item feminino. Outro problema é que só se sabe
do que o usuário gosta não existem pistas do que ele não gosta.
É claro que uma abordagem híbrida também é possível e aplicável, em alguns produtos
ou serviços. Por exemplo, indicar um condicionador baseado na marca que a pessoa costuma
comprar e no tipo de cabelo informado.
Neste trabalho pretende-se utilizar um Sistema de Recomendações em um site de aluguel
de filmes, utilizando dados de avaliações fornecidas pelo usuário para gerar as recomendações,
ou seja, será utilizada uma abordagem explícita.
Para alcançar tal objetivo o sistema deve verificar outros usuários, registrados na base de
dados, que tenham avaliado os mesmos filmes, e atribuído notas parecidas ao usuário que está
utilizando o sistema. Para estes usuários, o sistema verifica filmes aos quais tenha atribuído
boas notas, e que o usuário atual não tenha avaliado e então o sistema sugere tais filmes para
este.
1.2 Justificativa
O conhecimento é sempre importante. Quando alguém tem dúvidas pede ajuda a pessoas mais
experientes ou especialistas no assunto. Quando um comprador tem algum tipo de dúvida pede
conselhos aos vendedores, ao garçom, a amigos, a familiares, realiza pesquisas na Internet.
É um costume comum buscar conselhos, sugestões, recomendações para decidir em relação
a tudo o que seja necessário fazer escolhas. A opinião de um amigo em relação a uma garota,
opinião de um colega de turma em relação a um trabalho, os conselhos da vovó, a sugestão do
“chef” e nas lojas os vendedores... Mas e no mundo virtual? A compra de produtos seria uma
lista imensa e tediosa, com grande diversidade de produtos na tela do computador?
A utilidade de um Sistema de Recomendação é visível quando é necessário lidar com uma
quantidade muito grande de dados. Por exemplo, o site NetFlix aluga filmes para clientes ca-
dastrados e possui uma grande quantidade de filmes registrados em seu banco de dados. Entrar
nesse site e receber uma boa sugestão de filme pode ser a diferença entre manter ou perder o
cliente. É bem mais fácil aceitar a indicação de um bom filme que ficar navegando por uma
extensa lista sem se ter idéia do que se está procurando. Isso pode acabar fazendo com que o
cliente desista de alugar.
Existem duas atividades fundamentais online, buscar e navegar. Se um consumidor sabe o
que quer, ele busca e, em geral, descarta o que não tem relação com o que buscou, ao encontrar
1
www.amazon.com
2
www.netflix.com
3
www.submarino.com.br
4
www.americanas.com.br
3
avalia se o item encontrado lhe é útil ou não. Mas se não tem certeza, ou não procura por algo
específico o consumidor navega, e é na navegação que o cliente está mais aberto a sugestões,
então se um site possui um bom sistema de recomendações, tem maior probabilidade de exibir
a tal cliente algo que esteja de acordo com seu gosto, que ele necessite, e consequentemente,
ganhar mais dinheiro.
Os sistemas de recomendação se baseiam em comportamento real do usuário para sugerir
algo a este, não são adivinhações. As recomendações são personalizadas, ou seja, não são as
mesmas para todos. Por conta disso os sistemas de recomendação têm como principal foco
sites de comércio eletrônico, facilitando o uso de clientes com pouca experiência em buscas,
personalizando o site para cada cliente e melhorando a experiência de compra, o que se traduz
em maior volume de vendas.
Para que haja realmente uma melhoria na experiência de compra para o usuário faz-se neces-
sário um tempo de resposta adequado por parte do sistema. Sabendo-se da grande quantidade
de informações que sites de comércio eletrônico tendem a armazenar, dada a diversidade de
itens e a quantidade de clientes, podemos prever que o processamento de informações de ava-
liações para gerar recomendações torne-se lento. Assim sendo, o estudo de técnicas ou meios
que tornem o processo mais ágil é de grande utilidade.
1.3 Objetivos
Neste projeto, pretende-se desenvolver um site de aluguel de filmes, que utilize um Sistema de
Recomendação, de forma que, a cada acesso, sejam sugeridos filmes, que estejam de acordo
com o perfil do usuário.
O objetivo primordial é fazer uso de um sistema de recomendação. Sendo assim, o site
de aluguel de filmes será apenas uma contextualização, que servirá de base para o sistema de
recomendação.
Outro objetivo deste trabalho é explorar tecnologias e métodos que permitam aumentar a
performance do processo, apresentando testes que fazem uso de um cluster e implementação de
um sistema de recomendação executado de forma distribuída, utilizando paralelismo de dados.
1.4 Metodologia de Desenvolvimento

O primeiro passo é levantar informações sobre o assunto, de forma a tornar possível adquirir
dados para que sirvam de apoio no trabalho: livros, artigos, sites, grupos de discussão, etc.
Obter o máximo de informações, ler tudo o que for possível e criticar, o que é útil, o que
é realmente válido, filtrando, refinando e fomentando o conhecimento de forma a buscar a
maneira ótima de alcançar os objetivos.
Com o conhecimento estruturado será possível iniciar a escrita do capítulo referente a funda-
mentação teórica, o que permite averiguar se os conhecimentos adquiridos estão solidificados,
levantando dúvidas, revendo conceitos e idéias.
A partir daí torna-se possível o levantamento de requisitos, verificar ferramentas a utilizar:
ferramentas que apoiem a modelagem, ferramenta IDE (Integrated Development Environment
- Ambiente de Desenvolvimento Integrado - um ambiente integrado para desenvolvimento de
software), servidor WEB (ou um servlet conteiner), servidor de banco de dados, enfim, as
ferramentas de apoio ao desenvolvimento.
Torna-se possível também efetuar a modelagem do sistema, transformando os conhecimento
adquiridos em conceitos orientados a objetos (classes, pacotes, atributos, etc.), verificar a ne-
4
cessidade e buscar os frameworks e processos a serem utilizados na implementação, além da

definição da arquitetura do sistema. Partindo da modelagem de classes modelar o banco de
dados, normalizar tabelas e índices, com o andar do projeto, a partir das consultas necessárias,
novos índices podem vir a ser necessários e serão implementados.
Na implementação do sistema de recomendação que apoia o site de comércio eletrônico,
pretende-se utilizar o framework Apache Mahout, discutido na Seção 2.8. Tal framework pos-
sibilita que recomendações sejam geradas aos usuários cadastrados, com base em seu histórico.
As recomendações são geradas através da confrontação do histórico do usuário atual com his-
tórico de outros usuários de forma a descobrir perfis de usuários parecidos, a partir dos quais o
sistema possa recomendar algo que o usuário atual ainda não avaliou e que tenha sido avaliado
com nota alta por usuários de perfil parecido, este assunto é abordado com mais detalhes no
Capítulo 2.
Nos experimentos utiliza-se a base de dados fornecida pelo site NetFlix. Esta foi dispo-
nibilizada para uma competição, a qual teve o intuito de premiar, com um milhão de dólares,
o grupo que conseguisse melhorar em dez por cento a precisão das recomendações fornecidas
pelo sistema da própria NetFlix. Mais sobre o assunto na Seção 3.7.
1.5 Organização dos Capítulos Seguintes

No capítulo 2 são abordados os fundamentos teóricos dos Sistemas de Recomendação, conteúdo
sobre a qual o trabalho foi embasado.
Temos no capítulo 3, apresentação de requisitos, planejamento que norteia a implementação
e detalhes técnicos referentes ao projeto.
É abordada, no capítulo 4, a arquitetura da aplicação, procedimentos utilizados em sua
feitura e informações necessárias para instalação do projeto.
O capítulo 5 apresenta dados obtidos através de diferentes testes efetuados e análise dos
resultados.
Finalmente, no capítulo 5.2, são observadas conclusões referentes ao projeto, seu desenvol-
vimento, implementação e outros aspectos pertinentes.
5
Capítulo 2
Fundamentação Teórica
“Cauda Longa” (do inglês Long Tail) é um termo cunhado por Chris Anderson para descrever o
interessante fenômeno de que produtos de pequenos nichos de mercado, tendem a vender muito
mais na Internet que em mercados de presença física.
Em [13], os autores informam que no site de comércio eletrônico Amazon, 36,7% das ven-
das de livros são referentes aos que estão abaixo da 100.000a posição em vendas. No mesmo
artigo os autores informam ainda que a tendência deverá continuar, e citam como uma das fer-
ramentas que podem ter apoiado e dirigido consumidores a este tipo de mercado os Sistemas de
Recomendação.
Existe muito mais informação na Internet que qualquer pessoa pode processar, além disso,
encontrar, em meio a tanta informação, aquela que realmente lhe interessa é uma tarefa árdua.
Pesquisadores chamam este problema de “sobrecarga de informação” (information overload),
e sistemas de recomendação são uma ferramenta que pode ajudar as pessoas a superá-lo [25].
Estes sistemas são como filtros de informação ativos, que possuem a tarefa de apresentar
ao usuário apenas itens (livros, notícias, músicas, páginas WEB) que sejam de seu interesse,
permitindo que usuários de tais sistemas sejam expostos somente a informações que lhe sejam
realmente relevantes [18].
Tais filtros são ferramentas utilizadas em sites, possuem o intuito de apoiar o processo de
escolha, indicando itens ou serviços que melhor combinem com o perfil do usuário.
Estas ferramentas expandem as possibilidades dos usuários, vão além das buscas, uma vez
que o usuário só busca algo que saiba existir. As recomendações permitem mostrar algo novo
ao usuário, algo que talvez nem soubesse da existência, mas que pode estar de acordo com suas
necessidades, gostos e desejos. Sendo assim, geram possibilidades de novos negócios.
São observadas na Seção 2.1, informações que proporcionam alguma base para que seja
possível entender o processo de funcionamento de um sistema de recomendação. Na Seção 2.2
são apresentadas as diferentes maneiras pelas quais um sistema pode efetuar uma recomenda-
ção. A Seção 2.3 classifica tais sistemas de acordo com a abordagem utilizada. As maneiras de
adquirir dados sobre o usuário, de modo a fornecer recomendações apropriadas, são apresenta-
das na Seção 2.4. Na Seção 2.5, são descritos detalhes das etapas a serem cumpridas para que
um sistema gere uma recomendação. Onde e quando é possível apresentar recomendações aos
usuários é uma pergunta que tenta-se responder na Seção 2.6. Algumas idéias e conceitos da
geração de recomendações são vistos na Seção 2.7. Alguns artefatos de software que permitem
fazer o trabalho de criar um sistema deste tipo são apresentados na Seção 2.8.
6
2.1 Conceitos Relevantes

Existem duas entidades básicas utilizadas em sistemas de recomendação, os usuários do sistema
e os itens que se deseja recomendar. A relação entre ambas pode se dar através de avaliações
e/ou histórico de aquisição ou utilização do item pelo usuário.
As avaliações podem ser binárias, indicando se o usuário obteve ou não o item, se já utilizou
ou não, se gosta ou não. Podem ter também uma amplitude maior, discreta ou contínua, notas
de 0 a 5 inteiras ou reais, por exemplo [25].
Se um sistema possui m usuários e n itens, pode-se gerar uma matriz m por n contendo as
avaliações dos usuários para os itens, conforme a Tabela 2.1. Os algoritmos aplicados utilizam
várias técnicas com apenas duas orientações diferentes: nas linhas - as quais correspondem a
avaliações de um usuário para diferentes itens, ou nas colunas - que correspondem a avaliações
de usuários diferentes para um mesmo item.
Tabela 2.1: Tabela usuários X itens.

item 1 item 2 item 3 ... item n
usuário 1 avaliação 11 avaliação 12 avaliação 13 ... avaliação 1n
... ... ... ... ... ...
usuário m avaliaçãom m1 avaliação m2 avaliação m3 ... avaliação mn
O objetivo destes sistemas é estimar avaliações que os usuários dariam para itens ainda não
avaliados, para que então, baseado nos itens com estimativas maiores, gerar recomendações
para o usuário [22]. Esta estimativa é baseada nas avaliações dadas pelo usuário a outros itens,
ou resultado de uma comparação do perfil do usuário a alguma característica de referência,
ou ainda nas avaliações fornecidas por usuários ao item o qual deseja-se estimar a avaliação.
Uma vez disponíveis estimativas a itens ainda não avaliados, um sistema de recomendação pode
recomendar ao usuário os itens que tiverem as estimativas mais altas [17], [10].
2.2 Estratégias de Recomendação

As recomendações podem ter um grau de especificidade, relativa ao usuário, maior ou menor.
Em outras palavras, é possível fornecer sugestões mais, ou então menos específicas a cada
usuário.
Nas seções seguintes, são apresentadas algumas das estratégias de diferentes formas de gerar
recomendações. A Seção 2.2.1 mostra estratégia em que promoções são apresentadas aos clien-
tes. Já na Seção 2.2.2 é detalhada a técnica em que o cliente tem de informar as características do
produto que deseja para receber recomendações. Na Seção 2.2.3 demonstra-se como itens mais
vendidos podem ser utilizados em recomendações. Finalmente, na Seção 2.2.4, demonstra-se
como dados de compras anteriores podem ser utilizados para gerar recomendações.
2.2.1 Itens Promocionais

Uma recomendação pode ser feita sem a necessidade de dados sobre o usuário atual do sistema
e sem nenhuma informação acerca das vendas efetuadas, baseando a recomendação apenas, por
7
exemplo, em dados promocionais. Exemplos são a promoção do dia e descontos apresentados

em algum item ou setor específico.
2.2.2 Características Desejadas

O preenchimento de um formulário, informando as características do produto que se deseja,
para que no fim o usuário receba a recomendação de itens que se adequem a sua necessidade
é um exemplo de tipo de recomendação que independe de históricos, mas que requer que o
usuário defina explicitamente as características que deseja.
Para a implementação deste tipo de recomendação basta registrar as características de cada
item que se deseja recomendar e então efetuar uma pesquisa na base de dados de acordo com
as informações fornecidas pelo usuário ao preencher um formulário.
2.2.3 Itens Mais Vendidos

Recomendações baseadas em itens mais comprados não necessitam de dados do usuário atual,
mas sim de um histórico de itens vendidos. Os itens mais vendidos deverão ser sugeridos aos
clientes. Aqui surge um problema, a questão de quanto do histórico será utilizado, isso interfere
muito nas sugestões oferecidas.
Podemos comparar, por exemplo, o item bola de futebol, com o item celular (recém lan-
çado). Fazendo a suposição de que a bola existiu no histórico do sistema desde o primeiro dia
de sua utilização, a cinco anos atrás, e desde então tem acumulado dados de compra, não são
vendas altas, digamos que venda trinta unidades por mês. O celular foi lançado esta semana
e, apesar de suas vendas terem acabado com o estoque de cem unidades, a bola será sempre
sugerida aos clientes, pois possui um histórico de vendas muito maior.
Se o sistema restringisse o histórico aos últimos sete dias, com certeza o celular seria suge-
rido aos clientes, teria maiores vendas e geraria maiores lucros. Com esse exemplo hipotético é
possível observar um problema comum aos sistemas de recomendação baseados em históricos,
novos itens raramente são recomendados, por conta de seu histórico ser recente, se comparado
com outros itens.
De qualquer forma este tipo de recomendação é bem simples de ser implementada, o sistema
verifica quais são os itens que tem sido mais vendidos de um determinado momento no passado,
a questão do histórico, até hoje e recomenda ao usuário, sem necessitar de informações deste.
O diferencial que pode ser criado, para este tipo de recomendações, é gerar diferentes sugestões
a diferentes setores, desta forma, o sistema poderia gerar a sugestão de um telefone celular, por
exemplo, no setor de telefonia e uma sugestão de bola de futebol no setor esportivo.
2.2.4 Histórico de Compras

A recomendação de itens com base do histórico de compras do usuário leva este dado em conta
para que o sistema possa verificar outros usuários que tenham perfil de compra parecido e,
com base nas compras destes, gere recomendações de itens que o usuário atual ainda não tenha
adquirido.
Igual abordagem pode ser tomada quando temos notas fornecidas pelo usuário a itens. O
usuário fornece avaliações a itens permitindo ao sistema comparar as notas por ele fornecidas
com as notas de outros usuários, verifica itens de pessoas com perfis parecidos para fornecer
recomendações ao usuário.
8
Implementar este tipo de recomendação é uma tarefa mais complexa, e é a partir daí que
torna-se necessário o uso de um sistema de recomendação.
2.3 Tipos de Sistema de Recomendação

Os sistemas de recomendação podem ser diferenciados de acordo com a abordagem utilizada
para realizar as recomendações:
• filtragem por conteúdo - com base nos itens a serem recomendados, a qual é discutida na
Seção 2.3.1;
• filtragem colaborativa - baseada em perfis de outros usuários, detalhada na Seção 2.3.2;
• filtragem híbrida - mescla as duas anteriores, abordada na Seção 2.3.3.
2.3.1 Filtragem por Conteúdo

A abordagem baseada em conteúdo para recomendações tem suas raízes na extração de infor-
mações (Information Retrieval - uma área do processamento de dados que estuda meios de
obter informações a partir de uma coleção de dados) e emprega muitas das mesmas técnicas.
Documentos textuais são recomendados com base em uma comparação entre seu conteúdo e o
perfil do usuário, por exemplo, [12].
O perfil do usuário é constituído por uma coleção de dados através dos quais um sistema
de recomendação pode inferir preferências deste. Histórico de compras, páginas visitadas e
avaliações de itens são exemplos de dados que podem constituir o perfil de um usuário.
Nos sistemas que utilizam o método de filtragem por conteúdo para gerar recomendações, a
avaliação a ser estimada é baseada nas avaliações, já fornecidas pelo usuário, de itens que sejam
similares [10]. Em outras palavras, o usuário recebe recomendação de itens similares aos que
preferiu no passado. O sistema baseia as recomendações em características comuns aos artigos
já comprados, ou já avaliados, e os itens que se deseja recomendar.
Conhecendo o histórico de preferências do usuário por determinados itens e a semelhança
entre eles, o sistema de recomendação baseado em conteúdo é capaz de recomendar ao usuário
outros itens que possam vir a ser de seu interesse.
Muitos sistemas de recomendação baseados em filtragem por conteúdo focam na recomen-
dação de informações textuais, como documentos, sites, blogs, fóruns, etc, por conta de suas
raízes atreladas a recuperação e filtragem de informação.
Apesar dos detalhes dos vários sistemas serem diferentes, dividem em comum meios de des-
crever itens que podem ser recomendados, um meio de criar um perfil do usuário que descreva
os tipos de itens que o usuário gosta e meios de compará-los com os itens a serem recomendados
[23].
Basicamente possui dois passos: construir uma matriz item x item determinando relações
entre pares de itens; utilizando tal matriz, e dados do usuário atual, pode-se inferir seu gosto.
Técnicas baseadas em filtragem por conteúdo são limitadas pelas informações associadas
com os itens que esses sistemas recomendam, ou seja, para que tenhamos uma quantidade
razoável de informações o conteúdo deve poder ser interpretado automaticamente por um com-
putador, como texto, por exemplo, ou devemos definir tais informações manualmente [10].
Em geral apenas análises superficiais podem ser fornecidas, mesmo em domínios textuais,
como em páginas Web, por exemplo, técnicas de recuperação de informação não levam em
9
conta aspectos estéticos (A página possui um esquema de cores agradável? É intuitiva? As in-
formações estão bem organizadas?), enquanto que em alguns domínios os itens não são sujeitos
a métodos de extração de informações pela tecnologia atualmente disponível, comidas são um
bom exemplo, é necessária a intervenção humana, fornecendo algum tipo de dado, uma crítica
ou avaliação [12].
Este problema ocorre devido à dificuldade de análise do conteúdo. Técnicas de extração de
informação funcionam para documentos textuais, alguns outros domínios apresentam grande
dificuldade. É mais fácil classificar um documento, dizer quais palavras ele possui e quantas
vezes cada ocorre, que classificar um filme (é uma comédia, um romance, um filme de terror),
dizer quais são, quantas vezes aparecem os atores do elenco e criticar a atuação de cada um
deles.
Outros problemas para a abordagem baseada em conteúdo são o do novo usuário, que por
não possuir informações suficientes acerca de seus gostos, não recebe recomendações precisas
e o de grande especialização, onde o sistema acaba não recomendando itens muito diferentes
do que o usuário já avaliou [10].
2.3.2 Filtragem Colaborativa

A abordagem de filtragem colaborativa para geração de recomendações sugere itens os quais
outros usuários, “similares” ao qual se deseja efetuar uma recomendação, gostaram no passado,
ou seja, em vez de computar a similaridade entre itens, computa-se a similaridade entre usuários.
Tipicamente para cada usuário existe um conjunto de “vizinhos próximos”, “similares”, ou
seja, usuários com gostos parecidos, que tenham avaliado itens com certo grau de similaridade.
Estimativas para a avaliação de itens são baseadas na combinação das avaliações dos “vizinhos
próximos” [12].
Esta técnica baseia-se em avaliações dos itens. Dessa forma, usuários que avaliam de forma
semelhante os mesmos conteúdos são considerados usuários com preferências similares, assim,
entende-se que o que um avalia positivamente, os outros também devem fazê-lo.
Filtragem colaborativa não considera informações acerca dos itens, como o gênero de um
filme, por exemplo, mas somente as avaliações fornecidas pela comunidade de usuários, e assim
se mantém independente de domínio de uso [21]. Em consequência, não exige a compreensão
ou reconhecimento das características dos itens para realizar as recomendações, e sim a defini-
ção de similaridade entre os gostos e as preferências dos usuários.
De qualquer forma a mesma abordagem introduz seus próprios problemas, o aparecimento
de novos itens passa despercebida pelo sistema até que seja avaliado por alguns usuários ou
que se especifique a similaridade com outros itens. Se a base de dados possuir um pequeno
número de usuários, em relação ao volume de informação no sistema, existe o perigo de termos
uma pequena diversidade de recomendações. Um outro problema é que, para usuários com
gosto peculiar, não usual em comparação ao resto da população, não existirão outros usuários
similares a este e então o sistema fornecerá recomendações não satisfatórias [12].
A diferença entre os diversos sistemas de recomendação que usam a abordagem colaborativa
está em como a similaridade entre os usuários é efetivamente calculada [15]. Estes sistemas têm
muitas formas, mas de maneira geral podem ser reduzidos a dois passos: procurar por usuários
que compartilhem dos mesmos padrões de avaliações a itens em relação ao usuário atual, para o
qual desejamos efetuar a recomendação; e então utilizar as avaliações encontradas para estimar
a nota que o usuário atual daria a determinado item.
Os sistemas de filtragem colaborativa calculam um coeficiente de similaridade para os usuá-
rios que possuem gostos parecidos com o usuário atual. O segundo passo é estimar a avaliação
10
que o usuário atual forneceria ao item em questão, que é calculada como uma média ponderada
das avaliações fornecidas pelos outros usuários para aquele item, onde os pesos são os respec-
tivos coeficientes de similaridade. A intenção é que as avaliações dos usuários de gosto mais
similar ao do usuário atual sejam mais consideradas.
2.3.3 Filtragem Híbrida

O sistema que utiliza filtragem híbrida combina filtragem baseada em conteúdo e colabora-
tiva. O principal objetivo é evitar limitações apresentadas em sistemas que aplicam apenas uma
abordagem.
Obviamente mais complexa, dado que acumula as complexidades das abordagens por con-
teúdo e colaborativa, contudo, mais precisa por também acumular os benefícios de ambas. É
mais difícil de ser implementada, mas gera resultados mais precisos, com estimativas mais acu-
radas.
Permite que sejam efetuadas boas recomendações, mesmo com um número pequeno de
usuários similares, o que ocorre quando o sistema possui poucos usuários registrados ou para
algum usuário “não convencional” (se comparado aos outros registrados), aproveitando benefí-
cio da filtragem baseada por conteúdo onde a filtragem colaborativa seria falha.
Diminui o problema de grande especialização da filtragem baseada por conteúdo - sugestão
de itens muito parecidos aos que o usuário já avaliou. Utilizando a filtragem colaborativa aplica
tanta diversidade às sugestões quanto os usuários similares possuírem em seus itens avaliados.
Para implementação da abordagem híbrida, pode-se utilizar sistemas implementados sepa-
radamente (um baseado em conteúdo e outro colaborativo), combinando a saída de ambos ou
utilizando as melhores recomendações, baseando-se em alguma métrica ou critério de quali-
dade. Averiguar a similaridade entre os itens sugeridos por ambas as técnicas seria uma possi-
bilidade plausível. Um sistema pode também adicionar características de um modelo no outro.
Em vez de manter o histórico das avaliações dos usuários, o sistema pode, por exemplo, manter
perfis baseados em conteúdo.
Diversas maneiras de implementação unindo as abordagens baseada em conteúdo e a cola-
borativa são possíveis, e muitos artigos, como [12] e [26] informam ter alcançado resultados
mais significativos utilizando abordagens híbridas.
2.4 Entrada de Dados

São necessários dados acerca das preferências dos usuários para que o sistema de recomendação
possa gerar recomendações de acordo com a preferência deste. Se o sistema não possui infor-
mações sobre o usuário não tem como gerar uma recomendação que lhe atenda perfeitamente.
Sem dados referentes as preferências dos usuários para utilizar, o sistema enfrenta um
grande problema que é a “partida a frio” (cold-start problem), isto é, o sistema perde em efi-
ciência nas estimativas até que um número suficiente de dados estejam disponíveis, para que o
sistema tenha maior precisão nas recomendações [15].
Para que o sistema popule a base de dados, deve colher informações acerca dos usuários. O
objetivo de efetuar tal coleta é a de criar um perfil que descreva suas características. Os perfis,
contendo avaliações com notas, ou dados de compra, ou ainda qualquer informação que registre
as preferências do usuário são armazenados, e servem de base para gerar recomendações.
As técnicas mais comuns são a de abordagem explícita, a qual é discutida na Seção 2.4.1,
e a de abordagem implícita, detalhada na Seção 2.4.2, sendo possível também uma abordagem
híbrida, combinando ambas de alguma forma, apresentada na Seção 2.4.3.
11
2.4.1 Abordagem Explícita

Na abordagem explícita, o usuário é solicitado a informar seus gostos ou preferências de forma
que o sistema possa utilizar tais dados para fornecer recomendações.
Este método possui a vantagem de permitir aos usuários que especifiquem diretamente seus
interesses e também eliminar logo de início o problema da “partida a frio”. Em geral isso
se traduz no preenchimento de um formulário no qual o usuário indica o que gosta e o que
não gosta, ou então avaliação de itens, dando notas que representem seu grau de satisfação ou
aprovação em relação a cada um [15].
2.4.2 Abordagem Implícita

Utilizando a abordagem implícita as preferências do usuário são armazenadas automaticamente
pelo sistema. Este método é geralmente transparente ao usuário, ou seja, ele não precisa pre-
encher um formulário dizendo do que gosta e do que não gosta, não precisa avaliar itens. Os
dados necessários são armazenados, ao longo do tempo, de acordo com o comportamento do
usuário.
O registro de compras já efetuadas, as buscas feitas, os filmes já alugados, links nos quais
clicou, todos são exemplos de dados que o sistema pode colher do usuário de forma implícita,
mas que, ainda assim, dizem muito sobre seu gosto e hábitos.
A vantagem dessa técnica é que as manifestações de interesse dos usuários são silenciosa-
mente deixadas como um resultado natural da manipulação dos artefatos com os quais interage,
em vez de serem explicitamente solicitadas aos usuários [15].
Infelizmente tal abordagem vem esbarrando em problemas referentes a privacidade do usuá-
rio, muitos se sentem desconfortáveis ao perceber que dados acerca de sua navegação estão
sendo registrados e se mostram temerosos de que tais informações possam ser repassadas, ou
então expostas, gerando constrangimentos e consternação.
2.4.3 Abordagem Híbrida

A utilização desta abordagem elimina o problema de “partida a frio”, permitindo que nas pri-
meiras utilizações o sistema já forneça recomendações válidas, uma vantagem da abordagem
explícita.
Por outro lado a utilização em conjunto da abordagem implícita permite que, ao longo do
tempo, as recomendações sejam ainda mais precisas por ter acumulado ainda mais dados sobre
os usuários. Registrando também alterações de comportamento do usuário, por exemplo, um
usuário que tenha se tornado pai começa a se interessar por itens destinados a crianças, um
usuário que receba um generoso aumento salarial passa a preferir itens mais requintados.
2.5 Passos Para Gerar a Recomendação

O funcionamento de um sistema de recomendação pode ser dividido em dois passos princi-
pais: a formação de um grupo de similaridade, com o cálculo do coeficiente de similaridade
entre os itens ou os usuários de forma a encontrar os mais similares e, por fim, a geração da
recomendação ou a estimativa da avaliação que o usuário atual forneceria a determinado item
[21].
Contudo, antes de tudo isso, o sistema deve representar os dados a serem armazenados.
Como foi visto na Seção 2.1, um sistema de recomendação pode representar os dados que
12
possui como uma matriz de m usuários por n itens, contendo as avaliações que os usuários
fornecem aos itens. Observemos que o sistema raramente terá um usuário avaliando todos os
itens, em verdade, é comum que tenha uma matriz muito esparsa, ou seja, com muitos pontos
onde os usuários não avaliaram os itens.
É claro que essa matriz muito esparsa tende a dificultar o processo de gerar recomendações,
pois tal problema possibilita a existência de usuários sem, ou com poucos similares, impossibi-
litando a geração de recomendações adequadas ou gerando recomendações pouco confiáveis.
Existem algumas técnicas que podem ser aplicadas a esta matriz para obter melhores resul-
tados no processo, reduzindo este problema:
• valor padrão - esta é a técnica mais simples, fornece, para a avaliação de itens ainda não
avaliados por algum usuário, um valor padrão;
• valor da média - o sistema fornece o valor da média das avaliações já fornecidas, para
itens ainda não avaliados por algum usuário;
• robôs avaliadores - tais devem ser considerados como usuários comuns e devem fornecer
avaliação para cada item que faça parte de seu domínio, isso elimina o problema do novo
item não avaliado que acaba não sendo indicado a ninguém [27].
A seguir pode-se obervar os passos do processo de gerar recomendações, o cálculo de simi-

laridade, na Seção 2.5.1, e a geração da recomendação em si, Seção 2.5.2.
2.5.1 Cálculo de Similaridade

Neste ponto do processo o sistema deve calcular a similaridade entre os itens para formar classes
nas quais os itens já avaliados pelo usuário possam ser classificados, ou a similaridade entre os
usuários para que o sistema possa encontrar os mais “similares” ao usuário atual.
A similaridade é calculada com o auxílio de alguma métrica, como, por exemplo, a Corre-
lação de Pearson:
Pn
(rai − ra )(rbi − rb )
ρab = pPn i=1 Pn (2.1)
(r − r )2 (r − r )2
i=1 ai a i=1 bi b
Dado o conjunto de avaliações rai do usuário ativo a, e o conjunto de avaliações rbi do

vizinho b, ρab é o índice de similaridade entre os dois usuários. Note que é preciso mais de
uma avaliação, a itens comuns, para que o índice seja útil, e os resultados variam entre +1
(similaridade total) e -1 (total dissimilaridade). O mesmo pode ser utilizado para averiguar a
similaridade de itens [20].
Então, para os dados da tabela 2.2:
Tabela 2.2: Tabela contendo avaliações de itens efetuadas por dois usuários.
item 1 item 2 item 3 item 4
usuário a 1 5 3 -
usuário b 1 5 3 2
É possível calcular a similaridade entre os usuários a e b (ρab ):

ra = rb = média das avaliações fornecidas aos itens = (1 + 5 + 3)/3 = 3
13
Para o numerador da Correlação de Pearson, temos:
n
X
(rai − ra )(rbi − rb ) = (1 − 3).(1 − 3) + (5 − 3).(5 − 3) + (3 − 3).(3 − 3)
i=1
= 4+4+0
= 8
Para
pPon denominador: Pn
− 2 2
p i=1 (r ai r a ) i=1 (rbi − r b ) =
2
= p[(1 − 3) + (5 − 3) + (3 √2 − 3) ].[(1 − 3)2 + (5 − 3)2 + (3 − 3)2 ] =
2
= [4 + 4 + 0].[4 + 4 + 0] = 82 = 8
Então:
ρab = 8/8 = 1 (similaridade total), como era de se esperar.
A distância euclidiana (d - distância entre dois pontos) é outra métrica que pode ser utilizada:
v
u n
uX
dab = t (xai − xbi )2 (2.2)
i=1
Onde n é o número de atributos que se deseja utilizar e x é a avaliação, ou valoração dada a

cada atributo, de dois itens, ou usuários a e b.
Deve-se observar que quanto menor (com um mínimo de zero) a distância (d) mais similares
são os itens ou usuários avaliados.
Para os dados fornecidos, fica óbvio que, na subtração (xai − xbi ) itens avaliados igualmente
pelos usuários levará a um valor zero, com isso o somatório resultará em zero, similaridade
máxima.
Existe também a possibilidade de representação como vetores, com n componentes, onde n
é o número de características que se deseja utilizar. Para cada característica temos uma com-
ponente e para cada componente temos um módulo representando a importância ou avaliação
fornecida. Com isso um sistema pode utilizar, para cálculo da similaridade, o coseno do ângulo
entre vetores [20]:
→ →
→ → → → A.B
similaridade(A, B ) = cos(A, B ) = → → (2.3)
| A || B |
A similaridade por coseno tem o mesmo domínio da Correlação de Pearson, e o mesmo
significado para os valores extremos, +1 (similaridade total) e -1 (total dissimilaridade).
Para os valores fornecidos como exemplo, temos o seguinte cálculo:
→ → → → →
A=B = 1 i +5 j +3 k
→ →
A→. B = 12 +p52 + 32 = 35 √
→
| A || B | = (12 + 52 + 32 ).(12 + 52 + 32 ) = 352 = 35, então temos:
→ →
similaridade(A, B ) = 35/35 = 1 (similaridade total, como era de se esperar).
Tendo os valores de similaridade um sistema de recomendação pode então avaliar quais
os usuários ou itens possuem maior similaridade com o que estiver analisando e então ir ao
próximo passo, a geração da recomendação [27].
14
2.5.2 Gerando a Recomendação

No último passo do processo o sistema deverá gerar uma recomendação que deve ser expressa
por uma lista dos itens que o usuário ativo apreciaria ou então uma estimativa, na forma de um
valor, que o usuário avaliaria um item ainda não avaliado por ele.
Com a lista de vizinhos e os níveis de similaridade, é possível estimar as avaliações que o
usuário faria para os itens que ele ainda não avaliou. A similaridade entre usuários é utilizada
para dar peso as avaliações. A estimativa da avaliação Pai de um item i para um usuário a, é
calculada com base nas avaliações feitas para esse item por todos os usuários “similares” ao
usuário a, conforme a equação que segue:
Pn
wa,b .(rbi − rb )
Pai = ra + b=1Pn (2.4)
b=1 |wa,b |
Onde ra e rb são as médias das avaliações dos usuários a e b, respectivamente, e rbi é a
avaliação do usuário b para o item i, e wa,b é o índice de similaridade entre os usuários.
Se quisermos estimar Pa4 (avaliação do usuário a para o item 4), por exemplo, teremos:
Pa4 = 3 + 1.(2−3)
1
= 2, ou seja, estima-se que o usuário a forneceria avaliação igual a de seu
único “vizinho” b, como ambos possuem similaridade máxima, tal resultado era de se esperar.
Uma recomendação pode ser gerada de acordo com o item mais freqüentemente encontrado
nas avaliações dos usuários mais similares ao ativo; ou então os itens com notas mais altas, das
médias das avaliações dos itens avaliados pelos usuários mais similares; ou ainda itens próximos
aos que o usuário ativo tenha avaliado bem [27].
2.6 Apresentação da Recomendação

Recomendações podem ser apresentadas quando solicitadas pelo usuário, no apoio a uma com-
pra - como na Seção 2.2.2, ou a qualquer momento em que o usuário utiliza o site, até mesmo
antes de ser identificado - como na Seção 2.2.1, antes e/ou depois de uma compra, apresentando
um item do mesmo tipo ou complementar, ou algo como: “o usuário que comprou este item
comprou também...”, ou a cada nova página aberta por este.
Podem ser apresentadas mesmo quando o usuário se quer pensa em fazer uso dos serviços
da empresa que a gera, através de mensagens enviadas ao usuário contendo propaganda de
produtos, recomendações, de acordo com seu perfil.
2.7 Algoritmos Para Gerar Recomendações

Existem diferentes técnicas que podem ser utilizadas para resolver o problema de gerar uma
recomendação. Os algoritmos utilizados para filtragem colaborativa são vistos na Seção 2.7.1,
os utilizados para filtragem baseada em conteúdo são apresentados na Seção 2.7.2.
2.7.1 Para Filtragem Colaborativa

Para um sistema de recomendação que utilize a abordagem de filtragem colaborativa, existe
uma grande variedade de algoritmos propostos, mas podemos perceber duas classes principais:
baseado em histórico (memory-based) e baseado em modelo (model-based) [30]:
15
Baseada em Histórico (Memory-based)

Algoritmos deste tipo utilizam o histórico de avaliações dos usuários para estimar novas avalia-
ções, isto é, o valor da avaliação não efetuada por um usuário para um item é considerada como
um agregado de avaliações de alguns outros usuários, em geral os de perfil mais similar, para
o mesmo item [24]. A maneira mais simples de calcular o agregado das avaliações é a média
aritmética [10]. O uso da média ponderada, que utilize valores mais altos para vizinhos mais
próximos, por exemplo valor da similaridade (para a Correlação de Pearson), tende a aumentar
a acurácia das recomendações.
Encontrar os usuários mais similares para então utilizar suas avaliações, pode ser feito atra-
vés do uso do coeficiente de Pearson ou do coseno.
O método baseado em histórico pode ser motivado da observação de que as pessoas costu-
mam confiar nas recomendações de pessoas com mesmos gostos e preferências.
Existem algumas desvantagens nesta abordagem. Depende de avaliações fornecidas por
seres humanos. Não consegue lidar com o problema de “partida a frio”, ou seja, não consegue
ajudar novos usuários. Contudo é de simples implementação e eficiente.
Métodos mais comuns: Vizinhos mais próximos, clusterização e teoria dos grafos [10].
Baseado em Modelo (Model-based)

Em contraste com a filtragem colaborativa baseada em histórico, os algoritmos baseados em
modelo usam a coleção de avaliações para “aprender” um modelo das avaliações efetuadas pelo
usuário, o qual é então utilizado para estimar avaliações [24].
Esta abordagem primeiramente apreende um modelo descritivo das preferências do usuário
e o utiliza para predizer avaliações. Muitos destes métodos são inspirados em algoritmos de
aprendizado de máquinas (machine learning algorithms). Exemplos incluem classificadores de
redes neurais (neural network classifiers), aprendizado de regras por indução (induction rule
learning), classificadores lineares (linear classifiers), redes Baiesianas (Bayesian networks) e
mineração de regras de associação (association rule mining).
Muitos destes modelos são baseados em técnicas de classificação dos dados que utiliza.
Modelos de clusterização, por exemplo, tratam a filtragem colaborativa como um problema de
classificação e trabalha agrupando usuários similares na mesma classe e estimando a probabili-
dade das avaliações.
Existem algumas desvantagens com este paradigma. A construção de um modelo é uma
tarefa cara e, devido ao seu uso, pode perder informações valiosas acerca do usuário.
Técnicas mais comuns: Redes Bayesianas, clusterização, redes neurais artificiais, regressão
linear e modelos probabilísticos [10].
2.7.2 Para Filtragem Baseada em Conteúdo

Esta abordagem observa o conjunto de itens que o usuário já avaliou e averigua o quão similar
estes são a outros itens e então seleciona os mais similares. Uma vez que se tenha encontrado
os itens mais similares, a estimativa para a avaliação de um item é calculada.
Baseada no usuário (user-based)

Esta técnica se fundamenta na idéia de que uma pessoa pertence a um grupo de indivíduos com
interesses similares, tem gostos similares e assim, itens avaliados pelos indivíduos podem ser
utilizados como base para recomendar itens a um membro do grupo.
16
Técnicas comumente utilizadas: TF-IDF (Term Frequency-Inverse Document Frequency) e

clusterização (clustering) [10].
TF-IDF é uma técnica utilizada para avaliar o quão importante um termo é para um docu-
mento, ou para uma coleção de documentos. Muito utilizada em mineração de dados e recupe-
ração de informações.
Para a melhor compreensão da técnica TF-IDF passamos a observar alguns detalhes ma-
temáticos. A contagem da ocorrência do termo em um documento deve ser normalizada para
prevenir “ruídos” gerados por longos documentos, nos quais um termo pode ocorrer várias ve-
zes só porque o documento é realmente longo e não porque o termo é muito importante naquele
texto. Assim é possível fornecer a medida da importância do termo ti dentro de determinado
documento di .
Assim, a freqüência do termo, definida como:
ni,j
tfi,j = P (2.5)
k nk,j
Onde ni,j é o número de ocorrências do termo considerado (ti ) no documento dj , e o deno-
minador é a soma do número de ocorrências de todos os termos no documento dj , ou seja, o
tamanho do documento |dj |.
A frequência inversa do documento é uma medida da importância geral do termo. É obtida
pela divisão do número total de documentos pelo número de documentos contendo o termo, e
então tomando o logaritmo daquele cociente.
|D|
idfi = log (2.6)
|{d : ti ∈ d}|
Onde:
• |D| ⇒ é o total de documentos;
• |{d : ti ∈ d}| ⇒ é o número de documentos onde o termo ti aparece.
Então:
(tf − idf )i,j = tfi,j .idfi (2.7)

Clusterização é, basicamente, um processo de organização de elementos em grupos, nos
quais os membros são, de alguma maneira, similares. Em geral “treinamos” o algoritmo com
alguns dados de exemplo, dizendo a que grupo pertencem, e depois, para um novo elemento,
não classificado, o algoritmo determina o grupo mais apropriado para tal elemento, com base
no “treinamento” feito anteriormente.
Baseado em modelo (model-based)

Analisando informações do histórico e perfil do usuário, esta técnica identifica relações entre um
item e outros itens da comunidade. Por exemplo, a compra de um item pode estar relacionada
à compra de outro item, e então essas relações lógicas são utilizadas para criar as regra para
recomendação.
Comumente são utilizadas as técnicas: Classificadores Bayesianos, clusterização, árvores
de decisão e redes neurais artificiais [10].
17
2.8 Frameworks
A utilização de frameworks permite a introdução de novas funcionalidades de uma maneira
mais rápida. Outra vantagem do uso de frameworks advém do fato de se tratar de software
estável, já testado, com uma comunidade de usuários para trocar idéias, críticas e sugestões de
desenvolvimento [11], [19], [29], [28].
Em pesquisas efetuadas foi possível encontrar dois frameworks que fornecem base para o
desenvolvimento de sistemas de recomendação, o Apache Mahout, descrito na Seção 2.8.1 e o
Duine, abordado na Seção 2.8.2.
2.8.1 Apache Mahout

Em sua versão 0.4, o Apache Mahout, como o nome deixa transparecer é mantido pela Apa-
che Software Foundation1 , uma instituição que provê suporte para a comunidade de projeto de
software de código aberto, criado e desenvolvido por um time de desenvolvedores voluntários.
Apache Mahout é um conjunto de bibliotecas de aprendizado de máquina (machine lear-
ning), ou aprendizado automático, concebida para ser escalável e robusta.
Tal software dá suporte a quatro casos de uso:
• Recomendações - averigua o comportamento do usuário e, a partir de tal informação,

tenta encontrar itens que o usuário poderia gostar.
• Clusterização - utiliza documentos e grupos e relaciona-os de forma a obter documentos

relacionados a tópicos
• Aprendizado de classificação a partir de documentos categorizados previamente - veri-

fica como se parecem documentos de uma dada categoria e consegue classificar novos
documentos na categoria certa.
• Mineração de itens agrupados - verifica quais itens aparecem combinados com frequência.
Dentre as bibliotecas que fazem parte deste software, a de nome Taste é utilizada para fil-
tragem colaborativa em Java. Ela utiliza as preferências do usuário por itens e retorna uma
estimativa da preferência do usuário para outros itens.
A biblioteca Taste provê uma gama de componentes a partir dos quais pode ser construído
um sistema de recomendação selecionando alguns algoritmos.
Além de já desenhada para alta performance, escalabilidade e flexibilidade, pode prover um
servidor web de forma a responder requisições de aplicações, mesmo as não Java.
A figura 2.1 mostra o relacionamento entre as partes de um sistema de recomendação gerado
com o framework Apache Mahout. A aplicação cliente acessa o framework de recomendação
que utiliza os conceitos de vizinhança (Neighborhood), correlação (Correlation) e inferências
acerca de preferências (Preference Infere), para gerar as recomendações.
O framework de recomendação utiliza um modelo de dados (DataModel) para ter acesso
aos dados de usuários, que possuem suas preferências quanto aos itens armazenadas em uma
base de dados.
1
www.apache.org
18
Figura 2.1: Partes de sistema de recomendação utilizando Apache Mahout (fonte: [6]).
2.8.2 Duine
Atualmente na versão 4.0.0, o framework Duine foi desenvolvido pelo Instituto de Telemática
da empresa Novay2 .
O Duine é uma coleção de bibliotecas que permite desenvolvedores criarem mecanismos
que efetuem estimativas, as quais podem ser utilizadas para personalizar informações aos usuá-
rios, especificamente em recomendar aos usuários qual informação lhe é importante.
Este software estima o quanto um item é interessante para determinado usuário. Também
processa e armazena avaliações que usuários fornecem a itens e o interesse do usuário em
categorias, gêneros e outras informações relativas aos itens.
O framework também possui capacidade de aprendizado, adaptando o perfil do usuário a
cada avaliação fornecida a itens.
O Duine framework pode ser extendido, com novas técnicas e estratégias, com novos mo-
delos de perfil. Pode-se também substituir o mapeamento objeto relacional efetuado pelo fra-
mework Hibernate.
Uma técnica de estimativa avalia o quão interessado um usuário estará em um item, através
do uso de algum algoritmo. Como resultado temos um valor numérico representando a quan-
tidade de interesse esperada pelo usuário, é utilizada uma faixa de -1 (menos um) a +1 (mais
um), onde o 0 (zero) é considerado neutro.
Duine combina múltiplas técnicas para gerar as estimativas. Atualmente o Duine oferece
sete técnicas distintas para gerar os resultados desejados: filtragem colaborativa, filtragem de
2
www.novay.nl/en/
19
informação, raciocínio baseado em casos (com base na quantidade de itens similares que fo-
ram classificados pelo usuário no passado), GenreLMS (raciocínio em gêneros), TopNDeviation
(popularidade), AlreadyKnown e UserAverage.
O sistema de recomendação pode ter suas capacidades estendidas com o uso de algoritmos
criados por desenvolvedores, e possui seleção dinâmica de algoritmo, de modo a melhor se
adaptar a cada situação. Conta também com uma API que fornece explicações referentes a
recomendação fornecida, informando no que se baseou para fornecer suas estimativas.
O “recommender” (recomendador), parte do framework que fornece as estimativas, possibi-
lita que sejam registradas, “plugadas”, algumas facilidades, pluggable profile models, pluggable
feedback processors, pluggable caching support, que representam modelos de perfis, processa-
dores de retorno e suporte a cache, respectivamente, possibilitando que sejam utilizadas outras
ferramentas que não as fornecidas, adicionando extensibilidade a este framework.
Tudo isso pode ser utilizado junto a ferramenta de cache que implemente JCS (Java Caching
Systen) e o framework de persistência Hibernate, contudo o uso de interfaces permite que sejam
utilizados outros frameworks.
A figura 2.2 fornece uma visão superficial das capacidades do framework Duine.
Figura 2.2: Recursos do framework Duine (fonte: [1]).

20
Capítulo 3
Especificação do Sistema
Neste capítulo, são observados detalhes acerca dos requisitos, planejamento que norteiam a
implementação e detalhes técnicos referentes ao projeto.
Um modelo pode ser visto como a representação abstrata e simplificada de um sistema real,
com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em partes [14].
Com o uso de modelos, diagramas e descrições, pretende-se facilitar a compreensão do
sistema desenvolvido e do ambiente em que este se insere. Com isso, é possível transmitir mais
facilmente idéias, visão, a modelagem do sistema.
Desta forma, na Seção 3.1 o software a ser produzido é contextualizado, assim como objeti-
vos a serem alcançados com sua produção e alguns detalhes de como deverá funcionar, através
da descrição do contexto no qual o software se apresenta.
A Seção 3.2 informa o caminho seguido, o tempo utilizado e o esforço despendido. Na
Seção 3.3 são abordadas as necessidades a serem supridas pelo software.
Com a utilização de modelos, são apresentados objetivos e funcionalidades a serem alcan-
çados na Seção 3.4. A modelagem do problema sob uma perspectiva sistêmica, típica de um
software, é vista na Seção 3.5. Na Seção 3.6 pode-se perceber a colaboração entre os artefatos
de software no esforço de responder as requisições efetuadas pelo usuário.
A Seção 3.7 modela o problema de maneira relacional, típica de bancos de dados usados
para a persistência das informações. Finalmente, na Seção 3.8 são apresentados detalhes acerca
da interface com a qual o usuário terá de interagir com o sistema.
3.1 Descrição do Mini Mundo

O projeto desenvolvido pretende automatizar o processo de fornecer recomendações aos usuá-
rios de uma locadora de filmes online. Em empresas de comércio de presença física tal processo
é feito, muitas vezes, por vendedores.
Nosso processo de fornecer recomendações será contextualizado em um site de aluguel
de filmes, algo parecido com uma locadora de vídeos, onde o atendente da loja conhece os
gostos dos seus clientes e para cada cliente, já cadastrado, que adentra a loja ele fornece uma
recomendação.
A idéia não é nova, existe uma empresa chamada NetFlix que presta tais serviços através de
seu site, também utilizando um sistema de recomendações para auxiliar seus clientes.
Este projeto se insere, em um ambiente corporativo, na linha de frente de uma empresa de
comércio online, exibindo produtos, registrando vendas e apoiando o usuário em suas compras.
O objetivo básico do uso de um sistema de recomendação é o apoio ao usuário em sua
decisão, ajudando-o a escolher entre uma diversidade de opções. A consequência direta disso é
21
uma quantidade maior de clientes satisfeitos, em conseguinte, maiores lucros.

A empresa que presta o serviço de locação de filmes, tem como função organizacional pres-
tar serviço de entretenimento ao cliente, através dos filmes que aluga. Essa função terá resul-
tados muito mais positivos se o filme que o usuário toma emprestado realmente suprir suas
expectativas de diversão, assim, o sistema de recomendação tem papel fundamental.
Para gerar as recomendações foi utilizada a abordagem de filtragem colaborativa baseada
em histórico (memory-based), ou seja, o sistema estima avaliações que os usuários forneceriam
a itens com base nas avaliações de outros usuários semelhantes a este. As avaliações foram
obtidas através de abordagem explícita, a partir das avaliações que usuários forneceram a filmes
no site NetFlix, mais detalhes sobre a base de dados utilizada na Seção 3.7.
Como o sistema de recomendação foi contextualizado como parte de um sistema de aluguel
de filmes, foi desenvolvido um site que disponibiliza tal serviço. Tal site fornece suporte a todo
o processo de locação de filmes e ferramentas que apóiam o usuário neste processo.
Desta forma o sistema possui pesquisa na base de dados, “carrinho de compras” (adicionar
e remover itens à lista de produtos os quais o usuário tenha selecionado para efetuar locação),
cadastro de novos clientes, dentre outros. Tudo com o intuito de apoiar o cliente.
Todo este sistema, fazendo parte de um ambiente corporativo, deve disponibilizar interface
de uso ao cliente através da Internet.
É fator crítico de sucesso para qualquer empresa que presta serviços a qualidade. Não é
diferente para o comércio online, muito menos para os sistemas de recomendação: Para um
site, design intuitivo, onde as principais funcionalidades estejam sempre a um clique, páginas
“leves”, sem exageros de informação, que carreguem rápido e disponibilidade. Para um sistema
de recomendação, recomendações rápidas, confiáveis, de qualidade, que realmente sejam úteis,
que estejam de acordo com o perfil do usuário.
Na seção que se segue são discutidos o modo e técnicas utilizadas para alcançar tais objeti-
vos.
3.2 Planejamento
Aplicando metodologia de Processo Unificado, evolutivo e ágil, não é possível criar um crono-
grama rígido, dividindo-o em etapas onde só será efetuada uma disciplina por vez.
Não existe tarefa isolada nem momento em que não se pense no sistema como um todo, o
que existe são momentos em que são feitas diversas tarefas, como por exemplo, no início do
processo existe mais concentração, um maior esforço, em averiguar requisitos e entendê-los,
ao longo do tempo, com a maior compreensão do domínio do negócio existe a tendência a
despender menos esforço em tal tarefa.
O melhor a fazer é fornecer uma estimativa de esforço em cada disciplina que ocorre para-
lelamente a cada momento do projeto. Com este intuito, segue abaixo, na figura 3.1 um gráfico
tempo versus esforço estimado, que mostra o trabalho a cumprir. A figura mostra as disciplinas
do Processo Unificado e estimativas de esforço nelas dispendido em cada interação do processo
de desenvolvimento do software.
Em um ambiente corporativo, entende-se que a construção do projeto, em se utilizando
os mesmos frameworks utilizados no projeto construido, não deverá ser um esforço dos mais
dispendiosos. Grande parte do projeto foi desenvolvido em um curto espaço de tempo, sobrando
apenas ajustes visuais e detalhes a serem melhorados, sem os quais o sistema já funcionava
perfeitamente.
22
Figura 3.1: Disciplinas do projeto unificado x tempo (fonte: [19]).
3.3 Especificação dos Requisitos

Esta seção trata das capacidades mínimas a serem alcançados pelo software produzido. Apre-
senta as especificações das funcionalidades que o sistema deve possuir de modo a suprir as
necessidades dos clientes. Requisitos funcionais são abordados na Seção 3.3.1, demais requisi-
tos são expostos na Seção 3.3.2.
3.3.1 Especificação dos Requisitos Funcionais do Sistema

O principal requisito do sistema é gerar recomendações, este é o foco deste trabalho. É claro
que deve-se ter um bom grau de satisfação do cliente em relação à qualidade e diversidade das
recomendações geradas. Outros requisitos se seguem:
• Catálogo eletrônico - fornecer ao usuário uma listagem ordenada, onde o usuário encontre
os produtos comercializados pelo site.
• Pesquisa na base de dados - possibilitar ao usuário procurar por um item em específico

ou itens que sigam algum tipo de padrão.
• Carrinho de compras - possibilitar ao usuário adicionar e remover itens a uma lista dos
que serão alugados.
• Registro de usuários - um visitante, ainda não registrado, na base de dados de usuários,

deve poder se registrar.
• Login de usuário - usuários registrados podem utilizar identificação e senha para que
tenham acesso a funcionalidades restritas (solicitar locações e avaliar filmes).
• Gerar recomendações - usuários registrados ao se identificarem devem receber recomen-

dações de acordo com as avaliações que tenha efetuado anteriormente.
• Avaliação de filmes - usuários registrados, já identificados, devem poder avaliar filmes.
• Alugar filmes - usuários registrados, já identificados, devem ser capazes de alugar filmes.
23
3.3.2 Especificação dos Demais Requisitos do Sistema

Por ser utilizado em tempo real, através da Internet, e por se tratar de um site de comércio eletrô-
nico, o tempo de resposta aos comandos deve ter alto grau de prioridade. O tempo de resposta
do site é um fator importante para manter clientes satisfeitos. Assim sendo, o sistema deverá
apresentar páginas “leves”, que sejam carregadas o mais rápido possível e, ainda pensando em
tempo de resposta, as recomendações devem ser geradas em tempo hábil a serem transmitidas
ao cliente.
A privacidade do usuário deve ser mantida, ninguém deve ter acesso aos dados pessoais dos
clientes, dados de locação e de avaliação dos filmes devem ser mantidos em sigilo.
O sistema deve apresentar interface simples, intuitiva e funcional em todos os navegadores.
3.4 Modelo de Casos de Uso

Nesta seção são descritas as principais funcionalidades do sistema, ou seja, o que o usuário será
capaz de fazer quando utilizando a interface deste. A Seção 3.4.1 exibe o diagrama de casos
de uso que nos permite observar possíveis interações usuário-sistema. Já na Seção 3.4.2 são
descritos os atores, aqueles que interagem com o sistema. Finalmente, na Seção 3.4.3 detalhes
dos passos, das possíveis interações usuário - sistema.
3.4.1 Diagrama de Casos de Uso

A figura 3.2 mostra o diagrama de casos de uso referente ao sistema desenvolvido.
Figura 3.2: Diagrama de casos de uso.
3.4.2 Descrições Textuais dos Atores

Como principal ator do sistema temos o usuário, aquele que utiliza os serviços prestados pelo
site, aquele que, em um sistema real, geraria receita à empresa. É para este ator que todo o
sistema presta serviços.
24
Como ator secundário temos o sistema de e-mail - foi criada uma conta no Gmail1 esta é
utilizada para possibilitar que o sistema desenvolvido envie e-mail de confirmação de compras
aos clientes.
3.4.3 Descrições Textuais dos Casos de Uso

São detalhadas, a seguir, de forma textual, com o objetivo de relatar todo o processo, as intera-
ções entre os usuários e o sistema.
Um problema é comum a todos os casos de uso. Após longo período de inatividade, que
pode ser configurado no container da aplicação, a sessão pode expirar, assim que o sistema vol-
tar a ser utilizado iniciará nova sessão, com “carrinho de compras” vazio e sem identificação do
usuário mesmo que este já tenha efetuado login e/ou adicionado itens ao “carrinho de compras”.
Caso de Uso 01 - Navegar no catálogo

Ator primário: Usuário.
Objetivo: Navegar na listagem de filmes disponíveis, ordenados de alguma forma.
Cenário de sucesso (principal):
1. O usuário seleciona a parte do catálogo que gostaria de ver.
2. O sistema retorna a listagem referente a parte do catálogo solicitada.
Caso de Uso 02 - Efetuar pesquisa

Objetivo: Obter listagem de filmes que sigam determinado padrão.
1. Usuário digita padrão que deseja buscar, na caixa de texto referente as buscas, e clica no
botão “Buscar”.
2. O sistema retorna lista com elementos que apresentam o padrão informado.
Extensões:
2.a. O sistema não encontra itens contendo o padrão especificado, exibe mensagem infor-
mando que não existem itens a exibir.
Caso de Uso 03 - Registrar-se

Objetivo: Criar registro no banco de dados referente a novo usuário.
1. O usuário acessa a página de registro.
2. O sistema apresenta formulário a ser preenchido.
3. O usuário preenche o cadastro e clica no botão “Salvar”.
4. O sistema informa que o registro foi efetuado com sucesso e passa a exibir o nome do
usuário em todas as páginas.
Extensões:
4.a. O e-mail utilizado já consta na base de dados, o sistema recusa os dados, pois este deve
ser único.
Garantia de sucesso: O banco de dados deve gravar os dados do usuário com sucesso.
1
www.gmail.com
25
Caso de Uso 04 - Avaliar item

Objetivo: Fornecer nota de 0 a 5 a determinado filme.
Pré condição: O usuário deve ter se identificado previamente.
1. O usuário busca o filme que deseja avaliar.
2. O sistema apresenta listagem com filmes que apresentem o padrão fornecido.
3. O usuário encontra o filme procurado e fornece uma nota, de zero a cinco, ao filme.
4. O sistema armazena a nota informando ao usuário que a mesma foi armazenada.
Extensão:
2.a. O sistema não encontra filme que obedeça ao padrão buscado ou o filme pretendido não
se encontra na listagem fornecida pelo sistema em resposta a busca efetuada.
Garantia de sucesso: O sistema deve armazenar os dados da avaliação do item fornecida
pelo cliente.
Caso de Uso 05 - Alugar filme(s)

Objetivo: Alugar item(ns) que consta(m) no “carrinho de compras”.
Pré condição: O usuário deve ter se identificado previamente.
1. O usuário busca item(ns) e, ao encontrar, o(s) adiciona ao “carrinho de compras”.
2. O sistema armazena o(s) item(ns) no “carrinho de compras”.
3. O usuário decide alugar item(ns) que consta(em) no “carrinho de compras”, clica no link
“Fechar pedido”.
4. O sistema apresenta tela informando dados referentes ao aluguel - itens, valor individual
e valor total - e solicita informações sobre a forma de pagamento.
5. O usuário confirma dados do aluguel e determina a forma de pagamento.
6. O sistema registra dados da locação, esvazia o “carrinho de compras” e envia e-mail ao
cliente confirmando a compra (incluir casos de uso “Efetuar pagamento” e “Enviar e-mail”).
Extensão: A qualquer momento o usuário pode desistir do aluguel.
Garantia de sucesso: Os dados do aluguel devem ser armazenados.
Caso de Uso 06 - Gerar recomendação

Objetivo: Recomendar itens que estejam de acordo com as preferências do usuário, aumen-
tando, desta forma, a probabilidade de que este alugue filmes.
Pré condição: O usuário deve ter se identificado.
1. Após o usuário ter se identificado, o sistema fornece lista contendo recomendações de
filmes que estejam de acordo com o gosto do usuário.
Extensão: O usuário pode não ter dados suficientes ou usuários similares, o que impede que
o sistema gere recomendações adequadas.
26
3.5 Modelo de Classes

O modelo de classes representa as partes estáticas e estruturais do sistema. Um diagrama que re-
presenta o modelo conceitual do sistema é apresentado na Seção 3.5.1. Na Seção 3.5.2 é exposto
o significado de classes existentes no sistema. Por fim, na Seção 3.5.3 as classes envolvidas nas
respostas as requisições dos usuários são apresentadas.
3.5.1 Diagrama de Classes Conceituais

Esta seção mostra um dos modelos utilizados para transmitir uma visão estática do sistema. O
diagrama de classes conceituais apresenta os conceitos envolvidos no sistema, através da visão
do relacionamento entre suas classes fundamentais.
Na figura 3.3 pode-se ver o diagrama de classes conceituais referentes ao sistema desen-
volvido. Esta permite que seja observado como as classes referentes ao domínio do sistema
interagem entre si.
Figura 3.3: Diagrama de classes conceituais.
3.5.2 Dicionário das Classes

Esta seção traz detalhes das principais classes do sistema. São descritos os conceitos que repre-
sentam e seus respectivos propósitos enquanto parte do sistema.
Desta forma, descrevemos a seguir Controladores, Interceptadores, Repositórios DAOs e as
classes de negócio.
Controladores
Recebem as requisições das páginas, seus métodos são executados de acordo com as solicita-
ções.
Foram criados controladores para os principais conceitos do sistema:
• Controlador de carrinho - controla as funções que envolvem o “carrinho de compras”,

como adicionar, remover e listar itens.
• Controlador de filme - controla a função de busca e avaliação de filmes.

27
• Controlador de usuário - controla as funções que envolvem o usuário, como logon, logout
e registro de novo usuário.
• Controlador de página inicial - criado para aproveitar uma facilidade do framework utili-
zado, controla apenas o acesso à página inicial.
Interceptadores
O framework utilizado na construção do sistema, permite a criação da figura de interceptadores,
estes, como o próprio nome deixa claro, interceptam as requisições feitas pelas páginas ao
sistema, permitindo que sejam efetuados alguns tratamentos antes que as requisições cheguem
aos controladores solicitados.
Foram utilizados três interceptadores:
• Interceptador para o “carrinho de compras” - inclui nas respostas às requisições o número
de itens que constam no “carrinho de compras” da sessão atual. Tal artifício foi utilizado
de forma a evitar que fosse repetido este mesmo procedimento diversas vezes.
• Interceptador de autenticação - efetua controle de acesso impedindo que funções permiti-
das apenas a usuários logados sejam acessadas em sessões onde o usuário não tenha feito
logon.
• Interceptador de verificação de usuário - verifica se a sessão atual possui um usuário
logado e, em caso afirmativo, adiciona o nome do usuário, a ser exibido nas páginas, nas
respostas às requisições, evitando repetição de código.
Repositórios
Classes que guardam a “inteligência” de manipulação e organização das informações obtidas
das bases de dados. Foram utilizados os descritos a seguir:
• Repositório de carrinho - obtém infomações e manipula dados do “carrinho de compras”.
• Repositório de aluguéis - referente aos dados dos aluguéis de filmes.
• Repositório de filmes - para a busca de filmes.
• Repositório de usuários - obtém informações dos usuários.
DAOs
Camada de acesso a dados, possui a lógica de utilização do framework Hibernate para obtenção,
armazenamento, recuperação e exclusão dos dados. Foram utilizadas as seguintes:
• DAO - classe que contém toda a lógica de acesso aos dados com a utilização do framework
Hibernate, um framework utilizado justamente para a persistência e mapeamento objeto
relacional. Posssui operações de CRUD (Create Read Update Delete). Todos as outras
classes DAO extendem esta.
• DAO de usuário.
• DAO de aluguel.
• DAO de filme.
28
Classes de Negócio
São as classes que relacionadas carregam os conceitos do sistema, algumas das classes utilizadas
efetuam mapeamento objeto relacional através das anotações do framework Hibernate.
• Carrinho - é a classe que faz o papel do “carrinho de compras” no sistema. É uma classe
cujos objetos são transientes, ou seja, não persiste suas informações, dado que estas são
úteis apenas durante a execução do sistema.
• Filme.
• Aluguel.
• Usuário.
• Classe de envio de e-mail - utiliza a API mail da linguagem Java armazena toda a lógica
de envio de e-mail.
• Classe geradora de recomendações - utiliza o framework Apache Mahout para gerar re-
comendações.
3.5.3 Visões de Classes Participantes

Nesta seção são apresentadas as classes que colaboram para o atendimento de cada requisição
do usuário.
VCP 01 - Navegar no catálogo
Figura 3.4: VCP 02 - Navegar no catálogo.
VCP 02 - Efetuar pesquisa
Figura 3.5: VCP 02 - Efetuar pesquisa.

29
VCP 03 - Registrar-se
Figura 3.6: VCP 03 - Registrar-se.
VCP 04 - Avaliar item
Figura 3.7: VCP 04 - Avaliar item.
VCP 05 - Alugar filme(s)
Figura 3.8: VCP 05 - Alugar filme(s).
3.6 Modelo de Interações

O modelo de iterações do sistema é útil para que seja possível ter uma visão global das iterações
que ocorrem entre os objetos no software, para responder a diferentes estímulos recebidos pelo
sistema. Em outras palavras, são observadas as trocas de mensagens entre os objetos envolvidos
na resposta a uma requisição.
Na Seção 3.6.1 observa-se a descrição detalhada das operações que o usuário poderá efetuar
com o sistema. As solicitações possíveis e suas respectivas respostas são abordadas, através
30
de diagramas, na Seção 3.6.2. A Seção 3.6.3 mostra a troca de mensagens entre as classes no
esforço de responder solicitações dos usuários.
3.6.1 Descrição Textual dos Contratos das Operações de Sistema

Os contratos de operações do sistema documentam textualmente o comportamento esperado
para uma operação de sistema. Sua construção é efetuada a partir do modelo de classes concei-
tuais e do diagrama de sequência do sistema e da identificação das operações correspondentes
do sistema.
Operação: buscar(padrão)
Responsabilidade: efetuar busca por filmes que apresentem o padrão especificado em seu nome.
Referências cruzadas: caso de uso “efetuar pesquisa”.
Pré-condições: nenhuma.
Pós-condições: nenhuma.
Operação: identificar(id, senha)

Responsabilidade: buscar por usuário, verificar se senha é correta e, em caso positivo, retornar
uma lista de filmes recomendados ao usuário.
Referências cruzadas: caso de uso “gerar recomendação”.
Pré-condições: nenhuma.
Operação: fecharPedido()
Responsabilidade: informar ao usuário itens constantes no “carrinho de compras” com respec-
tivos valores e total para a locação, solicitando informação de forma de pagamento.
Referências cruzadas: caso de uso “alugar filme(s)”.
Pré-condições: o usuário deverá ter sido identificado e possuir itens em seu “carrinho de
compras”.
Operação: efetuarPagamento(modoPagamento)
Responsabilidade: Encerrar, registrar e confirmar aluguel de filme(s) ao usuário.
Referências cruzadas: caso de uso “alugar filme(s)”
Pré-condições: o usuário, previamente identificado, deverá ter selecionado a forma de pa-
gamento.
Pós-condições: o sistema deverá ter registrado os dados do aluguel (filmes alugados e valo-
res), enviado e-mail de confirmação ao usuário e retirado os itens do “carrinho de compras”.
3.6.2 Diagramas de Sequência de Sistema (DSS)

Os diagramas de sequência do sistema são utilizados para especificar, de forma gráfica, o com-
portamento externamente visível do sistema. Permite visualizar atores, o sistema, em forma de
uma “caixa preta”, os eventos com respectivas respostas.
31
DSS - Efetuar pesquisa e Navegar no catálogo
Figura 3.9: DSS - Efetuar pesquisa.
DSS - Identificar-se + Gerar recomendação
Figura 3.10: DSS - Identificar-se + Gerar recomendação.
DSS - Avaliar item
Figura 3.11: DSS - Avaliar item.
DSS - Alugar filme(s) + Efetuar pagamento
Figura 3.12: DSS - Alugar filme(s) + Efetuar pagamento.
3.6.3 Diagramas de Sequência (ou diagramas de comunicação)

Os diagramas de sequência nos permitem observar o encadeamento de mensagens trocadas
entre os objetos com o intuito de responder a uma requisição de um ator, mostram a maneira
que os objetos interagem e colaboram, ao longo do tempo, para atingir determinado objetivo.
Nas seções que se seguem são exibidos alguns diagramas de sequência relativos ao projeto.
32
Efetuar pesquisa
Figura 3.13: DS - Efetuar pesquisa.
Identificar-se + Gerar recomendação
Figura 3.14: DS - Identificar-se + Gerar recomendação.
Alugar filme(s) + Efetuar pagamento + Enviar e-mail
Figura 3.15: DS - Alugar filme(s) + Efetuar pagamento + Enviar e-mail.

33
3.7 Projeto de Banco de Dados

Neste projeto foi utilizada a base de dados fornecida pela empresa NetFlix para seu concurso
que forneceria a premiação de U$ 1 milhão a equipe que tivesse êxito em conseguir uma melho-
ria de dez por cento de eficiência em relação ao sistema de recomendação que a própria empresa
utiliza.
A base de dados é fornecida compactada, ao efetuar a descompactação deste arquivo um
outro arquivo compactado é obtido, da descompactação deste último obtem-se uma pasta de
nome download, contendo seis arquivos:
• movie_titles.txt - arquivo no formato texto, tipo CVS (Comma Separated Value - valores
separados por vírgula), as linhas são como registros relativos a um mesmo filme e vírgulas
separam os atributos. Cada linha possui o identificador do filme - um número natural,
sequencial, de 1 a 17770 - ou seja, totalizam-se dezessete mil setecentos e setenta filmes.
O segundo atributo é o ano de lançamento do filme, o terceiro é o título do filme;
• probe.txt - é um arquivo de uso específico para a competição, possui dados de teste para
avaliar a eficácia do sistema de sistemas de recomendação;
• qualifying.txt - também é um arquivo específico para a competição, possui dados de usuá-
rios e de filmes, solicitando, para determinada data, a estimativa da avaliação que o usuá-
rio forneceria para o dado filme;
• README - este arquivo possui um sumário, fornecendo algumas informações acerca da
base de dados, uma licença de uso, o formato dos arquivos, dentre outros detalhes;
• rmse.pl - este é um arquivo contendo uma implementação do cálculo de RMSE (Root
Mean Square Error - raiz quadrada média do erro) uma medida utilizada frequentemente
para verificar a diferença entre o valor estimado e o real valor observado do experimento
modelado. Este é utilizado para fins da competição;
• training_set.tar - é um arquivo compactado de uma pasta contendo 17770 arquivos, um
para cada filme. A primeira linha de cada arquivo contém a identificação do filme seguida
por dois pontos (:) . Cada linha subsequente no arquivo corresponde a uma avaliação de
um cliente e a data da avaliação. As avaliações são números naturais de 1 a 5.
Primeiramente foi efetuada a importação dos dados para um banco de dados, preferiu-se
a abordagem relacional, utilizando como SGBD (Sistema Gerenciador de Banco de Dados) o
MySql, um banco de dados Open Source (de código livre) muito popular por ser consistente,
possuir boa performance, confiabilidade e apresentar fácil utilização. Foi utilizada a versão que
funciona sobre a plataforma Windows, mas o mesmo disponibiliza versões para mais de vinte
plataformas, entre elas: Linux, HP-UX, AIX, e Netware.
O MySQL é muito popular, tanto que em seu site é anunciado como “The world’s most
popular open source database” (O banco de dados de código livre mais popular do mundo).
Boa performance, mesmo em sistemas modestos, confiabilidade e facilidade de uso são alguns
de seus benefícios. Por tais motivos é a escolha de muitos desenvolvedores para ambientes
de desenvolvimento, mas grandes empresas como Facebook, Google, Adobe, Alcatel, dentre
outras [5], utilizam o MySQL para ambientes de produção.
Além de todos os benefícios citados o MySQL fornece uma versão para clusterização que
utiliza arquitetura distribuída que “não compartilha nada”, em outras palavras, não possui pon-
tos únicos de falha, não existe um ponto que seja compartilhado e que, em caso de problemas,
todo o cluster falhe.
34
Para a criação da tabela Cliente foi necessário pesquisar os códigos de usuários diferentes na
tabela de avaliação, e foi criado um programa que criava nomes selecionando, aleatoriamente,
um nome de um vetor e dois sobrenomes diferentes de outro vetor.
Foram criadas as chaves primárias (e seus respectivos índices), chaves estrangeiras para
garantir a integridade referencial no modo “No Action”, de modo que ao executar os comandos
Update, Delete e Insert sobre tais campos (chave estrangeira) não seja executada nenhuma ação
aos seus correlatos em outras tabelas e foi feita também a tipificação dos atributos atendendo as
necessidades do framework Mahout.
O framework Apache Mahout exige que alguns detalhes sejam observados na tabela que
contém os dados das avaliações fornecidas pelos usuários aos itens:
• A identificação do usuário e a do item devem ser não nulas e tem de ser Índices.
• A chave primária tem de ser composta da identificação do usuário e do item.
• Os tipos de dados para as colunas devem ser os correspondentes aos tipos long e float do
Java. No MySQL estes são o BIGINT e o FLOAT.
Com o intuito de tornar os dados mais próximos dos que são utilizados em situações reais,
foram adicionados campos senha, igual ao ID do usuário, e e-mail que consta do primeiro nome
do usuário mais as iniciais do segundo e terceiro nome + @gmail.com.
A base de dados original foi adicionada a tabela “aluguel”, destinada a armazenar as loca-
ções de filmes efetuadas.
Por fim vale citar que a base de dados ficou com as características informadas na tabela
3.1. Um ponto importante a ser observado é a quantidade de dados, que totaliza 7,5 gigabytes,
principalmente obtida da tabela de avaliações, na qual temos 100.273.038 avaliações para um
total de 480.188 clientes, uma média de mais de 208 avaliações por cliente. Com um cliente
avaliando o máximo de 17.647 filmes e o mínimo de um filme.
Tabela 3.1: Características da base de dados.

Tabela Registros Tamanho (dados+índice)
aluguel 0 1 KB
avaliacao 100.273.038 7,4 GB
cliente 480.188 31,5 MB
filme 17.770 845,7 KB
Total 100.771.001 7,5 GB
3.7.1 Projeto Lógico de Banco de Dados

Após o levantamento de todos os requisitos do sistema, foi possível selecionar os objetos do
projeto AlugOnline que deveriam persistir em tabelas do Banco de Dados, tais objetos podem
ser encontrados no diagrama da figura 3.16.
Como a estrutura das tabelas são oriundas do Banco de Dados do Netflix, não houve a
necessidade de Normalizá-las, visto que as mesmas já se encontram devidamente normalizadas
até a 3a Forma Normal.
35
Figura 3.16: Projeto lógico do banco de dados.
3.7.2 Projeto Físico de Banco de Dados

Quanto às características físicas das tabelas, os atributos foram tipificados de acordo com o
solicitado pelo Apache Mahout. Este framework sugere que a tabela AVALIACAO (única ta-
bela utilizada pelo Apache Mahout) tenha como chave primária os campos ID_FILME e o
ID_CLIENTE, que são chaves estrangeiras das tabelas FILME e CLIENTE, respectivamente.
Estes campos devem ser do tipo BIGINT e o campo referente a avaliação (pontuação) deve
ser do tipo FLOAT. Além desses atributos, os demais (de todas as tabelas do Banco de Dados)
foram tipificados para que se enquadrem nas necessidades do site, conforme exposto na Seção
3.7.2.
A indexação dos campos foi feita de forma a obter um bom tempo médio de resposta das
consultas, segundo o plano de execução traçado, conforme Seção 3.7.2.
Tipificação dos Atributos

Seguindo os requisitos do framework Apache Mahout, os atributos das tabelas FILME, CLI-
ENTE e AVALIACAO foram criados respeitando a regra onde deve haver compatibilidade en-
tre os tipos de dados long e float encontrados no Java com o SGBD MySql cujos tipos são
respectivamente BIGINT (atributos ID’s das tabelas CLIENTE e FILME) e FLOAT (atributo
AVALIACAO da tabela AVALIACAO).
• Tabela ALUGUEL
Campos
Tabela 3.2: Campos Tabela ALUGUEL.

pk nome tipo tam. prec. val. padrão incremento bin
x id integer 11 0 x
id_filme bigint 5 0
id_cliente bigint 7 0
data date 0 0
valor decimal 5 2
Chaves Estrangeiras
36
Tabela 3.3: Chaves Tabela ALUGUEL.

campo banco fk tabela fk campo fk ao atualizar ao deletar
id_filme netflix filme ID restrict restrict
id_cliente netflix cliente ID restrict restrict
ID - Um campo auto-incremental do tipo INTEGER (exigência do MySql), identifica o

aluguel do filme.
ID_FILME - Tipo BIGINT que referencia o ID da tabela FILME, por exigência do
Mahout, o ID do filme deve ser do tipo BIGINT, então a chave estrangeira para a tabela
FILME deve ser do mesmo tipo.
ID_CLIENTE - Tipo BIGINT que referencia o ID da tabela CLIENTE, por exigência do
Mahout, o ID do cliente deve ser do tipo BIGINT, então a chave estrangeira para a tabela
CLIENTE deve ser do mesmo tipo.
DATA - Tipo DATE, que recupera somente a data sem a hora no formato “dd/mm/aaaa”
VALOR - Tipo DECIMAL com duas casas decimais para representação realista da subu-
nidade centavo.
• Tabela AVALIACAO
Campos
Tabela 3.4: Campos Tabela AVALIACAO.

x id_filme bigint 5 0
x id_cliente bigint 7 0
avaliacao float 0 0
data date 0 0
Chaves Estrangeiras
Tabela 3.5: Chaves Tabela AVALIACAO.

campo banco fk tabela fk campo fk ao atualizar ao deletar
id_filme netflix filme ID restrict restrict
id_cliente netflix cliente ID restrict restrict
ID_FILME - Tipo BIGINT que referencia o ID da tabela FILME, por exigência do

Mahout exigir o ID do filme deve ser do tipo BIGINT, então a chave estrangeira para
a tabela FILME deve ser do mesmo tipo.
ID_CLIENTE - Tipo BIGINT que referencia o ID da tabela CLIENTE, por exigência do
Mahout, o ID do cliente deve ser do tipo BIGINT, então a chave estrangeira para a tabela
CLIENTE deve ser do mesmo tipo.
AVALIACAO - Tipo FLOAT por exigência do Mahout.
37
VALOR - Tipo DECIMAL com duas casas decimais para representação realista da subu-
nidade centavo.
DATA - Tipo DATE, que recupera somente a data sem a hora no formato “dd/mm/aaaa”
• Tabela CLIENTE
Campos
Tabela 3.6: Campos Tabela CLIENTE.

x id bigint 7 0 x
nome varchar 50 0
senha varchar 10 0
email varchar 50 0
Chaves Estrangeiras
N/A
ID - Tipo BIGINT por exigência do Mahout.
NOME - Tipo VARCHAR, que armazena somente a quantidade de caracteres que forem
utilizadas, descartando espaços extras no momento do armazenamento, ganhando assim
maior dinamicidade quanto ao espaço gasto em disco.
SENHA - Tipo VARCHAR, que armazena somente a quantidade de caracteres que forem
EMAIL - Tipo VARCHAR, que armazena somente a quantidade de caracteres que forem
• Tabela FILME
Campos
Tabela 3.7: Campos Tabela FILME.

x id bigint 5 0
ano integer 4 0
filme varchar 110 0
preco decimal 5 2
Chaves Estrangeiras
N/A
ID - Tipo BIGINT por exigência do Mahout.
ANO - Tipo INTEGER com quatro posições para o ano.
38
FILME - Tipo VARCHAR, que armazena somente a quantidade de caracteres que forem
PRECO - Tipo DECIMAL com duas casas decimais para representação realista da subu-
nidade centavo.
Domínio, Obrigatoriedade e Unicidade
Tabela 3.8: Tabela ALUGUEL.

campo unidade índice domínio
id x x
id_filme x
id_cliente x
data
valor
Tabela 3.9: Tabela AVALIACAO.

id_filme x x
id_cliente x x
avaliacao
data
Tabela 3.10: Tabela CLIENTE.

id x x
nome
senha
email
Tabela 3.11: Tabela FILME.

id x x
ano
filme
preco
Projeto de Índices
Os índices foram definidos sobre a restrição PRIMARY KEY e UNIQUE especificadas na cri-
ação da tabela (comando CREATE TABLE)
39
O Mecanismo de banco de dados do MySql cria automaticamente um índice exclusivo para

forçar os requisitos de exclusividade de uma restrição PRIMARY KEY ou UNIQUE. Por pa-
drão, um índice clusterizado exclusivo é criado para forçar uma restrição PRIMARY KEY e um
índice não clusterizado exclusivo é criado para forçar uma restrição UNIQUE.
3.8 Projeto da Interface Gráfica

A interface gráfica de um site a ser acessado por um público alvo muito diversificado, como
sites de venda, ou neste caso, locação de filmes, deve ser:
• Intuitiva, isto é, a combinação de cores, o posicionamento, ícones, textos e navegação do

site devem deixar claro sua intenção, seu conteúdo, seu objetivo;
• Leve, ou seja, sem abusar das cores, sem muitas animações, sem muitos gráficos, que
sejam transmitidas e carregadas no navegador do usuário de forma rápida, independente
da velocidade da conexão que esteja utilizando;
• Acessível, de modo a permitir que, mesmo pessoas com deficiências visuais sejam capa-
zes de efetuar suas compras, mesmo pessoas com pouca experiência no uso de compras
online consigam efetuar o processo de forma simples.
Nas seções a seguir alguns padrões utilizados no sistema são apresentados. Na Seção 3.8.1
detalhes referentes a hierarquia e organização das páginas do projeto. A Seção 3.8.2 aborda
detalhes referentes a padronização dos elementos que compõem as páginas, imagens e botões,
por exemplo.
3.8.1 Hierarquia das Telas e Mapa de Navegação

O projeto ficou, ao final de sua feitura, com suas telas seguindo a hierarquia que pode ser
visualizada na figura 3.17:
Figura 3.17: Hierarquia de telas do site.
Na figura 3.18 observa-se o mapa de navegação do sistema.

40
Figura 3.18: Mapa de navegação do site.
O site está estruturado de forma simples ao ponto do usuário encontrar o que necessita em
poucos segundos, sempre com poucos cliques.
Buscou-se a primazia pela simplicidade e facilidade no acesso de todas as telas do sistema
através de seus ícones e botões auto-explicativos, mais detalhes sobre ícones e botões na Seção
3.8.2. O usuário contará ainda com o auxílio de uma barra de navegação exibida na parte
superior esquerda.
Os elementos comuns a várias telas e indispensáveis a navegação no site são descritas a
seguir:
• Barra de Navegação - Na parte superior esquerda é possível encontrar a barra dinâmica de

navegação que, a cada página, exibe a hierarquia das telas, e possibilita navegação entre
a página atual e a página de nível superior na hierarquia, conforme pode ser observado
na figura referente a hierarquia de telas. O uso da barra de navegação é primordial para
auxiliar a navegação do usuário no site, tornando mais ágil o acesso a páginas de nível
superior a utilizada.
• Busca - No canto superior direito, é possível, a partir de qualquer tela a realização de

busca pelo nome de um filme qualquer, ou parte dele. Tal elemento é primordial, pois
permite ao usuário encontrar com agilidade o que o procura.
• LogOut - No canto esquerdo, através do ícone “Sair”, após o usuário ter se identificado,
é possível, a partir de qualquer tela que o usuário encerre a sua sessão. Um fator im-
portante para segurança das informações do usuário é a utilização do botão “Sair”, com
seu uso é possível evitar que informações fiquem armazenadas na seção, tais informações
poderiam, por exemplo, ser acessadas por outras pessoas mal intencionadas que utilizem
o mesmo equipamento. Após a realização do Logout, o usuário é direcionado para a tela
Índice.
Nas próximas seções, é apresentado o detalhamento de cada tela da hierarquia do site.
Índice
Descrição: Esta tela é de grande importância para o site, afinal é a fachada da loja e deve
identificá-la visualmente, sem comprometer a navegabilidade e a localização de todos os links
de interesse do internauta. O usuário poderá então navegar pelo site com a finalidade de escolher
quais filmes deseja alugar, mas não poderá fechar o pedido (somente usuários identificados). Por
41
isso, buscou-se simplicidade e facilidade de navegação do site para uma confortável escolha dos
filmes por parte dos usuários, no acesso de usuários já cadastrados e no acesso ao cadastro de
novos usuários do site.
Acessa: Conta, Índice (Após Login) e Carrinho.
Acessada por: Conta, Índice (Após Login), Carrinho e Pagamento.
Conta
Descrição: É a tela de cadastro de novos usuários no site, onde são solicitadas informações
básicas e obrigatórias sobre o usuário. Neste projeto não há necessidade de maiores informações
(sexo, idade, cidade, bairro, etc) sobre o usuário, visto que a recomendação se dá baseada na
avaliação que o usuário fornece aos filmes e não pelo perfil do mesmo (sexo, idade, cidade,
bairro, etc).
Acessa: Índice. Para que uma vez efetuado o cadastro, possa retornar ao índex para realizar
o Login.
Acessada por: Índice. Para que usuários não cadastrados possam realizar seu cadastro.
Índice (Após o Login)

Descrição: Consiste na mesma tela (Índice), porém somente vista por usuários identificados
com sucesso (usuários previamente cadastrados na tela Conta). Nesta tela, encontra-se a reco-
mendação de filmes (baseadas no framework Apache Mahout) de uma forma clara (com itens
bem posicionados) e objetiva (com uma interface simples), no qual se pode através do ícone
de um carrinho abaixo da capa do filme, adicioná-lo ao “Meu Carrinho”. Após a escolha dos
filmes, pode-se então dar continuidade ao aluguel do mesmo acessando o “carrinho” através da
imagem na parte superior direita da tela.
Acessa: Índice e Carrinho.
Acessada por: Índice, Carrinho e Pagamento.
Carrinho
Descrição: É a tela onde constam todos os filmes previamente selecionados (para serem aluga-
dos). Nesta tela é apresentada a opção de voltar a página inicial para que se possam adicionar
novos filmes ao “Carrinho de Compras”. Após escolhidos todos os filmes desejados a alugar,
pode-se finalizar a solicitação de compra através do link “Fechar Pedido”.
Acessa: Índice, Índice (Após Login) e Pagamento.
Acessada por: Índice (Após Login) e Pagamento.
Pagamento
Descrição: É a tela na qual será realizado pagamento sobre o valor total dos filmes constantes
no “Carrinho de Compras”. Nesta tela encontram-se as formas de pagamento, selecionando-se
uma, pode-se realizar o pagamento através do botão “Pagar”. A funcionalidade do pagamento
não foi implementada, pois foge do âmbito do projeto.
Acessa: Índice, Carrinho e Índice (Após Login).
Acessada por: Carrinho.
42
3.8.2 Padronização de Botões, Ícones e Outros Atalhos

Nesta seção são descritos os padrões usados para cores, tamanho de fontes nos títulos dos
formulários, significados dos ícones utilizados, etc.
Facilidade de leitura significa empregar cores, fontes e tamanhos dos ícones nas páginas para
que não prejudiquem a leitura do texto até mesmo para quem possua algum tipo de deficiência
visual.
Foi aplicado contraste entre a cor de fundo do site e a cor das letras, de forma que não se
confunda com o texto ou se torne cansativa a leitura. Fonte de texto escura sobre um fundo
claro é mais fácil de ser visualizada. A partir desse princípio, a cor branca foi utilizada como
pano de fundo do site, junto a letras pretas.
Fontes exageradamente grandes podem quebrar a estrutura do site, sobrepondo outros tex-
tos e imagens ou desorganizando o texto na tela, fontes muito pequenas podem prejudicar a
leitura. Com isso, foi utilizada fonte “Arial” com tamanho quatorze. Tal fonte é padrão nos
sistemas operacionais Windows, Linux e MacOS, evitando assim que usuários de tais sistemas
operacionais não consigam visualizar os textos contidos no site.
A logo marca “AlugOnline” é simples contudo seu tamanho (592x109 pixels) a faz chama-
tiva, com intuito de que o usuário grave nosso nome para que em um momento futuro possa se
lembrar do nome do site e acessá-lo mais vezes, realizando novos alugueis.
Com um layout prático e de fácil entendimento alcançou-se boa usabilidade no site, pensada
para que facilite a vida do usuário na navegação. O conteúdo foi estruturado pensando nas
necessidade dos usuários, tentando tornar as telas intuitivas o suficiente.
Foram utilizados os mesmos padrões de grandes sites de vendas como Submarino e Ameri-
canas, por exemplo.
Alguns dos padrões empregados, que visam a usabilidade do site, permitindo que o usuário
encontre o que deseja mais facilmente, abrangem:
• Posicionamento de todos os componentes do site;
• Pesquisar - Canto superior direito do site
• Lista de Filmes - Centro do site
• Barra de Navegação - Lado esquerdo, abaixo da Logo do site
• Meu Carrinho - Lado direito do site
• Background da página: branco
• Background do Banner: Azul
• Banner AlugOnline
• Fonte: Arial
• Tamanho da Fonte: 14
• Cor da Fonte: Preta
• Pesquisa (para usuários identificados)
Segue a descrição e o significado de cada ícone utilizado e em que tela o mesmo pode ser
encontrado.
43
Pesquisa
Imagem:
Significado: Realiza busca do filme.
Descrição: O ícone de lupa é largamente encontrado em vários sites, sempre relacionado
ao sistema de buscas, até mesmo nos sistemas operacionais, como Windows. Com isso, tal
imagem é sempre associada a função de buscas.
Tamanho: 29x26 pixels.
Tela onde é encontrado: Índice, Índice (Após o Login), Carrinho e Paymment.
Adicionar Filme
Imagem:
Significado: Adiciona o filme ao qual se refere ao Carrinho de Compras.
Descrição: O ícone do carrinho, na proximidade de um item de compra (no caso, um filme)
é largamente encontrado em vários sites de comércio eletrônico. Com isso, tal imagem é difun-
dida como um método de adicionar o item ao qual se refere ao “carrinho de compras”.
Tela onde é encontrado: Índice (Após o Login).
Remover Filme
Imagem:
Significado: Remove o filme ao qual se refere do “carrinho de compras”.
Descrição: O ícone do carrinho com um “x” em vermelho na proximidade de um item de
compra (no caso, um filme) é largamente encontrado em vários sites de comércio eletrônico.
Com isso, tal imagem é difundida como um método de remover o item ao qual se refere do
“carrinho de compras”.
Tela onde é encontrado: Carrinho.
Meu Carrinho
Imagem:
Significado: Acessa a tela Carrinho, onde encontram-se todos os filmes escolhidos pelo
usuário.
Descrição: O ícone do carrinho de compras é uma forma de acesso ao “Meu Carrinho”.
Tamanho: 48x48 pixels. O ícone do Meu Carrinho é maior que os ícones Adicionar Filme
e Remover Filme por se tratar de acesso a uma página e não estar vinculado a uma imagem,
como em Adicionar Filme está associado à imagem da capa de um filme.
Tela onde é encontrado: Índice (Após o Login).
Formas de pagamento
Imagens:
44
Significado: Forma de pagamento.

Descrição: São as formas de pagamento oferecidas. Possui uma legenda abaixo da imagem
que traduz a bandeira do cartão, ou o boleto.
Tamanho: 60x50 pixels. Cada uma.
Tela onde são encontradas: Pagamento.
Botão Entrar
Imagem:
Significado: Realizar “login” do usuário.
Descrição: Este botão é acionado quando o usuário tenta realizar o “login”.
Tela onde é encontrado: Índice.
Botão Sair
Imagem:
Significado: Realizar “logout” do usuário.
Descrição: Este botão é acionado quando o usuário deseja encerrar sua sessão.
Tela onde é encontrado: Índice (Após Login), Carrinho e Pagamento.
Botão Fechar Pedido

Imagem:
Significado: Fecha o pedido dos itens existentes no carrinho.
Descrição: Este botão é acionado quando o usuário deseja realizar pagamento dos itens
constantes no carrinho.
Tela onde é encontrado: Carrinho.
Botão Pagar
Imagem:
Significado: Realizar pagamento dos itens constantes no carrinho.
Descrição: Este botão é acionado quando o usuário deseja encerrar o seu pedido.
Tela onde é encontrado: Pagamento.
45
Capítulo 4
Aspectos de Implementação
Após todo o processo de levantamento de requisitos a equipe começou a buscar soluções aos
problemas e respostas às questões levantadas. O primeiro problema e sua respectiva questão
foram, gerenciamento, como gerenciar um projeto de forma simples, rápida e eficiente.
Se tratando de um projeto bem grande em relação aos já criados pela equipe, imaginou-
se uma forma simples de gerenciar minimamente o projeto. A alternativa encontrada foi o
uso do programa XMind1 , em sua versão 3.2.0. Tal programa permite o gerenciamento visual
através de um “mapa mental”, exibindo as tarefas a realizar e sobre as quais podem ser aplicadas
diferentes cores.
A figura 4.1 mostra o mapa de um determinado momento do projeto, observem-se as cores:
verde, significando tarefa completa ou em estágio avançado, amarelo significando que a tarefa se
encontra em andamento mas ainda não passou por revisão do orientador, vermelho significando
tarefa não iniciada ou em estágio inicial.
Figura 4.1: Mapa mental utilizado para gerência do projeto.
O uso de tal ferramenta foi de grande valia para observar pontos a serem atacados e obje-
tivos a serem alcançados durante o projeto. Permitindo gerenciamento eficaz mas sem grande
dispêndio de tempo.
1
www.xmind.net
46
Sabendo o que fazer e como gerenciar o próximo passo foi o da descoberta de como alcançar
os objetivos da equipe, a próxima pergunta foi então, que ferramentas podem apoiar a feitura
do projeto.
A ferramenta utilizada na modelagem do sistema foi a astah*2 , versão 6.2.1 para comuni-
dade, permitindo a feitura de todos os diagramas UML constantes neste projeto, tais diagramas
são de grande importância pois permitem a transmissão do conhecimento sobre a estrutura
deste.
Como ponto inicial existia o requisito de um sistema com suporte a acesso através da In-
ternet, um sistema de comércio online. Foi decidido o uso da linguagem Java para desenvolvi-
mento do projeto, por se tratar de uma linguagem cuja API atenderia a todas as necessidades
levantadas e que possui possibilidade de desenvolvimento voltado para Web.
Para apoiar a tarefa do desenvolvimento selecionamos a IDE Eclipse3 , versão Helios SR1.
Se trata de uma IDE gratuita e leve, não exigindo computador muito potente para seu uso. Não
precisa ser instalada, basta descompactar e começar a utilizar, o que facilita seu uso mesmo em
ambientes corporativos onde o usuário é impossibilitado de instalar programas.
Como SGDB utilizamos o MySQL, contudo optamos por utilizar o programa XAMPP4 , em
sua versão 1.7.3, tal programa traz a instalação e apresenta interface de gerenciamento para os
programas Apache (Web Server) e MySQL, dentre outros, o que facilita a utilização de tais
ferramentas.
Com todo o ambiente de desenvolvimento pronto o sistema que dá suporte ao site de aluguel
de filmes foi desenvolvido paralelamente ao programa que fornece recomendações. Apesar do
primeiro ser bem maior que o segundo, seu desenvolvimento e refinamento levou mais tempo,
muito por conta da utilização de um framework que nenhum dos componentes do grupo havía
utilizado anteriormente, o Apache Mahout, mas também muito por conta da documentação
deficiente deste, assim, foram necessárias muitas pesquisas e muito esforço.
Na feitura da monografia foi utilizado o Microsoft Word 2010, com o objetivo de facilitar a
difícil tarefa de eliminar erros de escrita, contudo a edição final do trabalho foi feita utilizando
ferramentas padrão LATEX, de modo a oferecer maior qualidade visual.
Facilitando a feitura e gerenciamento das referências bibliográficas foi utilizado o ZO-
TERO5 , uma ferramenta gratuita, fácil de utilizar que ajuda a coletar, organizar, fazer citações
e compartilhar fontes de pesquisa. Funciona acoplado, como um plugin, para o navegador Fi-
reFox permitindo que sejam coletadas referências bibliográficas de sites, livros, etc. Possui
também conexão com o Microsoft Word permitindo gerenciamento e formatação automática da
Seção de Referências Bibliográficas, permite também exportação de arquivo de referências no
padrão LATEX.
O relato do processo de desenvolvimento dos artefatos de software é apresentado nas pró-
ximas seções. A Seção 4.1 relaciona a sequência de desenvolvimento do sistema, fornecendo
uma visão de análise e projeto do sistema. Já na Seção 4.2 observa-se uma visão mais técnica
do sistema, apresentando tecnologias envolvidas, frameworks, e descrição do código envolvido
na realização dos casos de uso. Finalmente a Seção 4.3 descreve de que forma todo este sistema
deve ser organizado e apoiado de forma a servir ao seu propósito.
2
astah.change-vision.com
3
www.eclipse.org
4
www.apachefriends.org
5
www.zotero.org
47
4.1 Estratégia de Implementação

Para o processo de desenvolvimento do sistema foi utilizada a estratégia do Processo Unificado,
como descrito em [19], cada caso de uso foi desenvolvido com qualidade de entrega do iní-
cio ao fim, em pequenas interações, com única exceção feita à interface, a qual, inicialmente,
não apresentou refinamentos de folhas de estilo (CSS - Cascading Style Sheets) ou imagens,
gerando todas as classes e métodos necessários para implementar as funcionalidades, optou-se
por melhorar a aparência do site após todo o projeto em funcionamento.
Todo o processo foi facilitado pelo uso do VRaptor6 , um framework MVC Java para Web fo-
cado em desenvolvimento rápido. Desenvolvido pela Caelum7 e mantido por uma comunidade
de desenvolvedores.
O passo inicial foi baixar, do site do VRaptor, o “vraptor-blank-project.zip”, um arquivo
compactado contendo um projeto estruturado e todas as dependências, pronto para iniciar o
desenvolvimento.
Iniciando o processo por montar a tela inicial e suas funcionalidades, a primeira a ser de-
senvolvida foi a de busca, montado o formulário na página, foi criado o referente controlador
que recebe as requisições e faz com que estas sejam respondidas e então o código de acesso a
dados. Neste ponto tivemos de adicionar as bibliotecas do Hibernate8 , um framework de código
aberto, para persistência de dados, o qual efetua o mapeamento objeto-relacional. O modelo de
classes foi feito de forma a refletir não só a base de dados, mas também o domínio do problema.
Com a funcionalidade de pesquisa funcionando o próximo passo foi a feitura do “carrinho
de compras”, com as funcionalidades de adicionar e remover itens deste. A apresentação do nú-
mero de itens constantes no carrinho foi alcançada através do uso de “interceptors”, figuras que
fazem parte do desenvolvimento utilizando o VRaptor, permitem “interceptar” uma requisição
antes que alcance o “controller” de destino, permitindo grande flexibilidade no tratamento das
requisições.
Logo depois foram desenvolvidas todas as funcionalidades relativas a identificação e regis-
tro do usuário, que permitem, respectivamente, usuários registrados obterem acesso a partes
restritas do sistema, e o registro de novos usuários. A funcionalidade da apresentação do nome
do usuário enquanto da navegação e de acesso à páginas restritas também foram alcançadas
através do uso de “interceptors”.
A funcionalidade de alugar filmes foi feita de modo um pouco diferente, iniciando a partir da
base de dados. Como dados de aluguel não estavam disponíveis na base de dados do NetFlix,
foi necessário criar uma tabela no banco de dados. Foram criadas as classes necessárias e
a modelagem do negócio efetuando o mapeamento objeto-relacional, o controlador e todo o
conteúdo necessário à página.
O envio de e-mail confirmando o aluguel de filmes ao usuário foi a parte mais complexa
do sistema de comércio eletrônico. Sem experiência no assunto, foi necessário pesquisar e
entender a API de modo que fosse possível o envio de e-mails. Foi criada uma conta de e-mail
no Gmail, que cumpre o papel de servidor de e-mail.
Trabalhando em um projeto à parte e com base de dados reduzida, o código fonte que gera
as recomendações apesar de complicado à primeira vista, é pequeno, em verdade possui menos
de vinte linhas. Ainda que pequeno e já totalmente compreendido, verificado e revisado não
gerava recomendações, nem mesmo erros, simplesmente não terminava a execução.
Depois de muitas pesquisas e várias revisões no código fonte, veio a conclusão de que este
6
vraptor.caelum.com.br
7
www.caelum.com.br
8
www.hibernate.org
48
estaria correto e o provável erro se encontraria na base de dados. Tipos de dados incorretos e
restrições impostas pelo framework faziam com que as recomendações nunca fossem geradas.
Tendo ambos os sistemas em funcionamento era possível decidir por manter ambos como
serviços separados, contudo, com o intuito de reduzir complexidade, estes foram acoplados, e
o sistema de comércio eletrônico agora conta também com recomendações.
4.2 Descrição da Arquitetura da Aplicação

Esta Seção tem o intuito de fornecer dados acerca da arquiteturra da aplicação desenvolvida.
Mas, o que é a arquitetura de uma aplicação? Roy Fielding, em [2], define como uma abstração
dos elementos de software de um sistema durante alguma fase de sua operação. Diz ainda
que um sistema pode ser composto de muitos níveis de abstração, cada qual com sua própria
arquitetura.
O Instituto de Engenharia de Software da Universidade de Carnegie Mellon apresenta em [7]
diferentes definições, algumas clássicas e bastante conhecidas, como “arquitetura é a estrutura
do sistema, composta de componentes, as propriedades que são visíveis externamente desses
componentes e o relacionamento entre eles”.
Nas palavras de Martin Fowler em [3], o termo arquitetura envolve a noção dos principais
elementos do sistema, as peças que são difíceis de mudar. Uma fundação sobre a qual o resto
precisa ser construído. Fowler reformula sua definição de arquitetura em [9] e a define como
“a peça que as pessoas acham que é difícil de mudar”. No mesmo artigo Ralph Johnson, do
GoF, diz que arquitetura “é o conjunto de decisões de design que gostaríamos de ter feito no
começo do projeto” e termina com uma definição mais abrangente: “arquitetura é tudo aquilo
que importa”, tentando diferenciar arquitetura de design.
Tendo em mente as definições apresentadas para “Arquitetura de Aplicação”, exibe-se, a
seguir, alguns dados considerados relevantes para a compreensão de como foi montado o sis-
tema, que partes o compõem e como tais peças foram “encaixadas” para que se obtivesse um
funcionamento harmônico entre elas.
Para o desenvolvimento do sistema referente a este projeto foi escolhida a tecnologia Java.
Esta é tanto uma linguagem de programação como uma plataforma. A linguagem de progra-
mação é de alto nível orientada a objetos. A plataforma é um ambiente em particular no qual a
linguagem de programação é executada.
A plataforma Java Enterprise Edition (JEE) consiste em uma máquina virtual, a JVM (Java
Virtual Machine), e em uma API (Aplication Programming Interface). A máquina virtual é
um programa, para uma plataforma de hardware e software em particular, o qual permite a
execução de aplicações Java. Uma API é uma coleção de componentes de software que podem
ser utilizadas para criar outros componentes de software e/ou aplicações.
A API Java Standard Edition (Java SE) provê as funcionalidades básicas da linguagem de
programação Java. Define tudo, desde tipos básicos e objetos da linguagem de programação a
classes de alto nível que são utilizadas para trabalho com redes, segurança, acesso a banco de
dados, interface gráfica de usuário (GUI - Graphical User Interface), dentre outras funciona-
lidades. Além disso a plataforma Java SE consiste de uma máquina virtual, ferramentas para
desenvolvimento, e outras bibliotecas utilizadas na tecnologia Java.
Sobre a plataforma Java SE foi construída a plataforma Java Enterprise Edition (Java EE),
tal plataforma provê uma API e um ambiente de tempo de execução para aplicações de rede
com larga escalabilidade, multi camadas, escaláveis e seguras. Como um nome curto para tais
aplicações existe o termo “Aplicações Empresariais” (Enterprise Applications), assim chamadas
pois tais aplicações resolvem problemas encontrados por grandes empresas.
49
Aplicações em camadas, onde as funcionalidades da aplicação são separadas em áreas fun-

cionais isoladas, chamadas camadas, tipicamente possuem uma camada do cliente, uma camada
central e uma camada de dados.
A camada cliente consiste em um programa que efetua requisições a camada central. As
funções de negócio da camada central lidam com as requisições vindas das aplicações clientes
e processam dados da aplicação.
Java EE é uma plataforma que se concentra em tornar mais fácil o desenvolvimento de
aplicações empresariais, além de torná-las mais robustas e seguras.
As seguintes tecnologias são utilizadas na camada Web, em aplicações Java EE:
• Servlets - Classes da linguagem de programação Java que, processam dinamicamente,

requisições e constroem respostas.
• JavaServer Pages (JSP) - Documentos em formato texto compilados em Servlets e de-

finidos como conteúdo dinâmico, pode ser adicionados em páginas estáticas tais como
páginas HTML.
• JavaServer Faces - Uma tecnologia que provê um framework com interface para usuá-
rio para aplicações Web que permite inclusão de componentes gráficos em uma página,
dentre outras funcionalidades.
• JavaServer Faces Facelets - Aplicações Facelets são um tipo de aplicação JavaServer

Faces que utiliza páginas XHTML ao invés de páginas JSP.
• Expression Language - Um conjunto de marcações utilizadas em páginas JSP e páginas

Facelets para referenciar componentes Java EE.
• JavaServer Pages Standard Tag Library - Uma biblioteca de marcações que encapsula
funcionalidades básicas comuns a páginas JSP.
• JavaBeans - Objetos que atuam como armazenadores de dados temporários para as pági-
nas de uma aplicação.
A camada de negócios consiste em componentes que proveem a lógica de negócios para

uma aplicação. Lógica de negócio é código que provê funcionalidade para um domínio de
negócio em particular, como na indústria financeira, ou um site de comércio eletrônico. Em
uma aplicação devidamente projetada, a funcionalidade principal existe nos componente da
camada de negócios.
As tecnologias Java EE utilizadas na camada de negócios são:
• Enterprise JavaBeans;
• JAX-RS RESTful web services;
• JAX-WS web services endpoints e
• Java Persistence API.
Das tecnologias citadas foram utilizadas no projeto: JavaServer Pages, Expression Lan-
guage, JavaServer Pages Standard Tag Library (JSTL) e Java Persistence API.
A proposta inicial para o conceito Model View Controller (MVC) data de 1974. No MVC
a aplicação fica subdividida em três componentes, modelo (Model), visão (View) e controle
50
(Controller). Hoje o MVC é um padrão de projeto que faz parte do catálogo PoEAA, como
pode ser visto em [16].
A ideia por trás do MVC é fazer uma divisão clara entre objetos de domínio, que modelam
nossa percepção sobre o mundo real, e objetos de apresentação, que são os elementos gráficos
que vemos na tela.
No MVC os elementos de domínio são referenciados como o modelo. Objetos de modelo
ignoram a existência da interface do usuário. Esse componente provê operações para que o
restante da aplicação possa manipulá-lo.
A camada da apresentação no MVC é feita dos dois elementos restantes, a visão e o con-
trolador. O trabalho do controlador é receber as entradas do usuário e saber o que fazer com
estas.
Uma aplicação pode possuir diferentes visões de um mesmo modelo, por exemplo uma visão
de edição, uma visão de impressão e uma visão de seleção. Adicionalmente, cada visão possui
a ela associada um controlador, que auxilia na implementação da interface gráfica associada a
visão.
Na construção do sistema foi utilizado o modelo MVC um pouco modificado, ao invés de
um controlador para cada interface do usuário, para cada conceito do sistema foi utilizado um
controlador diferente, com isso temos um controlador para o “carrinho de compras”, um para
ações relacionadas a filmes e um para ações referentes a usuários.
Como pode ser observado no trecho de código 4.1, os controladores utilizados possuem
visão sobre o modelo (linhas 3 e 13), para onde efetuam requisições no esforço de atender
solicitações dos usuários, e sobre a camada de visão (linha 14), para onde enviam dados. Atente
também para o uso da anotação @Resource (linha 1) referente ao framework VRaptor, que
permite que a classe disponibilize seus métodos a requisições de usuários.
1 @Resource
2 public class CartController {
3 private final CartRepository cartRepository;
4 private final Result result;
5 private final Sys sys;
6 public CartController(CartRepository cartRepository,
7 Result result, Sys sys) {
8 this.cartRepository = cartRepository;
9 this.result = result;
10 this.sys = sys;
11 }
12 ...
13 public void filmList() {
14 result.include("filmList", cartRepository.getFilms());
15 result.forwardTo(sys.getCartPage());
16 }
17 ...
18 }
Algoritmo 4.1: Trecho do controlador de carrinho.
Pode-se observar em 4.2 que a camada de visão possui dependência em relação a tipos de
dados do modelo (linha 10), os quais recebe dos controladores, sem contudo efetuar troca de
mensagens diretamente com o modelo. No trecho de código pode-se observar também o uso
de HTML (linhas 12 e 16), Expression Language (linhas 8, 10 e 13) e Standard Tag Library
(linhas 8 e 10) na feitura da página JSP.
51
1 <%-- IMPORTS --%>

2 <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
3 ...
4 <%-- constantes do sistema --%>
5 <jsp:useBean id="sys" class="br.cefetrj.alugonline.Sys"
6 scope="application"/>
7 ...
8 <c:forEach items="\${filmeList}" var="filme">
9 ...
10 <c:out value="\${filme.nome}"/>
11 ...
12 <img alt="carrinho"
13 src="<c:url value="\${sys.imagesDirectory}"/>cart.gif"
14 />
15 ...
16 </html>
Algoritmo 4.2: Trecho de index.jsp.
Observe-se que não existem caminhos ou nomes de arquivos no código do controlador ou

da página JSP, em outras palavras, não existem strings hard-coded, tudo foi codificado em uma
classe, Sys.java que busca dados em um arquivo de propriedades. Tal classe é importada na
visão (linhas 5 e 6 em 4.2 e recebida por injeção de dependência (efetuada pelo framework
VRaptor), através do método construtor do controlador (linha 7 em 4.1).
A camada de modelo recebe solicitações dos controladores e lhes retorna dados. Como
exemplo vemos o código em 4.3, onde temos, na linha 8, um método que permite que a classe
receba uma solicitação de carregar um filme, dada sua identificação, e delega tal solicitação a
classe que possui tal função, no caso a FilmeDAO.
Podemos ainda observar no código 4.3, na linha 1, o uso da anotação @Component referente
ao framework VRaptor. O uso de tal anotação permite que a classe anotada venha a ser utilizada
em injeção de dependências, para alguma classe que desta dependa.
1 @Component
2 public class FilmeRepository {
3 private final FilmeDAO dao;
4 public FilmeRepository(Session session) {
5 this.dao = new FilmeDAO(session, Filme.class);
6 }
7 ...
8 public Film load(Long id) {
9 return dao.load(id);
10 }
11 ...
12 }
Algoritmo 4.3: Trecho da classe FilmeRepository.
Para a implementação das camadas de Model e Controller foi utilizado o framework VRap-
tor, em substituição ao uso de Servlets. Tal framework utiliza os conceitos de injeção de depen-
dência, inversão de controle e POJOs, sendo extremamente flexível, ao permitir o uso de outros
frameworks, sem restringir ou amarrar a nenhuma tecnologia específica. É pouco intrusivo, ao
usar anotações e o conceito de COC (Convention Over Configuration - convenção acima de
52
configuração), no qual se prega que, ao seguir as convenções do framework utilizado não é ne-
cessário efetuar configurações, em outras palavras, só é necessário efetuar alguma configuração
quando não for seguida a convenção do framework.
A injeção de dependências é efetuada através dos construtores das classes, como foi possí-
vel ver em 4.1, bastando para isso que a dependência necessária para o funcionamento da classe
seja informada no método construtor desta. O VRaptor, ao “perceber” a dependência, se en-
carrega de criar uma instância do objeto necessário e passar ao construtor da classe. As classes
referentes às dependências precisam apresentar a anotação @Component do VRaptor para que
tudo funcione corretamente, como pode-se ver em 4.3.
Na camada de visão, ou seja, na feitura das páginas, foram utilizadas as tecnologias HTML
4, JSP, JSTL 1.2, Expression Language e CSS.
Para a camada de controle foram utilizadas classes comuns Java, com a anotação @Resource
do VRaptor, isso faz com que os métodos da classe fiquem disponíveis externamente através da
URL, no formato /aplicação/classe-controller/método/.
Na camada de modelo foram criadas diversas classes que servem de fachada para seus res-
pectivos objetos de domínio e classes de persistência, aplicando, desta forma, o padrão de pro-
jeto “Repository” (repositório).
A classe fachada recebe requisições da camada de controle ou de outras classes de fachada
e as repassa para classes de domínio do negócio e para classes que efetuam a persistência de
dados. Recebem a anotação @Component do VRaptor para que possam ser utilizadas através
de injeção de dependência onde forem necessárias.
As classes de persistência de dados, classes DAO (Data Access Object - objeto de acesso a
dados) também recebem a anotação @Component do VRaptor, são utilizadas através de injeção
de dependência nas classes fachada. São utilizadas para recuperar os dados, ou coleções de
dados, de maneiras, formatos, ordem, ou com critérios específicos.
DAO é um padrão do catálogo JEE, utilizado para abstrair e encapsular todos os acessos a
fonte de dados. O DAO gerencia a conexão com a fonte de dados para obtenção e armazena-
mento de dados. Comandos e configurações podem variar para cada banco de dados, com o
uso do DAO expõe-se uma interface independente do SGDB utilizado, escondendo detalhes da
implementação de acesso aos dados aos clientes.
Em 4.4 vemos uma classe DAO utilizada no projeto. Um fato importante é a não utilização
de SQL, ao invés disso utilizam-se métodos referentes a classes do framework Hibernate.
1 @Component
2 public class FilmDAO extends DAO<Film> {
3
4 public FilmDAO(Session session,
5 Class<Film> persistentClass) {
6 super(session, persistentClass);
7 }
8 public Lis find(String searchString) {
9 Criteria criteria = session.createCriteria(Film.class);
10 criteria.add(Restrictions.ilike("name", searchString, MatchMode.
ANYWHERE));
11 return criteria.list();
12 }
13 }
Algoritmo 4.4: Classe FilmeDAO.

53
Classes de mapeamento objeto-relacional de dados recebem anotações diversas, específicas

do framework Hibernate. Não fossem as anotações seriam POJOs, simples classes Java, como
pode ser observado em 4.5.
1 @Entity
2 @Table(name = "filme")
3 public class Filme implements Serializable {
4 private static final long serialVersionUID = 6L;
5 @Id
6 private Long id;
7 @Column(name = "ANO")
8 private Long ano;
9 ...
10 public Long getId() {
11 return id;
12 }
13 public void setId(Long id) {
14 this.id = id;
15 }
16 ...
17 }
Algoritmo 4.5: Trecho da classe Filme.
Hibernate é uma biblioteca de código livre de mapeamento objeto relacional (Object Relati-
onal Mapping - ORM) para a linguagem Java. Permite o desenvolvimento de classes persisten-
tes seguindo o “idioma” Java, incluindo associação, herança, polimorfismo, composição e uso
de coleções.
Mapeamento objeto relacional trata do esforço em se resolver as diferenças entre o para-
digma de orientação a objetos e o armazenamento de dados no modelo relacional, este pro-
blema também é conhecido como “descasamento de impedância” (impedance mismatch [8]).
Não existe somente uma diferença de tipos de dados, mas também em termos de tipos de rela-
cionamentos. O mundo orientado a objetos permite uma grande variedade de associações como
agregação, composição e herança, os quais não podem ser efetuados diretamente no mundo
relacional.
O Hibernate não somente efetua o mapeamento de classes Java para tabelas de um banco de
dados, mas também provê facilidades de filtragem e recuperação de dados.
Possui integração com a arquitetura JEE, inicialização tardia, dentre diversas outras vanta-
gens frente ao uso de JDBC.
O envio de e-mail foi conseguido com o uso da API Java Mail, a qual provê framework
independente de plataforma e de protocolo, para a construção de aplicações que utilizam sistema
de envio de e-mail. Com ela é possível fazer com que o sistema conecte-se a um servidor de
e-mail, autentique-se e transmita a mensagem. O Gmail é utilizado para tais fins.
O sistema de recomendação utiliza o framework Apache Mahout. Recebendo apenas uma
conexão à base de dados, busca as informações necessárias e gera as recomendações.
4.3 Procedimentos de Implantação

Para o devido funcionamento do sistema em ambiente de produção, faz-se necessário determi-
nado aparato. Nas seções seguintes são descritos alguns itens que apóiam o funcionamento do
54
sistema.
Na Seção 4.3.1 é descrito, com detalhes, o hardware necessário para utilização do sistema
desenvolvido. A Seção 4.3.2 detalha o software que deve existir para dar apoio ao sistema. Já
na Seção 4.3.3 são descritos dados referentes ao ambiente necessário para gerenciamento de
banco de dados, o SGBD a ser utilizado pela aplicação. É descrito na Seção 4.3.4 o necessário
para que a aplicação envie e-mail de confirmação de aluguel. Finalmente na Seção 4.3.5 são
descritos os procedimentos de implantação do sistema.
4.3.1 Hardware
Como se trata de um sistema informatizado, é necessário um computador em funcionamento,
com sistema operacional instalado e acesso à Internet, para que o sistema possa estar disponível
nesta.
O sistema funciona mesmo em um computador extremamente modesto, foram efetuados
testes em um computador com processador Pentium III de 600MHz, placa mãe ASUS P3BF,
500MB de memória, interface de rede 100Mbps, disco rígido IDE de 20GB. O sistema respon-
deu às requisições de um outro computador, através da rede montada, sem apresentar falhas.
Apesar de funcionar mesmo em uma configuração tão modesta quanto a apresentada deve-
se utilizar o bom senso, não faz sentido utilizar apenas uma máquina com tal configuração em
uma empresa que atenda à grandes demandas.
Em caso de utilização de diversos servidores que forneçam os diferentes serviços que for-
mam a aplicação, ou seja, o servidor de banco de dados, o servidor de e-mail, torna-se necessária
uma estrutura de rede com desempenho satisfatório, de acordo com a demanda.
Deve-se dar especial atenção a questão de segurança, montar uma estrutura que forneça ser-
viços disponíveis através da Internet é uma tarefa que demanda um grau elevado de capacitação,
não apenas para que os servidores troquem dados de forma extremamente rápida, mas também
para que toda a estrutura seja confiável. Tais detalhes estão fora do escopo deste trabalho, ainda
assim a segurança é de tal importância que não poderia ser ignorada.
4.3.2 Software
Um servidor Java EE é uma aplicação servidora que implementa as APIs da plataforma Java EE
e provê os serviços Java EE. Servidores Java EE são chamados, algumas vezes, de servidores de
aplicações porque permitem que um sistema provenha aplicações para clientes, como servidores
Web proveem páginas para navegadores.
Servidores Java EE hospedam diversos tipos de componentes de aplicações que correspon-
dem as camadas em uma aplicação multi camadas. O servidor Java EE provê serviços para estes
componentes na forma de um container.
Containers Java EE são interfaces entre o componente e a funcionalidade de baixo nível
provida pela plataforma para suportar aquele componente. A funcionalidade do contêiner é
definida pela plataforma, e é diferente para cada tipo de componente. O servidor permite a tipos
diferentes de componentes trabalharem juntos para prover funcionalidades em uma aplicação.
Assim, além do sistema operacional devidamente instalado, o sistema precisa de um con-
tainer Java EE que forneça suporte a sua execução. Durante o desenvolvimento e na fase de
testes foi utilizado o Apache Tomcat9 em sua versão 6.0, por conta de sua simplicidade de
uso, não necessidade de instalação (basta descompactar para uma pasta e executar) e relação
tamanho/desempenho.
9
tomcat.apache.org
55
Servidores de aplicação, como GlassFish, JBoss, Apache Geronimo, dentre diversos outros
existentes no mercado, também podem ser utilizados para fornecer suporte ao sistema, contudo
devem ser feitas alterações nas dependências do projeto nesse caso.
4.3.3 Servidor de Banco de Dados

Foi utilizado o banco de dados MySql em sua versão 5.1.41 durante toda a fase de desenvolvi-
mento e testes. A base de dados é relativamente simples, contendo apenas quatro tabelas.
O serviço de banco de dados pode ser provido pelo mesmo computador que hospeda a
aplicação, contudo, para um ambiente de produção, o ideal é que tal serviço seja provido por
máquina à parte, com configuração seguindo requisitos informados pelo fabricante do SGBD
utilizado, e que a ligação entre esta e o computador que hospedará o sistema seja efetuado, por
uma conexão de alta velocidade, visando maior desempenho.
4.3.4 Servidor de E-mail

Um serviço de e-mail é necessário para que o sistema possa enviar confirmação de aluguel de
filmes. O sistema utiliza atualmente o Gmail. O serviço de e-mail pode ser prestado por um
computador na empresa, novamente sugerimos que seja suprido por um computador diferente,
dada a possibilidade de alto tráfego de mensagens. Nada impede também que a empresa tercei-
rize tal serviço.
4.3.5 Procedimentos
São necessários alguns procedimentos além da instalação das máquinas e configuração do ambi-
ente de produção. De forma a efetuar a união de todas as partes citadas, com o objetivo de fazer
com que o sistema funcione. Estes procedimentos são detalhados nas Seções que se seguem.
Configurações dos Arquivos de Propriedades

Existem dois arquivos que carregam configurações importantes do sistema:
• “hibernate.cfg.xml” - possui configurações referentes à conexão com o banco de dados,

URL e porta do servidor, informações acerca do driver, nome de usuário e senha para a
conexão;
• “sys.properties” - acumula informações sobre caminhos de recursos disponíveis, ou seja,

URLs a serem utilizadas para acesso as funcionalidades do sistema, arquivos utilizados,
pastas que possuem recursos como imagens e scripts e também configurações referentes
ao servidor de e-mail, como URL e porta do SMTP, nome de usuário e senha, dentre
outros dados.
Deployment
A instalação do sistema no Servlet Container, procedimento também conhecido como “deploy-
ment”, deve ser feita somente depois de configurados todos os arquivos de propriedades. As
principais IDEs existentes geram automaticamente o arquivo utilizado para a instalação e esta
pode ser efetuada.
56
Dados dos Filmes

É necessária a inserção de dados referentes a filmes a serem disponibilizados para aluguel. O
sistema não provê esta funcionalidade, contudo, pode-se criar aplicação a parte para que tais
dados sejam devidamente registrados no banco de dados.
57
Capítulo 5
Experimentos
Este capítulo apresenta dados e resultados de experimentos práticos. Testes realizados com o
intuito de explorar diferentes tecnologias e métodos que possam vir a possibilitar o aumento de
desempenho no processo de geração de recomendações.
Foram realizados dois testes distintos, a utilização de uma implementação de banco de dados
em cluster, apresentado na Seção 5.1 e a utilização de processamento distribuído, Seção 5.2,
ambos utilizando diversos computadores no processo de apoiar a geração de recomendações.
5.1 Cluster
Foi utilizada, de forma experimental, uma implementação de banco de dados distribuído, com
o intuito de observar possíveis melhorias no tocante à eficiência do sistema de recomendações.
Inicialmente levantou-se a possibilidade de, dada a grande utilização de acesso aos dados do
banco de dados, melhorias no sentido de tornar tal acesso mais rápido poderiam gerar grandes
benefícios.
O objetivo primordial do teste utilizando banco de dados distribuído é o de verificar se com
a utilização deste as recomendações são geradas de maneira mais rápida.
O MySQL Cluster foi utilizado como opção a versão local do MySQL, utilizada durante
toda a fase de desenvolvimento e testes da aplicação. Assim como a versão local a versão
cluster é gratuita, e de código fonte aberto.
Sem a necessidade de uma infraestrutura complexa, ou computadores de alta performance -
em nossos testes conseguimos rodar um cluster utilizando até mesmo dois computadores Pen-
tium III 600MHz com 512MB de RAM. Funcionando nos principais sistemas operacionais -
Linux, Oracle Solaris e Microsoft Windows - sem a necessidade de serem servidores, são pon-
tos que fazem do MySQL Cluster uma opção barata e ainda assim confiável.
Com ótima documentação, fácil instalação, configuração simples, gerenciamento descom-
plicado, permite automatizar tarefas, é extremamente escalável - permite a adição de nós mesmo
com o cluster em funcionamento - suportando até 255 nós.
Qualquer falha é detectada instantaneamente e o controle é automaticamente passado a ou-
tros nós no cluster, sem a interrupção de serviço aos clientes. Além disso os nós do cluster
podem, automaticamente, reiniciar, recuperar e dinamicamente reconfigurar a si mesmos em
caso de falhas. A tecnologia de “auto cura” é completamente transparente para todas as aplica-
ções.
A arquitetura do MySQL Cluster, que pode ser observada na figura 5.1, é desenhada para
grande disponibilidade (99.999% - o que se traduz em menos de cinco minutos por ano de
downtime). O sistema consiste em múltiplos nós, os quais podem ser distribuídos através de
58
computadores para certificar disponibilidade contínua em caso de falha de um nó, hardware

ou rede. Acessível através de API nativa C++, Java, LDAP ou interface SQL padrão. Utiliza
replicação síncrona de dados que automaticamente propaga a informação de transações para os
nós e réplicas apropriados.
Figura 5.1: Arquitetura do MySQL Cluster (fonte: [4]).
Para garantir performance de tempo real armazena índices na memória, permite também
armazenamento de dados na memória para uso em aplicações que necessitam de baixa latência.
Permite replicação assíncrona de dados entre clusters remotos, permitindo a “replicação
geográfica”, o que é idealmente destinado para organizações com diversos data centers, permi-
tindo alta disponibilidade através de uma WAN e reduzindo os efeitos de latência geográfica,
localizando clusters próximo aos usuários.
Utilizando uma versão simplificada do sistema, como exibido no código fonte em 5.1, a
qual simplesmente fornecia recomendações para um usuário especificado programaticamente,
exibindo o tempo gasto no processo de gerar uma lista de recomendações, foi possível comparar
os tempos de geração de uma recomendação.
No intuito de tornar mais claro o código fonte em 5.1 seguem algumas explicações sobre o
que cada parte do código faz.
Para quantificar o tempo transcorrido do início ao fim do programa cria-se a variável inicio,
linha 3, e nela é armazenado, em milissegundos o horário de início do programa.
A linha 4 constrói uma DataSource e da linha 5 a 9 são informados parâmetros de confi-
guração do servidor de banco de dados. Logo depois utiliza-se tal informação para criar um
DataModel.
Na linha 11 temos a informação da maneira pela qual será calculada a similaridade entre os
usuários. Nos testes, como pode ser visto, foi utilizada a Correlação de Pearson, uma imple-
mentação do próprio framework Apache Mahout.
Já a linha 12 informa ao framework quantos “vizinhos” serão utilizados, o tipo de simila-
ridade a ser utilizada e que DataModel deve ser utilizado para buscar os dados, para o cálculo
dos “vizinhos” mais próximos.
59
O framework cria a figura do “recomendador”, ou seja, o objeto que irá gerar as recomen-
dações, na linha 13, foi utilizada uma implementação do próprio framework Apache Mahout.
1 public class TesteMahout {

2 public static void main(String[] args) throws TasteException {
3 long inicio = Calendar.getInstance().getTimeInMillis();
4 MysqlDataSource dataSource = new com.mysql.jdbc.jdbc2.optional.
MysqlDataSource();
5 dataSource.setUser("root");
6 dataSource.setPassword("");
7 dataSource.setServerName("localhost");
8 dataSource.setPortNumber(3306);
9 dataSource.setDatabaseName("netflix");
10 DataModel dataModel = new MySQLJDBCDataModel(dataSource, "avaliacao",
"ID_CLIENTE", "ID_FILME", "AVALIACAO", "DATA");
11 UserSimilarity similarity = new PearsonCorrelationSimilarity(
dataModel);
12 UserNeighborhood neighborhood = new NearestNUserNeighborhood(3,
similarity, dataModel);
13 Recommender recommender = new GenericUserBasedRecommender(dataModel,
neighborhood, similarity);
14 List<RecommendedItem> recommendations = recommender.recommend(7, 6);
15 for (RecommendedItem recommendation : recommendations) {
16 System.out.println(recommendation);
17 }
18 System.out.println("tempo: " + ((Calendar.getInstance().
getTimeInMillis() - inicio)/1000.0) + "s");
19 }
20 }
Algoritmo 5.1: Gerando recomendações utilizando o framework Apache Mahout.
Temos, na linha 14, a criação de uma lista de itens que o framework irá preencher com itens
recomendados, no exemplo, para o usuário de identificação 7, com o máximo de 6 recomenda-
ções.
Da linha 15 a 18 o sistema exibe a lista de recomendações, em ordem de importância, e o
tempo transcorrido do início ao fim do processamento.
Os testes para os quais foram registrados os tempos foram efetuados no laboratório 4 do
pavilhão 1 do CEFET-RJ, unidade Maracanã, onde se encontram as instalações do curso Tec-
nólogo em Sistemas para Internet.
Executando o programa exibido em 5.1, para diferentes configurações - local, utilizando
quatro computadores, seis e oito computadores fazendo parte de um cluster - registrando os
tempos de geração de recomendações para três clientes, os IDs escolhidos foram: 6, 25 e 911,
escolhidos pelo grupo ao acaso.
Tabela 5.1: Tabela contendo tempos registrados com utilização do cluster.

tempo melhoria melhoria acumulada
local 17.625 s 0,0 s = 0,0 % 0,0 s = 0,0 %
4 computadores 17.453 s 0,172 s = 0,976 % 0,172 s = 0,976 %
60
Dos valores encontrados, para cada configuração, foi efetuada média aritimética entre os
tempos das recomendações para os diferentes IDs de usuários e os valores são apresentados na
tabela 5.1:
Com a intenção de permitir uma análise mais fácil dos dados, geramos o gráfico em 5.2,
contendo os tempos obtidos com as diferentes configurações.
Figura 5.2: Gráfico tempo X computadores - cluster.
5.2 Processamento Distribuído

Com o intuito de verificar a possibilidade da realização do processo de gerar recomendações
utilizando diversas máquinas em conjunto e diferenças de tempo para diferentes números de
máquinas participando do processo, o grupo desenvolveu um sistema que realiza tal tarefa.
A intenção foi a de fazer com que diversas máquinas pudessem participar do processo de
geração das recomendações, dividindo o trabalho de forma que cada máquina pudesse gerar
recomendações referentes a uma parte do total de usuários, assim a soma de todas cubriria
todos os usuários.
Este procedimento possui um nome: Paralelismo de Dados - é uma forma de paralelização
de computação que foca em distribuir os dados através de diferentes nós computacionais. Se
refere ao cenário no qual a mesma operação é efetuada concorrentemente (em paralelo) em
elementos em uma coleção.
Os dados são divididos entre os nós disponíveis de maneira a alcançar paralelismo. Em
um ambiente que possui vários computadores o paralelismo de dados é alcançado quando cada
nó executa a mesma tarefa em diferentes partes dos dados distribuídos. Em um sistema com
vários nós de processamento, onde se deseja efetuar uma tarefa sobre dados, é possível fazer
com que o nó A efetue tal tarefa em uma parte dos dados, o nó B em outra parte, e assim por
diante, distribuindo a mesma tarefa pelos m nós simultaneamente, assim reduzindo a duração
da execução da tarefa.
O primeiro passo foi desenvolver um sistema de recomendações sem o uso de frameworks,
ou seja, o grupo teve de fazer sua própria implementação de um sistema de recomendações, que
realize todo o processo.
O objetivo foi alcançado, foi criado um sistema de recomendação que utiliza os dados de
avaliações dos usuários aos itens, o processo é basicamente igual ao do framework Apache
61
Mahout, o sistema utiliza a tabela AVALIACAO buscando os dados de cada cliente e para cada
um deles verifica seus similares, utilizando a Correlação de Pearson, gerando recomendações
com os itens mais bem avaliados por estes, apresentando como resultado a identificação dos
itens recomendados. O pseudo código pode ser observado em 5.2.
1 obter clientes que já avaliaram filmes

2 enquanto existirem usuários que já avaliaram itens
3 obter próximo
4 obter itens e avaliações referentes ao usuário atual
5 obter usuários que já avaliaram itens que o usuário atual avaliou
6 enquanto existirem usuários que já avaliaram itens que o usuário atual
avaliou
7 obter próximo
8 obter avaliações aos itens
9 calcular similaridade ao usuário atual
10 se similaridade > índice de similaridade mínimo, então
11 armazenar como usuário semelhante com grau de similaridade
12 fim de se
13 fim de enquanto
14 para cada usuário semelhante ao atual
15 para cada item seu que não tenha sido avaliado pelo usuário atual
16 IMPORTANCIA <- similaridade * avaliação dada ao item
17 armazenar item e IMPORTANCIA
18 fim de para
19 fim de para
20 recomendar itens com maiores valores de IMPORTANCIA
21 fim de enquanto
Algoritmo 5.2: Pseudo código - sistema de recomendações.
Foram efetuados alguns testes com o sistema desenvolvido, o sistema realmente funciona
com perfeição, o problema é a quantidade de dados existente, com a base de dados completa
o sistema leva cerca de 20 minutos para gerar as recomendações de cada usuário, sabendo-
se que a base de dados possui 480.188 usuários registrados, o tempo estimado para gerar as
recomendações para todos seria de alguns meses.
Ficou decidido que não seria utilizada toda a base de dados para os testes, e sim uma por-
centagem desta, mas utilizando apenas 2% dos usuários registrados o sistema ainda demora
três dias e meio para gerar todas as recomendações. Como os testes seriam efetuados nos la-
boratórios do CEFET e seriam feitas várias rodadas de testes com processamento distribuído
(utilizando 6, 5, 4 até 1 computador), com 2% dos dados tais testes durariam por volta de seis
dias e meio.
Para minimizar o impacto nas aulas das turmas do CEFET que utilizam os laboratórios,
decidiu-se que o sistema utilizaria apenas 0,5% da base de dados original, o que ainda assim
permitiria testes que durariam algumas horas.
O próximo passo seria o desenvolvimento de uma versão do sistema que permitisse proces-
samento distribuído, várias máquinas dividiriam o trabalho de gerar recomendações para toda a
base de dados, cada uma para um subgrupo do total de usuários registrados.
A ideia inicial era de construir uma arquitetura onde um computador gerenciasse outros, tan-
tos quanto necessários, fazendo com que estes iniciem o processo de gerar recomendações, com
uma mensagem com ordem de inciar e a informanção de por qual subgrupo de usuários cada
um seria responsável por gerar recomendações, registrasse os tempos que levam e finalizasse
todo o processo.
62
A forma pela qual mensagens são trocadas entre os computadores pode se dar de três formas
possíveis em uma rede:
• unicast - comunicação entre duas máquinas diretamente, também conhecida como ponto
a ponto, uma mensagem é enviada em específico para um host da rede - o problema desta
abordagem é que tem de se saber de antemão o endereço de cada máquina com a qual se
pretende comunicar. O grupo utilizou esta abordagem no momento em que as máquinas
que efetuam o processo de gerar as recomendações se identificam à máquina gerente
como “clientes”, quando a máquina que gerencia o processo informa às que geram as
recomendações, que estas devem iniciar o processo e o subgrupo de usuários pelo qual ela
está responsável de gerar as recomendações e quando as máquinas “clientes” informam
que terminaram seus respectivos trabalhos à máquina “servidor”;
• multicast - os hosts que desejarem fazer parte da comunicação devem aderir à um grupo,
que utiliza um IP, todas as inscritas neste grupo recebem as mensagens destinadas ao
grupo;
• broadcast - uma mensagem enviada em broadcast através de uma rede, é recebida por
todos os hosts no mesmo domínio de broadcast - esta abordagem permite que a máquina
gerente informe para todos os hosts “eu sou a máquina gerente”, sem a necessidade de
saber quantas e quais estarão envolvidas no processo, ou melhor ainda, limitar as má-
quinas envolvidas, mesmo que uma centena de máquinas estejam disponíveis para gerar
recomendações, ela pode utilizar apenas as mais rápidas a responder sua mensagem. Esta
abordagem foi utilizada no momento em que a máquina que gerencia o processo se iden-
tifica como “servidor” para todos os hosts na rede.
Podem ser utilizados dois protocolos distintos para a comunicação, a saber:
• TCP - provê um canal de comunicação ponto a ponto confiável, permitindo a comunica-

ção de fluxos de dados de maneira confiável. Utiliza o conceito cliente-servidor (comu-
nicação ponto a ponto - unicast) e estabelecimento de conexão;
• UDP - provê um modo de comunicação que permite que sejam enviados pacotes de dados,
chamados datagramas, entre máquinas. Não provê segurança, mas é mais rápido que o
TCP. Permite comunicação unicast, multicast ou broadcast. Foi a opção utilizada pelo
grupo.
Todo o processo passa a ser detalhado para maior facilidade de compreensão:

Todas as máquinas “clientes”, as máquinas que irão calcular as recomendações, deverão ter
uma cópia de igual, conteúdo, da base de dados, que corresponderá a 0,5% da base de dados
original do NetFlix.
As recomendações geradas serão armazenadas no computador “servidor”, o qual será res-
ponsável também por registrar o tempo de cada rodada, assim como o tempo de cada máquina
que participou de cada rodada.
O computador que gerenciará o processo enviará uma mensagem em broadcast, a porta de
comunicação selecionada foi a 6138, informando que ele é o “servidor”, os computadores que
efetuarão a geração das recomendações registarão o endereço IP dele, para que possam utilizar
para efetuar conexão com o banco de dados remoto, onde armazenarão as recomendações e para
que possam se comunicar com o ele.
63
Tendo registrado o endereço IP do computador “servidor”, cada uma deverá responder, em

unicast, que é uma máquina “cliente”. O computador “servidor” registra os “clientes”.
Tendo registrado os “clientes” o computador “servidor” informa à cada um, em unicast, que
inicie o processo e por qual subgrupo de usuários registrados este está responsável por calcular
as recomendações.
Cada “cliente”, ao terminar de gerar as recomendações, para os usuários que está responsá-
vel, informará ao computador servidor que terminou sua tarefa, aguardando por nova ordem.
Para que possa ficar bem clara a troca de mensagens entre os computadores que participam
do processo, observe a figura 5.3, a qual detalha todo o processo. Observe que na mensagem
“Iniciar. i/m”, m informa para quantos computadores o processamento foi distribuído e i in-
forma por qual subgrupo dos usuários o computador é responsável.
Figura 5.3: Troca de mensagens no sistema distribuído.
A implementação utilizada toma o cuidado de utilizar o computador que se comunicar mais

rápido ao se registrar no servidor (respondendo a mensagem “Eu sou o servidor.”), este será
utilizado em todas as rodadas, o segundo mais rápido será utilizado até a penúltima, e assim
sucessivamente.
O sistema também avisaria, por e-mail, o término de cada rodada e do processamento, con-
tudo, à data dos experimentos, o laboratório não contava com acesso à Internet, e as informações
foram armazenadas em banco de dados.
Os testes foram efetuados no laboratório 3 do pavilhão 1 do CEFET unidade Maracanã.
Foram utilizadas oito computadores, um fez o papel de “servidor” e os outro sete de “clientes”,
contudo configurou-se o servidor para utilizar apenas seis “clientes”, desta forma, dos sete,
apenas seis participaram do processo.
Os resultados foram registrados e tabulados em 5.2. Nesta tabela observam-se, nas linhas,
as rodadas e, para cada coluna, os tempos (em minutos) que cada computador “cliente” (PC1,
PC2, ..., PC6) levou para executar sua tarefa. Observe que as rodadas estão na ordem em que
ocorreram, primeiro a que utilizou seis computadores e por último a que utilizou apenas um
para gerar as recomendações.
64
Tabela 5.2: Resultados do processamento distribuído - em minutos.

rodada PC1 PC2 PC3 PC4 PC5 PC6 tempo da rodada
6 39,42 40,64 39,24 39,26 39,17 25,18 40,64
5 46,84 29,92 47,23 47,01 47,33 - 47,23
4 58,49 37,12 59,42 58,93 - - 59,42
3 77,74 49,45 79,54 - - - 79,54
2 115,85 75,05 - - - - 115,85
1 232,45 - - - - - 232,45
Com base nos dados obtidos foi gerado o gráfico 5.4, que se segue.
Figura 5.4: Gráfico tempo X número de computadores - processamento distribuído.

65
Conclusões
Os sistemas de recomendação possuem alguns problemas intrínsecos, como a grande quanti-

dade de dados necessários para que estes comecem a fazer realmente boas recomendações. Um
outro problema, que de certa forma é consequência do anterior, é que novos produtos raramente
serão recomendados em relação a produtos antigos.
A mudança de comportamento é também um problema para um sistema de recomendações.
Um cliente habitual de uma padaria, por exemplo, ao entrar recebe a sugestão da atendente -
“Acabou de sair aquele pão que o senhor adora!”, aí o cliente responde -“Hoje estou procurando
apenas um doce pra comer!”, a atendente logo consegue sugerir algo. No mundo virtual isso
não é tão simples, na verdade, é dificilmente adaptável.
A interferência do comportamento humano é um traço realmente dificil de ser prrevisto.
Técnicas que dependem que os usuários avaliem previamente itens a serem recomendados so-
frem a relutância dos usuários a terem de fazê-lo. Essa resistência natural é resultado da falta
de tempo e paciência dos usuários em colaborar com o sistema, e pode até mesmo ser rela-
cionada com a questão da privacidade, relutância em revelar explicitamente suas preferências.
Consequentemente, sistemas de recomendação que utilizam técnicas que dependam da avalia-
ção de itens por parte do usuário são sujeitos a problemas de eficiência gerados pela falta de um
número suficiente de avaliações no sistema.
Existem também diferenças no nível das avaliações e das motivações. As motivações que
levam um usuário a fornecer uma nota para um item pode ser muito diferente de um outro
usuário, em outras palavras, uma mesma nota pode ter significados diferentes. Uma nota um
(de uma escala de zero a dez) fornecida por um usuário a um vinho, por exemplo, pode significar
não gosto deste tipo ou marca de vinho, enquanto que uma nota um fornecida por um expert
pode significar, a safra é ruim e produziu um vinho de baixa qualidade. Em outro contexto
um usuário pode fornecer nota alta para uma ferramenta por entender que esta tenha boa razão
qualidade/preço, enquanto outro pode fornecer nota alta por entender que a qualidade do item é
boa comparativamente a outros de mesma função.
Os sistemas de recomendação apresentam também um problema de segurança. Pessoas
mal intencionadas podem inserir perfis tendenciosos, de forma a adaptar o sistema para gerar
recomendações que lhe sejam vantajosas. Tais ataques podem fazer com que os usuários percam
a confiança na objetividade e precisão do sistema [22].
Apesar dos problemas citados o grupo pode não só ter a compreensão de todo o funcio-
namento de um sistema de recomendação, como também perceber a facilidade do desenvol-
vimento de um sistema deste tipo com o uso de frameworks. Com poucos recursos, tempo
curto e sem dedicação exclusiva a tarefa, foi possível desenvolver um sistema de recomendação
funcional e que atende satisfatóriamente as necessidades.
Nas seções que se seguem observam-se aspectos importantes referente a evolução e desfe-
cho do trabalho realizado. Na Seção 5.2 são revisitadas as ideias iniciais do projeto e observadas
suas evoluções, alterações, problemas e realizações. Já na Seção 5.2 indicam-se possíveis me-
lhorias, evoluções que podem vir a ser implementadas.
66
Análise Restrospectiva
O propósito inicial deste trabalho era o de efetuar pesquisa e implementação de um sistema de
recomendação. Contudo, com o avanço da pesquisa foram descobertos dois frameworks que
possibilitam a criação de sistemas de recomendação, o Duine e o Apache Mahout.
A possibilidade do uso de frameworks, com código desenvolvido por equipes maiores, já
testado, maduro e assim menos propenso a falhas fez com que a equipe vislumbrasse a possibi-
lidade de gerar um sistema, logo de início, ultrapassando os problemas iniciais de desenvolvi-
mento - escolha do tipo de dados, arquitetura da aplicação, dentre outros - indo direto a geração
de recomendações com bons padrões de qualidade.
A escolha do grupo foi o Apache Mahout, o Duine não gera realmente recomendações,
ele analisa o valor de um dado item ao cliente, gerando uma estimativa da nota que o usuário
forneceria ao item. Já o Apache Mahout faz todo o trabalho de gerar recomendações ao usuário,
ou seja, faz o mesmo que o Duine, fornecendo, para cada item, a estimativa de avaliação que o
usuário forneceria, indo além, fornece uma lista de itens que seriam os mais bem avaliados.
Assim foi desenvolvido um sistema de comércio eletrônico, de maneira rápida e efetiva para
servir como linha de frente de um sistema de recomendação. Em paralelo foi efetuada a tenta-
tiva de desenvolver o sistema de recomendação, como um projeto em separado, infelizmente,
com todo o sistema de comércio eletrônico funcionando, ainda não havia êxito na geração de
recomendações.
A descoberta de que a implementação estaria correta e que o erro se encontrava na tipagem
dos dados na base de dados só viria vários dias depois. Com documentação precária, poucos
exemplos, e sem experiência no uso do framework, o grupo teve bastante trabalho para descobrir
que o Apache Mahout necessita que algumas regras sejam obedecidas no formato da base de
dados empregada na geração das recomendações.
Com todo o sistema funcionando houve um aumento de escopo, seria feita a tentativa de
utilizar a flexibilidade gerada pelo uso do Apache Hadoop, base do Apache Mahout, na utiliza-
ção de computação distribuída, na tentativa de dividir o trabalho de gerar recomendações entre
diversos computadores.
Com documentação péssima, pior que a do Apache Mahout, que já é ruim, pouquíssimos
exemplos, estes referentes a versões anteriores, aparentemente incompatíveis com a versão atu-
almente disponibilizada, exigência de ambiente específico, com o uso do sistema operacional
Linux e uma série de configurações, a implementação de um sistema distribuído para a geração
de recomendações se mostrou por demais complexa e, infelizmente o grupo não teve sucesso
nessa tarefa.
Cabe uma observação importante quanto ao processamento distribuído para a geração de
recomendações, distribuir a computação não a torna mais eficiente, pelo contrário, usualmente
requer muito mais recursos. Mover dados entre várias máquinas consome recursos de rede, a
computação frequentemente tem de ser estruturada de uma maneira que envolva computação
e armazenamento de diversos resultados intermediários, o que pode levar tempo de proces-
samento significativamente maior para computar. O software que “orquestra” tais operações
consome memória e poder de processamento também significativo.
De qualquer forma a computação distribuída oferece uma maneira de cálculo e geração
de recomendações em uma escala em que computação “não distribuída” não poderia se quer
começar, dada a falta de recursos necessários para tal em uma só máquina.
Com o fracasso da implementação de um algoritmo distribuído, houve nova mudança de
escopo, foi levantada a hipótese do uso de um banco de dados distribuído, acerca do qual o
grupo efetuou pesquisas e conseguiu sucesso em seu uso.
67
Ainda com a possibilidade de uso processamento distribuído, imaginou-se uma arquitetura

diferente, não exatamente como a implementada pelo Apache Hadoop, que distribui dados e
processamento, de forma que os dados fiquem próximos de onde será executado o processa-
mento, minimizando comunicações de rede, mas utilizando réplicas da base de dados em cada
computador a ser utilizado no processmanto distribuído.
O experimento foi um sucesso e os dados obtidos, e respectivo gráfico permitem observar o
aumento quase que exponencial de velocidade.
Trabalhos Futuros
O sistema desenvolvido para utilização em um site de aluguel de vídeos apresenta diversos
aspectos comuns a diversos sites de vendas e de aluguel de itens online. Uma possível melhoria
seria torna-lo mais genérico, possibilitando seu aproveitamento em diversos outros domínios.
A implementação de um arquivo de mensagens customizadas e algumas poucas mudanças em
alguns pontos da aplicação, a primeira vista, já parecem suficientes.
No tocante ao sistema de recomendações podem ser aplicados testes com diferentes métricas
de similaridade, de forma a encontrar a mais apropriada ao domínio do problema, o que pode
significar uma abordagem que leve menos tempo, ou uma que consiga melhor acurácia, ou ainda
uma que forneça um meio termo, ou ainda a descoberta da existência (ou a implementação) de
uma abordagem que alcance ambos os benefícios.
O número de vizinhos mais próximos é outro item que pode ser modificado de forma a trazer
melhores resultados. A utilização de um número fixo de vizinhos pode ser melhor ajustada, ou
ainda substituída por uma abordagem que leve em conta o grau de similaridade, por exemplo,
todos aqueles que apresentarem similaridade igual ou superior a oitenta por cento devem ser
levados em conta. Tal configuração pode levar a resultados mais precisos, mas por outro lado
pode levar a ausência de resultados, em casos que não existam vizinhos que atendam a tal
especificação.
Um desafio maior, e bem mais complexo é a implementação de uma abordagem distribuída
para a geração das recomendações nos moldes do Apache Hadoop, levando dados e proces-
samento exatamente para onde serão utilizados. Tal trabalho pode ser feito com o Apache
Handoop, talvez novas versões tragam melhores documentações ou possuam menos restrições
quanto ao ambiente necessário para seu funcionamento, ou talvez possa ser desenvolvido, o que
parece uma tarefa bem complexa.
Os resultados obtidos na utilização de um banco de dados distribuído reforçam a idéia de
que o uso de computação distribuída obtenha melhores resultados no processamento de grandes
quantidades de dados, com o intuito de gerar recomendações. Mesmo com computadores e uma
rede não apropriados para o intuito obteve-se bons resultados, a possibilidade, para uso empre-
sarial, de ligações em rede utilizando fibra ótica, redes extremamente velozes, e computadores
com grande capacidade de processamento mostram que o sistema desenvolvido pode sim, sob
as circunstâncias apropriadas, atender grandes demandas.
68
Apêndices
69
Apêndice A
Manual do Usuário
Este capítulo detalha a utilização do sistema de comércio eletrônico AlugOnline, informando

como utilizar os recursos disponíveis.
A Seção A.1 esclarece ao usuário alguns detalhes importantes. Alguns padrões tuilizados
na interface do sistema são observados na Seção A.2. A primeira interface do sistema a ser
alcançada pelo usuário é detalhada em A.3. Como novos usuários devem se registrar pode ser
visto em A.4. O conceito de carrinho de compras, é observado na Seção A.5. A finalização de
uma compra, o pagamento, é visto na Seção A.6.
A.1 Informações Relevantes

O AlugOnline é um sistema que permite ao usuário, através do navegador, aluguel de filmes,
registro, feitura de buscas, navegação pelo catálogo de filmes, dentre outras funcionalidades.
“Através do navegador” significa que o usuáario não possui o sistema instalado em seu com-
putador, ao invés disso o acessa através de uma rede de computadores, da mesma maneira que
acessa os dados de seu banco ou de seu WebMail, utilizando um navegador, como o Microsoft
Internet Explorer, ou o Mozilla Firefox, ou Google Chrome, etc.
Assim, as informações não são armazenadas no computador do usuário e sim em um outro
ambiente que provê tal serviço na rede. Desta forma, este sistema pode ser acessado através de
qualquer computador com acesso à Internet, bastando para isso informar o endereço do sistema.
Outra consequência do uso através do navegador é a independência de sistema operacional,
não importa se o usuário utiliza um computador com sistema operacional Windows, ou Linux,
ou ainda qualquer outro.
A.2 Padrões Utilizados

Alguns itens da interface são constantes em todas as telas do sistema, como pode ser observado
na figura A.1. Exemplos são a caixa de pesquisa, na parte superior direita, e o rodapé da página.
A caixa de pesquisa permite que se busquem nomes de filmes, ou padrões de texto, como
exemplo, uma busca por “time” retorna, como resultados: “Modern Times”, “Sting: All This
Time” e “Deal of a Lifetime”, dentre outros. Observe-se que a busca retorna mesmo filmes que
possuam a cadeia de caracteres “time” como parte de uma palavra.
Ainda sobre a pesquisa é importante ressaltar que esta é indiferente a maiúsculas e minús-
culas, sendo assim buscas efetuadas para a cadeia de caracteres “TiMe”, ou “TIME”, ou “time”,
70
retornam os mesmos resultados. Espaços são considerados nas buscas, com isso uma busca por
“time ” (palavra “time” com um espaço ao fim) não retornaria o filme “Modern Times”.
Figura A.1: Tela inicial do AlugOnline.
As pesquisas podem ser efetuadas digitando-se o padrão a ser encontrado na caixa de texto,
teclando ENTER ou clicando na imagem ao final.
No rodapé das páginas constam os links para a página do CEFET-RJ, do curso Tecnólogo em
Sistemas para Internet e para os e-mails dos componentes do grupo e do orientador do projeto.
A.3 Página Inicial

A página inicial do sistema, como visto na figura A.1, permite ao usuário efetuar busca, na-
vegando no catálogo de filmes e a partir daí adicionar itens aos carrinho de compras, permite
também que novos usuários se registrem e que os registrados identifiquem-se.
Para cada resultado da busca observam-se nome, ano e valor do aluguel. Na caixa logo
abaixo a quem contém tais dados existe a figura , que permite que se aidicione o item ao qual
se refere ao carrinho.
Na parte inferior da página, logo acima ao rodapé, encontram-se os links para navegação
dos registros resultantes da consulta. Em meio aos links exibem-se o número da página atual, e
o total de páginas retornadas em resposta à consulta.
Na parte direita da página exibem-se os detalhes referentes ao carrinho de compras, infor-
mando quantos itens este possui e a imagem que serve de link para a página referente ao
carrinho de compras, a qual é detalhada na Seção A.5
Assim que se identifica o usuário recebe recomendação(ões) de filme(s), de acordo com
seu histórico de avaliação de itens. A(s) recomendação(ões) aparecem da mesma forma que as
71
buscas, a mesma organização, a possibilidade de adicionar o item ao carrinho e, como o usuário

já se identificou, a possibilidade de avaliar o item.
Como pode-se observar na figura A.2 a tela inicial é diferente para clientes já identificados.
Usuários identificados podem avaliar itens, com notas de um a cinco, tal objetivo é atingido
selecionando-se a quantidade de estrelas que deseja-se como nota, na caixa referente ao iten
desejado.
Figura A.2: Tela inicial do AlugOnline para um usuário identificado.
Após identificado o nome do usuário passa a aparecer em todas as telas do sistema, em

lugar dos campos antes existentes para nome do usuário e senha. Também é importante notar
a presença do botão “Sair”, que permite que o usuário desconecte-se do sistema, não atuando
mais como um usuário identificado.
A.4 Cadastro
A tela de cadastro, que pode ser vista na figura A.3, permite que novos usuários efetuem registro
no sistema, para que possam fazer uso de todas as funções disponíveis neste. Para efetuar seu
cadastro o usuário deverá fornecer os dados requisitados: Nome, e-mail e senha.
Figura A.3: Tela referente ao cadastro de novos usuários.
Após fornecer os dados o usuário dever´s clicar no botão “Salvar”, o que fará que o sistema
registre os dados fornecidos.
72
A.5 Carrinho de Compras

A tela referente ao carrinho de compras, como pode ser visto em A.4, permite que o usuário
visualize o total e os itens constantes neste, podendo também remover qualquer item com o uso
do ícone .
Figura A.4: Tela referente ao carrinho de compras.
Na tela apresentada em A.4, observe-se que, como o usuário não se identificou, não lhe é
permitido que este finalize o aluguel dos filmes.
Para usuários identificados o sistema permite que se feche o pedido de aluguel dos filmes,
como pode ser visto na figura A.5, pode-se observar a existência do botão Usuários identificados
no sistema podem fechar o pedido de compra através de clique no botão “Fechar Pedido”, pouco
abaixo da identificação do usuário que existe na página.
Figura A.5: Tela referente ao carrinho de compras - usuários identificados.

73
Observe-se que tanto para usuários identificados como os não identificados podem observar
o total de filmes constantes no carrinho de compras, logo abaixo da identificação do usuário.
A.6 Pagamento
A tela de pagamento pode ser observada na figura A.6. Esta tela permite que se observem os
filmes que serão alugados, e a escolha da forma de pagamento.
Uma vez que seja escolhida a forma de pagamento e que se clique no botão “Pagar” o sis-
tema registra o aluguel dos filmes, envia ao usuário um e-mail e esvazia o carrinho de compras.
Figura A.6: Tela de pagamento.

74
Bibliografia
[1] Duine framework - recommender software toolkit. http://www.duineframework.

org.
[2] Fielding dissertation: CHAPTER 1: Software architecture. http://www.ics.uci.

edu//pubs/dissertation/software_arch.htm.
[3] Is design dead? http://martinfowler.com/articles/designDead.html#

GrowingAnArchitecture.
[4] MySQL :: MySQL cluster architecture. http://www.mysql.com/products/

cluster/architecture.html.
[5] MySQL :: MySQL customers. http://www.mysql.com/customers/.
[6] Recommender documentation - apache mahout - apache software founda-

tion. https://cwiki.apache.org/confluence/display/MAHOUT/
Recommender+Documentation.
[7] Software architecture | getting started | defining software architecture. http://www.

sei.cmu.edu/architecture/start/definitions.cfm.
[8] What is Object/Relational mapping? - JBoss community. http://www.hibernate.

org/about/orm.html.
[9] whoNeedsArchitect.pdf (objeto application/pdf).
[10] A DOMAVICIUS , G., AND T UZHILIN , A. Toward the next generation of recommender
systems: A survey of the state-of-the-art and possible extensions. IEEE TRANSACTIONS
ON KNOWLEDGE AND DATA ENGINEERING 17, 6 (2005), 734—749.
[11] A ZAK , M., AND B IRTURK , A. Crossing framework - a dynamic infrastructure to develop
knowledge-based recommenders in cross domains. In WEBIST (2) (2010), pp. 125–130.
[12] BALABANOVIC , M., AND S HOHAM , Y. Fab: Content-based, collaborative recommenda-

tion. Communications of the ACM 40 (1997), 6672.
[13] B RYNJOLFSSON , E., H U , Y. J., AND S MITH , M. D. The longer tail: The changing shape
of amazons sales distribution curve. SSRN eLibrary (Sept. 2010).
[14] C OUGO , P. Modelagem conceitual e projeto de bancos de dados. Campus, Rio de Janeiro,
1997.
75
[15] F IGUEIRA F ILHO , F. M., DE G EUS , P. L., AND DE A LBUQUERQUE , J. P. Sistemas de

recomendação e interação na web social. Anais do VII Simpósio Brasileiro de Fatores
Humanos em Sistemas Computacionais.
[16] F OWLER , M. Patterns of enterprise application architecture. Addison-Wesley, Boston,
2003.
[17] H ILL , W., S TEAD , L., ROSENSTEIN , M., AND F URNAS , G. Recommending and evalu-
ating choices in a virtual community of use. In Proceedings of the SIGCHI conference on
Human factors in computing systems - CHI ’95 (Denver, Colorado, United States, 1995),
pp. 194–201.
[18] K UMAR A RUNACHALAM , T. Collaborative web recommendation systems - a sur-
vey approach. http://computerresearch.org/stpr/index.php/gjcst/
article/viewArticle/95, Jan. 2010.
[19] L ARMAN , C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development, 3 ed. Prentice Hall, Oct. 2004.
[20] L INDEN , G., S MITH , B., AND YORK , J. Amazon.com recommendations: item-to-item
collaborative filtering. Internet Computing, IEEE 7, 1 (2003), 7680.
[21] M ASSA , P., AND AVESANI , P. Trust-aware collaborative filtering for recommender sys-
tems. In Proc. of Federated Int. Conference On The Move to Meaningful Internet: CoopIS,
DOA, ODBASE (2004).
[22] M OBASHER , B., B URKE , R., B HAUMIK , R., AND W ILLIAMS , C. Toward trustworthy
recommender systems. ACM Transactions on Internet Technology 7, 4 (Oct. 2007), 23–es.
[23] PAZZANI , M., AND B ILLSUS , D. Content-Based recommendation systems. In The Adap-
tive Web. 2007, p. 325341.
[24] S ARWAR , B., K ARYPIS , G., KONSTAN , J., AND R EIDL , J. Item-based collaborative
filtering recommendation algorithms. In Proceedings of the 10th international conference
on World Wide Web (New York, NY, USA, 2001), WWW ’01, ACM, p. 285295.
[25] S CHAFER , J. B., F RANKOWSKI , D., H ERLOCKER , J., AND S EN , S. The adaptive web.
Springer-Verlag, Berlin, Heidelberg, 2007, p. 291324.
[26] S OBOROFF , I., AND N ICHOLAS , C. Combining content and collaboration in text filte-
ring. In Proc. Int’l Joint Conf. Artificial Intelligence Workshop: Machine Learning for
Information Filtering (1999).
[27] VOZALIS , E., AND AL , E . Analysis of Recommender Systems’ Algorithms.
[28] W HATIS . COM. What is framework? definition from WhatIs.com. http://whatis.
techtarget.com/definition/0,,sid9_gci1103696,00.html.
[29] W IKIPEDIA. Software framework - wikipedia, the free encyclopedia. http://en.
wikipedia.org/wiki/Framework_(software).
[30] Y U , K., S CHWAIGHOFER , A., T RESP, V., X U , X., AND K RIEGEL , H. Probabilistic
memory-based collaborative filtering. IEEE Transactions on Knowledge and Data Engi-
neering 16, 1 (Jan. 2004), 56–69.

Monografia

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Monografia

Transféré par

Droits d'auteur :

Formats disponibles

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA

CELSO SUCKOW DA FONSECA - CEFET/RJ

Um sistema de recomendação para a base de dados

Antonio Jose de Castro Filho

Prof. Orientador: Eduardo Bezerra da Silva

Um sistema de recomendação para a base de dados

Antonio Jose de Castro Filho

Projeto final apresentado em cumprimento às

Prof. Orientador: Eduardo Bezerra da Silva

Ficha catalográfica elaborada pela Biblioteca Central do CEFET/RJ

Projeto Final (Tecnólogo) Centro Federal de Educação Tecnológica

1.Sistemas de computação 2.Comécio eletrônico 3.Base de dados

3.3.2 Especificação dos Demais Requisitos do Sistema . . . . . . . . . . . . 23

2.1 Partes de sistema de recomendação utilizando Apache Mahout (fonte: [6]). . . 18

3.1 Disciplinas do projeto unificado x tempo (fonte: [19]). . . . . . . . . . . . . . 22

4.1 Mapa mental utilizado para gerência do projeto. . . . . . . . . . . . . . . . . . 45

5.1 Arquitetura do MySQL Cluster (fonte: [4]). . . . . . . . . . . . . . . . . . . . 58

A.1 Tela inicial do AlugOnline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.1 Tabela usuários X itens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Características da base de dados. . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1 Tabela contendo tempos registrados com utilização do cluster. . . . . . . . . . 59

4.1 Trecho do controlador de carrinho. . . . . . . . . . . . . . . . . . . . . . . . . 50

1.4 Metodologia de Desenvolvimento

cessidade e buscar os frameworks e processos a serem utilizados na implementação, além da

1.5 Organização dos Capítulos Seguintes

2.1 Conceitos Relevantes

Tabela 2.1: Tabela usuários X itens.

2.2 Estratégias de Recomendação

2.2.1 Itens Promocionais

exemplo, em dados promocionais. Exemplos são a promoção do dia e descontos apresentados

2.2.2 Características Desejadas

2.2.3 Itens Mais Vendidos

2.2.4 Histórico de Compras

2.3 Tipos de Sistema de Recomendação

• filtragem colaborativa - baseada em perfis de outros usuários, detalhada na Seção 2.3.2;

• filtragem híbrida - mescla as duas anteriores, abordada na Seção 2.3.3.

2.3.1 Filtragem por Conteúdo

2.3.2 Filtragem Colaborativa

2.3.3 Filtragem Híbrida

2.4 Entrada de Dados

2.4.1 Abordagem Explícita

2.4.2 Abordagem Implícita

2.4.3 Abordagem Híbrida

2.5 Passos Para Gerar a Recomendação

A seguir pode-se obervar os passos do processo de gerar recomendações, o cálculo de simi-

2.5.1 Cálculo de Similaridade

Dado o conjunto de avaliações rai do usuário ativo a, e o conjunto de avaliações rbi do

É possível calcular a similaridade entre os usuários a e b (ρab ):

Para o numerador da Correlação de Pearson, temos:

Onde n é o número de atributos que se deseja utilizar e x é a avaliação, ou valoração dada a

2.5.2 Gerando a Recomendação

2.6 Apresentação da Recomendação

2.7 Algoritmos Para Gerar Recomendações

2.7.1 Para Filtragem Colaborativa

Baseada em Histórico (Memory-based)

Baseado em Modelo (Model-based)

2.7.2 Para Filtragem Baseada em Conteúdo

Baseada no usuário (user-based)

Técnicas comumente utilizadas: TF-IDF (Term Frequency-Inverse Document Frequency) e

• |D| ⇒ é o total de documentos;

• |{d : ti ∈ d}| ⇒ é o número de documentos onde o termo ti aparece.

(tf − idf )i,j = tfi,j .idfi (2.7)

Baseado em modelo (model-based)

2.8.1 Apache Mahout