Content uploaded by Vinicius Cardoso Garcia
Author content
All content in this area was uploaded by Vinicius Cardoso Garcia
Content may be subject to copyright.
Especificação, Projeto e Implementação de uma Arquitetura
para um Engenho de Busca de Componentes
Vinicius Cardoso Garcia1∗1, Frederico Araujo Durão1,
Gibeon Soares de Aquino Júnior1, Marcely Daniela Silva dos Santos1,
Eduardo Santana de Almeida1, Daniel Lucrédio3,
Jones Oliveira de Albuquerque2, Silvio Romero de Lemos Meira1
1Centro de Informática – Universidade Federal de Pernambuco
C.E.S.A.R. – Centro de Estudos e Sistemas Avançados do Recife
{vcg,esa2,srlm}@cin.ufpe.br
{frederico.durao,gibeon.aquino,marcely.santos}@cesar.org.br
2Dept. de Estatística e Informática, Universidade Federal Rural de Pernambuco
joa@ufrpe.br
3Instituto de Ciências Matemáticas e da Computação – Universidade de São Paulo
lucredio@icmc.usp.br
Resumo. Este artigo apresenta a especificação, o projeto e a implementação
de uma arquitetura para um engenho de busca de componentes de software
desenvolvido como um plug-in para a ferramenta Eclipse. O engenho permite
o reuso dos componentes por meio de uma busca em repositórios de código
fonte de projetos. A busca dos componentes é realizada por meio de técnicas de
text mining, utilizando o mecanismo do Lucene. A arquitetura é capaz de fazer
buscas em servidores CVS, carregar os componentes selecionados, indexá-los
localmente e mostrá-los no workbench do Eclipse através do plug-in.
1. Introdução
No processo de desenvolvimento de software, o reuso caracteriza-se pela utilização de
produtos de software em uma situação diferente daquela para qual estes produtos foram
originalmente construídos. Esta idéia, que não é nova [10], apresenta benefícios cruciais
para as organizações, tais como, redução de custos e tempo de entrega das aplicações e
aumento da qualidade.
Dentre os fatores que favorecem o sucesso com programas de reuso, encontram-se
os repositórios de componentes [2, 14]. Entretanto, a simples aquisição de um repositório
de componentes não leva aos benefícios esperados, uma vez que outros fatores também
devem ser combinados, como, por exemplo, gerenciamento, planejamento, processos de
reuso, entre outros [11, 13].
Os atuais gerenciadores e repositórios de componentes [1] são, na sua maioria,
produtos que permitem apenas o reuso de componentes black-box [17], ou seja, compo-
nentes empacotados onde não se tem acesso ao código fonte, o que dificulta tarefas como
∗Financiado pela Fundação de Amparo à Pesquisa do Estado da Bahia (FAPESB) - Brasil
adaptação ou evolução. Além disso, a adoção deste tipo de repositório em organizações,
muitas vezes, ocorre de forma intrusiva, uma vez que os componentes, para serem disponi-
bilizados para o reuso, devem ser documentados e empacotados utilizando determinados
critérios. Adicionalmente, esses repositórios representam soluções isoladas, não sendo
associadas a ferramentas de desenvolvimento comumente utilizadas, como, por exemplo,
o Eclipse R
, o que aumenta a barreira para sua adoção e utilização.
Assim, um modo inicial para estimular a cultura de reuso nas empresas e obter
os seus benefícios iniciais [3], no que diz respeito a ferramentas, deve concentrar-se em
oferecer subsídios para a reutilização de componentes white-box - com código fonte dis-
ponível - e código fonte já existentes, seja na própria organização, em projetos anteriores,
ou em repositórios disponíveis na Internet1.
Neste contexto, este artigo apresenta a especificação, o projeto e a implementação
de uma arquitetura para um engenho de busca de componentes, que objetiva auxiliar no
reuso durante o desenvolvimento de software. O artigo está organizado como se segue: A
Seção 2 apresenta a especificação da arquitetura proposta e discute seus requisitos iniciais.
A Seção 3 discute o projeto da arquitetura e seus elementos. Na Seção 4 é apresentada
a implementação da arquitetura. Trabalhos relacionados são discutidos na Seção 5, e,
finalmente, a Seção 6 apresenta algumas considerações finais e trabalhos futuros.
2. Especificação da Arquitetura para um Engenho de Busca de Componentes
As pesquisas atuais em busca e recuperação de componentes têm se concentrado em as-
pectos e requisitos chaves para os mercados de componentes, que buscam promover o
reuso em larga escala [9].
Lucrédio et al. [9] apresentam um conjunto de requisitos para um eficiente enge-
nho de busca e recuperação de componentes de software, dentre os quais pode-se destacar,
de forma reduzida:
a. Elevada precisão e recuperação. Elevada precisão significa que a maioria
dos componentes recuperados são relevantes. Elevada recuperação significa que poucos
elementos relevantes são identificados, sem ser recuperados.
b. Segurança. Em um mercado de componentes global, a segurança deve ser
considerada uma característica primordial, já que existe a possibilidade de que pessoas
não autorizadas possam acessar o repositório.
c. Formulação de consultas. Há uma natural perda de informação quando os
usuários formulam consultas. Segundo [5], existe uma lacuna conceitual entre o problema
e a solução, já que componentes são descritos em termos da sua funcionalidade (“como”)
e as consultas em termos da solução (“o quê”). Assim, um engenho de busca deve prover
meios de auxiliar o usuário na formulação das consultas, buscando reduzir esta lacuna.
d. Descrição do componente. O engenho de busca é responsável por identificar
os componentes relevantes para o usuário de acordo com a consulta formulada e executada
em cima das descrições dos componentes.
e. Familiaridade no repositório. O reuso ocorre mais freqüentemente através
de componentes bem conhecidos [18]. Entretanto, um engenho de busca deve auxiliar o
1OSourceForge, até 08 de Julho de 2005, disponibilizava 102.740 projetos.
usuário a explorar e recuperar componentes familiares ao que era o alvo inicial, facilitando
futuras buscas e estimulando a concorrência entre os fornecedores de componentes.
f. Interoperabilidade. Em um cenário envolvendo repositórios distribuídos, é
inevitável não pensar em interoperabilidade. Deste modo, um engenho de busca que
funciona neste cenário deve ser baseado em tecnologias que facilitem sua futura expansão
e integração com outros sistemas e repositórios.
g. Desempenho. Desempenho é usualmente medida em termos de tempo de res-
posta. Sistemas centralizados envolvem variáveis relacionadas ao poder de processamento
e algoritmos de busca. Já em sistemas distribuídos outras variáveis devem ser conside-
radas, como, por exemplo, controle de tráfego da rede, distância geográfica e, claro, o
número de componentes disponíveis.
Entretanto, esses requisitos são referentes a um mercado de componentes utili-
zando componentes black-box. Para um engenho de busca, que recupera também compo-
nentes white-box e código fonte reutilizável, diferentes requisitos são necessários.
A seguir são apresentadas as características e os requisitos macro para o engenho
de busca Maracatu. O conjunto de requisitos não é definitivo, entretanto, nós acreditamos
que eles constituem uma base sólida para trabalhos futuros.
2.1. Características e Requisitos Técnicos
O Maracatu permitirá o reuso de componentes por meio de uma busca em repositórios
de código fonte de projetos. A busca será feita através de palavras-chave e utilizará o
engenho de busca Lucene [4]. O Lucene é responsável pela indexação dos componentes
bem como o ranqueamento do resultado da busca. A arquitetura deverá ser capaz de
fazer buscas em servidores CVS (Web ou em uma Intranet), carregar os componentes
selecionados, indexá-los, ranqueá-los e exibir o resultado no workbench do Eclipse.
Dois processos básicos são suportados pelo Maracatu: i) localização, check-out
e indexação dos componentes; e ii) busca e recuperação de componentes. O primeiro
processo é uma tarefa realizada automaticamente, em background, enquanto o desenvol-
vedor é responsável pelo segundo. Para a execução destes dois processos básicos foram
identificados inicialmente alguns requisitos macros, conforme se segue:
i. Repositórios CVS na Web ou na Intranet. O Maracatu deverá acessar inicial-
mente repositórios CVS. Após o check-out do componente, deverá ser feita uma análise
qualitativa do código com o objetivo de eliminar os componentes que tenham baixo po-
tencial de reuso. Especificamente, nesta versão, foi implementada apenas uma estratégia
que avalia a densidade de documentação Javadoc no código (70% no mínimo).
ii. Selecionar Repositórios. O desenvolvedor deverá incluir manualmente a lista
dos repositórios para a busca dos componentes. Será possível a qualquer momento reali-
zar uma busca nos repositórios cadastrados para encontrar novas versões dos componentes
consumidos, ou novos componentes;
iii. Armazenar Componentes Localmente. O Maracatu deverá fazer o check-
out dos componentes localizados e candidatos ao reuso e armazená-los localmente em um
cache (centralização do repositório de componentes para reuso);
iv. Atualizar Repositórios. Periodicamente, os repositórios cadastrados devem
ser acessados para verificar a existência de novos componentes e/ou a atualização de com-
ponentes já existentes. Neste caso, estes dois tipos de componentes (novos e atualizados)
devem ser baixados para o cache. Sempre que novos check-out forem feitos, deve ser
refeito o índice dos componentes;
v. Indexar os Componentes. Só devem ser consumidos os componentes que
ainda não foram indexados e que forem aprovados no processo de verificação da potenci-
alidade de reuso (item i);
vi. Buscar por Palavra-Chave. A busca será realizada por meio do uso de
palavras-chave. A busca deve aceitar como entrada uma string e irá interpretar opera-
dores lógicos como “E” e“OU”;
vii. Exibir resultado da busca. O resultado da busca será exibido no workbench
do Eclipse. A partir deste resultado, será possível acessar um determinado componente
recuperado pela consulta, e inserí-lo em um projeto do Eclipse.
De acordo com os conjuntos de requisitos apresentados anteriormente, tanto para
um mercado de componentes quanto para um engenho de busca, foi projetado o engenho
de busca Maracatu como um plug-in do Eclipse.
3. Projeto da Arquitetura do Engenho de Busca de Componentes
A arquitetura do Maracatu foi pro-
Figura 1. Arquitetura do Maracatu
jetada para ser extensível a diferentes tec-
nologias de componentes, provendo a ca-
pacidade de adição de novas característi-
cas na indexação, ranqueamento, busca e
recuperação dos componentes. Esta pos-
sibilidade é obtida através do particiona-
mento do sistema em elementos meno-
res, com responsabilidades bem definidas,
baixo acoplamento e encapsulamento de
detalhes de implementação.
Durante a estratégia de projeto da
arquitetura foram integrados à arquitetura
do Maracatu alguns componentes já exis-
tentes: o Lucene foi adotado como me-
canismo de busca e a API Javacvs [12]
foi utilizada para acesso aos repositórios
CVS. Além disso, foi adotada a API JavaNCSS [7] para a análise do código fonte, atu-
ando como um filtro.
De um modo geral, a arquitetura do Maracatu contém dois sub-sistemas princi-
pais: i) Eclipse Plug-in eii) Maracatu Service, conforme mostra a Figura 1.
A arquitetura do Maracatu está baseada no modelo cliente-servidor e utiliza a tec-
nologia de Web Services [16] para troca de mensagens entre os sub-sistemas. Esta estra-
tégia de implementação permite que o serviço (Maracatu Service) possa estar disponível
em qualquer lugar na Internet, ou até mesmo em Intranets corporativas, em situações onde
os componentes são proprietários.
O modelo de comunicação do Maracatu ocorre da seguinte forma:
1. Inicialmente, o plug-in Eclipse (cliente Web Service), após localizar o serviço
remoto definido por um documento WSDL (Web Service Definition Language) invoca os
serviços através de RPC (Remote Procedure Call).
2. Em seguida, o Maracatu Service (Web Service) recebe a chamada, processa
a informação e envia a resposta (resultado da busca ou o arquivo para o desenvolvedor
realizar o download).
3. Oplug-in e o Maracatu Service comunicam-se usando o protocolo SOAP (Sim-
ple Object Access Protocol) sobre HTTP. O protocolo SOAP é um dos padrões para a
troca de mensagens entre aplicações e Web Services.
Para uma melhor compreensão, os sub-sistemas do Maracatu são apresentados a
seguir.
3.1. Eclipse Plug-in
Este sub-sistema é a interface visual com o desenvolvedor e é responsável por repassar
as consultas para o sub-sistema Maracatu Service. Ele funciona totalmente integrado ao
ambiente de desenvolvimento do desenvolvedor (nesta versão, apenas o Eclipse). O plug-
in se comporta como um cliente Web Service que consome os serviços disponíveis pelo
Maracatu Service. Para garantir o acesso ao serviço, ele foi projetado utilizando o padrão
de projeto ServiceLocator2, com a finalidade de localizar o serviço remoto (definido pelo
documento WSDL) e disponibilizá-lo para o plug-in.
3.2. Maracatu Service
Este sub-sistema é responsável pela execução dos serviços requisitados pelo plug-in. Ele
foi dividido em sub-módulos, onde cada um deles têm papel fundamental no funciona-
mento geral do sub-sistema Maracatu Service. Os sub-módulos são detalhados a seguir:
i. CVS. Este sub-módulo é responsável por recuperar o código fonte dos repo-
sitórios CVS cadastrados pelo Administrador do Maracatu Service. Além disso, ele fica
periodicamente, monitorando os repositórios com o objetivo de recuperar as atualizações.
ii. Analyser. Este sub-módulo é responsável por realizar uma análise no código e
avaliar se ele é adequado para ser reutilizado. Apenas os códigos aprovados nesta etapa do
processo estão disponíveis para a próxima etapa de indexação. Para otimizar o processo,
este sub-módulo só é disparado quando o módulo CVS realizar alguma atualização.
iii. Indexer. Este sub-módulo é responsável por indexar os arquivos Java que
passaram pela análise do módulo Analyser. Ele é otimizado para consumir apenas os
arquivos que ainda não foram indexados. Além disso, ele está preparado para rever os
índices criados quando os artefatos forem modificados ou acrescentados.
iv. Download. Este sub-módulo auxilia o processo de download (check-out) do
código fonte para a máquina do desenvolvedor, quando solicitado pelo mesmo.
v. Search. Este sub-módulo recebe os parâmetros da consulta solicitada pelo
desenvolvedor, interpreta (por exemplo, operadores “E” e“OU”), busca no índice, e
retorna um conjunto de entradas do índice.
2http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html
4. Implementação da Arquitetura do Engenho de Busca de Componentes
Um exemplo de busca pode ser visto na Figura 2, que mostra o plug-in Maracatu3sendo
utilizado no ambiente de desenvolvimento do Eclipse (1).
Figura 2. Maracatu em execução no ambiente do Eclipse
A Figura mostra a janela do plug-in (2), onde é possível ao desenvolvedor digitar
uma string para a busca por componentes. No exemplo, foi realizada a busca a partir
da string “Search” & “Retrieve”, e retornou como resultado os seguintes componen-
tes: AssigmentCommand,DBConnection,Assembler entre outros. A partir do resultado
da busca, é possível identificar de qual projeto (repositório) esse componente faz parte(
representado em “Module”), bem como a opção de download do componente. Em se-
guida, o desenvolvedor pode importar o componente para o seu projeto no Eclipse (3).
No exemplo da figura, o desenvolvedor escolheu o componente AssigmentCommand.
Oplug-in Maracatu foi implementado em 32 classes, divididas em 17 pacotes e
com 955 linhas de código não comentadas.
5. Trabalhos Relacionados
OAgora [15] é um protótipo desenvolvido pelo SEI/CMU4. O objetivo do Agora é criar
um banco de dados (repositório), gerado automaticamente, indexado e disponível na in-
ternet, de produtos de software classificados por tipos de componentes (por exemplo,
Javabeans ou controles ActiveX). O Agora combina técnicas de introspecção com meca-
nismos de busca da Web para reduzir os custos de recuperar e localizar os componentes
de software em um mercado de componentes.
OKoders [8] foi o primeiro motor de busca Open Source desenvolvido. Ele se
conecta diretamente nos sistemas de controle de versão (como CVS eSubversion) para
identificar o código fonte, podendo reconhecer cerca de 30 linguagens de programação
3O protótipo na versão 1.0 pode ser obtido no site do projeto http://done.dev.java.net
4Software Engineering Institute at Carnegie Mellon University
e 20 licenças de software. O Koders é um projeto mantido pela Microsoft Architecture
Resource Center5. O Koders só pode ser utilizado na Web, via o seu site, já o Maractu
pode atuar em uma Intranet, o que é ideal para empresas que não querem tornar públicos
seus repositórios. Entretanto, ao contrário do Koders, o Maracatu conecta-se somente a
repositórios CVS.
Em [6], Holmes e Murphy apresentam o Strathcona, um plug-in para o Eclipse que
localiza exemplos de códigos que auxiliam desenvolvedores no processo de codificação.
Os exemplos são extraídos de repositórios através de pesquisa baseada em seis diferentes
heurísticas. A escolha das classes é baseada na similaridade da estrutura do código que
o desenvolvedor está escrevendo. Após a localização no repositório, o plug-in relaciona
cada classe extraída com o código já desenvolvido, caso exista, e estrutura um modelo de
aplicação das classes retornadas (pela busca). O Strathcona, diferente do Maracatu, não
é um cliente web service, o que implica diretamente na questão da escalabilidade. Além
disso, o Maracatu pode acessar diferentes repositórios distribuídos remotamente enquanto
que o Strathcona apenas repositórios locais, com isso, caso o tamanho dos repositórios
cresça, o desenvolvedor pode ter problemas de performance durante as buscas.
Outro importante trabalho de pesquisa foi apresentado em [18], no qual Ye e Fis-
cher propõem um novo mecanismo para localizar componentes. Este mecanismo localiza
e apresenta para o desenvolvedor, de forma autônoma, informações sobre componentes
que sejam relevantes para as atividades que estão sendo realizadas no momento, e perso-
nalizados de acordo com o conhecimento e ambiente do desenvolvedor. Tal mecanismo
foi projetado, implementado e avaliado em um sistema que recebeu o nome de CodeBro-
ker. Avaliações empíricas mostraram que este tipo de estratégia é realmente efetiva em
promover o reuso. Do ponto de vista funcional, pode-se afirmar que o Maracatu e o Co-
deBroker são complementares. O CodeBroker realiza uma interação mais rebuscada com
o usuário, de modo ativo, enquanto o Maracatu é passivo, pois somente responde à soli-
citações do usuário. Por outro lado, o back-end do Maracatu (parte do servidor) tem um
comportamento mais complexo, localizando e coletando informações sobre componentes
na rede de uma forma autônoma e sem intervenção direta do usuário.
6. Conclusões e trabalhos futuros
Desde 1968 [10], quando Mcllroy propôs a idéia inicial de uma indústria de componen-
tes de software, o tema vem sendo alvo de constantes pesquisas. Deste período, até os
dias atuais [9], a área de busca e recuperação de componentes vem evoluindo, com meca-
nismos que, inicialmente, permitiam apenas a reutilização de rotinas matemáticas, até os
mecanismos e repositórios de componentes mais robustos, que permitem a seleção e re-
cuperação de componentes black-box em um contexto interno ou em um mercado global.
Neste artigo foi apresentada a especificação, o projeto e a implementação de um
engenho de busca que permite, não apenas a recuperação de componentes black-box,
como também, componentes white-box e de trechos de código. Nós acreditamos que esta
abordagem é o ponto inicial para empresas obterem os benefícios com a reutilização, no
que diz respeito a ferramentas, uma vez que a mesma apresenta-se de forma não intrusiva,
tanto no que diz respeito a novos métodos para documentar e empacotar componentes,
como também, na familiarização do desenvolvedor com o seu ambiente de trabalho.
5http://www.microsoft.com/architecture
Como trabalhos futuros, encontra-se em desenvolvimento um modulo extrator,
que permitirá que os componentes existentes em organizações ou em repositórios distri-
buídos, possam ser recuperados e armazenados em facetas definidas pelo administrador.
Com a utilização de facetas, as buscas poderão ser otimizadas, uma vez que parte dos
componentes podem ser descartados de acordo com o critério do desenvolvedor. Esta
versão ainda é parte de uma grande agenda de pesquisa e desenvolvimento, que inclui
outras funcionalidades, como, por exemplo, a incorporação de conteúdo semântico no
mecanismo de busca, melhorias nos algoritmos de ranqueamento do engenho de busca,
além da definição de métricas. Além disso, um projeto piloto está sendo preparado para
analisar a viabilidade de utilização da ferramenta no ambiente industrial.
Referências
[1] V. A. A. Burégio. Especificação e Implementação de uma Arquitetura de Repositório de Componentes.
Dissertação de mestrado, Universidade Federal Pernambuco, Recife, 2005.
[2] W. B. Frakes and S. Isoda. Success Factors of Systematic Software Reuse. IEEE Software, 11(01):14–19,
1994.
[3] M. Griss. Making Software Reuse Work at Hewlett-Packard. IEEE Software, 12(01):105–107, 1995.
[4] E. Hatcher and O. Gospodnetic. Lucene in Action (In Action series). Manning Publications, 2004.
[5] S. Henninger. Using Iterative Refinement to Find Reusable Software. IEEE Software, 11(5):48–59, 1994.
[6] R. Holmes and G. C. Murphy. Using structural context to recommend source code examples. In Proceedings
of the 27th ICSE, pages 117–125, New York, NY, USA, 2005. ACM Press.
[7] JavaNCSS. A Source Measurement Suite for Java, URL: http://www.kclee.de/clemens/java/javancss/, 2005.
[8] Koders. Koders - Source Code Search Engine, URL: http://www.koders.com, 2005.
[9] D. Lucrédio, E. S. d. Almeida, and A. F. d. Prado. A Survey on Software Components Search and Retrieval.
In R. Steinmetz and A. Mauthe, editors, 30th IEEE EUROMICRO Conference, Component-Based
Software Engineering Track, pages 152–159, Rennes - France, 2004. IEEE/CS Press.
[10] M. D. McIlroy. Software Engineering: Report on a conference sponsored by the NATO Science Committee.
In NATO Software Engineering Conference, pages 138–155. NATO Scientific Affairs Division, 1968.
[11] M. Morisio, M. Ezran, and C. Tully. Success and Failure Factors in Software Reuse. IEEE Transactions on
Software Engineering, 28(04):340–357, 2002.
[12] NetBeans. Javacvs, URL: http://javacvs.netbeans.org, 2005.
[13] T. Ravichandran and M. A. Rothenberger. Software Reuse Strategies and Component Markets. Communi-
cations of the ACM, 46(8):109–114, 2003.
[14] D. Rine. Success factors for software reuse that are applicable across Domains and businesses. In ACM
Symposium on Applied Computing, pages 182–186, San Jose, California, USA, 1997. ACM Press.
[15] R. C. Seacord, S. A. Hissam, and K. C. Wallnau. Agora: A Search Engine for Software Components.
Technical report, CMU/SEI - Carnegie Mellon University/Software Engineering Institute, 1998.
[16] M. Stal. Web services: beyond component-based computing. Commun. ACM, 45(10):71–76, 2002.
[17] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison Wesley, 2002.
[18] Y. Ye and G. Fischer. Supporting Reuse By Delivering Task-Relevant and Personalized Information. In
Proceedings of the 24th ICSE, pages 513–523, Orlando, Florida, USA, 2002.
