“RetriBlog: Um Framework Centrado na Arquitetura para
Criação de Blog Crawlers”
Por
Rafael Ferreira Leite de Mello
Dissertação de Mestrado
Universidade Federal de Pernambuco
[email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE, Dezembro/2011
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Rafael Ferreira Leite de Mello
“RetriBlog: Um Framework Centrado na Arquitetura
para Criação de Blog Crawlers”
Trabalho apresentado ao Programa de Pós-graduação em
Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para
obtenção do grau de Mestre em Ciência da Computação.
Orientador: Frederico Luiz Gonçalves de Freitas
Co-Orientador: Patrick Henrique da Silva Brito
RECIFE, Dezembro/2011
Agradecimentos
Gostaria de agradecer e dedicar essa dissertação à minha família que sempre incentivou os
meus estudos mesmo com a distância. Aos professores Fred Freitas e Patrick Brito, que
foram bons orientadores mesmo estando longe em alguns momentos. À Rinaldo Lima
que colaborou muito com orientação, pesquisa e escrita de artigos. À Dimas e Hilário
que participaram de discussões e implementações. Por fim, a todos os meus Amigos que
me ajudam a buscar o verdadeiro Sonho.
iii
Resumo
Com o grande crescimento da Web, foram criados inúmeros mecanismos para interação
entre os usuários. Tal fenômeno ficou conhecido como Web 2.0, onde o conhecimento
é gerado através da interação dos usuários, fazendo uso da inteligência coletiva. Sob
uma perspectiva da Web 2.0, diversas ferramentas colaborativas se tornaram populares,
dentre elas podemos destacar: os blogs. Atualmente, há mais de 133 milhões de blogs
e a cada dia são criados centenas deles. Além disto, a atividade nos blogs dobra a cada
duzentos dias, sendo este fenômeno social conhecido como Blogosfera. A partir do
conhecimento gerado na Blogosfera, as potencialidades de aplicações e decisões que
podem ser tomadas através destas informações tornam-se inúmeras. Entretanto, torna-se
impraticável utilizar as informações disponíveis na Blogosfera de forma manual. Com
isso, mostra-se fundamental utilizar abordagens computacionais para auxiliar nessa tarefa.
Uma primeira tarefa a ser realizada é encontrar blogs relevantes em meio a essa
grande quantidade de blogs. Para lidar com esse problema a área de recuperação de
informação(RI) se destaca em relação às demais, pois a mesma se preocupa em identificar
textos relevantes para uma determinada busca dentro de uma grande coleção de textos. É
importante destacar que para facilitar o acesso aos documentos, existe necessidade de
indexar e armazenar os textos dos blogs. Tal mecanismo é realizado por uma entidade de
software conhecido como web crawlers. Especificamente no contexto de blogs, os web
crawlers são chamados de blog crawlers.
Diante desse cenário, este trabalho propõe um framework centrado na arquitetura
para construção de blog crawlers. Por um lado, utilizar um framework centrado na
arquitetura provê principalmente os seguintes aspectos: i) criação de uma aplicação
genérica e facilmente configurável; ii) alto grau de reuso dos componentes; iii) facilidade
na evolução. O blog crawler criado possui as seguintes características: i) extrai o conteúdo
principal do blog, eliminando propagandas e menus. Isto é feito utilizando algoritmos de
extração de conteúdo disponibilizados no sistema; ii) o sistema dispõe de algoritmos de
pré-processamento para melhorar a precisão e cobertura; iii) serviços auxiliares também
são disponibilizados, como por exemplo serviço para recomendação de tag.
Para validar a proposta foram criados três estudos de caso. Além disto, os principais
algoritmos disponibilizados foram testados e avaliados. Por fim, é apresentado uma
análise qualitativa, mostrando as vantagens de se usar a engenharia de software, e
quantitativa, para validar o uso de inteligência artificial. Os resultados obtidos mostram a
eficiência dos principais algoritmos propostos.
iv
Palavras-chave: Recuperação de informação; Rastreadores de Blogs; Arcabouço
v
Abstract
With the huge growth of the World Wide Web, several mechanisms for user interaction
were created. This phenomenon became known as Web 2.0, in which knowledge is
generated through user interaction, making use of the collective intelligence. From the
perspective of the Web 2.0, many collaboration tools have become popular. In this M.Sc.
dissertation, the importance of blogs is highlight. Currently, there are over 133 million
blogs and hundreds of them are created every day. Moreover, the activity in blogs doubles
every two hundred days; such phenomenon is known as the Blogosphere. From the
knowledge generated in the blogosphere, the potential applications and decisions can be
taken through this information become numerous. However, it is impracticable to use
the information available in the Blogosphere manually. Therewith, it is crucial to use
computational approaches to assist in this task.
The first task is to find relevant blogs in blogosphere. In order to deal with this
problem the information retrieval (IR) area stands forward in relation to others, because it
is concerned with identifing relevant text to a specific query in a large collections of texts.
To facilitate the access to documents, it is necessary to index and store the text of blogs.
This mechanism is performed by a software entity known as web crawlers. Specifically
in the context of blogs, web crawlers are called blog crawlers.
In this context, this M.Sc. dissertation proposes an architecture-centered framework
for building blog crawlers. This work uses aspects from software engineering and artificial
intelligence to solve the afore mentioned problem. On the one hand, an architecturecentered framework provides the following aspects: i) creation of a generic and easily
configurable application, ii) high degree of components reuse, and iii) ease of system
evolution. The blog crawler created has the following characteristics: i) extracts the main
content of the blog, eliminating advertisements and menus. This is done using content
extraction algorithms available in the system, ii) the system has pre-processing algorithms
to improve precision and recall, iii) Auxiliary services are also available, such as tag
recommendation service.
Three case studies were created in order to validate the proposal. The main algorithms available were tested and evaluated. Finally, a qualitative assessment is presented,
showing the advantages of using software engineering, and quantitative, to validate the
use of artificial intelligence. The results show the efficiency of the proposed algorithms.
Keywords: Information Retrieval; Blogs Crawlers; Framework
vi
Sumário
Lista de Figuras
viii
Lista de Tabelas
ix
1
Introdução
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
4
5
2
Embasamento Teórico
2.1 Visão Geral da Blogosfera . . . . . . . . . . . . . .
2.1.1 Quem são os blogueiros? . . . . . . . . . . .
2.1.2 Quais os motivos para escrever um blog? . .
2.2 Recuperação de Informação . . . . . . . . . . . . .
2.3 Web Crawler . . . . . . . . . . . . . . . . . . . . .
2.3.1 Fluxo de atividades . . . . . . . . . . . . . .
2.3.2 Arquitetura . . . . . . . . . . . . . . . . . .
2.3.3 Crawlers sociais . . . . . . . . . . . . . . .
2.4 Classificação . . . . . . . . . . . . . . . . . . . . .
2.5 Projeto de Software com Reuso . . . . . . . . . . . .
2.5.1 Framework . . . . . . . . . . . . . . . . . .
Framework versus Bibliotecas de Classes . .
Framework versus Padrões de Projeto . . . .
Modelo de Características . . . . . . . . . .
2.5.2 Desenvolvimento Baseado em Componentes
Metodologia COSMOS* . . . . . . . . . . .
2.5.3 Arquitetura de Software . . . . . . . . . . .
2.5.4 Desenvolvimento Centrado na Arquitetura . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
RetriBlog: Um Framework Centrado na Arquitetura para Criação de Blog
Crawlers
3.1 Visão Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Projeto Arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Especificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Serviços Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
7
8
9
11
12
13
13
14
16
17
21
21
21
22
23
25
27
28
28
30
33
34
vii
3.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
38
39
40
42
42
44
45
45
45
46
46
46
46
46
Estudos de Caso
4.1 Estudo de Caso 1: Sistema Baseados em Agentes para Recuperar Blogs
da Tecnhorati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Configuração dos Agentes . . . . . . . . . . . . . . . . . . . .
4.1.2 Configuração do Framework . . . . . . . . . . . . . . . . . . .
4.1.3 Execução da Aplicação . . . . . . . . . . . . . . . . . . . . . .
4.2 Estudo de Caso 2: Sistema de Recomendação de Blogs . . . . . . . . .
4.2.1 Configuração do Framework . . . . . . . . . . . . . . . . . . .
4.2.2 Criação do Sistema de Recomendação . . . . . . . . . . . . . .
4.2.3 Execução da aplicação . . . . . . . . . . . . . . . . . . . . . .
4.3 Estudo de Caso 3: Rastreador de Notícias para Clipagem . . . . . . . .
4.3.1 Configuração do Arcabouço . . . . . . . . . . . . . . . . . . .
4.4 Discussão Sobre os Estudos de Caso . . . . . . . . . . . . . . . . . . .
47
47
47
48
51
52
52
55
56
58
59
61
Experimentos e Resultados Preliminares
5.1 Avaliação: Extração de Conteúdo . . . . . . . . . . . . . . . . . . . . .
5.2 Avaliação: Classificação . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Avaliação: Recomendação de Tags . . . . . . . . . . . . . . . . . . . .
63
63
66
68
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
4
5
Serviços de Aplicação . . . . . . . . . . . . .
3.5.1 Coletor de URL . . . . . . . . . . . .
3.5.2 Extração de Conteúdo . . . . . . . .
3.5.3 Pré-Processamento . . . . . . . . . .
3.5.4 Classificação . . . . . . . . . . . . .
3.5.5 Recomendação de tags . . . . . . . .
3.5.6 Indexação . . . . . . . . . . . . . . .
Ferramentas e Persistência . . . . . . . . . .
Implementação . . . . . . . . . . . . . . . .
Como Criar uma Aplicação com o RetriBlog .
1º Passo . . . . . . . . . . . . . . . . . . . .
2º Passo . . . . . . . . . . . . . . . . . . . .
3º Passo . . . . . . . . . . . . . . . . . . . .
4º Passo . . . . . . . . . . . . . . . . . . . .
5º Passo . . . . . . . . . . . . . . . . . . . .
6º Passo . . . . . . . . . . . . . . . . . . . .
7º Passo . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
viii
5.4
6
7
Avaliação: COSMOS* . . . . . . . . . . . . . . . . . . . . . . . . . .
Trabalhos Relacionados
6.1 COSMOS* . . . . . . . . . . . . . . . . . .
6.2 Serviços de Recomendação de Tags . . . . .
6.3 Serviços de Classificação . . . . . . . . . . .
6.4 Sistema para Recuperar Informações de Blogs
72
.
.
.
.
75
75
77
78
79
Conclusão
7.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Palavras Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Publicações relacionadas ao RetriBlog . . . . . . . . . . . . . . . . . .
83
83
84
84
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
Lista de Figuras
2.1
2.2
2.3
2.4
Assuntos blogados(Adaptado de (Technorati, 2009)) . . . . . . . . . . .
Fluxo de um Processo Básico de RI . . . . . . . . . . . . . . . . . . .
Fluxo básico de um crawler (Adaptado de (Pant et al., 2004)) . . . . . .
Arquitetura básica de um crawler (Adaptado de (Shkapenyuk and Suel,
2002)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo de Características (Adaptado de (Ana Elisa Lobo and Rubira,
2007)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemplo de Componente COSMOS* (Gayard et al., 2008) . . . . . . .
Exemplo configuração arquitetural em UML ( Adaptada de (Sommerville,
2001)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
12
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Visão Geral do Framework . . . . . . . . . . . . . . . . . .
Visão Geral da Arquitetura do RetriBlog . . . . . . . . . . .
Modelo de Características de RetriBlog . . . . . . . . . . .
Arquitetura dos Compoentes do Framework . . . . . . . . .
Arquitetura dos Compoentes do Framework - Detalahada . .
Fluxo Básico do Crawler . . . . . . . . . . . . . . . . . . .
Página relacionada da Technorati relacionada a tag educação
Exemplo de Componente - Similaridade . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
31
34
35
36
37
45
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
Arquitetura dos Agentes . . . . . . . . . . . .
Diagrama de Componentes - Estudo de Caso 1 .
Tela do Jade . . . . . . . . . . . . . . . . . . .
Diagrama de Componentes - Estudo de Caso 2 .
Diagrama de Atividades . . . . . . . . . . . . .
Postagem do Professor . . . . . . . . . . . . .
Postagem dos Alunos . . . . . . . . . . . . . .
Gráfico das Interações no Fórum . . . . . . . .
Semelhança entre Blog e Site de Notícias . . .
Diagrama de Componentes - Estudo de Caso 3 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
49
51
53
56
57
57
57
58
59
5.1
Resultado da Classificação: CE = Extração de Conteúdo; P = PréProcessamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Influência da Extração de Conteúdo e do Pré-Processamento no Algoritmo de Naive Bayes . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5
2.6
2.7
5.2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
22
24
25
67
67
x
5.3
Resultado Similaridade . . . . . . . . . . . . . . . . . . . . . . . . . .
70
xi
Lista de Tabelas
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Avaliação - Extração de Conteúdo . . . . . . . . . . . . . . . . .
Distribuição das Categorias . . . . . . . . . . . . . . . . . . . .
Tempo para Execução da Classificação . . . . . . . . . . . . . .
Distribuição das Tags no Dataset . . . . . . . . . . . . . . . . . .
Regras Geradas pelo Serviço de Recomendação por Similaridade
Regras Geradas pelo Serviço de Recomendação por Dicionário .
Regras Geradas pelo Serviço de Recomendação por Classificação
Regras Geradas pelo Serviço de Recomendação por Agrupamento
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
66
68
69
70
70
71
71
6.1
6.2
Comparação entre tecnologias de componentes . . . . . . . . . . . . .
Comparação dos Trabalhos Relacionados e o RetriBlog . . . . . . . . .
76
82
xii
1
Introdução
A Web 2.0 (O’Reilly, 2005) está mudando a maneira como os usuários interagem com
a informação. Ela permite que eles se tornem uma parte ativa da Web através de novas
ferramentas que permitem a criação e gerenciamento de conteúdo de forma colaborativa.
Alguns exemplos de ferramentas da Web 2.0 são wikis, fóruns, blogs, twitter. Entre essas
a importância dos blogs devem ser enfatizados.
“Um blogueiro necessita apenas de um computador, acesso à Internet e uma opinião (Rosenbloom, 2004)” e “Blogs tornaram-se tão ubíquos que o termo é sinônimo
de ‘site pessoal’ (Blood, 2004)” são duas frases retiradas do journal especial da ACM1
chamado Blogosphere2 . Elas claramente apresentam o principal motivo pelo qual o blog
é largamente adotado: a simplicidade.
Além disso, de acordo com um relatório realizado pela Technorati 3 em 2008 (Technorati, 2008), já havia mais de 133 milhões de blogs indexados somente por essa empresa.
Este mesmo relatório mostrou que a atividade nos blogs dobra a cada duzentos dias e
novecentos mil postagens são escritas diariamente.
Outras empresas como a Blog Pulse4 e Blog Scope5 também tem estatísticas interessantes. A primeira de mais de 160 milhões de blogs indexados e mais de sessenta mil são
criados todos os dias. Já a segunda indexa aproximadamente 53 milhões de blogs e mais
de um trilhão de postagens.
Devido ao grande volume de dados gerados nos blogs, torna-se impraticável utilizar
as informações disponíveis na Blogosfera de forma manual. Assim, é fundamental a
1 Association
for Computing Machinery-http://www.acm.org/
in: http://portal.acm.org/toc.cfm?id=1035134&type=issue&coll=GUIDE&dl=GUIDE
&CFID=97672162&CFTOKEN=83186061
3 http://technorati.com/
4 http://www.blogpulse.com/
5 http://www.blogscope.net/
2 Avaliable
1
utilização de abordagens computacionais para auxiliar nessa tarefa. Essas informações
podem ser: preferências do usuário, quais assuntos estão sendo tratados na blogosfera,
textos interessantes para determinados domínios (Xiong and Wang, 2008). Com isso elas
podem ser usadas por empresas para determinar se um produto dela está sendo bem aceito
na blogosfera (Geun Chol Moon, 2010). Outro exemplo seria usar blogs educacionais
para ajudar em ambientes de ensino (Qiao et al., 2009; Yang, 2008). Por esta razão,
vários estudos para lidar com o problema de automatização estão sendo desenvolvidos.
Técnicas como processamento de linguagem natural (Abney, 1991), recuperação de
informação (Manning et al., 2008) e extração de informação (Gaizauskas and Wilks,
1998) são algumas abordagens que procuram obter informações interessantes de textos
de forma automática.
Com relação a obtenção de documentos, a área de recuperação de informação (RI)
se destaca em relação às demais (Hotho et al., 2005), mesma se preocupa em identificar
textos relevantes para uma determinada busca, dentro de uma grande coleção de textos6 .
É importante destacar que para facilitar o acesso aos documentos, existe necessidade de
indexar e armazenar os textos dos blogs. Tal mecanismo é realizado por uma entidade de
software conhecido como Web Crawler (Arasu et al., 2001). Especificamente no contexto
de blogs, são chamados de Blog Crawler.
Entretanto, para criação de um blog crawler deve-se levar em consideração vários aspectos, como: i) idioma do blog; ii) engenho de busca7 ; iii) técnicas de pré-processamento
e indexação que serão aplicadas aos textos do blog; iv) empresa estruturadora8 , entre
outros.
Devido à variabilidade e quantidade dos blogs é necessário construir uma abordagem
genérica para lidar com essas questões. Para tratar esse problema uma abordagem que
já vem sendo utilizado em outros trabalhos é a criação de um framework (Johnson and
Foote, 1988). Duas obras lidam com estes problemas (Chau et al., 2009; Ferreira et al.,
2010b). No entanto, estes dois frameworks não seguem alguns princípios de engenharia
de software, como por exemplo a rastreabilidade explícita entre arquitetura de software e
implementação, que facilita, por exemplo, a evolução do framework.
Para isso, uma abordagem centrada na arquitetura é uma solução. Desenvolver um
sistema centrado na arquitetura (Garlan and Shaw, 1994) tem inúmeras vantagens, por
exemplo:
6 Existem
vários algoritmos que recuperam e organizam dados como: PageRank (Brin and Page, 1998),
Anchor Text (Brin and Page, 1998), Kleinberg’s HITS (Kleinberg, 1999), entre outras.
7 Technorati, Icerocket, entre outros
8 Facebook, Blogger, entre outros
2
• Controle de complexidade, como o sistema é documentado a cada etapa e a arquitetura é bem definida a complexidade diminui, abordagem top-down;
• O desenvolvedor não precisa se preocupar com detalhes do código, mas apenas
com a arquitetura;
• facilita a evolução e instanciação do sistema, utilizando essa abordagem o desenvolvedor só precisa definir uma configuração arquitetural para instanciar o sistema, e
para acrescentar um componente ele não precisa saber detalhes da implementação
de outros.
Esta abordagem vem preencher a lacuna deixada pelos sistemas citados acima. Com
ela a rastreabilidade entre arquitetura e código é bem definida.
Além deste problema, outros problemas básicos como extrair o conteúdo principal
dos blogs e recomendar tags para as postagens também são um desafio para conseguir
informações interessantes dos blogs. Para resolver o primeiro problema é necessário criar
algoritmos que possam detectar o conteúdo principal de uma página HTML qualquer
sem nenhuma informação prévia.
Já o segundo lida, principalmente, com o problema de alinhamento de tags. O mesmo
blog pode ser marcado com tags diferentes devido a diferenças na cultura, conhecimento
e experiências dos usuários (Subramanya and Liu, 2008). Ainda, de acordo com (Golder
and Huberman, 2006), três tipos de problemas podem ocorrer: i) sinonímia: quando
existem múltiplas palavras com o mesmo significado; ii) polissemia: a mesma palavra
pode se referir a conceitos diferentes; iii) variação de nível básico da tag: variação
da granularidade da tag. Um exemplo deste último tipo de problema surge quando um
blogueiro posta sobre o seu animal de estimação; ele pode atribuir tags gerais, como
"animal"ou "animal doméstico"ou aqueles específicos, como "cachorro"e "gato".
Por um lado, para lidar com o primeiro problema, tem sido implementado algoritmos
que lidam com problema de extração de conteúdo, são eles: Boilerplate (Kohlschütter
et al., 2010), Document Slope Curve (DSC) (Pinto et al., 2002) e Text-to-Tag Ratio (TTR)
(Weninger and Hsu, 2008), bem como a heurística Link Quota Filter (LQF) (Gottron,
2007) que estão entre os algoritmos mais eficientes para extração de conteúdo. Além
disso, os algoritmos citados têm propriedades muito desejadas no contexto da pesquisa,
incluindo a independência em relação a estrutura dos blogs. Isto também nos permite
aplicá-los a outros tipos de páginas HTML (por exemplo, notícias), independência da
idioma, e rápido tempo de execução.
3
1.1. OBJETIVOS
Por outro lado, para recomendar tags, este trabalho propõe quatro serviços de sugestão
de tags. Esses serviços são classificados em abordagens baseados em tags e baseados em
postagem. Estes serviços lidam com esse problemas de maneira diferente, permitindo
assim aos usuários escolher o tipo apropriado de serviço de acordo com suas necessidades.
Por exemplo, se o usuário tiver um corpus com pouco ruído, ele pode usar um serviço
baseados na postagem para alcançar melhores resultados. Por outro lado, se ele precisa
de uma implementação rápida, os serviços baseados em tags são mais apropriados.
Neste contexto, este trabalho propõe um framework chamado RetriBlog para criar
blog crawlers usando uma abordagem centrada na arquitetura e seguindo o modelo de
implementação COSMOS*(Gayard et al., 2008). Este framework lida com os problemas
mencionados acima e com questões relacionadas com a engenharia de software, tais
como uma melhor evolução e facilidade para instanciar o framework em uma aplicação
de software.
1.1
Objetivos
O principal objetivo deste trabalho é propor um framework centrado na arquitetura
para construção de blog crawlers. Este framework visa disponibilizar serviços de préprocessamento, indexação, extração de conteúdo, entre outros. Desta forma, o trabalho
lida tanto com aspectos mais gerais como facilitar a criação de um blog crawler como
com problemas específicos como alinhamento de tags. As contribuições do trabalho
podem ser divididas em duas grandes áreas da computação: Inteligência Artificial e
Engenharia de Software.
Por um lado, em relação a área de Inteligência Artificial, as contribuições são as
seguintes:
• Construção de mecanismos para recuperar e indexar textos de blogs e informações
como título do texto e preferências do usuário (blog crawlers);
• Implementação de algoritmos para extração de conteúdo em páginas HTML;
• Criação de serviços de recomendação de tags para blogs;
• Estudo e avaliação sobre a influência da utilização de algoritmos de extração de
conteúdo e pré-processamento no desempenho de classificação de páginas HTML.
Por outro lado, as contribuições na área de Engenharia de Software são:
4
1.2. ORGANIZAÇÃO DO TEXTO
• Utilizar uma abordagem centrada na arquitetura para criação do framework;
• Utilização de componentes seguindo o modelo COSMOS*;
• Criação de estudos de caso para avaliar as possíveis vantagens do uso das abordagens centrada na arquitetura e COSMOS*.
1.2
Organização do texto
Esta dissertação está dividida em sete capítulos. O Capítulo 1 introduz a problemática e os
objetivos do trabalho proposto. No Capítulo 2 são apresentados os conceitos relacionados
ao tema deste trabalho. A teoria básica acerca de blogs, recuperação de informação, web
crawlers, algoritmos de classificação, projeto de software centrado na arquitetura e uma
breve explicação sobre alguns diagramas que serão utilizados para explicar o framework
proposto e sobre o COMSOS*.
O Capítulo 3 mostra como o RetriBlog foi criado descrevendo em detalhes cada
um dos seus serviços e funcionalidades. Neste capítulo também é mostrado como o
framework foi implementado, para isso são usados vários tipos de diagramas.
Depois no Capítulo 4, 3 estudos de caso são detalhados para mostrar toda a flexibilidade do framework. Nele também são mostrados trechos de código para evidenciar a
facilidade de instanciação do framework. No Capítulo 5 mostra os experimentos realizado
com os algoritmos de extração de conteúdo, recomendação de tag e classificação. Por
fim o capítulo faz uma avaliação do uso do COSMOS*.
No Capítulo 6, são apresentados trabalhos relacionados ao framework proposto, à
utilização do COSMOS*, e aos algoritmos de extração de conteúdo, recomendação de tag
e classificação. Na conclusão do capítulo uma tabela mostra as principais diferenças do
trabalho com os principais sistema encontrados. Por fim, no Capítulo 7, são apresentadas
as considerações finais deste trabalho, alguns trabalhos futuros são definidos e é mostrado
uma lista de publicações relativas ao RetriBlog.
5
2
Embasamento Teórico
O objetivo deste capítulo é apresentar ao embasamento teórico referente ao foco deste
trabalho, fazendo uma pequena introdução sobre conceitos correlacionados. O capítulo
divide-se em duas partes, na primeira são levantados aspectos tecnológicos envolvidos
com o trabalho, já a segunda trata de questões relacionadas a engenharia de software. Na
Seção 2.1 serão discutidas algumas motivações para utilizar os blogs e o que está acontecendo na blogosfera. Na seção seguinte, serão apresentados conceitos sobre recuperação
de informação que serão utilizados na proposta do trabalho. Na Seção 2.3 serão discutidos
aspectos relacionados aos web crawlers, suas definições e características. A seção 2.4
mostra uma visão geral sobre classificação supervisionada e os algoritmos usados no
RetriBlog. A última seção trata de definições ligadas à engenharia de software. Nela são
abordadas características relacionadas a projetos de software com reuso, com enfoque
em framework 2.5.1, desenvolvimento baseado em componentes 2.5.2, arquitetura de
software 2.5.3 e desenvolvimento centrado na arquitetura 2.5.4.
2.1
Visão Geral da Blogosfera
Blogosfera é o nome dado a toda a comunidade de blogs na Internet, é parte da infraestrutura pela qual idéias são desenvolvidas e transmitidas. Os blogs são, essencialmente,
apenas o texto publicado dos pensamentos de um autor, enquanto a blogosfera é um
fenômeno social.
Para usar um blog é necessário apenas um computador, acesso a Internet e uma
opinião (Rosenbloom, 2004). Essa frase mostra bem algumas das principais motivações
de se usar blogs, a facilidade e velocidade que o usuário, chamado de blogueiro (do inglês
Blogger), tem de participar desse fenômeno. Além disso, é importante frisar que os blogs
foram uma das primeiras mídias que começaram a mudar o paradigma de comunicação.
6
2.1. VISÃO GERAL DA BLOGOSFERA
Antes era comum encontrar meios de comunicação em uma só via, por exemplo o jornal.
Os textos eram publicados nos jornais e os leitores quase sempre não podiam dar opiniões.
Até mesmo na Internet, os sites eram feitos apenas para se apresentar um conteúdo e não
para receber os comentários sobre eles. Com os blogs isso começa a mudar. A facilidade
para postar opiniões é tão grande quanto a para receber comentários.
O blog (uma contração da expressão "Web log") é um site cuja estrutura permite
a atualização rápida a partir de acréscimos dos chamados artigos, ou postagens. Estes
são, em geral, organizados de forma cronológica inversa, tendo como foco a temática
proposta do blog, podendo ser escritos por um número variável de pessoas, de acordo
com a política do blog (Blood, 2004). Dessa forma, os blogs se tornaram ferramentas tão
ubíquas que são tratados como sites pessoais.
Em 2008, uma pesquisa da Technorati, empresa indexadora de blogs chegou a conclusões interessantes sobre o tamanho da blogosfera. Todos os estudos comprovam que
os blogs são um fenômeno global que atingiu a Web. Nessa pesquisa podemos perceber
fatos relevantes como a grande quantidade de postagens que são escritas diariamente,
novecentos mil, e existem mais de 133 milhões de blogs indexados pela Technorati entre
os anos de 2002 e 2008. De acordo com a mesma estimativa a atividade nos blogs
dobra a cada duzentos dias. Além disto, outras empresas como a Blog Pulse1 e Blog
Scope2 também tem estatísticas interessantes. A primeira possui mais de 160 milhões de
blogs indexados e mais de sessenta mil são criados todos os dias. Já a segunda indexa
aproximadamente 53 milhões de blogs e mais de um trilhão de postagens.
Duas perguntas devem ser feitas sobre os blogs: i) Quem são os blogueiros? e ii)
Quais os motivos para escrever um blog? Elas serão respondidas nas subseções a seguir.
2.1.1
Quem são os blogueiros?
A palavra blogueiros se refere às pessoas que escrevem em blogs. Segundo pesquisa de
(Technorati, 2008), os blogueiros em geral, fazem parte de um grupo altamente educado
e rico. Quase metade de todos os blogueiros examinados possuem um diploma de pósgraduação, e a maioria tem uma renda familiar de US $ 75,000 ou superior por ano. Além
destes dados, outras características interessantes são:
• Dois terços são do sexo masculino;
• 60% tem idade entre 18-44;
1 http://www.blogpulse.com/
2 http://www.blogscope.net/
7
2.1. VISÃO GERAL DA BLOGOSFERA
• A maioria são mais ricos e educados do que a população em geral;
• 75% têm diploma universitário;
• 40% têm pós-graduação;
• profissionais independentes que são blogueiros possuem alta renda familiar. Cerca
de metade tem uma renda familiar anual de 75,000 dólares e um terço superara o
nível de 100,000 dólares.
Algumas destas características indicam que as pessoas que estão utilizando os blogs
são qualificadas, com isso os textos publicados fornecem informações interessantes.
2.1.2
Quais os motivos para escrever um blog?
Troca de experiência de auto-expressão continuam a ser as principais motivações para
blogueiros, e 70% dos inquiridos dizem que a satisfação pessoal é uma maneira de medir
o sucesso de seu blog (Technorati, 2009). Entre os blogs profissionais, no entanto, a
principal métrica de sucesso é o número de visitantes únicos. Blogueiros comuns tendem
a escrever sobre reflexões e opiniões pessoais, enquanto os profissionais tendem a ser
mais atuais.
A ascensão do blogueiro profissional continua, 70% dos funcionários em tempo
parcial e trabalhadores autônomos estão postando mais do que nunca, enquanto os
blogueiros comuns são um pouco menos. O principal motivo para diminuir a atividade dos
blogueiros foi o aumento do trabalho e dos compromissos familiares (64%). Blogueiros
descrevem significativos impactos positivos em suas vidas pessoais, mas os blogueiros
mais experientes têm de carreira e os impactos positivos do negócio. 70% dizem que
eles são mais conhecidos em sua indústria por causa de seu blog. A diversidade da
blogosfera, Figura 2.1, refletem na questão do assunto da postagem - mesmo tendo 23
opções, incluindo a maioria dos grandes campos de instrução, 30% dos inquiridos dizem
que seu assunto principal é "Outro".
Diante do que foi exposto mostra-se necessário abordagens computacionais para
encontrar blogs relevantes em meio à essa grande quantidade de blogs. Uma possibilidade
para isso é utilizar recuperação de informação.
8
2.2. RECUPERAÇÃO DE INFORMAÇÃO
Figura 2.1 Assuntos blogados(Adaptado de (Technorati, 2009))
2.2
Recuperação de Informação
Recuperação de informação (RI) (Manning et al., 2008) pode ser definida como a procura
de textos interessantes para uma determinada busca dentro de uma grande coleção de
textos. Durante muito tempo essa área foi pouco explorada pela comunidade científica,
contudo após a popularização da Web, grandes empresas, como a Google e a Yahoo
surgiram e vários investimentos nessa área foram feitos.
As áreas de pesquisa na recuperação da informação envolvem modelagem, classificação e categorização da informação, arquitetura de sistemas, filtragem, linguagens
de consulta, entre outros. RI pode ser usado para: pesquisa na Web, recuperação de
informações pessoais e pesquisas em empresas, instituições ou na web sobre um domínio
específico (Baeza-Yates and Ribeiro-Neto, 1999). A Figura 2.2, mostra um fluxo de um
processo básico de recuperação de informação que foi tratado ao longo desta seção.
Figura 2.2 Fluxo de um Processo Básico de RI
O objetivo da recuperação da informação, nestas aplicações, é representar eficientemente a coleção de documentos que o usuário pretende interagir. Uma estrutura de dados
9
2.2. RECUPERAÇÃO DE INFORMAÇÃO
muito utilizada para representar tal coleção é a indexação invertida (Manning et al., 2008;
Hatcher and Gospodnetic, 2004). A idéia do índice invertido é construir uma tabela de
referência onde cada termo ocorrido no documento é usado como um item para a lista de
documentos que cada termo ocorre. Ele funciona como um índice remissivo de um livro,
ou seja, guarda as páginas que contém as palavras e não o contrário. Então na busca ao
invés de procurar página por página até encontrar a palavra, ele vai direto para as páginas
em que a palavra ocorre. Além disso, outro fator importante que deve ser armazenado é a
freqüência de um termo em determinado documento. Quando concluído o processo, o
índice invertido recebe o nome de dicionário.
Existem várias técnicas para se implementar os índices invertidos, por exemplo a
árvore B+ (Tenenbaum, 1995). Este tipo de árvore representa a ordenação de dados de
uma maneira que permita uma inserção e remoção eficiente de elementos. Desta forma
ela torna o processo de índice invertido eficiente.
Contudo, um problema é facilmente identificado neste processo: existem palavras
que têm pouco poder representativo no documento, por exemplo os artigos no português,
e outras palavras podem conter a semântica semelhante em um determinado contexto,
como as palavras no masculino e no feminino, no plural e no singular. Para resolver
esses problemas, antes de indexar, os documentos devem ser submetidos a um préprocessamento. Existem várias técnicas que procuram processar o texto antes de indexálos, entre elas estão (Hotho et al., 2005):
• Análise léxica: divide o documento em tokens e verifica palavra por palavra, trata
a retirada de símbolos não pertencentes à linguagem trabalhada, por exemplo
retirar código HTML (HyperText Markup Language) do texto, caracteres inválidos,
espaços em branco, entre outros;
• Filtragem: retira palavras do dicionário e dos documentos. A idéia desse método é
retirar palavras que contém pouco valor de informação (stop words). Por exemplo,
no português os artigos (a, o, um, uma...) possuem pouco valor para o texto, além
disso palavras que aparecem muito na coleção de documentos também poder ser
consideradas stop words pois não irão acrescentar valor significativo para as buscas;
• Lemmatization: métodos que tentam mapear os verbos para formas primitivas e
nomes para o singular. Contudo esta técnica ainda apresenta algumas dificuldades,
pois ela mantém no texto a palavra e cria uma estrutura, normalmente usam tags,
que contém as formas reduzidas, ou seja, ela não retira do texto a palavra original,
10
2.3. WEB CRAWLER
apenas marca aquela palavra com uma tag que vai conter uma palavra reduzida
relacionada a original.
• Stemming: mapeia a forma básica das palavras, como tirar o plural ou reduzir o
verbo obtendo o radical. Por exemplo no inglês os verbos são transformados para a
forma primitiva, traveling e traveled são transformados em travel. Um exemplo
em português é menino e menina que são transformados em menin;
• Remoção de spam: técnicas para encontrar e retirar do conjunto de documentos
textos que possuem pouco valor para a pesquisa ou domínio utilizado pelo usuário.
Depois do pré-processamento e criação do dicionário, utilizando o processo de índice
invertido, é necessário criar mecanismos de buscas e consultas, como por exemplo o
modelo booleano ou o modelo estatístico (Manning et al., 2008). Com este mecanismo o
usuário poderá recuperar qualquer documento que já esteja no dicionário através de uma
consulta.
Ferramentas como o Bow (McCallum, 1996) e Lemur (Lemur, 2009) possuem diversas funcionalidades de recuperação de informação, contudo o Lucene (Lucene, 2001) é a
ferramenta mais conhecida e completa que disponibiliza funcionalidades de recuperação
de informação em diversos idiomas.
Porém antes de realizar esses serviços com os blogs é necessário obter eles da Internet.
Para isso são usados web crawlers.
2.3
Web Crawler
Os sistemas de busca vem se tornando cada dia mais indispensáveis para obter informação
relevante da grande quantidade de dados que a Web disponibiliza. Os motores de
busca armazenam imensas coleções de páginas com ajuda dos web crawlers, que são
responsáveis por percorrer a Web através de links e colher dados que normalmente são
indexados para que o usuário possa executar consultas eficientemente (Arasu et al., 2001).
Segundo Gautam Pan (Pant et al., 2004) web crawler é um programa de computador
que explora a estrutura de grafo da Web para mover uma página para outra. Como já foi
dito, a maior motivação para idealizar os web crawlers foi recuperar as páginas da Web e
adicionar elas ou a representação delas em um repositório local para facilitar a busca do
usuário. Na sua forma mais simples um crawler parte de uma página e a partir daí utiliza
links externos para atingir as outras páginas.
11
2.3. WEB CRAWLER
Por detrás desta simples descrição, encontra-se uma série de questões relacionadas
com as conexões de rede, análise de páginas HTML, entre outros.
Se a Web fosse uma coleção estática de páginas, logo chegaria o momento em que
os crawlers não seriam mais necessários, visto que todas as páginas já estariam ligadas
a um repositório. Contudo, a Web é uma entidade dinâmica que evolui com taxas e
velocidades diferentes. Por isso existe a necessidade de continuar usando os crawlers.
Eles normalmente são os responsáveis por deixar o banco de dados de sistemas de busca
sempre atualizado.
A seguir, serão descritos detalhes sobre o fluxo atividades e arquitetura básica de um
web crawler.
2.3.1
Fluxo de atividades
A Figura 2.3 mostra o fluxo básico de atividades de um crawler, que é detalhado a seguir.
Figura 2.3 Fluxo básico de um crawler (Adaptado de (Pant et al., 2004))
• Inicializa fronteira com URLS: O frontier é a lista de coisas a fazer do crawler e
contém uma lista de URIs que ainda não foram visitadas. Para esta etapa pode ser
12
2.3. WEB CRAWLER
implementado, por exemplo, um esquema de escalonamento Fist In Fist Out(FIFO)
(Tanenbaum, 2007) para ordenar as URIs que serão acessadas;
• Checa finalização e Pega URL da fronteira: Verifica se a fronteira está vazia,
caso não esteja retorna a próxima URI a ser analisada;
• Recupera página: Obtém a página, normalmente através de uma requisição feita
por meio de um cliente HTTP. Trata erros de conexão e determina algumas características das páginas, como a última atualização;
• Processa página: Faz uma análise sintática na página para extrair informações
úteis e possivelmente guiar o próximo passo do crawler, além disso, procura
também eliminar informações pouco expressivas ou inúteis;
• Adiciona URLS a fronteira: Adiciona URIs, obtidas no passo anterior, à fronteira.
2.3.2
Arquitetura
A figura 2.4 apresenta os componentes básicos de uma arquitetura de um crawler.
Figura 2.4 Arquitetura básica de um crawler (Adaptado de (Shkapenyuk and Suel, 2002))
Nesta arquitetura existem dois componentes fundamentais que são os módulos de
aplicação e de sistema. O crawler de sistema tem a responsabilidade de ir até a Web e
obter as páginas. Por outro lado, o de aplicação é responsável por passar a lista de páginas
que devem ser baixadas e fazer as devidas operações com os dados obtidos pelo crawler
de sistema.
2.3.3
Crawlers sociais
Cada dia é maior a utilização de ferramentas sociais como: wikis, fóruns, blogs, ferramentas de relacionamento, entre outros. Estas ferramentas possuem informações que podem
13
2.4. CLASSIFICAÇÃO
ser valiosas se bem utilizadas, por exemplo, uma ferramenta de relacionamento descreve
algumas características dos usuários que podem ser usadas para traçar o perfil dele e criar
mecanismos de individualização de serviços.
Contudo, para isso é necessário mecanismos para obter informações dessas ferramentas. Aí que entra os crawlers sociais (Ying Ding and Yan, 2008), eles são similares
aos crawlers descritos anteriormente, mas possuem uma diferença fundamental, eles
são projetados para colher informações específicas das ferramentas e não a sua página
completa. Dentro desse contexto encontramos os blog crawlers, que são usados para
conseguir informações dos blogs (Agarwal et al., 2009).
Para lidar com todos os pontos de variabilidade encontrados nos blogs (idioma,
técnicas de pré-processamento que se deseja usar, empresa estruturadora, entre outros) se
faz necessário utilizar técnicas de engenharia de software para projetar o crawler.
2.4
Classificação
O objetivo de Classificação de Texto consiste em categorizar um conjunto de documentos,
com base no seu conteúdo, em um número fixo de categorias pré-definidas. Cada
documento pode ser atribuído a uma, várias ou nenhuma categoria (Sebastiani and
Delle Ricerche, 2002). Classificação supervisionada de texto é uma abordagem em que
um conjunto de documentos são previamente etiquetados em categorias já definidas; um
classificador (algoritmo de aprendizagem de máquina) é treinado sobre este conjunto
de documentos previamente rotulados; finalmente, o classificador treinado é capaz de
atribuir classes para novos documentos.
O algoritmo Naive Bayes é um classificador probabilístico, baseado no teorema de
Bayes (Mitchell, 1997). Ele assume que todos os atributos dos dados de treinamento
são independentes, ignorando possíveis dependências (Islam et al., 2007). Basicamente,
funciona da seguinte forma: primeiro, em uma fase de aprendizado, ele gera uma lista
de palavras com suas freqüências a partir do corpus de entrada. Cada palavra nesta
lista gerada é rotulada com a classe a que pertence, resultando em uma espécie de
"dicionário"para cada classe. Então, a partir deste dicionário de classes, é construída uma
árvore cujas folhas são classes e nós intermediários indicam probabilidades calculadas
de acordo com o teorema de Bayes. Finalmente, quando um novo texto é apresentado
ao classificador, ele percorre a árvore gerada até encontrar uma folha que indica a classe
que mais combinam com as palavras no texto de entrada. O classificador Naive Bayes
apresentou bom desempenho para a classificação de texto em muitos trabalhos de pesquisa
14
2.4. CLASSIFICAÇÃO
(Islam et al., 2007), (Roy et al., 2004; Aris Kosmopoulos and Androutsopoulos, 2008)).
No algoritmo KNN (Li Baoli and Qin, 2003) o classificador encontra k (em geral k é
um inteiro pequeno positivo) vizinhos mais próximos entre os documentos de treinamento
e a nova entrada, atribuindo a categoria da maioria dos vizinhos a este último. O algoritmo
funciona da seguinte forma: primeiro, é gerado uma lista de palavras com suas freqüências
a partir do corpus, com estes dados, um vetor é gerado para cada documento. Então, esses
vetores são colocados em um plano cartesiano criado pelo algoritmo. Finalmente, quando
um novo documento é apresentado ao classificador, que gera um vetor que representa
este novo documento e a distância é calculada para todos todos os vetores do plano. A
classe com mais votos ao longo dos k vizinhos mais próximos será a classe escolhida
para o documento de entrada. Muitas obras sobre o algoritmo KNN e suas variações têm
relatado que ele consegue um bom desempenho (Li Baoli and Qin, 2003, 2002; Yang and
Liu, 1999).
O algoritmo baseado TF/IDF (Salton and Buckley, 1988) é baseado nos pesos
de frequência do termo(TF do inglês Term-Frequency) e frequência inversa do documento(IDF do inglês Inverse Document Frequency). Esses pesos consistem em uma
medida estatística usada para avaliar o quão importante é uma palavra em um documento
dentro de uma coleção de documentos(corpus). Ele gera um vetor de freqüência para cada
classe com base no corpus. Este vetor contém termos e as freqüências em que ocorrem
em determinada classe. Então, o IDF do documento de entrada é calculado e um vetor
que representa ele é criado. Finalmente, a similaridade, usando cosseno (Markines et al.,
2009), entre este e os vetores que representam as classes são calculados. A classe que
tem mais semelhança com o documento de entrada é atribuída a ele.
Em outras palavras, dado um termo w, e uma página p, o seu TF-IDF é dado pela
equação abaixo:
T F − IDFw,p = T Fw,pxIDFw(3.1)
Temos que TFw,p e IDFw são:
15
2.5. PROJETO DE SOFTWARE COM REUSO
f reqnciaw
(3.2)
f reqnciaM
N
IDFw = log (3.3)
nw
T Fw,p =
Onde:
• M é o termo de maior freqüência na página p.
• N é o número total de documentos na coleção e n o número de documentos onde o
termo w ocorre.
É importante frisar que esse algoritmo por si só não faz a classificação. É necessário
o passo final de verificação de similaridade para a classificação ser realizada.
2.5
Projeto de Software com Reuso
O processo de projeto, na maioria das disciplinas de engenharia, tem como base o reuso
de componentes. No desenvolvimento do software cada vez mais é necessária uma
abordagem parecida, o software é considerado um ativo e o reuso dele é essencial para
aumentar o retorno de seus custos de desenvolvimento. Requisitos como menor custo de
produção e manutenção do software, maior rapidez na entrega e aumento da qualidade,
só podem ser atendidos pelo reuso generalizado e sistemático do software (Sommerville,
2004).
A engenharia de software baseado no reuso é uma abordagem para desenvolvimento
que tenta maximizar o reuso do software já existente. As unidades de software reutilizadas
podem ser, por exemplo (Sommerville, 2004):
• Reuso de sistemas de aplicações: Todo sistema de aplicação pode ser reutilizado
pela sua incorporação, sem mudanças, em outros sistemas ou pelo desenvolvimento
de famílias de aplicações;
• Reuso de componente: Os componentes de uma aplicação, que variam em tamanho incluindo desde subsistemas até objetos isolados, podem ser reutilizados;
• Reuso de funções: Os componentes de software que implementam uma única
função, como uma função matemática, podem ser reutilizados.
16
2.5. PROJETO DE SOFTWARE COM REUSO
As principais vantagens de utilizar sistemas baseados em reuso são apresentadas a
seguir (Sommerville, 2004):
• Maior confiabilidade: Componentes reutilizados normalmente são experimentados e testados em diferentes ambientes;
• Redução de riscos do processo: Recorrendo a um componente já existente, serão
menores as incertezas sobre os custos relacionados ao reuso desse componente do
que sobre custos de desenvolvimento;
• Uso efetivo de especialistas: Especialistas podem fazer componentes reusáveis
que englobem seus conhecimentos;
• Conformidade com os padrões: Alguns padrões podem ser implementados com
um conjunto de componentes-padrão;
• Desenvolvimento acelerado: O reuso de componentes acelera a produção, porque
o tempo de desenvolvimento e o de validação devem ser reduzidos.
Por outro lado também existem alguns problemas relacionados a esse tipo de desenvolvimento (Sommerville, 2004):
• Aumento nos custos de manutenção: Se o código fonte de um componente não
estiver disponível, então o custo de manutenção pode aumentar, uma vez que os
elementos reutilizados no sistema podem se tornar crescentemente incompatíveis
com as mudanças do sistema;
• Síndrome do "não-foi-inventado-aqui": Alguns engenheiros de software preferem reescrever componentes, pois acreditam que podem fazer melhor que o
componente reutilizável;
• Manutenção de uma biblioteca de componentes: Implementar uma biblioteca
de componentes e assegurar que os desenvolvedores de software utilizem essa
biblioteca pode ser dispendioso;
• Encontrar e adaptar componentes reutilizáveis: Os engenheiros de software
precisam ter uma razoável certeza de poder encontrar um componente, antes de
incluírem a rotina de busca de componentes como parte de seu processo normal de
desenvolvimento.
17
2.5. PROJETO DE SOFTWARE COM REUSO
Dentro do projeto de software com reuso algumas abordagens, muitas vezes complementares, são muito utilizadas. As próximas seções abordam os seguintes temas:
Arcabouço, desenvolvimento usando componentes, arquitetura de software e desenvolvimento centrado na arquitetura.
2.5.1
Framework
Existem várias definições de framework, sendo que as mais famosas são as de Ralph E.
Johnson (Johnson and Foote, 1988; Johnson, 1997), que dizem: i) Um framework é um
conjunto de classes que incluem um projeto abstrato para soluções de uma família de
problemas relacionados; ii) Um framework é um conjunto de objetos que colaboram para
realizar um conjunto de responsabilidades para um domínio de aplicação, um esqueleto
de uma aplicação que pode ser customizada pelo desenvolvedor.
Destas definições podemos listar algumas características de um framework:
• Reusa o projeto de software e não apenas o código;
• Não é uma aplicação, e sim, um arcabouço para construir aplicações num domínio
específico;
• É um framework voltado para um determinado domínio;
• Resolve problemas de uma mesma natureza;
• São aplicações incompletas.
Além das características citadas a partir das definições acima, outras devem ser
ressaltadas, são elas (Sauvé, 2000; Fayad et al., 1999):
• Reusabilidade: Este é o propósito final do framework, mas para ser reusável antes
tem que ser usável, por isso ele tem que ser bem documentado e fácil de usar;
• Extensibilidade: Deve conter funcionalidade abstrata (sem implementação) que
deve ser completada. Desta forma, inúmeras aplicações podem ser instanciadas
com base no mesmo framework;
• Completude: Precisa endereçar o domínio do problema pretendido;
• Inversão de controle: A inversão do controle é uma característica fundamental na
arquitetura de um framework. Ela permite determinar que conjunto de métodos
18
2.5. PROJETO DE SOFTWARE COM REUSO
de uma aplicação específica deve ser chamado pelo framework. Quem define o
controle de fluxo é o framework.
Os framework podem ser classificados de várias maneiras, por exemplo, em relação a
onde ele é usado (Sauvé, 2000):
• Framework de suporte: Provê serviços de nível de sistema operacional, como
acesso a arquivos ou computação distribuída;
• Framework de aplicação: São também conhecidos como framework horizontais.
Esses fornecem funcionalidades que são aplicadas a uma variedade de problemas.
São utilizados em mais de um domínio. Por exemplo um framework para construção
de interface GUI;
• Framework de domínio: São também conhecidos como framework verticais. Esses fornecem funcionalidades que são aplicadas num domínio específico. Por
exemplo, framework para construir aplicações de controle de manufatura.
Eles também podem ser classificados em relação à técnica de extensão (Fayad et al.,
1999):
• Framework caixa branca: Estão fortemente ligado às características das linguagens, para realizar a customização utilizam-se de herança. Requer um bom entendimento do framework para criar uma aplicação;
• Framework caixa preta: São instanciados a partir de algum tipo de configuração,
como XML por exemplo. Esses frameworks confiam principalmente em composição (classes ou componentes) e delegação para realizar customização. Não requer
entendimento de detalhes internos para produzir uma aplicação;
• Framework caixa cinza: São framework projetados para evitar as desvantagens
apresentadas por framework caixa branca e caixa preta, permitindo certo grau de
flexibilidade e extensibilidade sem expor informações internas desnecessárias.
Para projetar um framework é necessário estar atento a algumas propriedades, como
(Clements and Northrop, 2001):
• Núcleo do framework: Conjunto de classes que juntas colaboram para implementar
uma arquitetura de família de sistemas;
19
2.5. PROJETO DE SOFTWARE COM REUSO
• Pontos de extensão: Admite pontos de extensão, normalmente, na forma de classes
abstratas ou interfaces;
• Controle de Fluxo da Aplicação: O fluxo é definido pelas classes que estão no
núcleo, e elas são responsáveis por invocar as classes que estendem os pontos de
extensão;
• Hot Spots: São as partes flexíveis de um framework, estes pontos são passíveis de
extensão. Hot spots são invocados pelo framework, ou seja, classes (implementadas
pelo programador da aplicação) recebem mensagens de uma classe do framework
(frozen spot). Isso geralmente é implementado através de herança e de métodos
abstratos;
• Frozen Spots: Partes fixas de um framework, fornece os serviços já implementados
do framework. Normalmente realizam chamadas indiretas aos hot spots.
Algumas vantagens de utilizar os framework são (Sauvé, 2000; Sommerville, 2004):
1. Menos código para projetar e escrever;
2. Redução de custos e do tempo de desenvolvimento;
3. Código mais confiável e robusto;
4. Manutenção reduzida e evolução facilitada;
5. Melhor consistência e compatibilidade entre aplicações;
6. Estabilização do código (menos defeitos) devido ao uso em várias aplicações.
Por outro lado também podemos citar algumas desvantagens de se trabalhar com
framework (Sauvé, 2000; Sommerville, 2004):
• Requer mais esforço para construir;
• Benefícios são realizados em longo prazo;
• Precisa modificar o processo de desenvolvimento e criar novos incentivos;
• Requer documentação, manutenção e suporte.
20
2.5. PROJETO DE SOFTWARE COM REUSO
A documentação do framework é um dos fatores que podem definir o sucesso dele. Ela
precisa se adaptar a diferentes públicos, para isso deve ter diferentes níveis de abstração.
Quatro tópicos não podem deixar de ser documentados (Markiewicz and Lucena, 2001):
• Propósito, que contém uma breve descrição do framework e o domínio do problema
para o qual foi desenvolvido;
• Como usar o framework, garante a reutilização do framework, descreve como
utiliza-lo;
• Propósito das aplicações, exemplos que ajudem a entender melhor o framework;
• Design, deve conter as classes, seus relacionamentos e colaborações.
Por fim, é importante distinguir framework de outras abordagens de reuso, como
bibliotecas de classes e padrões de projeto, e mostrar o que é modelo de framework,
diagrama muito usado para descrever variabilidades, por isso muito importante para a
criação de um framework.
Framework versus Bibliotecas de Classes
Uma biblioteca de classes possui características como: cada classe é única e independente
das outras, os clientes chamam funções e não existe controle de fluxo. Por outro lado o
framework possui: classes com dependências/colaborações estão embutidas, os clientes
chamam funções da "aplicação"e existe controle de fluxo de execução.
Framework versus Padrões de Projeto
A diferença entre framework e padrão de projeto é: i) Padrões de projeto são mais
abstratos do que frameworks. Um framework inclui código, um padrão de projeto não;
ii) Padrões de projeto são elementos arquiteturais menores do que frameworks. Um
framework típico contém vários padrões de projeto mas o contrário nunca ocorre; iii)
Padrões de projeto são menos especializados do que frameworks. Arcabouços sempre
têm um domínio de aplicação particular enquanto padrões de projeto não ditam uma
arquitetura de aplicação particular.
21
2.5. PROJETO DE SOFTWARE COM REUSO
Modelo de Características
Uma feature é uma propriedade do sistema que é relevante para o usuário e é usado para
capturar semelhanças e variabilidades entre os sistemas (Czarnecki et al., 2005). Modelagem de feature é a atividade de identificar semelhanças e variabilidades dos produtos
de uma linha de produtos, ou aplicações em frameworks, em termos de características
e organizá-los em um modelo. Um diagrama de feature representa uma decomposição
hierárquica de recursos, normalmente incluindo dois tipos de relacionamentos: agregação
e generalização. O relacionamento de agregação é usado se um recurso pode ser decomposto em um conjunto de sub-funções, e a relação de generalização é usada quando um
recurso pode ser especializado em outras mais específicas com informações adicionais
(Lee and Kang, 2004).
Os relacionamentos básicos entre as características podem ser de três tipos:
• Mandatário: Para existir uma instância da feature é obrigatório que exista uma
instância da outra;
• Alternativo: Para existir uma instância da feature pode existir, no máximo, uma
instância de um conjunto de características, podendo exitir nenhuma também;
• Opcional: Pode existir ou não uma instância da feature dependente, e caso exista,
pode ser mais que uma.
Figura 2.5 Modelo de Características (Adaptado de (Ana Elisa Lobo and Rubira, 2007))
Por exemplo, na Figura 2.5 (Ana Elisa Lobo and Rubira, 2007), para existir uma
instância de Sistema, necessariamente precisam existir instâncias de Identificador do
usuário e Balanço associadas a ela (relacionamento mandatário). Por outro lado para
existir o Identificador do usuário é necessário que seja escolhido apenas um dos sub-tipos
Touch Screen e Leitor de Cartão (relacionamento alternativo). Por fim, para existir uma
22
2.5. PROJETO DE SOFTWARE COM REUSO
instância de Balanço é necessário ter uma de Monitor (relacionamento mandatário) e
pode ter ou não uma instância de Impressora (relacionamento opcional).
2.5.2
Desenvolvimento Baseado em Componentes
A grande utilização de Desenvolvimento Baseado em Componentes(DBC) está sendo
motivada principalmente pelas pressões sofridas na indústria de software por prazos mais
curtos e produtos de maior qualidade. No DBC, uma aplicação é construída a partir
da composição de componentes de software que já foram previamente especificados,
construídos e testados, o que proporciona um ganho de produtividade e qualidade no
software produzido.
Esse aumento da produtividade é decorrente da reutilização de componentes existentes
na construção de novos sistemas. Já o aumento da qualidade é uma conseqüência do fato
dos componentes utilizados já terem sido empregados e testados em outros contextos.
Porém, ale a pena ressaltar que apesar desses testes prévios serem benéficos, a reutilização
de componentes não dispensa a execução dos testes no novo contexto onde o componente
está sendo reutilizado.
Apesar da popularização atual do DBC, não existe um consenso geral sobre a definição
de um componente de software, que é a unidade básica de desenvolvimento do DBC.
Porém, um aspecto muito importante é sempre ressaltado na literatura: um componente
deve encapsular dentro de si seu projeto e implementação, além de oferecer interfaces
bem definidas para o meio externo. O baixo acoplamento decorrente dessa política
proporciona muitas flexibilidades, tais como: i) facilidade de montagem de um sistema
a partir de componentes COTS3 ; e ii) facilidade de substituição de componentes que
implementam interfaces equivalentes.
Uma definição de componentes, adotada na maioria dos trabalhos publicados atualmente, foi proposta em 1998 (Szyperski, 1998). Segundo Szyperski, um componente de
software é uma unidade de composição com interfaces especificadas através de contratos
e dependências de contexto explícitas. Sendo assim, além de explicitar as interfaces com
os serviços oferecidos (interfaces providas), um componente de software deve declarar
explicitamente as dependências necessárias para o seu funcionamento, através de suas
(interfaces requeridas).
Além dessa distinção clara entre interfaces providas e requeridas, os componentes
seguem três princípios fundamentais, que são comuns à tecnologia de objetos (Chessman
and Daniels, 2000):
3 do
inglês Common-Off-The-Shelf
23
2.5. PROJETO DE SOFTWARE COM REUSO
1. Unificação de dados e funções: Um componente deve encapsular o seu estado
(dados relevantes) e a implementação das suas operações oferecidas, que acessam
esses dados. Essa ligação estreita entre os dados e as operações ajudam a aumentar
a coesão do sistema;
2. Encapsulamento: Os clientes que utilizam um componente devem depender
somente da sua especificação, nunca da sua implementação. Essa separação de
interesse4 reduz o acoplamento entre os módulos do sistema, além de melhorar a
sua manutenção;
3. Identidade: Independentemente dos valores dos seus atributos de estado, cada
componente possui um identificador único que o difere dos demais.
Existem várias tecnologias para se implementar componentes, entre as mais famosas
estão: CORBA do OMG (Object Management Group), COM/COM+ da Microsoft e
Entreprise JavaBeans (EJB) da Sun. Contudo, todas elas seguem um modelo dependente
de plataforma. Por essa razão decidimos utilizar o COSMOS* no trabalho apresentado. A
próxima seção vai apresentar as motivações da metodologia COSMOS*, suas vantagens
e implementação.
Metodologia COSMOS*
O modelo COSMOS* (Gayard et al., 2008) usa recursos de linguagem de programação e
padrões de projeto amplamente conhecidos para representar arquiteturas de software explicitamente no código do programa. Este modelo define a especificação e implementação
de componentes, conectores, configurações arquitetônicas e componentes compostos.
Ele é dividido em um modelo de especificação, pelo qual um componente expõe
as suas especificações; um modelo de implementação, que orienta a implementação
interna de um componente, um modelo de conector, que especifica a conexão entre
os componentes através de conectores, e um modelo de composição, pelo qual novos
componentes ou sistemas inteiros são construídos utilizando componentes existentes.
Portanto, os principais objetivos do modelo COSMOS* são: fornecer um acompanhamento a partir da arquitetura de software até código do programa e facilitar na manutenção
do software. Este modelo reduz o acoplamento entre os módulos da arquitetura e ainda
oferece reutilização de software. Embora COSMOS* tenha quatro sub-modelos (especificação, implementação conector, e composição), este trabalho utiliza apenas dois que são
4 do
inglês separation of concerns
24
2.5. PROJETO DE SOFTWARE COM REUSO
o modelo de especificação e modelo de implementação, pois os conectores são classes
simples. É importante citar todos os componentes do framework foram implementados
usando COSMOS*.
A figura 2.6 mostra um exemplo de um componente especificado com o COSMOS*.
Nesta figura podemos identificar as principais propriedades de um componente especificado com o COSMOS*. Elas são:
Figura 2.6 Exemplo de Componente COSMOS* (Gayard et al., 2008)
• A interface provida (IA na figura) é a única parte do componente que o usuário
tem acesso direto. Dessa forma para utilizar o componente ele não precisa saber de
detalhes da implementação;
• A interface requerida (IB na figura) representa a restrição do componente. Para ele
funcionar adequadamente o usuário tem que passar uma classe que implemente
essa interface;
• A classe Facade1 implementa a interface provida e funciona como o padrão de
projeto facade. Em outras palavras, essa classe é responsável por delegar as funções
da interface provida para as classes que realmente implementam elas;
• A classe componenteFactory implementa o padrão de projeto Factory Method. Em
outras palavras, É responsável por instanciar as classes internas do componente;
25
2.5. PROJETO DE SOFTWARE COM REUSO
• A classA neste exemplo é a classe que implementa os serviços do componente.
Como mostra a figura ela depende diretamente da interface requerida;
• Por fim, temos a classe manager, que é responsável por gerenciar todo acesso ao
componente.
Todos os serviços criados no framework proposto nesse trabalho usar a especificação
COSMOS*. Em outras palavras, eles são componentes e a implementação deles é muito
parecida com a figura 2.6.
2.5.3
Arquitetura de Software
A arquitetura de software, através de um alto nível de abstração, define o sistema em
termos de seus componentes arquiteturais, que representam unidades abstratas do
sistema; a interação entre essas entidades, que são materializadas explicitamente através
dos conectores; e os atributos e funcionalidades de cada um (Sommerville, 2001), um
exemplo disto é apresentado na Figura 2.7.
Figura 2.7 Exemplo configuração arquitetural em UML ( Adaptada de (Sommerville, 2001))
Esta figura tem a interface provida chamada IA_Provided, e a interface requerida
chamada IA_Required. O conector conn é o mediador das atividades entre os componentes. A maneira que os componentes e conectores são ligados entre si é definido pela
configuração da arquitetura.
Por conhecerem o fluxo interativo entre os componentes do sistema, é possível nos
conectores, estabelecer protocolos de comunicação e coordenar a execução dos serviços
que envolvam mais de um componente do sistema.
Essa visão estrutural do sistema em um alto nível de abstração proporciona benefícios
importantes, que são imprescindíveis para o desenvolvimento de sistemas de software
complexos. Os principais benefícios são: i) a organização do sistema como uma composição de componentes lógicos; ii) a antecipação da definição das estruturas de controle
globais; iii) a definição da forma de comunicação e composição dos elementos do projeto;
e iv) o auxílio na definição das funcionalidade de cada componente projetado. Além
disso, uma propriedade arquitetural representa uma decisão de projeto relacionada a
algum requisito não-funcional do sistema, que quantifica determinados aspectos do seu
26
2.5. PROJETO DE SOFTWARE COM REUSO
comportamento, como confiabilidade, reusabilidade e modificabilidade (Bass et al., 2003;
Sommerville, 2001).
A presença de uma determinada propriedade arquitetural pode ser obtida através da
utilização de estilos arquiteturais que possam garantir a preservação dessa propriedade
durante o desenvolvimento do sistema (Shaw and Garlan, 1996; Monroe et al., 1997).
Um estilo arquitetural caracteriza uma família de sistemas que são relacionados pelo
compartilhamento de suas propriedades estruturais e semânticas. Esses estilos definem
inclusive restrições de comunicação entre os componentes do sistema. A maneira como
os componentes de um sistema ficam dispostos é conhecida como configuração.
As propriedades arquiteturais são derivadas dos requisitos do sistema e influenciam,
direcionam e restringem todas as fases do seu ciclo de vida. Sendo assim, a arquitetura de
software é um artefato essencial no processo de desenvolvimento de softwares modernos,
sendo útil em todas as suas fases (Chen et al., 2002).
A importância da arquitetura fica ainda mais clara no contexto do desenvolvimento
baseados em componentes. Isso acontece, uma vez que na composição de sistemas, os
componentes precisam interagir entre si para oferecer as funcionalidades desejadas.
Além disso, devido à diferença de abstração entre a arquitetura e a implementação de um sistema, um processo de desenvolvimento baseado em componentes deve
apresentar uma distinção clara entre os conceitos de componente arquitetural, que é
abstrato e não é necessariamente instanciável; e componente de implementação, que
representa a materialização de uma especificação em alguma tecnologia específica e deve
necessariamente ser instanciável.
2.5.4
Desenvolvimento Centrado na Arquitetura
A arquitetura de software é um artefato essencial no ciclo de vida do software e deve
auxiliar todas as suas fases (Chen et al., 2002). A principal motivação para isso é que a
abstração oferecida pela arquitetura de software possibilita uma análise estrutural em alto
nível e um melhor entendimento do sistema.
Um processo de desenvolvimento centrado na arquitetura, além de usufruir dessa
abstração arquitetural em todas as fases do desenvolvimento, deve fornecer meios de
especificar a arquitetura do sistema, obedecendo as restrições impostas pelos seus requisitos não-funcionais (You-Sheng and Yu-Yun, 2003). Além disso, enquanto os processos
tradicionais consideram a composição do sistema como sendo uma atividade de implementação (Chessman and Daniels, 2000), nos processos centrados na arquitetura, a
composição dos componentes deve ser considerada em diferentes fases do desenvol-
27
2.5. PROJETO DE SOFTWARE COM REUSO
vimento. Em outras palavras, a composição deve ser pensada nos diversos níveis de
abstração (modelo abstrato, especificação detalhada e implementação) (Chen et al., 2002).
As principais vantagens decorrentes da adoção de um processo de desenvolvimento
centrado na arquitetura são: i) facilidade de se especificar propriedades não-funcionais
no sistema; ii) reutilização em um nível maior de granularidade; iii) redução do tempo
de desenvolvimento; iv) representação estrutural explícita; v) compreensão facilitada do
sistema; e vi) facilidade de manutenção.
Motivadas principalmente pela reutilização de software em larga escala, é cada vez
maior o número de empresas que utilizam alguma técnica de desenvolvimento centrado
na arquitetura (Koskimies, 2001).
28
3
RetriBlog: Um Framework Centrado na
Arquitetura para Criação de Blog
Crawlers
O RetriBlog é um framework centrado na arquitetura para criação de blog crawlers, em
que o usuário pode rapidamente especificar os requisitos de sua aplicação. Além disto,
o sistema oferece serviços para resolver problemas específicos encontrados em várias
aplicações web, por exemplo, extração de conteúdo e recomendação de tag. Este capítulo
descreve como os objetivos, descritos no Capítulo 1, foram satisfeitos pelo RetriBlog,
explicando a sua arquitetura, componentes e ferramentas utilizadas, além de detalhes
sobre o projeto de arquitetura, código e implementação.
O framework proposto aqui está publicado em vários artigos. A idéia inicial do
RetriBlog está publicado em nos artigos Arcabouço para criação de Blog Crawlers
Baseados em Contexto Ferreira et al. (2010a) e A Framework for Developing ContextBased Blog Crawlers Ferreira et al. (2010b). A arquitetura do sistema está publicada nos
artigos: An Architecture-Based Framework for Developing Blog Crawlers Ferreira et al.
(2012a) e Creating a Blog Recommendation System Through a Framework for Building
Blog Crawlers Ferreira et al. (2011b). Por fim o artigo RetriBlog: A Framework for
Creating Blog Crawlers Ferreira et al. (2012b) mostra o sistema como está descrito aqui.
3.1
Visão Geral do Sistema
O principal objetivo do RetriBlog é criar sistema que facilite a instanciação de blog
crawlers. Para isso, ele foi implementado de forma que o desenvolvedor precisa modificar
pequenos trechos de código para criar uma aplicação. É importante frisar que não é
29
3.1. VISÃO GERAL DO SISTEMA
necessário conhecer todo o código para criar uma aplicação, deve-se conhecer apenas
algumas interfaces de alto nível caracterizando assim um framework caixa cinza. O
RetriBlog pode também ser classificado como híbrido entre framework de domínio e
de aplicação. É de domínio porque facilita a instanciação de blog crawlers, para isso
conter controle de fluxo interno de um crawler. Por outro lado, o framework também
pode ser considerado de aplicação, pois ele disponibiliza serviços que podem ser usados
em qualquer contexto, não apenas para criar o crawler. A Figura 3.1 mostra uma visão
geral do framework e a seguir cada módulo é brevemente discutido.
Figura 3.1 Visão Geral do Framework
• Módulo de Especificação: Este módulo está diretamente ligado à instanciação do
framework. A fim de criar uma aplicação, o desenvolvedor deve definir especificações necessárias ao futuro blog crawler;
• Módulo de Serviços de Aplicação: Principais serviços que são usados no RetriBlog. Tais como: pré-processamento, classificação, indexação, entre outros. Os
hot spots do framework estão nesse módulo;
• Módulo de Serviços Gerais: Este módulo implementa serviços básicos que são
usados no crawler. Tais como: manipulação de strings, requisição HTTP, detecção
de idioma, entre outros. Estes serviços são frozen spots do framework;
• Módulo de Ferramentas: Este módulo contém um conjunto de ferramentas que
são usadas para realizar os serviços dos outros módulos. Tais como: Lucene,
Lingpipe, SimMetrics, entre outras.
• Módulo de Persistência: É responsável pelo armazenamento do framework em
banco de dados. Atualmente suporta o bando MySQL.
30
3.2. PROJETO ARQUITETURAL
A Figura 3.2 mostra como cada módulo acima se localiza na arquitetura do RetriBlog
baseada na arquitetura padrão de web crawlers descrita na seção 2.3.2.
Figura 3.2 Visão Geral da Arquitetura do RetriBlog
3.2
Projeto Arquitetural
Antes de explicar a arquitetura do framework é importante destacar algumas decisões de
projeto que foram tomadas e suas conseqüências.
• Framework: Foi escolhido criar um framework porque o problema tratado neste
trabalho possui muitos pontos de variabilidade;
• Framework caixa cinza: A vantagem de desenvolver um framework deste tipo é
que o usuário não precisa conhecer todos os detalhes do código para criar uma
aplicação (como no caso de caixa branca) e ao mesmo tempo não fica "preso"ao
que já está definido (como no caso de caixa preta);
• Desenvolvimento centrado na arquitetura: Utilizar esta abordagem para criar o
framework deixa cada componente bem modularizado dessa forma facilita, por
exemplo, a instanciação e evolução do sistema. Além disto, é bem mais simples de
entender o código com os artefatos da arquitetura;
• Desenvolvimento baseado em componentes(DBC): Utilizar DBC traz principalmente duas vantagens: i) aumento da produtividade, é decorrente da reutilização de
componentes existentes na construção de novos sistemas; ii) aumento da qualidade,
em conseqüência do fato dos componentes utilizados já terem sido empregados e
testados em outros contextos;
31
3.2. PROJETO ARQUITETURAL
• COSMOS*: A principal vantagem de se utilizar o COSMOS* no contexto desse
trabalho é que a especificação dele é toda definida utilizando este padrão. Desta
forma qualquer desenvolvedor que conhece o COSMOS* facilmente entende o código do RetriBLog. No COSMOS* o conceito de interfaces requeridas e conectores
são explicitamente representados.
Como o RetriBlog possui variações internas que podem ser personalizadas, a Figura 3.3 apresenta o modelo de features contendo possíveis decisões envolvendo essa
configuração.
Figura 3.3 Modelo de Características de RetriBlog
Alguns pontos desse diagrama devem ser ressaltados:
• Os atributos Extração de Conteúdo, Indexação e Coletor de URL são mandatários;
• Os atributos Classificação e Recomendação de tags são opcionais, podem ser
instanciados quantos forem necessários;
• Os sub-tipos de todos os atributos, com exceção do Pré-Processamento, são alternativos. Em outras palavras, o desenvolvedor precisa escolher um deles para cada
atributo principal;
• O atributo Pré-Processamento tem três sub-tipos mandatários e outros quatro
opcionais.
32
3.2. PROJETO ARQUITETURAL
O modelo de features pode definir o modelo de decisões. Esse modelo apresenta
possíveis instanciações e configurações do framework no contexto de diferentes cenários.
Uma breve descrição de cada hot spot é apresentada a seguir:
• Coletor de URL: executa uma pesquisa e retorna uma lista links de blogs correspondentes a uma determinada tag. Atualmente estãdo disponíveis para pesquisas
nas engenhos de busca: Technorati 1 e Icerocket 2 .
• Extração de Conteúdo: Este serviço extrai o conteúdo textual relevante do blog.
Quatro serviços já estão implementados:
– Summary Strategy(Ferreira et al. (2010b)), usa o resumo do blog para extrair
o conteúdo;
– Document Slope Curve (DSC)(Pinto et al. (2002)), procura de blocos de texto
com base na quantidade de tags no texto;
– Text-to-Tag Ratio (TTR)(Weninger and Hsu (2008)), ele usa a razão da quantidade de caracteres que não são tag pelo número de tags HTML por linha de
texto para extrair o conteúdo;
– Boilerplate Detection(Kohlschütter et al. (2010)), é um algoritmo baseado
em árvore de decisão para analisar o texto.
• Pré-Processamento: remove informações consideradas irrelevantes para a analise
do blog. A versão atual do framework disponibiliza sete tipos de pré-processamento:
Clean HTML, White Space Remover, Lowercase, English Filtering, English Stemming, Portuguese Filtering, Portuguese Stemming. Eles serão melhor explicados
na Seção 3.5.3.
• Classificação: fornece serviços de texto classificação baseada em técnicas estatísticas. Três serviços estão já implementados:
– Naive Bayes: Fornece um classificador Naive Bayes(Mitchell (1997)), com
tokens como features;
– K-nearest-neighbor (KNN): implementa o classificador k-nearest-neighbor
usando a distância euclidiana para medir a distância entre os vizinhos;
1 http://technorati.com
2 http://www.icerocket.com
33
3.2. PROJETO ARQUITETURAL
– TF-IDF: Oferece um serviço para a formação de classificadores descritivos
com base no term-frequency (TF) e inverse document frequency (IDF).
• Recomendação de tags: Recomenda tags para blogs. Quatro tipos de recomendação foram definidos:
– Por Similaridade, usa distância de Levenshtein Miller et al. (2009) para
encontrar palavras similares;
– Dicionário, usa sinônimos do WordNet para realizar a recomendação;
– Cluster, realiza a recomendação usando a técnica de agrupamento KNN;
– Classificação, realiza a recomendação usando um classificador naive bayes.
• Indexação: O serviço indexa textos para o processo de busca. Existe um serviço
implementado, ele usa a ferramenta Lucene 3 .
A Figura 3.4 mostra a arquitetura dos componentes do framework. Ela segue um
estilo de arquitetura heterogêneo baseado em componentes independentes e camadas. As
quatro camadas de alto nível foram definidas como: (i) Aplicação, contém o processo
geral criado com o framework (processo de crawler), (ii) Sistema, contém os principais
componentes do framework (kernel do sistema), (iii) Negócio, controla a persistência do
framework, e (iv) Infra, representa a conexão com o banco.
A Figura 3.5 mostra como os componentes interagem entre si de forma mais detalhada.
Nela é apresentado os componentes derivados da arquitetura básica usando o modelo de
features.
É importante destacar que alguns componentes internos da camada Sistema foram
omitidos para não deixar a figura muito grande. Por exemplo, embora o componente
Preprocessing seja representado como um único componente, que representa apenas um
componente fachada que se propaga a solicitação para outros componentes (omitidos)
que realmente implementam as estratégias de pré-processamento como apresentados na
Figura 3.3, como CleanHTML e LowerCase. O mesmo ocorre com outros componentes
na Figura 3.5.
As próximas seções vão detalhar cada uma dos módulos da arquitetura assim como
os seus componentes.
3 http://lucene.apache.org
34
3.3. ESPECIFICAÇÃO
Figura 3.4 Arquitetura dos Compoentes do Framework
3.3
Especificação
Para criar uma aplicação com o RetriBlog é necessário criar uma classe de especificação, seguindo o modelo COSMOS*. Esta classe deve conter: i) Os algoritmos de
coletar url, extração de conteúdo e indexação escolhidos; ii) Possíveis algoritmos de
pré-processamento; e o idioma da aplicação. Exemplos e mais detalhes sobre como criar
uma aplicação serão apresentados no Capítulo 4.
3.4
Serviços Gerais
Este módulo disponibiliza serviços básicos que serão utilizados pela maioria dos crawlers
a serem criados. A princípio este conjunto de classes são frozen spots. Em outras
palavras, esse módulo não possui pontos de variabilidade. Novos componentes podem
ser adicionados a ele, mas normalmente estes componentes são isolados dos outros. Os
35
3.4. SERVIÇOS GERAIS
Figura 3.5 Arquitetura dos Compoentes do Framework - Detalahada
serviços disponibilizados por este módulo são:
• Manipulação de arquivos: Este serviço fornece operações básicas com arquivos.
Algumas das operações são: salvar, carregar e alterar arquivo, descobrir o nome de
todos os arquivos de um diretório;
• Manipulação de página HTML: Este serviço disponibiliza acesso as páginas
HTML. Operações como requisição de página e salvar página em um arquivo
fazem parte desse componente;
• Manipulação de String: Serviço que disponibiliza operação como: contar a
quantidade de palavras de uma string, verificar se existe uma determinada palavra na
string, contar uma determinada palavra na string, pegar o texto entre duas substrings,
verificar a similaridade de duas strings (usando distância de Levenshtein);
36
3.5. SERVIÇOS DE APLICAÇÃO
• Manipulação de XML: Oferece operações básicas com arquivos XML, como por
exemplo, carregar um arquivo XML.
• Identificação de idioma: Este serviço disponibiliza uma operação de identificação
de idiomas. Ele tem como entrada um texto e a saída é o idioma desse texto.
• Operações com WordNet: Disponibiliza uma operação que retorna todos os
sinônimos de uma palavra que o WordNet Miller (1995) oferece. Como entrada ele
recebe uma palavra e como saída retorna uma lista de sinônimos.
Os serviços desse módulo não são usados diretamente pelo crawler. Os serviços de
aplicação que usam essas funcionalidades, ou seja, o usuário que vai criar uma aplicação
com o RetriBlog não precisa se preocupar com esses serviços, o uso deles é transparente
ao usuário.
3.5
Serviços de Aplicação
É neste módulo que os principais serviços do framework se encontram. Estes serviços
foram implementados de forma que pudessem ser facilmente re-usáveis (mais detalhes
na Seção 3.7) desta forma eles podem ser usados tanto para criar crawlers quanto para
criar aplicações específicas como recomendação de tags.
Figura 3.6 Fluxo Básico do Crawler
Como já foi dito os serviços desse módulo são os hot spots do framework, ou seja,
são a parte variável do sistema. Desta forma eles precisam ser bem descritos para que o
usuário possa escolher os mais adequados para a sua aplicação.
37
3.5. SERVIÇOS DE APLICAÇÃO
Para ilustrar o funcionamento do processo de crawler a Figura 3.6 mostra o fluxo
dele. Nele fica claro que existem serviços obrigatórios e opcionais no crawler.
As próximas seções vão explicar, em detalhes, cada um dos componentes disponibilizados neste módulo seguindo o fluxo apresentado.
3.5.1
Coletor de URL
Este serviço é o responsável pela primeira etapa do crawler, descobrir os links dos blogs
que serão analisados no resto do processo. Em resumo ele funciona assim: i) acessa
um engenho de busca de blogs (previamente escolhida pelo usuário); ii) entra na página
relacionada à uma determinada tag (Figura 3.7); iii) extrai os links dos blogs que estão
nesta página; iv) retorna a lista links dos blogs correspondentes a essa tag.
Figura 3.7 Página relacionada da Technorati relacionada a tag educação
Atualmente o RetriBlog disponibiliza para pesquisas as soluções: Technorati 4 e
Icerocket 5 . Além disto, outros 3 jornais eletrônicos também possuem este serviço: NE10
(Jornal do Comércio), FolhaPE, Diário de Pernambuco6 .
4 http://technorati.com
5 http://www.icerocket.com
6 http://ne10.uol.com.br/;
http://www.folhape.com.br/; http://www.diariodepernambuco.com.br/
38
3.5. SERVIÇOS DE APLICAÇÃO
Após coletar os links o RetriBlog parte para a etapa de extração do conteúdo principal
da página.
3.5.2
Extração de Conteúdo
O processo de Extração de Conteúdo (CE - do inglês Content Extraction) tenta detectar
e extrair conteúdo textual relevante dos blogs, ignorando menus de navegação, banners
anúncios e informações estruturais apresentadas sobre eles. Para atingir isso, o RetriBlog
implementa quatro algoritmos de CE: i) Document Slope Curve (DSC); ii) Text-to-Tag
Ratio (TTR); iii) Boilerplate Detection(BD); iv) Summary Strategy(SS). Além disto,
foi implementado uma heurística para remoção de links das páginas, Link Quota Filter
(LQF), que ajuda a melhorar os resultados desses algoritmos. Todos estes algoritmos
fazem uso de razões e proporções para detectar o conteúdo principal do documento, por
isso são independente de idiomas.
O DSC, como mostrado por (Pinto et al. (2002)), trata a página web como uma
seqüência de tokens. Estes tokens podem ser tags html ou texto. Quando há uma seção da
página com um baixo número de tags HTML, o algoritmo considera ela como conteúdo
textual relevante. Menus e informações estruturais, supostamente, contém um elevado
número de tags e uma pequena quantidade de texto, por isso eles são ignoradas pelo
algoritmo.
O algoritmo de TTR, conforme apresentado pelos autores em (Weninger and Hsu
(2008)), considera a relação entre a contagem de caracteres que não são tags HTML com
a contagem dos que são tags HTML por linha. Quando há uma linha com uma relação de
TTR alta, ou seja, há um grande número de caracteres de texto e apenas algumas tags em
uma única linha, o algoritmo considera a linha a ser conteúdo. Caso contrário, a linha é
ignorado pelo algoritmo.
Os outros dois algoritmos implementados são o BD (Kohlschütter et al. (2010)) e o
SS (Ferreira et al. (2010b)). O primeiro usa recursos de texto e informação estrutural
para detectar o conteúdo de um website. No segundo, o link e o resumo do texto do blog
são usados para recuperar o texto relevante.
Além disto, O LQF foi implementado como um complemento para reduzir o número
de listas de links, anúncios e informações estruturais antes de usar os outros algoritmos(Gottron (2007)).
É importante frisar que os algoritmos são baseados em medidas, recursos de texto e
informações estruturais. Eles não dependem do idioma do blog e não necessitam de qualquer corpus de treinamento. Além disso, eles são muito eficientes para o processamento
39
3.5. SERVIÇOS DE APLICAÇÃO
de grandes conjuntos de dados.
É importante ressaltar que de todos esses algoritmos citados apenas o Boilerplate
Detection já avia uma implementação em java. Então todos os outros algoritmos foram
implementados para o trabalho apresentado. Com o texto principal extraido o próximo
passo é eliminação de caracteres inválidos e processamento linguístico.
3.5.3
Pré-Processamento
Um problema identificado no processo de recuperação de informação em texto é que
existem palavras que têm pouco poder representativo no documento. Por exemplo, os
artigos no português, e outras palavras podem ter uma semântica similar, como as palavras
no masculino e no feminino, no plural e no singular. Para resolver esses problemas, antes
de indexar, os documentos devem ser submetidos a um pré-processamento. Existem
várias técnicas que procuram processar o texto antes de indexá-los, alguns exemplos delas
foram apresentados na seção 2.2.
O RetriBlog disponibiliza serviços que trabalha com análises léxicas, filtragem e
stemming. Para remover caracteres que não fazem parte da linguagem existem três
serviços, são eles:
• Clean HTML, este serviço remove todas as tags HTML do texto;
• White Space Remover, remove espaços em branco desnecessários;
• Lowercase, deixa todas as letras do texto minúsculas.
Todos esses serviços foram implementados usando expressões regulares em java.
Além disto, foram criados serviços de filtragem, remoção de stop words, e stemming
para os idiomas inglês e português. Para implementar eles foi usado um pacote do
Lucene7 . Para melhorar o processamento desses serviços para o português o pacote foi
alterado e novas stop words foram adicionadas a ele.
Depois do processamento realizado nesse módulo o crawler passa por duas etapas
opcionais, classificação e recomendação de tags. A primeira serve para classificar os
blogs em uma categoria específica. Já a segunda serve principalmente para alinhar as
tags de diferentes blogs.
7 http://lucene.apache.org/java/docs/index.html
40
3.5. SERVIÇOS DE APLICAÇÃO
3.5.4
Classificação
O objetivo de Classificação de Texto consiste em categorizar um conjunto de documentos, com base no seu conteúdo, em um número fixo de categorias pré-definidas.
Cada documento pode ser atribuído a uma, várias ou nenhuma categoria(Sebastiani and
Delle Ricerche (2002)). Classificação supervisionada de texto é uma abordagem em que
um conjunto de documentos são previamente etiquetados em categorias já definidas; um
classificador (algoritmo de aprendizagem de máquina) é treinado sobre este conjunto de
documentos rotulados; finalmente, o classificador treinado é capaz de atribuir classes
para novos documentos.
A classificação de texto foi considerada uma tarefa importante no contexto do presente
trabalho, pois ela organiza as páginas recuperadas por nosso framework em grupos.
Como resultado, categorias comuns podem ser determinadas, oferecendo ao usuário uma
maneira fácil de acessar informações de acordo com seus interesse.
O RetriBlog implementa três algoritmos diferentes para classificação supervisionada texto: Naive Bayes(Mitchell (1997)), KNN (k-Nearest Neighbor)(Li Baoli and Qin
(2003)), e TF/IDF - Term-Frequency(TF) e Inverse Document Frequency(IDF)(Salton
and Buckley (1988)). Esses classificadores foram implementados usando LingPipe8 que
consiste em um kit de ferramentas para processamento de texto através de técnicas computacionais linguística. Ele oferece um grande número de abordagens para a classificação
de texto. Mais detalhes sobre essa ferramenta serão mostrados na Seção 3.6.
3.5.5
Recomendação de tags
Para facilitar a recuperação de informação em redes sociais, incluindo a blogosfera, foi
criado o recurso de tags sociais. Ele permite que os usuários marquem os seus posts com
categorias que os definam. Sistemas de busca podem então aproveitar essas tags para
fornecer melhores resultados de pesquisa. No entanto, o mesmo post pode ser marcado
de forma diferente devido, por exemplo, as diferenças culturais, do conhecimento e
experiência dos usuários (Subramanya and Liu (2008)). De acordo com (Golder and
Huberman (2006)), três tipos de problemas podem ocorrer: i) Sinônimos: quando existem
múltiplas palavras com o mesmo significado; ii) Polissemia: a mesma palavra pode se
referir a conceitos diferentes; iii) Variação do Nível Básico: a variação da granularidade
da tag. Por exemplo, quando um usuário posta sobre o seu animal de estimação, ele pode
atribuir tags gerais, como "animal"ou "animal doméstico"ou aqueles específicos, como
8 http://alias-i.com/lingpipe/
41
3.5. SERVIÇOS DE APLICAÇÃO
"cachorro"ou "gato".
Para tratar desses problemas o RetriBlog possui serviços de recomendação de tag
implementados. Estes serviços tentam resolver os problemas citados de forma diferente.
Com isso o usuário pode escolher o mais adequado para a sua aplicação. Por exemplo, se o
usuário tiver um corpus com pouco ruído, ele pode usar um serviço que é baseado no post
para alcançar melhores resultados. Por outro lado, se ele precisa de uma implementação
rápida, serviços baseados na tag são mais adequados. Estes serviços tentam alcançar boa
escalabilidade, eficiência e baixa dependência do corpus. Atualmente existem quatro
serviços de recomendação implementados, são eles: i) Similarity; ii) Dictionary; iii)
Classify; e iv) Cluster.
O serviço baseado em similaridade(Similarity) foca na ortografia das palavras.
Entre outras questões este serviço tenta lidar com a conjugação do verbo, palavras no
plural, diferença de gênero, e palavras com a mesma raiz. Ele é baseado na métrica de
Distância de Levenshtein (Miller et al. (2009)). Esta métrica de distância é dada pelo
número mínimo de operações necessárias para transformar uma string em outra, com
as operações permitidas editar sendo inserção, exclusão ou substituição de um único
caractere. Ela é amplamente utilizada para aplicações que necessitam para determinar
quão semelhantes são duas strings.
Nossa implementação deste serviço utiliza a SimMetrics9 que consiste em uma
biblioteca de código aberto extensível de algoritmos para calcular métricas string. Nosso
serviço de usa a distância Levenshtein para encontrar palavras que são potencialmente
similares e recomendando-as como tags relacionadas.
O serviço baseado em dicionário(Dictionary) foca no sinônimos das palavras. Este
serviço recomenda palavras com semântica similar. A definição de sinônimo é uma
palavra com o mesmo ou quase o mesmo significado que outra palavra ou outras palavras
em um idioma. Este método utiliza um dicionário de sinônimos (thesaurus), que é um
índice simples que liga uma palavra a seus sinônimos.
Desta forma, o nosso serviço baseado em dicionário fornece um dicionário de sinônimos para recomendar possíveis tags relacionadas. Ele usa o WordNet e a biblioteca JWI
(Java WordNet Interface) para implementá-lo. O WordNet (Fellbaum (1998)) consiste em
um grande banco de dados léxicos do Inglês em que os substantivos, verbos, adjetivos
e advérbios são agrupados em conjuntos de sinônimos cognitivos (synsets), cada um
expressando um conceito distinto. JWI10 é uma biblioteca Java para interface com banco
9 http://staffwww.dcs.shef.ac.uk/people/[email protected]/simmetrics.html
10 http://projects.csail.mit.edu/jwi/
42
3.5. SERVIÇOS DE APLICAÇÃO
de dados WordNet.
O serviço baseado em classificador(Classify) utiliza um classificador baseado em
lista de palavras. Ele usa as palavras dos posts e suas respectivas freqüências para gerar
um classificador Naive Bayes. Em resumo, este serviço cria um classificador e recomenda
possíveis tags relacionadas com o resultado categorização do novo post. Assim, quando
um post é classificado, sua tag está relacionado a esta categoria.
Por fim, o serviço baseado em agrupamento(Cluster) consiste em uma versão clássica do KNN (Tan (2006)). Assim como o serviço anterior, para realizar a recomendação
usando este serviço precisamos de um corpus previamente anotado para treinar o sistema.
Após o treinamento o documento é classificado pelo voto da maioria de seus vizinhos.
Para implementar esses dois últimos serviços foram usados os algoritmos do próprio
RetriBlog descritos na Seção 3.5.4.
Depois da recomendação temos a última etapa do crawler que é a indexação e depois
armazenamento dos dados.
3.5.6
Indexação
Para facilitar a busca por documentos relevantes numa grande coleção de documentos é
importante utilizar técnicas computacionais nesse processo. Uma técnica muito utilizada
é a criação de índices invertidos (Hatcher and Gospodnetic (2004)).
A idéia do índice invertido é construir uma tabela de referências onde cada termo
ocorrido no documento é usado como um item para a lista de documentos que cada termo
ocorre. Ele funciona como um índice remissivo de um livro, ou seja, guarda as páginas
que contém as palavras e não o contrário. Então na busca ao invés de procurar página por
página até encontrar a palavra, ele vai direto para a palavra que já contém as páginas em
que ela ocorre. Além disso, outra informação importante que deve ser armazenado é a
freqüência de um termo em determinado documento. Quando concluído o processo, o
índice invertido recebe o nome de dicionário.
O RetriBlog disponibiliza um serviço de indexação que utiliza a ferramenta Lucene.
Este serviço cria um dicionário que pode ser facilmente acessado para fazer consultas.
Uma das facilidades do Lucene é que não importa a origem dos dados, seu formato ou
mesmo a linguagem em que foi escrito, desde que esses dados possam ser convertidos
para texto. Isto significa que o Lucene pode ser utilizado para indexar e buscar dados
gravados em: arquivos, páginas web em servidores remotos, documentos gravados no
sistema de arquivos local, arquivos textos, documentos Microsoft Word, documentos
HTML, arquivos PDF, ou qualquer outro formato do qual possa ser extraído informação
43
3.6. FERRAMENTAS E PERSISTÊNCIA
textual. Desta forma todos os conteúdos textuais dos blogs são indexados por esse serviço.
3.6
Ferramentas e Persistência
O módulo de ferramentas contém todas as APIs e ferramentas utilizadas para criar os
serviços de aplicação e gerais, entre elas estão:
• Lucene e Lingpipe, para extração e recuperação de texto;
• Hibernate, que lidar com a persistência de dados;
• HttpClient, recuperação de página HTTP;
• Google Language Detection, para detectar o idioma de textos;
• Boilerpipe, para extração do conteúdo principal da página;
• SimMetrics, para comparar similaridade entre strings.
Este módulo torna transparente o uso de cada uma dessas ferramentas, proporcionando
um acesso fácil a elas o que diminui o tempo de aprendizagem do usuário para usar
cada uma dessas funcionalidades. Por exemplo, o usuário não precisa se aprofundar em
detalhes sobre a API do Lucene, a fim de construir uma aplicação que usa ela. Em vez
disso, ele poderia delegar as funções do Lucene do framework. Como no RetriBlog todas
essas ferramentas estão encapsuladas em componentes, o usuário só precisa escolher o
componente com a operação que ele deseja utiliza e instanciar ele.
O módulo de persistência é responsável pelo armazenamento dos dados. Atualmente
o RetriBlog suporta o banco MySQL. No sistema tem uma classe que representa o post,
com os seguintes atributos:
• Id: Identificador da instância, gerado automaticamente pelo banco;
• Title: Título da postagem;
• Author: Autor da postagem;
• Excerpt: Resumo da postagem;
• Created: A data da postagem;
• Permalink: Link da postagem;
44
3.7. IMPLEMENTAÇÃO
• HTMLText: Texto da postagem com HTML;
• CompleteText: Texto completo da postagem, sem HTML;
• AnalyzedText: Texto da postagem depois de passar por algum pré-processamento;
• Charset: Codificação da página;
• Category: Categoria da postagem;
• Company: Companhia que mantém o blog.
É importante notar que o texto da postagem é armazenado de três formas.
• HTMLText: Texto da postagem com HTML. Essa forma de armazenar é importante pois o HTML algumas vezes pode significar que uma palavra é importante
para o texto. Com isso uma futura etapa de extração se torna mais fácil.
• CompleteText: Texto completo da postagem, sem HTML. O texto sem HTML,
mas sem passar pelo processo de pré-processamento é importante pois em algumas
aplicações é necessário ter as palavras completas.
• AnalyzedText: Texto da postagem depois de passar por algum pré-processamento.
Esse tipo de armazenamento ajuda principalmente em sistemas de busca pois
diminui bastante o espaço a ser buscado.
Todo o acesso ao banco é realizado através do hibernate11 , um framework desenvolvido em java para persistência. O sistema disponibiliza operações como salvar e
carregar post como um serviço, igual aos descritos nas seções anteriores. Além disto, é
importante frisar que os dados também ficam armazenados em um índice, como descrito
na Seção 3.5.6. Então temos duas formas de armazenamento, o índice ajuda a busca dos
posts, já o banco de dados armazena mais informações sobre eles.
3.7
Implementação
A fim de atender requisitos de engenharia de software como reuso e facilidade de evolução,
e melhorar a rastreabilidade entre a arquitetura de software e código-fonte, o RetriBlog
segue uma implementação baseada em componentes e centrado na arquitetura.
11 http://www.hibernate.org/
45
3.7. IMPLEMENTAÇÃO
Os componentes foram criados com base no modelo de implementação COSMOS*.
O COSMOS* usa recursos de linguagem de programação, tais como interfaces, classes e
pacotes, e um conjunto de padrões de projeto para representar a arquitetura de software
explicitamente no código do programa. Além disso, as orientações definidas pelo modelo
COSMOS* também melhora a modularidade do sistema e da evolução interna dos
componentes de software.
Para ilustrar a implementação, a Figura 3.8 mostra o diagrama de classes do componente Similaridade, que implementa uma técnica de recomendação tag.
Figura 3.8 Exemplo de Componente - Similaridade
De acordo com o modelo COSMOS*, o usuário tem acesso apenas ao pacote spec
pacote e a classe SimilarityFactory. A interfaceiManager é definida pelo COSMOS*
e fornece as operações básicas do componente, por exemplo, as operações para obter
instâncias para as interfaces providas pelo componente getProvidedInterface e para a
ligar um objeto a uma interface requerida setRequiredInterface. A interface ISimilarity é
a interface provida, ela contém as operações do serviço de recomendação de tag.
Além disso, outras informações importantes são:
• O framework está todo implementado em Java e seguindo as especificações COSMOS*;
• Todos os componentes foram testados usando gUnit;
• O framework está disponível para download no site: https://sourceforge.net/projects/retriblog/;
46
3.8. COMO CRIAR UMA APLICAÇÃO COM O RETRIBLOG
• o RetriBlog segue a licença GNU General Public License (GPL)12 .
3.8
Como Criar uma Aplicação com o RetriBlog
Para criar uma aplicação usando o RetriBlog basta seguir os seguintes passos:
3.9
1º Passo
Fazer o download do RetriBLOG no link:
http://sourceforge.net/projects/retriblog/files/RetriBLOG.rar/download
3.10
2º Passo
Importar para o eclipse.
1. Abra o eclipse;
2. Clique em file->import->existing Project into Work space
3. Escolha o arquivo do RetriBLOG.
3.11
3º Passo
Crie um banco de dados (no momento só está disponibilizado a persistência em MySQL)
com qualquer nome.
3.12
4º Passo
No projeto, abra o arquivo hibernate.cfg.xml e faça as seguintes configurações:
1. No atributo <property name="hibernate.connection.url»
jdbc:mysql://localhost/NOMEDOBANCO?autoReconnect=true </property> substituir a palavra NOMEDOBANCO, pelo nome do banco;
2. Trocar o atributo update por create <property name="hibernate.hbm2ddl.auto»update</property>.
Obs: Depois de executar uma vez o create deve ser mudado de novo para update.
12 http://www.gnu.org/licenses/gpl.html
47
3.13. 5º PASSO
3.13
5º Passo
Criar uma classe crawler specification. Essa classe deve conter: O coletor de url do site
que se deseja fazer o crawler, o tipo de extração de conteúdo, o tipo de pré-processamento,
o tipo de persistência, o idioma da aplicação e quais tags se deseja extrair. Existem quatro
exemplos de crawler specification no pacote grow.retriblog.crawlerSpecification.
3.14
6º Passo
Abrir a classe crawler do pacote demos e mudar o TechnoratiSpecificationExample para
o crawler specification criado.
3.15
7º Passo
Executar essa classe.
48
4
Estudos de Caso
Este capítulo apresenta um conjunto de estudos de caso utilizando o RetriBlog. Os estudos
de caso enfatizam as vantagens do uso das abordagens de componentes e desenvolvimento
centrado na arquitetura. Eles servem para mostrar principalmente a flexibilidade e a
facilidade de reuso do framework.
4.1
Estudo de Caso 1: Sistema Baseados em Agentes
para Recuperar Blogs da Tecnhorati
Este sistema consiste de um blog crawler indexados pela Tecnhorati. Contudo, para
paralelizar o sistema, foi criada uma aplicação usando agentes. As próximas seções
descrevem a arquitetura dos agentes, a configuração do framework utilizada e a execução
da aplicação.
4.1.1
Configuração dos Agentes
A arquitetura proposta contém os agentes, módulo de configuração e módulo de persistência. A Figura 4.1 mostra os detalhes da arquitetura.
A aplicação contém dois tipos de agentes, agente gerenciador(AG) e agente de busca
(AB). Esses agentes foram criados usando o framework Jade (Bellifemine et al., 2007).
O AG gerencia os agentes do framework. Também é responsável por adicionar e
remover os ABs. Este agente fornece os seguintes comportamentos:
• Gestão - verifica informações contidas na camada configuração e atualiza os AB;
• Adição - ele cria novos agente no ambiente;
49
4.1. ESTUDO DE CASO 1: SISTEMA BASEADOS EM AGENTES PARA
RECUPERAR BLOGS DA TECNHORATI
• Remoção - ele remove os agentes do meio ambiente.
Figura 4.1 Arquitetura dos Agentes
Os ABs são responsáveis por fazer o buscar e armazenar os blogs. Em outras palavras,
ele utiliza os serviços do RetriBlog para recuperar informações de blogs e armazenar as
informações em um banco de dados, além de criar um índice invertido. Cada agente de
busca é criado para fazer o crawler de uma categoria. Por exemplo, se eu quiser fazer o
crawler das categorias de educação e esportes um agente de cada tipo é criado.
O módulo de configuração descreve as informações necessária para que o AG gerencie
os ABs. Para isso foi criado uma ontologia que descreve as informações necessárias para
que os ABs sejam criados. Dentre essas informações estão a empresa que se deseja fazer
o crawler (nesse estudo de caso escolhemos Technorati) e a categoria que o AB vai fazer
a busca.
Por fim, o módulo de persistência utiliza os serviços de indexação e acesso ao banco
MySQL disponibilizados pelo framework.
4.1.2
Configuração do Framework
A Figura 4.2 mostra a configuração dos componentes usados nesse estudo de caso.
Deste diagrama podemos observar os componentes que foram escolhidos para criar
essa aplicação, temos:
• Coletor de URLS: Technorati;
• Extração de conteúdo: Summary Strategy;
50
4.1. ESTUDO DE CASO 1: SISTEMA BASEADOS EM AGENTES PARA
RECUPERAR BLOGS DA TECNHORATI
Figura 4.2 Diagrama de Componentes - Estudo de Caso 1
• Pré-processamento: English Filtering;
• Indexação: Lucene Index.
Para carregar os componentes dessa configuração é necessário criar o código de
especificação 4.1.
Código 4.1 Classe de Especificação do Estudo de Caso 1
1
2
public class Case1Specification {
3
4
ITechnoratiUrlCollector
urlCollector ;
5
ISummaryStrategy
contentExtraction ;
6
IEnglishFiltering
preprocessing ;
7
ILuceneIndexing
index ;
8
String
language ;
9
10
IManager m a n a g e r U r l C o l l e c t o r ;
11
IManager m a n a g e r C o n t e n t E x t r a c t i o n ;
12
IManager m a n a g e r P r e p r o c e s s i n g ;
13
IManager managerIndex ;
14
15
public Case1Specification (){
16
17
managerUrlCollector = TechnoratiUrlCollectorFactory
18
. getManager ( ) ;
51
4.1. ESTUDO DE CASO 1: SISTEMA BASEADOS EM AGENTES PARA
RECUPERAR BLOGS DA TECNHORATI
19
managerContentExtraction = SummaryStrategyFactory
20
. getManager ( ) ;
21
managerPreprocessing = E n g l i s h F i l t e r i n g F a c t o r y . getManager ( ) ;
22
managerIndex = LuceneIndexingFactory . getManager ( ) ;
23
24
managerUrlCollector . setRequiredInterface ( " IHttpUtils " ,
25
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
26
27
managerContentExtraction . setRequiredInterface ( " IHttpUtils " ,
28
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
29
30
managerContentExtraction . setRequiredInterface
31
( " IWhiteSpaceRemover " , WhiteSpaceRemoverFactory . getManager ( )
32
. getProvidedInterface ( ) ) ;
33
34
managerContentExtraction . setRequiredInterface
35
( " IStringManipulation " , StringManipulationFactory
36
. getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
37
38
urlCollector = ( ITechnoratiUrlCollector )
39
managerUrlCollector . getProvidedInterface ( ) ;
40
41
c o n t e n t E x t r a c t i o n = ( ISummaryStrategy )
42
managerContentExtraction . getProvidedInterface ( ) ;
43
44
preprocessing = ( IEnglishFiltering )
45
managerPreprocessing . getProvidedInterface ( ) ;
46
47
index = ( ILuceneIndexing )
48
managerIndex . g e t P r o v i d e d I n t e r f a c e ( ) ;
49
50
l a n g u a g e = " en " ;
51 }
Este código segue o modelo COSMOS*, ou seja:
• Instância as interfaces e seus gerenciadores(Linhas 4-13);
• Configura as interfaces requeridas (Linhas 17-36);
52
4.1. ESTUDO DE CASO 1: SISTEMA BASEADOS EM AGENTES PARA
RECUPERAR BLOGS DA TECNHORATI
• Recebe as interfaces providas(Linhas 38-48).
Para executar o crawler é necessário criar o método main como mostrado abaixo.
Código 4.2 Método Principal
1
2
p u b l i c s t a t i c v o i d main {
3
C r a w l e r c r a w l e r = new C r a w l e r ( new C a s e 1 S p e c i f i c a t i o n ( ) ) ;
4
crawler . runCrawler ( ) ;
5 }
4.1.3
Execução da Aplicação
Como já foi dito esta aplicação faz o crawler de blogs da Technorati que estiverem no
idioma inglês. Para criar o arquivo de configuração, descrito na arquitetura de agentes, as
tags da Technorati foram obtidas através da página de tags mais usadas1 . O AG percebe
a mudança no arquivo de configuração e cria novos AB. Para cada nova categoria da
Technorati, é criado um novo agente de software.
A Figura 4.3 mostra uma tela com os agentes criados para algumas categorias. Do
lado esquerdo da figura temos, por exemplo, o Searcher_2010, Searcher_3d-tv, Searcher_3d, e assim por diante. Eles são agentes de busca das categorias 2010, 3d-tv e 3d
respectivamente.
Figura 4.3 Tela do Jade
A aplicação está publicada no artigo An Agent-Based Semantic Web Blog Crawler
(Ferreira et al., 2011a).
1 http://technorati.com/tag/
53
4.2. ESTUDO DE CASO 2: SISTEMA DE RECOMENDAÇÃO DE BLOGS
4.2
Estudo de Caso 2: Sistema de Recomendação de Blogs
Este estudo de caso cria uma aplicação que recomenda blogs para ajudar estudantes com
interações em fórum educacionais. Este sistema está sendo usado no ambiente MASSAYO
(Bittencourt et al., 2009). Este ambiente visa construir uma plataforma educacional com
base em tecnologias da Web Semântica, oferecendo as seguintes vantagens:
• Extensibilidade;
• Garantir a geração de conhecimento participativo;
• Possuir uma estrutura que leva em conta as características de cada usuário, tornando
o sistema adaptável a estes.
Diante deste contexto, as aplicações propostas neste estudo de caso lidam com os
aspectos citados acima na ferramenta fórum disponibilizada pelo MASSAYO. O estudo
de caso apresentado aqui é:
• Extensível porque o desenvolvedor tem permissão para criar novas aplicações,
alterando poucas linhas de código.
• Usa textos de blogosfera assegurar a criação de conhecimento universal e participativo.
• O sistema de recomendação mapeia cada aluno e recomenda blogs específicos para
cada um(adaptável).
Este estudo de caso vai ser dividido em três seções configuração do framework,
criação do sistema de recomendação, execução da aplicação.
4.2.1
Configuração do Framework
Esta aplicação recupera blogs da IceRocket relacionados a categorias especificas. O
sistema de recomendação que será detalhado na próxima seção utiliza as informações
adquiridas pelo crawler para recomendar blogs para os estudantes.
Assim como no estudo de caso anterior precisamos escolher os componentes para a
aplicação. A configuração do crawler ficou da seguinte maneira:
• Coletor de URLS: IceRocket;
54
4.2. ESTUDO DE CASO 2: SISTEMA DE RECOMENDAÇÃO DE BLOGS
• Extração de conteúdo: TTR;
• Pré-processamento: English Filtering;
• Indexação: Lucene Index.
A Figura 4.4 mostra o diagrama de componentes.
Figura 4.4 Diagrama de Componentes - Estudo de Caso 2
O código para carregar esses componentes é bastante parecido com o do estudo de
caso 1. Com o objetivo de ressaltar a facilidade de criação de aplicações com o RetriBlog
o Código 4.3 mostra a criação desta aplicação.
Código 4.3 Classe de Especificação do Estudo de Caso 2
1
2
public class Case2Specification {
3
4
IIceRocketUrlCollector
urlCollector ;
5
ITTR
contentExtraction ;
6
IEnglishFiltering
preprocessing ;
7
ILuceneIndexing
index ;
8
String
language ;
9
10
IManager m a n a g e r U r l C o l l e c t o r ;
11
IManager m a n a g e r C o n t e n t E x t r a c t i o n ;
12
IManager m a n a g e r P r e p r o c e s s i n g ;
13
IManager managerIndex ;
55
4.2. ESTUDO DE CASO 2: SISTEMA DE RECOMENDAÇÃO DE BLOGS
14
15
public Case2Specification (){
16
17
managerUrlCollector = IceRocketUrlCollectorFactory
18
. getManager ( ) ;
19
m a n a g e r C o n t e n t E x t r a c t i o n = TTR F a c t o r y . g e t M a n a g e r ( ) ;
20
managerPreprocessing = E n g l i s h F i l t e r i n g F a c t o r y . getManager ( ) ;
21
managerIndex = LuceneIndexingFactory . getManager ( ) ;
22
23
managerUrlCollector . setRequiredInterface ( " IHttpUtils " ,
24
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
25
26
managerContentExtraction . setRequiredInterface ( " IHttpUtils " ,
27
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
28
29
managerContentExtraction . setRequiredInterface
30
( " IWhiteSpaceRemover " , WhiteSpaceRemoverFactory . getManager ( )
31
. getProvidedInterface ( ) ) ;
32
33
managerContentExtraction . setRequiredInterface
34
( " IStringManipulation " , StringManipulationFactory
35
. getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
36
37
urlCollector = ( IIceRocketUrlCollector )
38
managerTagParser . g e t P r o v i d e d I n t e r f a c e ( ) ;
39
40
c o n t e n t E x t r a c t i o n = ( ITTR )
41
managerContentExtraction . getProvidedInterface ( ) ;
42
43
preprocessing = ( IEnglishFiltering )
44
managerPreprocessing . getProvidedInterface ( ) ;
45
46
index = ( ILuceneIndexing )
47
managerIndex . g e t P r o v i d e d I n t e r f a c e ( ) ;
48
49
l a n g u a g e = " en " ;
50 }
56
4.2. ESTUDO DE CASO 2: SISTEMA DE RECOMENDAÇÃO DE BLOGS
Esta especificação é similar ao do primeiro estudo de caso:
• Instância as interfaces e seus gerenciadores(Linhas 4-13);
• Configura as interfaces requeridas (Linhas 17-35);
• Recebe as interfaces providas(Linhas 37-47).
4.2.2
Criação do Sistema de Recomendação
Este sistema usa os componentes de classificação, usando redes bayseanas, e o English
filtering disponibilizados pelo framework. O objetivo deste estudo de caso é mostrar
a utilização dos componentes do RetriBlog para criar outros tipos de aplicação, dessa
forma reforçando o reuso destes componentes.
Como já foi dito esse sistema recomenda blogs para ajudar nas interações do fórum do
ambiente MASSAYO. Em suma, este sistema monitora a discussão entre os estudantes no
fórum e identifica possíveis duvidas dos estudantes. Depois disso, o sistema recomenda
um blog que pode ajudar a resolver a dúvida.
O sistema pode classificar os postagem do usuário como:
• Dúvida, dúvidas que o usuário posta no fórum;
• Explicação, respostas para dúvidas postadas no fórum;
• Comentário neutro, que não foram classificados nas classes anteriores.
O sistema recomenda blogs para postagens classificados como dúvida. A Figura 4.5
mostra o diagrama de atividades do sistema.
Abaixo as descrevem-se as fases do diagrama:
• Interação do Usuário: O usuário interage com o fórum, e cada postagem é enviado
para o sistema de recomendação;
• Classificação da Postagem: O sistema de recomendação classifica a postagem
(usando o componente do RetriBlog) como dúvida, explicação ou comentário
neutro;
• Eliminação de Stop Words: Usando o componente English Filtering, o sistema de
recomendação elimina todas as stop words do texto;
57
4.2. ESTUDO DE CASO 2: SISTEMA DE RECOMENDAÇÃO DE BLOGS
Figura 4.5 Diagrama de Atividades
• Detecção do assunto da Postagem: Para determinar o assunto da postagem, o sistema de recomendação usa as palavras chaves providas pelo ambiente MASSAYO.
Estas palavras são criadas quando o curso se inicia;
• Recomendação de Blog: O sistema testa a postagem. Se for uma dúvida, o sistema
sugere um blog para o usuário. Caso contrário, o sistema não faz nada.
4.2.3
Execução da aplicação
Para avaliar o sistema de recomendação foi usando o fórum do ambiente MASSAYO
e 12 estudantes da disciplina de engenharia de software. Depois de uma postagem do
professor os estudantes interagem no fórum. O objetivo do sistema é manter os estudantes
sempre ativos. Então para avaliar a recomendação usamos como parâmetro a quantidade
de estudantes que interagiram depois da recomendação.
A interação começa com o professor fazendo uma postagem(Figura 4.6). Depois
disso, seguem com as postagens dos alunos(Figura 4.7).
Após a interação do sistema, recomendando blogs para os estudantes com dúvidas, foi
percebida uma melhora na participação dos alunos no fórum e a qualidade das postagens
aumentou. O sistema não tem como garantir que todos os estudantes participem do fórum,
mas melhora a discussão gerada nesta ferramenta. A Figura 4.8 apresenta um gráfico que
mostra como as interações aumentaram depois da recomendação. A linha vermelha na
figura mostra o momento exato da recomendação e depois fica claro que as interações
aumentaram.
Este sistema foi inicialmente publicado em Creating a Blog Recommendation System
Through a Framework for Building Blog Crawlers (Ferreira et al., 2011b) e depois foi
58
4.2. ESTUDO DE CASO 2: SISTEMA DE RECOMENDAÇÃO DE BLOGS
Figura 4.6 Postagem do Professor
Figura 4.7 Postagem dos Alunos
Figura 4.8 Gráfico das Interações no Fórum
publicado com mais detalhes em Improving the Dynamic Interaction in Virtual Learning
Environments Through an Ontology-based Recommender System (Melo et al., 2011).
59
4.3. ESTUDO DE CASO 3: RASTREADOR DE NOTÍCIAS PARA CLIPAGEM
4.3
Estudo de Caso 3: Rastreador de Notícias para Clipagem
Do inglês clipping, o termo "clipagem"define o processo de selecionar notícias em meios
de informação, como jornais, revistas e sites, para resultar em um conjunto de recortes
sobre os assuntos de total interesse de quem os coleciona (Baeza-Yates and Ribeiro-Neto,
1999). Os profissionais do jornalismo, esse método é utilizado para vários objetivos
entre os quais selecionar notícias semelhantes a outra que ele possui, com o objetivo de
definir a veracidade desta notícia. O profissional da área busca a informação requerida em
diversos meios de comunicação. Se a busca retornar informações semelhantes à notícia
que ele possui, é comprovada que esta é verdadeira e ela é então publicada. Além disto,
com o conjunto de notícias similares, os jornalistas podem adquirir mais informações
sobre um determinado acontecimento.
Contudo, antes de realizar a clipagem é necessário obter as notícias. Com esse fim
foi criado um crawler para obter notícias na web. O objetivo deste estudo de caso é
mostrar que o RetriBlog também pode ser usado para criar crawlers de notícias facilmente.
Este fato acontece pela similaridade de como as notícias e os blogs são construídos, a
Figura 4.9 mostra essa semelhança.
Figura 4.9 Semelhança entre Blog e Site de Notícias
60
4.3. ESTUDO DE CASO 3: RASTREADOR DE NOTÍCIAS PARA CLIPAGEM
Este estudo de caso vai ser dividido em duas seções: i) Configuração do Framework;
ii) Execução da aplicação.
4.3.1
Configuração do Arcabouço
Esta aplicação recupera notícias de três sites de notícias de Pernambuco, são eles: FolhaPE, NE10, diário de Pernambuco2 . Como esse crawler coleta URLS de três sites
diferentes, foi criado um processo para cada um, ou seja, foram usados três componentes de coletor de URLS que foram criados especificamente para essa aplicação. Os
componentes escolhidos para a aplicação foram:
• Coletor de URLS: FolhaPE, NE10 e diário de Pernambuco;
• Extração de conteúdo: DSC;
• Pré-processamento: Portuguese Filtering;
• Indexação: Lucene Index.
A Figura 4.10 mostra o diagrama de componentes.
Figura 4.10 Diagrama de Componentes - Estudo de Caso 3
O código dessa aplicação seria similar aos códigos mostrados nos outros dois estudos
de caso. Contudo, ele apresenta uma diferença fundamental, são instanciados três
coletores de URLS. O Código 4.4 mostra a especificação.
2 http://www.folhape.com.br/,
www.ne10.uol.com.br,http://www.diariodepernambuco.com.br/
61
4.3. ESTUDO DE CASO 3: RASTREADOR DE NOTÍCIAS PARA CLIPAGEM
Código 4.4 Classe de Especificação do Estudo de Caso 3
1
2
public class Case3Specification {
3
4
IFolhaUrlCollector
urlCollector1 ;
5
INE10UrlCollector
urlCollector2 ;
6
IDiarioUrlCollector
urlCollector3 ;
7
IDSC
contentExtraction ;
8
IPortugueseFiltering
preprocessing ;
9
ILuceneIndexing
index ;
String
language ;
10
11
12
IManager m a n a g e r U r l C o l l e c t o r 1 ;
13
IManager m a n a g e r U r l C o l l e c t o r 2 ;
14
IManager m a n a g e r U r l C o l l e c t o r 3 ;
15
IManager m a n a g e r C o n t e n t E x t r a c t i o n ;
16
IManager m a n a g e r P r e p r o c e s s i n g ;
17
IManager managerIndex ;
18
19
public Case3Specification (){
20
21
managerUrlCollector1 = F o l h a U r l C o l l e c t o r F a c t o r y . getManager ( ) ;
22
managerUrlCollector2 = NE10UrlCollectorFactory . getManager ( ) ;
23
managerUrlCollector3 = D i a r i o U r l C o l l e c t o r . getManager ( ) ;
24
m a n a g e r C o n t e n t E x t r a c t i o n = DSCFactory . g e t M a n a g e r ( ) ;
25
managerPreprocessing = PortugueseFilteringFactory
26
. getManager ( ) ;
27
managerIndex = LuceneIndexingFactory . getManager ( ) ;
28
29
managerUrlCollector1 . setRequiredInterface ( " IHttpUtils " ,
30
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
31
32
managerUrlCollector2 . setRequiredInterface ( " IHttpUtils " ,
33
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
34
35
managerUrlCollector3 . setRequiredInterface ( " IHttpUtils " ,
36
H t t p U t i l s F a c t o r y . getManager ( ) . g e t P r o v i d e d I n t e r f a c e ( ) ) ;
37
62
4.4. DISCUSSÃO SOBRE OS ESTUDOS DE CASO
38
urlCollector1 = ( IFolhaUrlCollector )
39
managerTagParser . g e t P r o v i d e d I n t e r f a c e ( ) ;
40
41
urlCollector2 = ( INE10UrlCollector )
42
managerTagParser . g e t P r o v i d e d I n t e r f a c e ( ) ;
43
44
urlCollector3 = ( IDiarioUrlCollector )
45
managerTagParser . g e t P r o v i d e d I n t e r f a c e ( ) ;
46
47
c o n t e n t E x t r a c t i o n = ( ITTR )
48
managerContentExtraction . getProvidedInterface ( ) ;
49
50
preprocessing = ( IPortugueseFiltering )
51
managerPreprocessing . getProvidedInterface ( ) ;
52
53
index = ( ILuceneIndexing )
54
managerIndex . g e t P r o v i d e d I n t e r f a c e ( ) ;
55
56
language = " pt " ;
57 }
Esta especificação é similar à dos outros estudos de caso, a principal diferença é,
como já foi dito, instanciar três coletores de URLS. A explicação do código é:
• Instância as interfaces e seus gerenciadores(Linhas 4-17);
• Configura as interfaces requeridas (Linhas 21-36);
• Recebe as interfaces providas(Linhas 38-54).
4.4
Discussão Sobre os Estudos de Caso
Os estudos de caso tinham dois objetivos principais, mostrar a flexibilidade do sistema,
instanciando ele em vários contextos diferentes e mostrar a vantagem de usar uma abordagem baseada na arquitetura. Por essa razão foram utilizados o máximo de componentes
diferentes na implementação dos estudos de caso.
O primeiro ponto foi satisfeito visto que usamos serviços diferentes do framework em
vários contextos. Com blogs e notícias, diferentes algoritmos, aplicado a educação, entre
outros.
63
4.4. DISCUSSÃO SOBRE OS ESTUDOS DE CASO
O segundo ponto fica bem evidente nas explicações dos códigos das classes de
especificação. Em todos os caso a explicação era a mesma, mudando apenas as linhas de
código a que ela se referia. Isso mostra que apenas precisamos escolher os componentes
e criar a classe de configuração, que é basicamente a mesma sempre, para gerar uma
aplicação do o framework.
Outros pontos que ficam evidenciados nesses estudos de caso são:
• Que o sistema apresentado é um framework caixa cinza, visto que o usuário só
precisa saber das interfaces para instanciar o sistema, ele não precisa saber de
detalhes da implementação de cada classe;
• Que o framework é de domínio e aplicação, pois os seus serviços foram feitos para
lidar com o crawler de blogs (domínio), mas pode ser usado para outros fins como
crawler de notícias (aplicação).
64
5
Experimentos e Resultados Preliminares
Para avaliar os serviços do RetriBlog um conjunto de experimentos nos algoritmos
de extração de conteúdo, classificação(avaliação sobre a influência do desempenho
de classificação de páginas HTML usando algoritmos de extração de conteúdo e préprocessamento) e recomendação de tags foram realizados. Além disto, é apresentado
uma avaliação qualitativa sobre a utilização do COSMOS*. Esse capítulo descreve como
esses experimentos foram feitos, apresenta resultados sobre alguns algoritmos propostos
e discute algumas conclusões derivadas de cada deles. Esses algoritmos foram avaliados
usando as métricas de precisão, cobertura e f-measure. Os números obtidos mostram que
os algoritmos propostos alcançaram bons resultados.
5.1
Avaliação: Extração de Conteúdo
Os documentos tratados pelo sistema são blogs, ou seja, são páginas HTML das quais
o sistema deve recuperar o conteúdo principal e o título. Contudo, não foi encontrado
em nossa pesquisa bibliográfica, nenhum corpus anotado de blogs que atende as nossas
necessidades. Sendo assim, verificamos a similaridade entre textos de blogs com outros
tipos de páginas Web, e decidimos estender nossos experimentos em páginas de notícias
(news), pois estas possuem uma estrutura muito parecida com as de blog, como já foi dito
em um dos estudos de caso.
Para avaliar o desempenho do sistema proposto, foi utilizado o corpus de notícias
descrito em (Kohlschütter et al., 2010). Este corpus consiste de 621 páginas de notícias
coletadas manualmente de 408 sites diferentes, escolhidos aleatoriamente de um conjunto
de 254.000 notícias. Elas foram obtidas através do Google News search engine1 durante
1 http://news.google.com.br/
65
5.1. AVALIAÇÃO: EXTRAÇÃO DE CONTEÚDO
à primeiro semestre de 2008.
Na construção do corpus, estas páginas foram anotadas por 7 pessoas que marcaram
sequências de textos como sendo não-conteúdo, título, texto completo, texto suplementar
(texto que não pertence ao artigo, mas que é texto completo, tais como captions de
imagens, etc), comentários e conteúdos relacionados (links para outros artigos). Destas
anotações, foram utilizadas o título, o conteúdo e o texto suplementar para testar os
algoritmos de extração de conteúdo. Dessas a primeira se refere ao título, e as outras
duas, se referem ao texto principal da postagem.
Foram realizados experimentos com os algoritmos de extração de conteúdo SummaryStrategy (Ferreira et al., 2010b), BoilerPlate (Kohlschütter et al., 2010), Document
Slope Curve (DSC) (Pinto et al., 2002), Text-to-Tag Ratio (TTR) (Weninger and Hsu,
2008) e uma heurística baseada no algoritmo Link Quota Filter (LQF) (Gottron, 2007).
De acordo com (Gottron, 2007) as quatro abordagens mais utilizadas para avaliação
de algoritmos de extração de conteúdo são:
• Cadeia de Caracteres, que verifica cada letra do texto em ordem seqüencial como
aparece no texto;
• Seqüência de palavras, que analisa cada palavra também levando em conta a
ordem entre elas no texto;
• Conjunto de Palavras e Freqüência, que analisa quais palavras apareceram, e
em qual freqüência;
• Conjunto de Palavras, que analisa quais palavras apareceram, independente de
ordem ou freqüência.
Dentre os quatro métodos de avaliação citados acima, foi escolhido no trabalho o
Conjunto de Palavras, por sua simplicidade na implementação. Em princípio, o método
escolhido pode parecer muito simples ou menos exato que os demais; no entanto, como
mostra (Gottron, 2007), este método fornece resultados muito similares às outras três
abordagens. Além disso, para fins de indexação de documentos, por se tratar de uma das
principais aplicações dos algoritmos de extração de conteúdo aqui apresentados, é crucial
não deixar de considerar todas as palavras que serão usadas no processo de indexação.
Um ponto observado foi que por alguns algoritmos analisados serem baseados em
limiares proporcionais à quantidade de texto da página, eles podem cometer erros em
blogs com muitos comentários ou com comentários mais longos, pois o limiar para
extração será mais alto que o convencional.
66
5.1. AVALIAÇÃO: EXTRAÇÃO DE CONTEÚDO
Outro problema encontrado em todos os algoritmos avaliados é o fato de algumas
vezes não conseguirem extrair campos com pouco texto, que ficam separados do conteúdo
principal, como o título ou a data de publicação. Este problema pode ser contornado
com heurísticas simples baseadas em atributos desses campos, tal como sua posição.
Geralmente esses campos, apesar de separados do conteúdo principal, encontram-se
imediatamente antes ou depois do conteúdo principal.
A análise do sistema é fundamentada nas medidas clássicas usadas em sistemas de
recuperação de informação, isto é, Precisão(P), Cobertura(C) e F-measure(F1) (BaezaYates and Ribeiro-Neto, 1999). A precisão calcula quantas palavras capturadas são
relevantes para o documento(5.1), enquanto a cobertura indicou a relevância das palavras
na recuperação, considerando o conjunto total de palavras relevantes(5.2). A análise feita
apresentou os resultados em relação ao conteúdo principal do post. A Tabela 5.1 a seguir
expõe os resultados referentes a cada algoritmo utilizado nos experimentos.
P=
PalavrasCapturadas
(5.1)
TotalDePalavrasRecuperadas
C=
PalavrasCapturadas
(5.2)
PalavrasRelevantes
Tabela 5.1 Avaliação - Extração de Conteúdo
Algoritmo
SummaryStrategy
TTR
Boilerplate
DSC
DSC + LQF
Precisão
73,46
71,09
93,19
94,33
92,37
Cobertura
71,92
87,38
91,69
88,29
98,28
F-measure
72,68
78,40
92,43
91,21
95,23
Os melhores resultados foram alcançados pelo algoritmo DSC e Boilerplate. Contudo,
estes algoritmos utilizam o DOM das páginas HTML para encontrar o texto principal.
Com isso, eles são mais lentos do que os algoritmos TTR e SummaryStrategy, estes
utilizam apenas o texto da página para extrair o conteúdo. Desta forma, dependendo
dos requisitos da aplicação o usuário pode escolher um algoritmo que tenha precisão e
cobertura menores, porém que seja mais eficiente.
67
5.2. AVALIAÇÃO: CLASSIFICAÇÃO
5.2
Avaliação: Classificação
Para avaliar os algoritmos de classificação foi usado o mesmo corpus empregado na
avaliação dos algoritmos de extração de conteúdo. Contudo, esse corpus não possuía
as classes das notícias. Então, foram selecionados 270 notícias do corpus e elas foram
distribuídas em 4 categorias, como mostra a Tabela 5.2. Essas classes foram anotadas
manualmente para realizar o experimento.
Tabela 5.2 Distribuição das Categorias
Categoria
Esportes
Entretenimento
Tecnologia
Mundo
Frequência
70
70
60
70
Assim como no experimento anterior, foram adotadas as métricas clássicas de recuperação de informação(P, C e F1) para avaliar os algoritmos de classificação. Os testes
foram realizados usando a metodologia cross validation (Geisser, 1993).
Para cada algoritmo de classificação discutido no trabalho foram realizados testes
com o objetivo de analisar a influência dos algoritmos de extração de conteúdo e préprocessamento nos resultados da classificação. Para isso foram realizadas as seguintes
avaliações:
• Classificação da página sem nenhum pré-processamento;
• Classificação da página depois da extração do conteúdo;
• Classificação da página depois da extração de conteúdo e da remoção de stop
words.
O gráfico apresentado na Figura 5.1 mostra os resultados da classificação.
Considerando o gráfico acima percebemos que o algoritmo que alcançou melhor
F-measure (mais de 90%) no experimento foi o TF-IDF. Além disto, foi confirmado que
todos os algortimos de classificação obtiveram melhores resultados depois da realização
da extração de conteúdo e do pré-processamento. Por exemplo, a Figura 5.2 mostra que
o ganho de performance para o algoritmo de redes bayseanas foi de quase 30%. Isso
acontece porque a extração de conteúdo e o pré-processamento eliminam propagandas
e informações pouco usadas deixando apenas o conteúdo principal do blog para ser
classificado.
68
5.2. AVALIAÇÃO: CLASSIFICAÇÃO
Figura 5.1 Resultado da Classificação: CE = Extração de Conteúdo; P = Pré-Processamento
Figura 5.2 Influência da Extração de Conteúdo e do Pré-Processamento no Algoritmo de Naive
Bayes
69
5.3. AVALIAÇÃO: RECOMENDAÇÃO DE TAGS
Os algoritmos de classificação também foram avaliados segundo a sua eficiência. Em
outras palavras, foi medido qual o tempo médio que cada um deles leva para classificar
uma página. A Tabela 5.3 mostra o desempenho de cada algoritmo.
Tabela 5.3 Tempo para Execução da Classificação
Algoritmo
Redes Bayesiana
KNN
TF-IDF
Tempo
2,16
1,97
1,42
Apesar de o algoritmo TF-IDF ter alcançado melhores desempenhos tanto na performance quando na eficiência, ele é um algoritmo um pouco mais complicado de se
usar, enquanto os outros dois são mais simples. Diante destes resultados o usuário pode
escolher o melhor algoritmo para a sua aplicação.
Esses resultados foram publicados em Improving News Web Page Classification
Through Content Extraction (Ferreira et al., 2011c).
5.3
Avaliação: Recomendação de Tags
Para criar o corpus para o experimento dos algoritmos de recomendação de tags foi utilizado o crawler descrito na Seção 4.1. Foram coletados 623 posts da Technorati escritos
em inglês, e foram armazenados no banco MySQL do sistema. Para os experimentos
estamos interessados nos seguintes elementos: título, link da postagem, resumo, texto em
HTML, texto sem tags HTML, e tag. A Tabela 5.4 mostra a distribuição das tag para este
conjunto de dados.
Os resultados apresentados nesta seção mais uma vez vão ser expressos usando
precisão, cobertura, e F-measure. No nosso caso, a precisão mede quantas tags foram
corretamente recomendadas (Fórmula 5.3). Enquanto cobertura indica quantas tags foram
recomendadas, considerando o conjunto total de marcas relevantes no conjunto inteiro
(Fórmula 5.4). Os valores de precisão e cobertura foram obtidos por avaliação humana, ou
seja, as regras geradas pelos serviços foram analisados por quatro avaliadores humanos.
P=
TagsCorretamenteRecomendadas
(5.3)
TotalDeTagsRecomendadas
70
5.3. AVALIAÇÃO: RECOMENDAÇÃO DE TAGS
Tabela 5.4 Distribuição das Tags no Dataset
Tag
propaganda
anúncio
atletismo
livro
booking
livros
negócios
modelo de negócios
comunidade
cozinha
corrupção
didactics
drama
ebooks
economia
economia
educação
engenharia
entretenimento
fashion
fashionable
fashions
filme
futebol americano
C=
Freqüência
10
9
10
33
9
10
33
5
8
10
3
9
4
7
10
19
39
10
39
38
9
7
3
9
Tag
governo
hollywood
humor
jazz
aprendizagem
literatura
maneira
mp3
música
nba
notícias
nlf
Obama
oscars
pedagogia
fotografia
política
esportes
estilo
ensino
tecnologia
viagem
escrita
Freqüência
5
9
4
8
8
6
8
5
38
5
8
10
8
9
10
5
37
35
6
6
36
7
7
TotalDeTagsRecomendadas
(5.4)
TotalDeTagsRelevantes
O primeiro serviço de recomendação avaliado será o de similaridade. O gráfico
apresentado na Figura 5.3 apresenta o percentual de precisão, cobertura e F-measure
em termos de grau de similaridade. Conforme mencionado na Seção 3.5.5, grau de
similaridade é medido usando como métrica a Distância Levenshtein.
Os melhores resultados alcançados por este serviço é quando o grau de similaridade
está entre 65% e 70%. Também observou-se que regras com grau de similaridade inferior
a 55% são descartáveis, pois existem muito mais regras erradas do que certas quando
o grau de similaridade é esse. A Tabela 5.5 mostra alguns exemplos de regras obtidas
usando este tipo de serviço.
71
5.3. AVALIAÇÃO: RECOMENDAÇÃO DE TAGS
Figura 5.3 Resultado Similaridade
Tabela 5.5 Regras Geradas pelo Serviço de Recomendação por Similaridade
Regra
businesslike is similar to business
ebooks is similar to book
booking is similar to book
books is similar to book
economics is similar to economy
fashions is similar to fashion
Grau de Similaridade
0.66
0.66
0.57
0.80
0.66
0.87
Como mencionado antes o serviço de recomendação de tag baseado em dicionário
usa o WordNet (Miller, 1995). Foram considerado todos os sinônimos sugeridos pelo
WordNet como relevantes para a esta solução. Por esta razão, não temos este serviço
avaliado em termos de precisão e cobertura. A Tabela 5.6 mostra algumas regras obtidas
após a execução deste serviço.
Tabela 5.6 Regras Geradas pelo Serviço de Recomendação por Dicionário
Regra
amusement is synonymous of entertainment
teaching is synonymous of education
pedagogy is synonymous of education
didactics is synonymous of education
manner is synonymous of fashion
style is synonymous of fashion
athletics is synonymous of sport
engineering is synonymous of technology
O serviço baseado em classificação alcançou resultados encorajadores (precisão =
72
5.3. AVALIAÇÃO: RECOMENDAÇÃO DE TAGS
62.1%, cobertura = 65.4% and F-measure = 63.7%) comparados com outros trabalhos,
mais detalhes na Seção de trabalhos relacionados. Algumas regras geradas por este
serviço são mostradas na Tabela 5.7.
Tabela 5.7 Regras Geradas pelo Serviço de Recomendação por Classificação
Regra
athletics is related to sport
football is related to sport
didactics is related to education
pedagogy is related to education
government is related to politics
jazz is related to music
Obama is related to politics
economics is related to politics
Por fim, o serviço baseado em agrupamento alcançou resultados satisfatórios comparados com os trabalhos relacionados: precisão = 41.1%, recall = 50.4% and F-measure =
45.2%. Algumas regras geradas por este serviço são mostradas na Tabela 5.8.
Tabela 5.8 Regras Geradas pelo Serviço de Recomendação por Agrupamento
Regra
mp3 is related to entertainment
football is related to sport
nfl is related to entertainment
nba is related to entertainment
manner is related to business
government is related to business
news is related to fashion
travel is related to entertainment
Os melhores resultados foram alcançados pelo serviço de similaridade. Esses resultados preliminares sugerem que o trabalho é competitivo com os melhores resultados
outros sistemas(Seção 6.2). Por exemplo, a Autotag (Mishne, 2006) obteve F-measure de
quase 50%, enquanto para o serviço baseado em classificação proposto neste trabalho,
este valor foi de 63,7%(mais detalhes sobre isso será mostrado no capítulo 6).
Vale ressaltar que os valores de desempenho do serviço baseado em similaridade
foram obtidos quando o grau de similaridade foi entre 0,65 e 0,7, mas os resultados acima
de 0,55 são considerados aceitáveis quando comparados com trabalhos relacionados.
Em relação às abordagens baseadas em classificação e agrupamento, observamos que
as tags de educação e esportes tiveram melhor desempenho do que tag entretenimento,
73
5.4. AVALIAÇÃO: COSMOS*
por exemplo. Uma razão que poderia explicar este fato é o uso de estilos de linguagem
diferentes (formal, informal, coloquial, etc), adotada pelo blogs. Uma vez que os blogs
de educação e esportes têm mais ligações com organizações do que os de entretenimento.
Blogs de educação e esportes tendem a ser mais formais e estruturados. Conseqüentemente, os resultados da classificação foram melhores, pois os algoritmos lidam com
palavras mais "corretas". Por outro lado, mensagens de blog sobre entretenimento são
escritos principalmente pelo público em geral, e eles tendem a conter sentenças coloquiais
e linguagem de gírias que podem induzir o classificador ao erro. Finalmente, como já
mencionado, todos os sinônimos sugeridos pelo WordNet são considerados relevantes.
5.4
Avaliação: COSMOS*
Esta seção discute algumas vantagens e desvantagens de projetar um framework utilizando
uma abordagem centrada na arquitetura utilizando o COSMOS*. As principais vantagens
identificadas são:
• Baixo custo de instanciação: Como há uma definição clara da variabilidade do
framework o desenvolvedor de software é capaz de facilmente identificar os hot
spots e, em seguida, instância-lo de acordo com os requisitos da aplicação desejado.
Além disso, este framework oferece algumas implementações de possíveis exemplo
de classes concretas e serviços que realiza os principais hot spots. O desenvolvedor
de software também podem desenvolver outras variantes, se necessário;
• Compreensibilidade: A representação de alto nível proporcionado pela abordagem orientada a arquitetura adotada pelo framework permite que profissionais que
não são de programadores compreendam os detalhes da execução framework, e os
aspectos estruturais para estende-lo. A decomposição uniforme (Klein et al., 1999)
estratégia utilizada durante o projeto arquitetônico deixa essa característica ainda
mais explícita;
• Modularidade e Evolução: Uma vantagem de se adotar uma estratégia centralizada na arquitetura para o desenvolvimento do framework é a existência de módulos
bem definidos, que têm funções específicas e comunicar uns com os outros através
de interfaces explícitas. Além de reduzir o acoplamento entre os componentes do
sistema, ele permite que alterações sejam feitas localmente em módulos específicos.
Isso também facilita a adição e remoção de um novo componente;
74
5.4. AVALIAÇÃO: COSMOS*
• Gerenciamento: Uma vez que o framework proposto é composto por uma arquitetura híbrida (camadas e componentes independentes), isso fornece o paralelismo
no processo de desenvolvimento. Além disso, como já mencionado, os componentes são auto-suficientes, isto é, o desenvolvedor só precisa saber suas interfaces.
Portanto, o gerenciamento torna-se mais fácil;
• Monitoramento: Devido aos benefícios da programação modular, o tempo de
desenvolvimento deve ser encurtado porque grupos separados poderiam trabalhar
em cada componente com pouca necessidade de comunicação. Assim, é mais fácil
monitorar os componentes separados (subsistemas) do que todo o sistema;
• Reuso: Com base nas vantagens citadas anteriormente, por exemplo, baixo acoplamento e modularidade, cada componente é independente e auto-suficiente, desta
forma a reutilização é mais simples. Portanto, é possível fazer alterações em
um componente sem mudar os outros. Além disso, os componentes podem ser
facilmente utilizados separadamente em outros aplicativos, como o sistema de
recomendação.
Por outro lado, as desvantagens mais evidentes são:
• Evolução Interna: Para adicionar novas features ou novos pontos de variação
no framework o desenvolvedor precisa conhecer o modelo COSMOS* e entender
o código do sistema. Em outras palavras ele tem que ter uma curva maior de
aprendizagem sobre o sistema;
• Uso de conectores explícitos: Utilizar conectores explícitos aumenta a flexibilidade e melhora a evolução. Contudo, isto aumenta consideravelmente o número
de indireções o que pode prejudicar alguns requisitos de qualidade, tais como:
desempenho e consumo de memória. Porém, com esse tipo de sistema é mais fácil
implementar distribuição, uma possível solução para esse problema;
• Escalabilidade: Devido ao número de componentes para ser instanciados o sistema
exige muita memória o que pode prejudicar aplicações que trabalhem com muitos
dados. Porém, como já foi dito, a componentização também facilita a distribuição,
solução direta para esse problema;
• O framework não automatiza o processo de instanciação: Dessa forma precisa
que o usuário entenda uma parte do código, as interfaces. Contudo, por se tratar de
75
5.4. AVALIAÇÃO: COSMOS*
um framework caixa cinza a automatização da instanciação é um processo pouco
custoso de se criar.
76
6
Trabalhos Relacionados
Este Capítulo detalha os principais trabalhos relacionados à utilização do COSMOS*,
aos serviços de recomendação de tag e classificação e ao RetriBlog. Dessa forma, este
Capítulo foi dividido em quatro partes. A primeira apresentam trabalhos relacionados à
utilização do COSMOS*. Depois duas seções sobre trabalhos que apresentam serviços
de recomendação de tags e de classificação de páginas HTML. A quarta seção fala sobre
trabalhos relacionados ao RetriBlog como um todo. Por fim, na última seção, algumas
conclusões e comparações são apresentadas.
6.1
COSMOS*
Koala (van Ommering et al., 2000) é um modelo de componente que utiliza uma notação
gráfica para representar arquiteturas de sistemas embarcados. Esta descrição da arquitetura é baseada em uma linguagem de descrição de arquitetura chamada Darwin (Magee
and Kramer, 1996). Neste modelo, as interfaces são entidades de primeiro nível, que
pode ser providas ou requeridas por elementos arquiteturais.
Whitehead e seus colaboradores (Whitehead et al., 1995) identificaram diretrizes
para melhor especificar arquiteturas de software, tais como: i) maior granularidade
dos componentes da arquitetura, que pode ser obtida através do encapsulamento de
muitas classes de implementação, ii) facilidade para mudar componentes, que pode ser
obtida através do uso de interfaces providas e requeridas explícitas, e iii) facilidade para
implementar distribuição, que pode ser obtida através da integração do ambiente de
desenvolvimento com um repositório de componentes.
A referência a seguir (McDirmid et al., 2001) estende a linguagem Java com o conceito
de componentes de software, que podem ser compilados separadamente e ligados entre si.
Nesta abordagem, os componentes são chamados de unidades, que podem ser átomos,
77
6.2. SERVIÇOS DE RECOMENDAÇÃO DE TAGS
que são construídos usando classes Java, ou composto, que são construídos usando uma
linguagem específica definida como parte da solução. A principal diferença entre este
modelo e COSMOS* é que, enquanto McDirmid et al. define uma nova linguagem de
programação para a especificação de aplicações baseadas em componentes, o modelo
COSMOS* define diretrizes para o uso da linguagem Java para realizar a criação dos
compenentes de software em código.
ArchJava (Aldrich et al., 2002) também define uma extensão da linguagem Java que
permite a representação explícita de arquiteturas baseadas em componentes de software
(componentes, conectores e configuração) em nível de programação. A representação da
arquitetura, que é feito em uma linguagem específica, pode ser ainda transformada em
código fonte de Java.
Rosenblum e Natarajan (Rosenblum and Natarajan, 2000) estenderam o modelo
JavaBeans, a fim de permitir a representação explícita de componentes de software e
conectores compatíveis com o estilo arquitetural C2 (Taylor et al., 1995). Esta extensão
é suportada por um ambiente de desenvolvimento de software chamado Arabica. Diferentemente, o modelo COSMOS* não impõe a adoção de qualquer estilo específico de
arquitetura.
Como JavaBeans e COM, o COSMOS* também define padrões para representar
componentes de software. No entanto, diferentemente de tais modelos, componentes
COSMOS* pode encapsular várias classes de implementação. Além disso, o conceito de
interfaces requeridas e conectores não são explicitamente representadas no JavaBeans e
modelos COM.
A Tabela 6.1 apresenta uma comparação envolvendo as tecnologias de componente
acima e o modelo COSMOS*.
6.2
Serviços de Recomendação de Tags
Os trabalhos relacionados podem ser classificados em duas categorias: abordagens
baseadas em tags e baseadas em postagem. No primeiro, somente tags são usadas para
fazer sugestões de novas tags relevantes. No último, o sistema utiliza as tags e o texto da
postagem para recomendar novas tags.
Os autores em (Kim et al., 2009) propõem um sistema baseado em tags que usa
padrões de associação. Estes padrões são usados para relacionar uma tags com outras.
Sua abordagem também usa medidas de co-ocorrência de tags como parâmetro para
ajudar a sugerir tags relevantes.
78
6.2. SERVIÇOS DE RECOMENDAÇÃO DE TAGS
Tabela 6.1 Comparação entre tecnologias de componentes
Funcionalidade
JavaBeans
Separação explícita entre especificação
sim
e implementação
Representação explícita de interfaces
não
requeridas
Representação explícita de conectores
não
Baixo acoplamento entre os componennão
tes
Facilidade para a evolução
não
Independência de linguagem/tecnolonão
gia
Ferramenta para Suporte
sim
COM
sim
ArchJava
sim
COSMOS*
sim
não
sim
sim
não
não
sim
sim
sim
sim
não
não
não
não
sim
sim
sim
sim
sim
Em (Hassan-montero and solana A, 2006) os autores apresentam uma abordagem
baseada em tag que usa a relação de co-ocorrência(CO) como uma medida de similaridade. A medida de co-ocorrência relativa de duas tags A e B é dada pelo número de
postagens em que essas tags aparecem juntas, dividido pelo número de postagens que
contém qualquer uma delas (fórmula 6.1). Outro sistema baseado em tag é proposto em
(Sigurbjörnsson and van Zwol, 2008). Ele também usa a medida co-ocorrência.
CO =
TotalP ostAB
(6.1)
TotalP ostA + TotalP ostB
Onde:
• Total_PostAB: Total de postagens que contém as tags A e B juntas;
• Total_PostA: Total de postagens que contém a tag A;
• Total_PostB: Total de postagens que contém a tag B.
Em (Mishne, 2006), foi proposto o AutoTag, um sistema de recomendação de tag
baseado em postagem que usa a mesma estratégia de sistemas de recomendação comercial:
sugerindo produtos para um usuário com base nos produtos comprados por outros. O
AutoTag sugere tags para um blog com base em tags de postagens semelhantes. O
sistema encontra posts similares, usando técnicas de recuperação de informações que são
baseadas no conteúdo textual das postagens.
TagAssist (Sood et al., 2007) consiste de um outro sistema de recomendação baseado
em postagem. TagAssist é semelhante ao sistema AutoTag por também ser baseado
79
6.3. SERVIÇOS DE CLASSIFICAÇÃO
em sistemas de recomendação comercial. No entanto, mostrou um melhor desempenho
devido ao uso de técnicas de compressão tag, o que reduz as tags à sua forma de raiz.
SocialTagger (Subramanya and Liu, 2008) também usa estratégias semelhantes.
O sistema iTag (Hart et al., 2009) segue as mesmas idéias das outras abordagens baseadas em postagens. Ele melhora TagAssist com diferentes abordagens para a recuperação
de tag e usa dados de treinamento diferentes para fornecer melhores recomendações tag.
Neste trabalho foram implementados e avaliados quatro serviços diferentes de recomendação de tag, dois baseados em tags e dois baseados em postagem. Os serviços
de recomendação de tags foram integrados no RetriBlog com o objetivo de alcançar
melhores valores de eficiência, escalabilidade e baixa dependência do corpus. Com todas
estas opções à mão, o usuário pode escolher qual serviço melhor se adapta às suas necessidades. Esta é uma das principais contribuições desta parte do trabalho, considerando
a flexibilidade que ele fornece para o usuário. Além disso, estes serviços obtiveram
resultados encorajadores em termos de precisão e cobertura.
6.3
Serviços de Classificação
Os autores em (Hong Qu, 2006) propõem uma abordagem para classificação automática de blogs em quatro gêneros: diário pessoal, notícias, política e esportes, usando
representação de documento TF-IDF e classificação usando redes bayseanas. Em seus
experimentos, os autores utilizaram um corpus composto por 120 blogs, sendo 30 para
cada categoria, e o desempenho da classificação foi de cerca de 84%.
O BlogHarvest (Joshi, 2006) é um framework de pesquisa e mineração blog que
extrai interesses dos blogueiros, acha e recomenda blogs com temas similares, e fornece
a funcionalidade de pesquisa de blog. O BlogHarvest usa um classificador baseado
em redes bayseanas para identificar blogs com temas semelhantes. Uma limitação que
pode ser apontada neste trabalho é que ele tem crawlers diferentes para cada serviço de
indexação de blog (google, yahoo, etc.) Além disso, os autores não relataram qualquer
resultado experimental para a etapa de classificação.
(Hiep Phuc Luong and Wang, 2009) apresentou um framework para aprendizagem
de ontologias que permite a recuperação de documentos da Web usando um crawlers
focado em um domínio de biologia. Os autores utilizaram uma ontologia como entrada e,
para cada conceito na ontologia, o crawlers gera uma consulta que é submetido a duas
fontes de dados (motores de pesquisa e bibliotecas digitais). Um classificador SVM é
então empregado para identificar documentos específicos do domínio, e para executar
80
6.4. SISTEMA PARA RECUPERAR INFORMAÇÕES DE BLOGS
a mineração de texto para extrair informação útil em um processo de enriquecimento
de ontologias. Por outro lado, encontramos os seguintes problemas neste trabalho: a
necessidade de criar um crawler específico para cada motor de busca, e um conjunto de
dados pequenos (96 documentos, sendo 48 para cada categoria) foi usado na montagem
do experimento.
A abordagem apresentada nesse trabalho se diferencia das obras acima referidas,
principalmente porque:
• O framework proposto é independente de plataforma, ou seja, ele não tem que criar
um crawler separado para cada host de blog;
• Algoritmos de extração de conteúdo são capazes de identificar o conteúdo textual
relevante a partir de blogs independente do seu host. Além disso, foi demonstrado
que a fase de pré-processamento teve um grande impacto nos resultados de classificação, em que o nosso melhores resultados de classificação (precisão = 91,3% e
cobertura = 89,2%).
6.4
Sistema para Recuperar Informações de Blogs
Os principais sistemas que procurar trabalhar com blogs encontrados na literatura podem
serão divididos em dois blocos. O primeiro tem os sistemas Blogscope (Bansal and
Koudas, 2007), Blogranger (Fujimura et al., 2006) e BlogTrackers (Agarwal et al.,
2009), eles possuem serviços para obter informações dos blogs, porém não foram criados
pensando em variabilidades. O segundo blog são frameworks, assim como o RetriBlog.
Neste bloco temos os sistemas (Chau et al., 2009) e BlogHarvest (Joshi, 2006). A seguir
cada um desses sistemas são mais detalhados.
O Blogscope (Bansal and Koudas, 2007) é um sistema de análise de grandes volumes
de dados on-line, atualmente é aplicado à análise da Blogosfera. Ele indexa a Blogosfera
e extrai informações a fim de auxiliar a análise interativa e descoberta de informações. O
processo de crawler funciona da seguinte forma:
1. Recebe uma lista dos blogs atualizados na última hora 1 ;
2. Utiliza um classificador baseado na técnica de redes bayesianas para remover spans;
3. Armazena os dados em um banco de dados relacional e cria um index para ajudar
na busca.
1 informação
obtida do site site weblogs.com
81
6.4. SISTEMA PARA RECUPERAR INFORMAÇÕES DE BLOGS
Além disso a sistema oferece os serviços de detecção de tags, suporte on-line para
análise OLAP, interface de navegação nos blog, e extração de resumo.
O Blogranger (Fujimura et al., 2006) é uma ferramenta de busca de blogs baseada
em múltiplas interfaces. Ela oferece quatro interfaces diferentes, duas para pesquisa tag,
e outras para blogueiro e pesquisa reputação. As interfaces são facilmente alteradas, elas
funcionam como um filtro que classifica o resultado da pesquisa baseada na intenção
da pesquisa. Esta ferramenta apresenta um crawler relativamente simples, mas oferece
serviços de análises sentimento de blog, detecção de tag, e uma interface de busca que
são bastante interessantes.
O BlogTrackers (Agarwal et al., 2009) é uma aplicação Java que fornece uma
plataforma unificada para o usuário fazer crawler e analisar os dados dos blog. Ele
concede ao usuário, a liberdade de escolher os dados de interesse e ajuda na efetivamente
a analisá-los. O crawler funciona da seguinte forma: i) recupera links para blogs; ii)
Extraí o conteúdo principal usando expressão regular; iii) Armazena em um bando de
dados relacional e cria um índice. Além disto, ela fornece serviços como recomendação
tag, classificação e possui uma interface de visualização.
Em (Chau et al., 2009) é proposto um framework para mineração blog. Este framework é composto por um crawler de blogs, um analisador de blog, um analisador de
conteúdo do blog, um analisador de rede do blog, e um visualizador do blog. O processo
de crawler tem as seguintes etapas:
1. Se conecta a sites especializados2 para conseguir links de blogs;
2. Extrai informações dos blogs como nome de pessoas, nomes de produtos, informações de tempo;
3. Extrai tags dos postagens;
4. Armazena as informações obtidas nas etapas anteriores.
Além disto, possui um módulo de visualização para o usuário.
O BlogHarvest (Joshi, 2006), como já foi dito, é um framework para busca e mineração de blogs que extrai os interesses dos blogueiros e recomenda blogs com temas
similares. O processo do crawler funciona da seguinte maneira:
1. Recupera links de blogs de sites especializados3 ;
2 Por
3 por
exemplo technorati e google blogs
exemplo technorati
82
6.4. SISTEMA PARA RECUPERAR INFORMAÇÕES DE BLOGS
2. Para cada tipo de blog é criado uma regra (manualmente) que encontre o conteúdo
principal;
3. Identifica as tags do blog;
4. Utiliza serviços de análise de sentimento (para dizer se o post fala bem ou mal do
conteúdo da postagem) e agrupamento de usuários (para futuras recomendações);
5. Indexa os blogs.
Além disto, ele fornece uma interface que ajuda na navegação do usuário.
A principal diferença do RetriBlog para esses trabalhos é a utilização de técnicas de
engenharia de software na implementação do sistema. De todos os trabalhos apresentados
apenas o BlogHarvest apresenta de alguma forma um sistema que fornece para o usuário
pontos de variação. Todos os outros possuem os componentes bastante acoplados. Como
foi dito na seção 3.7 o RetriBlog possui vários pontos de variação e foi implementando
usando componentes o que acarreta nas vantagens descritas na seção 4.4.
Outra diferença fundamental é que nenhum dos trabalhos utiliza serviços de préprocessamento. Além disto, os serviços de extração do conteúdo apresentados são
baseados em expressão regular ou regras manualmente produzidas. Desta forma eles são
fortemente acoplados a apenas um tipo de blog, ou seja, para cada novo tipo de blog o
usuário deve criar uma nova regra de extração.
Os serviços em comum foram os de indexação, recomendação/detecção de tag e
classificação de blogs. Por outro lado, serviços de análise de sentimento, análise OLAP e
extração de resumo são serviços disponibilizados por estas ferramentas que o RetriBlog
não contempla.
Por fim, alguns dos trabalhos apresentados possuem interfaces enquanto o RetriBlog
não disponibiliza. Isso se deve ao fato de que o sistema proposto neste trabalho é voltado
para o desenvolvedor e não para o usuário final. Por isso o módulo de interface não fez
parte inicialmente do projeto. A Tabela 6.2 faz um resumo da comparação.
83
6.4. SISTEMA PARA RECUPERAR INFORMAÇÕES DE BLOGS
Tabela 6.2 Comparação dos Trabalhos Relacionados e o RetriBlog
Sistema
RetriBlog
Blogscope
Blogranger
BlogTrackers
(Chau et al., 2009)
BlogHarvest
Pontos de Variabilidade
sim
não
não
não
não
sim
Sistema
RetriBlog
Blogscope
Blogranger
BlogTrackers
(Chau et al., 2009)
BlogHarvest
Extração de Conteúdo
Automática
não
não
manual
manual
manual
Sistema
RetriBlog
Blogscope
Blogranger
BlogTrackers
(Chau et al., 2009)
BlogHarvest
análise OLAP
não
sim
não
não
não
não
Componentes
desacoplados
acoplados
acoplados
acoplados
acoplados
levemente acoplados
Análise de sentimento
não
não
sim
não
não
sim
extração de resumo
não
sim
não
não
não
não
Indexação
sim
sim
não
sim
não
sim
Recomendação de tag
sim
sim
sim
sim
sim
sim
Pré-processamento
sim
não
não
não
não
não
Classificação
sim
sim
sim
sim
não
sim
84
7
Conclusão
O trabalho apresentou o RetriBlog, um framework para criar blog crawlers usando uma
abordagem centrada na arquitetura e que segue o modelo de implementação COSMOS*.
As principais contribuições do trabalho foram: i) Construção de mecanismos para
recuperar informação na blogosfera (blog crawlers); ii) Implementação de algoritmos
para extração de conteúdo em páginas HTML; iii) Criação de serviços de recomendação
de tags para blogs; iv) Avaliação da influencia da utilização de algoritmos de extração
de conteúdo e pré-processamento no desempenho de classificação de páginas HTML;
v) Criação de um framework centrado na arquitetura; vi) Utilização de componentes
seguindo o modelo COSMOS*; vii) Criação de estudos de caso para avaliar as possíveis
vantagens de criar um software centrado na arquitetura e seguindo o modelo COSMOS*.
A adoção do desenvolvimento centrado na arquitetura possibilita um melhor controle
da complexidade do desenvolvimento e proporciona um consequente ganho na curva
de aprendizado. O uso de componentes de software, em especial o modelo COSMOS*,
proporciona uma melhor rastreabilidade entre arquitetura de software e código, o que
facilita a identificação de falhas e a identificação dos eventuais pontos de evolução do
software, o que representa uma potencial redução nos custos de manutenção.
Do ponto de vista funcional, o framework proposto se diferencia dos trabalhos relacionados pela presença de uma etapa de pré-processamento, que aumenta a qualidade
do resultado final através da limpeza dos dados antes da extração da informação propriamente dita e disponibiliza serviços de extração de conteúdo, recomendação de tag e
classificação.
7.1
Trabalhos Futuros
Como trabalhos futuros são sugeridas as seguintes extensões e melhoramentos:
85
7.2. PALAVRAS FINAIS
1. Utilização de um dataset maior para avaliar os algoritmos de extração de conteúdo,
recomendação de tags, classificação, assim como o sistema como um todo;
2. Calcular métricas como tempo de execução de cada algoritmos e custo computacional para ajudar os usuários a escolher adequadamente os algoritmos que melhor
atende os requisitos da aplicação dele;
3. Criação de novos estudos de caso em outros domínios como e-commerce e egovernment;
4. Criar uma aplicação voltada para o usuário final, utilizando uma interface simples
de ser usada;
5. Criar uma avaliação mais detalhada com relação a outras ferramentas da literatura;
6. Aplicação do sistema no projeto BlogSpread. Projeto em parceria com universidades da Alemanha que visa determinar a disseminação do meme na blogosfera;
7. Aplicação do sistema com funcionalidades em francês no sistema AGATHE. Este
sistema busca extrair informações de domínios específicos da Web. O RetriBlog
entraria para melhorar a parte de recuperação de informação do sistema.
7.2
Palavras Finais
Os blogs possuem informações que se bem utilizadas podem colaborar com várias
áreas como e-learning, e-commerce e e-government. Por esta razão, neste trabalho
foi desenvolvido o RetriBlog, um framework para criação de blog crawlers que possui
serviços para ajudar a extrair de forma automática informações úteis dos blogs. Depois de
realizar vários experimentos, os resultados preliminares mostram que o sistema proposto
está pronto para ser usado de forma massiva e que pode ser bastante relevante para o
presente e o futuro de aplicações na blogosfera.
7.3
Publicações relacionadas ao RetriBlog
A lista abaixo mostra uma série de publicações que foram realizadas com o resultado
desse trabalho.
1. Arcabouço para criação de Blog Crawlers Baseados em Contexto (Ferreira et al.,
2010a).
86
7.3. PUBLICAÇÕES RELACIONADAS AO RETRIBLOG
2. A Framework for Developing Context-Based Blog Crawlers (Ferreira et al., 2010b).
3. Improving the Dynamic Interaction in Virtual Learning Environments Through an
Ontology-based Recommender System (Melo et al., 2011).
4. An Agent-Based Semantic Web Blog Crawler (Ferreira et al., 2011a).
5. An Architecture-Based Framework for Developing Blog Crawlers (Ferreira et al.,
2012a).
6. RetriBlog: A Framework for Creating Blog Crawlers (Ferreira et al., 2012b).
7. Tag-Based and Post-Based Services for Tag Recommendation (Ferreira et al.,
2011d).
8. Improving News Web Page Classification Through Content Extraction (Ferreira
et al., 2011c).
9. Creating a Blog Recommendation System Through a Framework for Building Blog
Crawlers (Ferreira et al., 2011b).
10. A Framework for Building Web Mining Applications in the World of Blogs: A
Case Study in Product Sentiment Analysis (Costa et al., 2012).
87
Referências Bibliográficas
Abney, S. (1991). Principle-Based Parsing: Computation and Psycholinguistics. Kluwer
Academic Publishers, Norwell, MA, USA.
Agarwal, N., Kumar, S., Liu, H., and Woodward, M. (2009). Blogtrackers: A tool for
sociologists to track and analyze blogosphere. In ICWSM.
Aldrich, J., Chambers, C., and Notkin, D. (2002). Archjava: connecting software
architecture to implementation. In Proceedings of the 24th International Conference
on Software Engineering, ICSE ’02, pages 187–197, New York, NY, USA. ACM.
Ana Elisa Lobo, P. B. and Rubira, C. M. F. (2007). A systematic approach for architectural
design of component-based product lines. Technical report, Instituto da Computação Universidade Estadual de Campinas.
Arasu, A., Cho, J., Garcia-Molia, H., Paepcke, A., and Raghavan, S. (2001). Searching
the web. Acm Transactions On Internet Technology, 1(1), 2–43.
Aris Kosmopoulos, G. P. and Androutsopoulos, I. (2008). Adaptive spam filtering using
only naive bayes text classifiers. 5th Conference on Email and Anti-Spam (CEAS
2008).
Baeza-Yates, R. and Ribeiro-Neto, B. (1999). Modern Information Retrieval. Addison
Wesley, 1st edition.
Bansal, N. and Koudas, N. (2007). Searching the blogosphere.
Bass, L., Clements, P., and Kazman, R. (2003). Software Architecture in Practices.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
Bellifemine, F. L., Caire, G., and Greenwood, D. (2007). Developing Multi-Agent Systems
with JADE. Wiley.
Bittencourt, I. I., de Barros Costa, E., Silva, M., and Soares, E. (2009). A computational
model for developing semantic web-based educational systems. Knowl.-Based Syst.,
22(4), 302–315.
Blood, R. (2004). How blogging software reshapes the online community. Commun.
ACM, 47(12), 53–55.
88
REFERÊNCIAS BIBLIOGRÁFICAS
Brin, S. and Page, L. (1998). The anatomy of a large-scale hypertextual web search
engine. Computer Networks and ISDN Systems, 30(1–7), 107–117.
Chau, M., Xu, J., Cao, J., Lam, P., and Shiu, B. (2009). A blog mining framework. IT
Professional, 11, 36–41.
Chen, F., Wang, Q., Mei, H., and Yang, F. (2002). An architecture-based approach for
component-oriented development. 26th Annual International Computer Software and
Applications Conference.
Chessman, J. and Daniels, J. (2000). UML Components. Addison-Wesley.
Clements, P. and Northrop, L. (2001). Software product lines: practices and patterns.
0201703327.
Costa, E., Ferreira, R., Brito, P., Bittencourt, I., Machado, A., and Holanda, O. (2012). A
framework for building web mining applications in the world of blogs: A case study in
product sentiment analysis. Expert Systems with Applications, 1.
Czarnecki, K., Helsen, S., and Eisenecker, U. (2005). Staged configuration through
specialization and multilevel configuration of feature models. Software Process:
Improvement and Practice, 10(2), 143–169.
Fayad, M. E., Schmidt, D. C., and Johnson, R. E. (1999). Building application frameworks: object-oriented foundations of framework design. John Wiley & Sons, Inc.,
New York, NY, USA.
Fellbaum, C., editor (1998). WordNet: an electronic lexical database. MIT Press.
Ferreira, R., Bittencourt, I., Costa, E., and Pacca, H. (2010a). Arcabouço para criação
de blog crawlers baseados em contexto. in: Simpósio brasileiro de informática na
educação. In Simpósio Brasileiro de Informática em Educação.
Ferreira, R., Lima, R. J., Bittencourt, I. I., Filho, D. M., Holanda, O., Costa, E., Freitas,
F., and Melo, L. (2010b). A framework for developing context-based blog crawlers.
Proceedings of the IADIS International Conference on WWW/Internet, pages 120–126.
Ferreira, R., Holanda, O., Melo, J., Bittencourt, I., Freitas, F., and Costa, E. B. (2011a).
An agent-based semantic web blog crawler. In International Conference on Information
Technology and Application.
89
REFERÊNCIAS BIBLIOGRÁFICAS
Ferreira, R., Melo, J., Brito, P., Costa, E., Lima, R., and Freitas, F. (2011b). Creating
a blog recommendation system through a framework for building blog crawlers. In
Simpósio Brasileiro de Sistemas Colaborativos.
Ferreira, R., Lima, R., Filho, D., Tomaz, H., and Freitas, F. (2011c). Improving news
web page classification through content extraction. In Proceedings of the IADIS
International Conference WWW/INTERNET.
Ferreira, R., Lima, R., Melo, D., and Freitas, F. (2011d). Tag-based and post-based
services for tag recommendation. In Proceedings of the IADIS International Conference
WWW/INTERNET.
Ferreira, R., Melo, J., Lima, R., Brito, P., Costa, E., and Freitas, F. (2012a). An
architecture-based framework for developing blog crawlers. In Symposium On Applied
Computing.
Ferreira, R., Melo, J., Lima, R., Brito, P., Costa, E., and Freitas, F. (2012b). Retriblog: A
framework for creating blog crawlers. In Symposium On Applied Computing.
Fujimura, K., Toda, H., Inoue, T., Hiroshima, N., Kataoka, R., and Sugizaki, M. (2006).
Blogranger - a multi-faceted blog search engine. In In Proc. 3rd Annual WWE.
Gaizauskas, R. and Wilks, Y. (1998). Information extraction: Beyond document retrieval.
Journal of Documentation, 54(1), 70–105.
Garlan, D. and Shaw, M. (1994). An introduction to software architecture. Technical
report, Pittsburgh, PA, USA.
Gayard, L. A., Rubira, C. M. F., and de Castro Guerra, P. A. (2008). COSMOS*: a
COmponent System MOdel for Software Architectures. Technical Report IC-08-04,
Institute of Computing, University of Campinas.
Geisser, S. (1993). Predictive Inference. Chapman & Hall.
Geun Chol Moon, Go Kikuta, T. Y. A. Y. T. T. (2010). Blog information considered
useful for book sales prediction. 7th International Conference on Service Systems and
Service Management (ICSSSM), 1, 1 – 5.
Golder, S. A. and Huberman, B. A. (2006). Usage patterns of collaborative tagging
systems. J. Inf. Sci., 32, 198–208.
90
REFERÊNCIAS BIBLIOGRÁFICAS
Gottron, T. (2007). Evaluating content extraction on html documents. ITA, pages 123 –
132.
Hart, M., Johnson, R., and Stent, A. (2009). itag: a personalized blog tagger. In
Proceedings of the third ACM conference on Recommender systems, RecSys ’09, pages
297–300, New York, NY, USA. ACM.
Hassan-montero, Y. and solana A, V. H. (2006). Improving tag-clouds as visual information retrieval interfaces. In Merída, InSciT2006 conference.
Hatcher, E. and Gospodnetic, O. (2004). Lucene in Action (In Action series). Manning
Publications.
Hiep Phuc Luong, S. G. and Wang, Q. (2009). Ontology-based focused crawling. In
EKNOW’09, pages 123–128.
Hong Qu, Andrea La Pietra, S. P. (2006). Automated blog classification: Challenges
and pitfalls. In AAAI Spring Symposium on Computational Approaches to Analysing
Weblogs.
Hotho, A., Nürnberger, A., and Paaß, G. (2005). A brief survey of text mining. LDV
Forum - GLDV Journal for Computational Linguistics and Language Technology,
20(1), 19–62.
Islam, M. J., Wu, Q. M. J., Ahmadi, M., and Sid-Ahmed, M. A. (2007). Investigating the
performance of naive- bayes classifiers and k- nearest neighbor classifiers. In Proceedings of the 2007 International Conference on Convergence Information Technology,
ICCIT ’07, pages 1541–1546, Washington, DC, USA. IEEE Computer Society.
Johnson, R. E. (1997). Components, frameworks, patterns. COMMUNICATIONS OF
THE ACM, 40, 10–17.
Johnson, R. E. and Foote, B. (1988). Designing reusable classes. Journal of ObjectOriented Programming, 1(2), 22–35.
Joshi, M. (2006). Blogharvest: Blog mining and search framework. In In: Proc. of the
International Conf. on Management of Data COMAD.
Kim, H., Lee, K., Shin, H., and Kim, H.-J. (2009). Tag suggestion method based on
association pattern and bigram approach. Software Engineering, Artificial Intelligence,
91
REFERÊNCIAS BIBLIOGRÁFICAS
Networking, and Parallel/Distributed Computing, ACIS International Conference on,
0, 63–68.
Klein, M. H., Kazman, R., Bass, L. J., Carrière, S. J., Barbacci, M., and Lipson, H. F.
(1999). Attribute-based architecture styles. In WICSA1: Proceedings of the TC2
First Working IFIP Conference on Software Architecture (WICSA1), pages 225–244,
Deventer, The Netherlands, The Netherlands. Kluwer, B.V.
Kleinberg, J. M. (1999). Authoritative sources in a hyperlinked environment. Journal of
the ACM, 46, 668–677.
Kohlschütter, C., Fankhauser, P., and Nejdl, W. (2010). Boilerplate detection using
shallow text features. In Proceedings of the third ACM international conference on
Web search and data mining, WSDM ’10, pages 441–450, New York, NY, USA. ACM.
Koskimies, K. (2001). Towards architecture-oriented programming environments. First
ASERC Workshop on Software Architecture.
Lee, K. and Kang, K. C. (2004). Feature dependency analysis for product line component
design. pages 69–85.
Lemur (2009). The lemur toolkit. http://www.lemurproject.org/. Accessed on December
2011.
Li Baoli, Y. S. and Qin, L. (2002). A comparative study on automatic categorization
methods for chinese search engine. Proceedings of the Eighth Joint International
Computer Conference, pages 117–120.
Li Baoli, Y. S. and Qin, L. (2003). An improved k-nearest neighbor algorithm for
text categorization. Proceedings of the 20th international conference on computer
processing of oriental languages.
Lucene (2001). Lucene. http://lucene.apache.org/java/docs/. Accessed on December
2011.
Magee, J. and Kramer, J. (1996). Dynamic structure in software architectures. In Proceedings of the 4th ACM SIGSOFT symposium on Foundations of software engineering,
SIGSOFT ’96, pages 3–14, New York, NY, USA. ACM.
Manning, C. D., Raghavan, P., and Schütze, H. (2008). Introduction to Information
Retrieval. Cambridge University Press, 1 edition.
92
REFERÊNCIAS BIBLIOGRÁFICAS
Markiewicz, M. E. and Lucena, C. J. (2001). Object oriented framework development.
http://www.acm.org/crossroads/xrds7-4/frameworks.html. Último acesso em Dezembro de 2011.
Markines, B., Cattuto, C., Menczer, F., Benz, D., Hotho, A., and Gerd, S. (2009). Evaluating similarity measures for emergent semantics of social tagging. In Proceedings
of the 18th international conference on World wide web, WWW ’09, pages 641–650,
New York, NY, USA. ACM.
McCallum, A. K. (1996). Bow: A toolkit for statistical language modeling, text retrieval,
classification and clustering. http://www.cs.cmu.edu/ mccallum/bow.
McDirmid, S., Flatt, M., and Hsieh, W. C. (2001). Jiazzi: new-age components for
old-fasioned java. In Proceedings of the 16th ACM SIGPLAN conference on Objectoriented programming, systems, languages, and applications, OOPSLA ’01, pages
211–222, New York, NY, USA. ACM.
Melo, J., Ferreira, R., Pontes, J., Costa, E., Brito, P., and Machado, A. (2011). Improving
the dynamic interaction in virtual learning environments through an ontology-based
recommender system. In Fourth Brazilian Workshop on Semantic Web and Education.
Miller, F. P., Vandome, A. F., and McBrewster, J. (2009). Levenshtein Distance: Information theory, Computer science, String (computer science), String metric, Damerau?
Levenshtein distance, Spell checker, Hamming distance. Alpha Press.
Miller, G. A. (1995). Wordnet: A lexical database for english. Communications of the
ACM, 38, 39–41.
Mishne, G. (2006). Autotag: a collaborative approach to automated tag assignment for
weblog posts. In Proceedings of the 15th international conference on World Wide Web,
WWW ’06, pages 953–954, New York, NY, USA. ACM.
Mitchell, T. (1997). Machine Learning (Mcgraw-Hill International Edit). McGraw-Hill
Education (ISE Editions), 1st edition.
Monroe, R. T., Kompanek, A., Melton, R., and Garlan, D. (1997). Architectural styles,
design patterns, and objects. IEEE Softw., 14(1), 43–52.
O’Reilly,
T.
(2005).
and
business
models
What
for
the
is
web
2.0.
design
next
generation
of
patterns
software.
93
REFERÊNCIAS BIBLIOGRÁFICAS
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.
Stand 12.5.2011.
Pant, G., Srinivasan, P., and Menczer, F. (2004). Crawling the web. In M. Levene and
A. Poulovassilis, editors, Web Dynamics. Springer.
Pinto, D., Branstein, M., Coleman, R., Croft, W. B., King, M., Li, W., and Wei, X. (2002).
Quasm: a system for question answering using semi-structured data. In Proceedings of
the 2nd ACM/IEEE-CS joint conference on Digital libraries, JCDL ’02, pages 46–55,
New York, NY, USA. ACM.
Qiao, S., Chu, X., and Wang, S. (2009). Study on application strategies of blog in
information-based teaching. Artificial Intelligence, International Joint Conference on,
0, 526–528.
Rosenbloom, A. (2004). The blogosphere - introduction. Commun. ACM, 47(12), 30–33.
Rosenblum, D. S. and Natarajan, R. (2000). Supporting architectural concerns in
component-interoperability standards. IEEE Proceedings of Software Special Issue on
ComponentBased Software Engineering, 147(6), 215–223.
Roy, S., Joshi, S., and Krishnapuram, R. (2004). Automatic categorization of web sites
based on source types. In Proceedings of the fifteenth ACM conference on Hypertext
and hypermedia, HYPERTEXT ’04, pages 38–39, New York, NY, USA. ACM.
Salton, G. and Buckley, C. (1988). Term-weighting approaches in automatic text retrieval.
Information Processing and Management, 24, 513–523.
Sauvé, J. P. (2000).
Projeto de software orientado a objeto.
http://www.dsc.ufcg.edu.br/ jacques/cursos/map/html/frame/oque.htm.
Último
acesso em Dezembro de 2011.
Sebastiani, F. and Delle Ricerche, C. N. (2002). Machine learning in automated text
categorization. ACM Computing Surveys, 34, 1–47.
Shaw, M. and Garlan, D. (1996). Software Architecture: Perspectives on an Emerging
Discipline. Prentice-Hall, Inc., Upper Saddle River, NJ, USA.
Shkapenyuk, V. and Suel, T. (2002). Design and implementation of a high-performance
distributed web crawler. pages 357–368.
94
REFERÊNCIAS BIBLIOGRÁFICAS
Sigurbjörnsson, B. and van Zwol, R. (2008). Flickr tag recommendation based on
collective knowledge. In Proceeding of the 17th international conference on World
Wide Web, WWW ’08, pages 327–336, New York, NY, USA. ACM.
Sommerville, I. (2001). Software Engineering. Addison-Wesley, 6th edition.
Sommerville, I. (2004). Software Engineering (7th Edition) (International Computer
Science Series). Addison Wesley.
Sood, S., Hammond, K., Owsley, S., and Birnbaum, L. (2007). TagAssist: Automatic Tag
Suggestion for Blog Posts. In Proceedings of the International Conference on Weblogs
and Social Media (ICWSM 2007).
Subramanya, S. B. and Liu, H. (2008). Socialtagger - collaborative tagging for blogs in
the long tail. In Proceeding of the 2008 ACM workshop on Search in social media,
SSM ’08, pages 19–26, New York, NY, USA. ACM.
Szyperski, C. (1998). Component Software: Beyond Object-Oriented Programming.
Addison-Wesley.
Tan, S. (2006). An effective refinement strategy for knn text classifier. Expert Syst. Appl.,
30, 290–298.
Tanenbaum, A. S. (2007). Modern Operating Systems. Prentice Hall Press, Upper Saddle
River, NJ, USA.
Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead, Jr., E. J., and Robbins,
J. E. (1995). A component- and message-based architectural style for gui software. In
Proceedings of the 17th international conference on Software engineering, ICSE ’95,
pages 295–304, New York, NY, USA. ACM.
Technorati
(2008).
State
of
the
blogosphere
http://technorati.com/blogging/feature/state-of-the-blogosphere-2008/.
acesso em Dezembro de 2011.
2008.
Último
Technorati
(2009).
State
of
the
blogosphere
http://technorati.com/blogging/feature/state-of-the-blogosphere-2009/.
acesso em Dezembro de 2011.
2009.
Último
Tenenbaum, A. (1995). Estruturas de Dados Usando C. MAKRON BOOKS.
95
REFERÊNCIAS BIBLIOGRÁFICAS
van Ommering, R., van der Linden, F., Kramer, J., and Magee, J. (2000). The koala
component model for consumer electronics software. Computer, 33, 78–85.
Weninger, T. and Hsu, W. H. (2008). Text extraction from the web via text-to-tag ratio.
In Proceedings of the 2008 19th International Conference on Database and Expert
Systems Application, pages 23–28, Washington, DC, USA. IEEE Computer Society.
Whitehead, E. J., Jason, J., Robbins, E., Medvidovic, N., and Taylor, R. N. (1995).
Software architecture: Foundation of a software component marketplace. In Proceedings of the First International Workshop on Architectures for Software Systems, pages
276–282.
Xiong, H. and Wang, X. (2008). The information filtering under the web 2.0 environment.
In Proceedings of the 2008 International Conference on Information Management,
Innovation Management and Industrial Engineering - Volume 01, pages 141–146,
Washington, DC, USA. IEEE Computer Society.
Yang, X. (2008). Improving teachers’ knowledge management with blog platform.
In Proceedings of the 2008 International Workshop on Education Technology and
Training & 2008 International Workshop on Geoscience and Remote Sensing - Volume
01, pages 73–76, Washington, DC, USA. IEEE Computer Society.
Yang, Y. and Liu, X. (1999). A re-examination of text categorization methods. In
Proceedings of the 22nd annual international ACM SIGIR conference on Research and
development in information retrieval, SIGIR ’99, pages 42–49, New York, NY, USA.
ACM.
Ying Ding, Ioan Toma, S. J. K. M. F. and Yan, Z. (2008). Data mediation and interoperation in social web: Modeling, crawling and integrating social tagging data. Workshop
on Social Web Search and Mining.
You-Sheng, Z. and Yu-Yun, H. (2003). Architecture-based software process model.
Software Engineering Notes, 28(2).
96
Catalogação na fonte
Bibliotecário Vimário Carvalho da Silva, CBR 4-1204
Mello, Rafael Ferreira Leite de.
RetriBlog: um framework centrado na arquitetura para criação de
blog crawlers./ Rafael Ferreira Leite de Mello. – Recife: O Autor, 2012.
Cvii, 107 f.: fig. tab.
Orientador: Frederico Luiz Gonçalves de Freitas.
Dissertação (Mestrado) – Universidade Federal de Pernambuco, CIN,
Ciência da Computação, 2012.
Inclui bibliografia.
1. Recuperação da informação. 2. Blog Crawlers. 3. Framework. I.
Freitas, Frederico Luiz Gonçalves de (orientador). II. Título.
025.04 (22. ed.)
MEI 2012-006