Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes Vinicius Cardoso Garcia 1 1, Frederico Araujo Durão 1, Gibeon Soares de Aquino Júnior 1, Marcely Daniela Silva dos Santos 1, Eduardo Santana de Almeida 1, Daniel Lucrédio 3, Jones Oliveira de Albuquerque 2, Silvio Romero de Lemos Meira 1 1 Centro 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 2 Dept. de Estatística e Informática, Universidade Federal Rural de Pernambuco joa@ufrpe.br 3 Instituto 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, componentes 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 disponibilizados 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 disponível - e código fonte já existentes, seja na própria organização, em projetos anteriores, ou em repositórios disponíveis na Internet 1. 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 aspectos 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 engenho 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 1 O SourceForge, 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 resposta. Sistemas centralizados envolvem variáveis relacionadas ao poder de processamento e algoritmos de busca. Já em sistemas distribuídos outras variáveis devem ser consideradas, 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 utilizando componentes black-box. Para um engenho de busca, que recupera também componentes 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 desenvolvedor é 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 inicialmente 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 potencial 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 realizar 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 checkout 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 componentes 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 potencialidade 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 operadores 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 projetada para ser extensível a diferentes tecnologias de componentes, provendo a capacidade de adição de novas características na indexação, ranqueamento, busca e recuperação dos componentes. Esta possibilidade é obtida através do particionamento do sistema em elementos menores, 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á existentes: o Lucene foi adotado como mecanismo de busca e a API Javacvs [12] foi utilizada para acesso aos repositórios Figura 1. Arquitetura do Maracatu CVS. Além disso, foi adotada a API JavaNCSS [7] para a análise do código fonte, atuando como um filtro. De um modo geral, a arquitetura do Maracatu contém dois sub-sistemas principais: i) Eclipse Plug-in e ii) Maracatu Service, conforme mostra a Figura 1. A arquitetura do Maracatu está baseada no modelo cliente-servidor e utiliza a tecnologia de Web Services [16] para troca de mensagens entre os sub-sistemas. Esta estraté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. O plug-in e o Maracatu Service comunicam-se usando o protocolo SOAP (Simple Object Access Protocol) sobre HTTP. O protocolo SOAP é um dos padrões para a troca de mensagens entre aplicações e Web Services. seguir. Para uma melhor compreensão, os sub-sistemas do Maracatu são apresentados a 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 plugin 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 ServiceLocator 2, 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 funcionamento 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 repositó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. 2 http://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 Maracatu 3 sendo 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 componentes: 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 seguida, o desenvolvedor pode importar o componente para o seu projeto no Eclipse (3). No exemplo da figura, o desenvolvedor escolheu o componente AssigmentCommand. O plug-in Maracatu foi implementado em 32 classes, divididas em 17 pacotes e com 955 linhas de código não comentadas. 5. Trabalhos Relacionados O Agora [15] é um protótipo desenvolvido pelo SEI/CMU 4. O objetivo do Agora é criar um banco de dados (repositório), gerado automaticamente, indexado e disponível na internet, de produtos de software classificados por tipos de componentes (por exemplo, Javabeans ou controles ActiveX). O Agora combina técnicas de introspecção com mecanismos de busca da Web para reduzir os custos de recuperar e localizar os componentes de software em um mercado de componentes. O Koders [8] foi o primeiro motor de busca Open Source desenvolvido. Ele se conecta diretamente nos sistemas de controle de versão (como CVS e Subversion) para identificar o código fonte, podendo reconhecer cerca de 30 linguagens de programação 3 O protótipo na versão 1.0 pode ser obtido no site do projeto http://done.dev.java.net 4 Software Engineering Institute at Carnegie Mellon University
e 20 licenças de software. O Koders é um projeto mantido pela Microsoft Architecture Resource Center 5. 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 Fischer 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 personalizados de acordo com o conhecimento e ambiente do desenvolvedor. Tal mecanismo foi projetado, implementado e avaliado em um sistema que recebeu o nome de CodeBroker. 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 CodeBroker 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 à solicitaçõ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 componentes 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 mecanismos 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 recuperaçã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. 5 http://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 distribuí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. Communications 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.