reuse repository-specification design implementation

Ps-Graduao em Cincia da Computao

SPECIFICATION, DESIGN AND IMPLEMENTATION OF A REUSE REPOSITORYPor

Vanilson Andr de Arruda BurgioDissertao de Mestrado

Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao

RECIFE, SETEMBRO/2006

UNIVERSIDADEFEDERALDEPERNAMBUCO CENTRODEINFORMTICA PSGRADUAOEMCINCIADACOMPUTAO

VANILSONANDRDEARRUDABURGIO

Specification,DesignandImplementationofaReuseRepository" ESTE TRABALHO FOI APRESENTADO PS-GRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO.

ORIENTADOR(A): Silvio Romero de Lemos Meira

RECIFE, SETEMBRO/2006

Burgio, Vanilson Andr de Arruda Specification, design and implementation of a reuse repository / Vanilson Andr de Arruda Burgio. - Recife : O Autor, 2006. ix, 131 p. : il., fig., tab. Dissertao (mestrado) Universidade Federal de Pernambuco. CIn. Cincia da Computao, 2006. Inclui bibliografia e apndices. 1. Engenharia de software. 2. Reuso de software. 3. Componentes de software. I. Ttulo. 005.1 CDD (22.ed.) MEI2008-068

A

gradecimentos

Primeiramente, quero aqui registrar meus agradecimentos a Deus, que tanto me deu fora e coragem durante todo esse percurso e me concedeu a oportunidade de realizar este trabalho. Sem Ele nada disso seria possvel. Em seguida, agradeo ao meu orientador Silvio Romero de Lemos Meira, pela orientao, pelo incentivo e, principalmente, por me proporcionar a oportunidade de desenvolver um trabalho de mestrado que pudesse ser aplicado em um projeto real de desenvolvimento de software. Ao grande pesquisador e amigo Eduardo Almeida, por sempre ter acreditado no sucesso deste trabalho e ter me dado total apoio nos momentos de extrema dificuldade; pelas crticas, sugestes, revises e por todo incentivo e disponibilidade em sempre querer ajudar. Obrigado a todos os membros do grupo RiSE, pelas discusses, sugestes e crticas fornecidas, especialmente a Alexandre Martins, Eduardo Cruz, Liana Lisboa e Daniel Lucrdio pela prontido prestada nos momentos difceis do trabalho. Ao Centro de Estudos e Sistemas Avanados do Recife CESAR, pelo apoio tcnico, pessoal e financeiro. Em especial aos membros do projeto GComp, principalmente, a Juliana Dantas que sempre me incentivou a alcanar essa conquista to almejada. Gostaria de agradecer tambm a colaborao de Luiz Eugnio e os demais participantes envolvidos no processo de avaliao de arquitetura.

ii

Agradeo SEFAZ, na pessoa de Nevton Borba, por ter me prestado total apoio em momentos de difcil conciliao entre o trabalho e a vida acadmica. Obrigado aos meus pais e a toda minha famlia pelo grande incentivo prestado no decorrer de todas as atividades envolvidas na confeco deste trabalho. Em especial, dedico este trabalho a minha av Creuza que, onde quer que esteja, tenho certeza de que continua torcendo e vibrando pelas minhas conquistas.

iii

R

esumo

A disciplina de Reuso de Software tem crescido em importncia, tornando-se uma ferramenta estratgica para empresas que almejam um aumento de produtividade, a obteno de baixos custos e a alta qualidade dos seus produtos. Porm, antes de obtermos as vantagens inerentes ao reuso, preciso termos mecanismos hbeis a fim de facilitar o armazenamento, a busca, a recuperao e o gerenciamento dos artefatos reusveis. Nesse contexto, encaixa-se a idia de repositrios de reuso. Um repositrio de reuso pode ser entendido como uma base preparada para o armazenamento e a recuperao de componentes. O mesmo pode ser visto tambm, como um grande facilitador, que atua como suporte aos engenheiros de software e outros usurios no processo de desenvolvimento de software para e com reuso. Na literatura, existem diversos trabalhos que exploram repositrios de reuso, porm, o foco desses trabalhos est, quase sempre, voltado a questes de busca e recuperao de componentes e, muitas vezes, aspectos importantes de repositrios de reuso no so explorados adequadamente, como, por exemplo, o uso destes como ferramenta para auxiliar gerentes no monitoramento e controle do reuso em uma organizao. Por outro lado, algumas questes levantadas por empresas que desejam construir um repositrio de reuso continuam mal respondidas. Tais questes geralmente incluem: Que papis um repositrio deve desempenhar no contexto de reutilizao? Quais so os principais requisitos de um repositrio de reuso? Quais as alternativas prticas existentes? Como um repositrio de reuso pode ser projetado? Motivado por essas questes, esta dissertao apresenta a especificao, o projeto e a implementao de um repositrio de reuso baseado na anlise das solues existentes e em uma experincia prtica de construo de um ambiente de reuso para fbricas de software. Adicionalmente, so discutidos os resultados obtidos, os problemas encontrados, e as direes futuras para pesquisa e o desenvolvimento. Palavras-chave: Repositrio de Reuso, Componentes de Software, Reuso de Software

iv

A

bstract

The software reuse subject has increased in importance, becoming a strategic tool for enterprises that aspire to a productivity boost, low costs and high quality of their products. Nevertheless, before obtaining the advantages relevant to reuse, it is necessary that we have useful mechanisms in a way to make storage, search, recovery and managing of reusable artifacts easier. In this context is where the idea of reuse repositories perfectly fits. A reuse repository can be understood as a prepared base for the storage and recovery of components. It can also be seen as a big facilitator which acts as a support to software engineers as well as other users in software development process for and with reuse. In the literature, several works that explore reuse repositories are available. However, the focus of these works is quite often related to matters of search and recovery of components and, time and again, important aspects of reuse repositories are not explored properly, for instance, their use to aid managers in the monitoring and reuse control in an organization. On the other hand, some questions brought up by companies that aim at building a reuse repository remain unanswered. Such questions usually include: which roles should a repository play in a reutilization context? What are the main requisites of a reuse repository? What are the existing practical alternatives? How can a reuse repository be designed? Fostered by these questions, this dissertation presents the specification, the project and implementation of a reuse repository based on the analysis of existing solutions as well as on a building practical experience of a reuse environment for software factories. In addition, the obtained results, setbacks found as well as future directions for research and development will be presented. Keywords: Reuse Repository, Software Components, Software Reuse

v

Cs

ontedo

Agradecimentos ....................................................................................................................ii Resumo .................................................................................................................................iv Abstract ................................................................................................................................. v Contedo ..............................................................................................................................vi Lista de Figuras .................................................................................................................viii Lista de Tabelas ...................................................................................................................ix 1 Introduo .......................................................................................................................... 1 1.1 Motivao ..................................................................................................................... 1 1.2 Estabelecimento do problema ...................................................................................... 4 1.3 Viso geral da soluo proposta .................................................................................. 5 1.4 Escopo negativo............................................................................................................ 7 1.5 Principais Contribuies.............................................................................................. 9 1.6 Organizao da dissertao....................................................................................... 10 2 Repositrios de Reuso ..................................................................................................... 11 2.1 Papis de um Repositrio ........................................................................................... 12 2.1.1 Repositrio como um veculo de comunicao entre os stakeholders ................ 14 2.1.2 Repositrio como assistente no gerenciamento................................................... 14 2.1.3 Repositrio como um promotor de reuso ............................................................ 16 2.1.4 Repositrio como um assegurador de qualidade ................................................. 16 2.2 Trabalhos na Academia.............................................................................................. 17 2.2.1 Consideraes...................................................................................................... 21 2.3 Solues Prticas ....................................................................................................... 22 2.3.1 Repositrios de Uso Geral................................................................................... 23 2.3.2 Repositrios especficos de reuso........................................................................ 27 2.3.3 Consideraes das solues existentes ................................................................ 31 2.4 Resumo do captulo .................................................................................................... 35 3 Repositrio de Reuso: Especificao, Projeto e Implementao................................. 36 3.1 Requisitos ................................................................................................................... 36 3.1.1 O armazenamento de ativos em repositrios....................................................... 37 3.1.2 Funcionalidades do Repositrio .......................................................................... 39 vi

3.1.3 Perfis de usurios................................................................................................. 45 3.1.4 Resumo dos requisitos......................................................................................... 46 3.2 Arquitetura do repositrio.......................................................................................... 46 3.2.1 Viso geral........................................................................................................... 47 3.2.2 Mdulo de Infra-estrutura.................................................................................... 50 3.2.3 Mdulo de Produo............................................................................................ 53 3.2.4 Modulo de Consumo ........................................................................................... 57 3.2.5 Mdulo de Gerenciamento .................................................................................. 60 3.2.6 Resumo da arquitetura ......................................................................................... 62 3.3 Experincia de implementao................................................................................... 62 3.3.1 Processo de desenvolvimento.............................................................................. 63 3.3.2 Tecnologias e frameworks................................................................................... 65 3.3.3 Resultados do projeto .......................................................................................... 70 3.4 Resumo do captulo .................................................................................................... 73 4 Anlise do Repositrio .................................................................................................... 74 4.1 Exemplos de Utilizao .............................................................................................. 74 4.1.1 Cenrio 1: publicar nova verso de um ativo ...................................................... 75 4.1.2 Cenrio 2: recuperar ativo ................................................................................... 77 4.1.3 Cenrio 3: certificar verso de um ativo.............................................................. 81 4.2 Avaliao de Arquitetura ........................................................................................... 85 4.2.1 Mtodos de avaliao .......................................................................................... 87 4.2.2 Escolha do Mtodo a ser utilizado....................................................................... 89 4.2.3 Processo de avaliao .......................................................................................... 92 4.2.4 Resultados da avaliao de arquitetura................................................................ 97 4.3 Decises Tcnicas ...................................................................................................... 98 4.4 Resumo do captulo .................................................................................................. 102 5 Concluses e Trabalhos Futuros .................................................................................. 103 5.1 Principais concluses ............................................................................................... 103 5.2 Trabalhos Relacionados........................................................................................... 104 5.3 Trabalhos Futuros .................................................................................................... 106 5.4 Concluso ................................................................................................................. 107 6 Apndice A -Modelo de ativo........................................................................................ 108 7 Apndice B- Exemplos de Relatrios ........................................................................... 109 8 Apndice C - Processo de Certificao ........................................................................ 115 Referncias ........................................................................................................................ 124

vii

L

ista de Figuras

Figura 1.1 - Ilhas de informao......................................................................................... 2 Figura 1.2 Framework do projeto RiSE......................................................................... 5 Figura 1.3 Arquitetura da soluo proposta ................................................................. 7 Figura 2.1 Processo de produo-gerncia-consumo................................................ 13 Figura 2.2 - Taxonomia das Solues ............................................................................. 30 Figura 3.1 Modelo de ativo simplificado ..................................................................... 39 Figura 3.2 Viso geral da arquitetura.......................................................................... 48 Figura 3.3 Mdulo de Infra-estrutura ......................................................................... 51 Figura 3.4 Mdulo de Produo................................................................................... 54 Figura 3.5 Mdulo de Consumo ................................................................................... 57 Figura 3.6 Mdulo de Gerenciamento......................................................................... 60 Figura 3.7 Processo de desenvolvimento adotado..................................................... 64 Figura 3.8 Esforo de desenvolvimento...................................................................... 71 Figura 3.9 - Tela inicial do repositrio ........................................................................... 72 Figura 3.10 Tela do prottipo de plug-in para Eclipse ............................................. 73 Figura 4.1- Fluxo navegacional : Criao de verso ...................................................... 75 Figura 4.2 - Tela de manuteno de ativos .................................................................... 76 Figura 4.3 Tela de criao de verso............................................................................ 77 Figura 4.4 - Busca e recuperao: Fluxo navegacional ................................................ 78 Figura 4.5 - Exemplo de filtro de busca.......................................................................... 79 Figura 4.6 - Tela de resultado de busca .......................................................................... 80 Figura 4.7 Tela de visualizao de detalhes de um ativo .......................................... 81 Figura 4.8 Certificao: Mquina de estados ............................................................. 82 Figura 4.9 - Fluxo navegacional: certificar ativo........................................................... 83 Figura 4.10 - Sees da tela de detalhes da certificao de um ativo ......................... 84 Figura 4.11 Tela de anexao de relatrio de certificao ........................................ 84 Figura 4.12 - Mtodo genrico de avaliao de arquitetura......................................... 88 Figura 4.13 - Processo de avaliao de arquitetura....................................................... 92 Figura 4.14 Estrutura de ativo adotada..................................................................... 100 Figura A.1 Modelo de classes do repositrio ............................................................ 108

viii

L

ista de Tabelas

Tabela 2.1 - Comparao de gerenciadores de componentes comerciais .................. 29 Tabela 2.2 Requisitos para comparar as solues de repositrio reuso............................. 33 Tabela 2.3 Anlise das solues de repositrio.......................................................... 34 Tabela 3.1 - Perfis bsicos do repositrio ....................................................................... 46 Tabela 4.1 - Comparao dos mtodos de avaliao ..................................................... 91 Tabela 4.4.2 Resultado da priorizao dos atributos de qualidade ........................ 93 Tabela C.8.1 Caractersticas e tcnicas utilizadas no processo de certificao.... 116

ix

11

Introduo

1.1 MotivaoExiste um consenso que empresas de software esto sempre buscando produzir produtos com um menor custo e tempo e com uma maior qualidade. Neste sentido, o reuso de software tem crescido em importncia e se tornado uma abordagem indispensvel em busca desses objetivos. A idia bsica de reuso construir software atravs da utilizao de artefatos ou conhecimento j existentes, ao invs de iniciar o desenvolvimento do zero, sem nenhum reaproveitamento [Krueger, 1992]. Algumas experincias prticas na indstria [Basili, 1991] [Bauer, 1993] [Griss, 1994] [Joos, 1994] [Griss, 1995] tm comprovado que o reuso de software aumenta a produtividade e ajuda a obter baixos custos e alta qualidade durante o ciclo de desenvolvimento de software como um todo. Porm, reuso no uma tarefa de desenvolvimento simples e o sucesso de um programa de reuso, muitas vezes, depende da aplicao efetiva de aspectos tcnicos e no tcnicos. Os aspectos no-tcnicos incluem questes como: educao, treinamento, incentivos e gerenciamento organizacional. Por outro lado, os aspectos tcnicos compreendem a utilizao de mtodos, processos, ferramentas e ambientes que forneam suporte ao desenvolvimento e posterior reuso de software. Geralmente, a falta de conhecimento sobre a disponibilidade de artefatos de software que podem ser reutilizados, aliada ao custo de se encontrar tais artefatos so as principais causas para que desenvolvedores no tentem reusar software [Frakes & Fox, 1995]. Como mostra a Figura 1.1, o desenvolvedor enfrenta o

1

Captulo 1 Introduo

2

problema de localizar, entender e integrar software reutilizvel em um novo software a ser criado, pois, o conhecimento disponvel normalmente desestruturado e est espalhado nas diversas ilhas de informao. Na prtica, em uma empresa, estas ilhas podem representar departamentos, equipes de projetos e outras unidades organizacionais que geram software e/ou conhecimento no compartilhado. Por esta razo, o problema de localizar software reutilizvel um aspecto fundamental para um programa de reuso efetivo [Almeida et al., 2004][Mascena, 2006][Vanderlei, 2006].

Figura 1.1 - Ilhas de informao Desta forma, antes dos desenvolvedores obterem as vantagens inerentes ao reuso, eles devem possuir mecanismos hbeis a fim de facilitar o armazenamento, a busca, a recuperao e a distribuio dos artefatos reutilizveis. neste contexto que se encaixa a idia de sistemas de repositrio. Um sistema de repositrio pode ser entendido como um sistema de informao que auxilia os programadores na localizao dos artefatos reusveis [Ye, 2002].

2

Captulo 1 Introduo

3

Guo & Luqi [Guo & Luqi, 2000] se referem a sistemas de repositrios (bibliotecas de reuso) como sendo organizaes de pessoas, procedimentos, ferramentas e componentes direcionados a facilitar que o reuso de componentes de software alcance objetivos especficos de produtividade e custo-benefcio. De acordo com Poulin [Poulin, 1995], Bibliotecas de Software Reutilizveis formam, quase sempre, o centro de uma estratgia de reuso organizacional. De fato, Frakes [Frakes, 1994] afirma que biblioteca de software um fator crtico para se implementar um programa de reuso sistemtico e ele complementa sua afirmao dizendo: Uma vez que uma organizao adquire ativos reutilizveis, ela tem que possuir uma maneira de armazen-los, busc-los e recuper-los uma biblioteca de reuso. (p. 19) Isso refora a idia de que repositrios representam um recurso precioso para os desenvolvedores, alm de formarem a infra-estrutura bsica de suporte ao processo de reutilizao de software [Mili et al., 1997]. Contudo, apesar de sua importncia, o uso de repositrios para suportar um processo de reuso tem muitas vezes falhado na prtica [Frakes, 1995] [Morisio, 2002]. Uma das razes para estas falhas que, quase sempre, um repositrio construdo apenas sob a perspectiva de desenvolvedores. Ou seja, os repositrios so tidos como simples mecanismos de busca e recuperao de componentes e importantes aspectos, como, por exemplo, o uso destes como ferramenta para auxiliar gerentes no monitoramento e controle do reuso em uma organizao no so tratados. Alm disso, segundo Wohlin [Wohlin, 1998], para que os componentes possam ser recuperados de uma infra-estrutura, como um repositrio, eles devem possuir um certo grau de qualidade, definindo eficientemente o nvel de confiabilidade que pode ser esperado destes componentes, antes que eles sejam reusados no desenvolvimento de uma aplicao. Assim, extremamente importante assegurar a qualidade dos componentes que esto sendo armazenados no repositrio atravs do suporte a um processo de certificao de componentes adequado [lvaro, 2006]. No obstante, esse aspecto raramente tratado nas solues existentes, conforme ser visto no prximo Captulo.

3

Captulo 1 Introduo

4

De fato, na literatura, existem diversos trabalhos que exploram a utilizao de repositrios no contexto de reuso de software, porm, o foco desses trabalhos est, quase sempre, voltado a questes de busca e recuperao de componentes e, na maioria das vezes, os aspectos organizacionais e de qualidade no so explorados adequadamente. Por outro lado, durante a ltima dcada, vrias organizaes comerciais e industriais tm desenvolvido diversas solues que permitem o acesso a componentes de software e os seus recursos relacionados [Pan et al., 2004]. Na prtica, as solues adotadas por empresas variam desde o uso de ferramentas especficas de reuso (projetadas com o objetivo principal de promover o reuso de software) a ferramentas de uso geral que, muitas vezes, correspondem a ferramentas tradicionais de desenvolvimento de software adaptadas para servirem como repositrios de componentes. Desta forma, algumas questes levantadas por empresas que desejam construir ou adotar um repositrio para apoiar suas atividades de reuso continuam mal respondidas. Tais questes, geralmente incluem: Que papis um repositrio deve desempenhar no contexto de reutilizao? Quais so os principais requisitos de um repositrio de reuso? Quais as alternativas prticas existentes? Como um repositrio de reuso pode ser projetado e implementado?

1.2 Estabelecimento do problemaMotivado pelas questes apresentadas na Seo anterior, o principal objetivo deste trabalho , em linhas gerais: Especificar, projetar e implementar um repositrio de reuso

corporativo que possa auxiliar tanto desenvolvedores na produo e consumo de ativos de software reutilizveis, bem como prover meios para monitorar as atividades de reuso e permitir a garantia de qualidade dos ativos disponibilizados.

4

Captulo 1 Introduo

5

1.3 Viso geral da soluo propostaCom o objetivo de alcanar o objetivo deste trabalho, estabelecido na Seo anterior, foi realizado um estudo das solues de repositrio de reuso existentes tanto na academia, quanto na indstria. Este estudo teve como finalidade identificar o tipo de soluo mais adequada para desempenhar os papis do repositrio proposto. A partir desse estudo foram definidos os requisitos e, em seguida, a arquitetura da soluo, que passou por um processo formal de avaliao de arquitetura [Clements et al., 2002a]. Depois de especificado e projetado, o repositrio proposto foi implementado dentro de um projeto de desenvolvimento real que gerou um produto comercial. As prximas Sees descrevem o contexto deste trabalho e apresenta uma viso geral da arquitetura da soluo. Contexto Este trabalho parte de uma grande iniciativa de reuso promovida pelo grupo de pesquisa Reuse in Software Engineering (RiSE1) [Almeida et al., 2004]. A Figura 1.2 mostra o framework global do projeto RiSE.

Figura 1.2 Framework do projeto RiSE O projeto RiSE engloba diversos aspectos de reuso no includos no escopo deste trabalho, tais como, processo de reuso [Almeida et al., 2005b], certificao de componentes [Alvaro et al., 2005b] e ambientes de reuso de software [Garcia et al.,1

http://www.rise.com.br

5

Captulo 1 Introduo

6

2006b]. Outras ferramentas e ambientes propostos pelo grupo incluem, entre outras, o engenho de busca Maracatu [Garcia et al., 2006], a ferramenta de anlise de domnio ToolDay [Lisboa, 2006], o ambiente de reuso integrado baseado em mtricas ADMIRE [Mascena, 2006] e o engenho de busca de artefatos com suporte a folksonomia [Vanderlei, 2006]. Estes esforos so coordenados e faro parte de uma soluo completa de reuso a ser aplicada em contextos corporativos. No caso particular deste trabalho, uma implementao baseada na soluo proposta por esta dissertao foi desenvolvida em conjunto com o Centro de Estudos e Sistemas Avanados do Recife (C.E.S.A.R.) e teve o apoio (financiamento) do governo, representado pela FINEP, a qual publicou (no DOC de 31/08/2004) uma seleo pblica de propostas para apoio cooperao tecnolgica entre o setor produtivo e instituies cientficas e tecnolgicas (CHAMADA PBLICA MCT/FINEP/Ao Transversal-Cooperao ICTsEmpresas-02/2004 - Referncia FINEP n. 2176/04). O desenvolvimento do repositrio proposto fez parte da principal meta do projeto industrial submetido FINEP. Tal projeto envolveu tambm, a criao de processos, mtodos e ferramentas para suportar as atividades de reuso de software em empresas. Viso geral da arquitetura A arquitetura do repositrio proposto consiste em um conjunto de mdulos e componentes que trabalham em conjunto para prover as funcionalidades necessrias de um repositrio de reuso efetivo. A Figura 1.3 mostra a arquitetura proposta. Os trs principais mdulos de negcio da arquitetura so: Produo, Gerenciamento e Consumo. Estes mdulos provem as funcionalidades essenciais utilizadas pelos diferentes tipos de usurios do sistema.

6

Captulo 1 Introduo

7

Figura 1.3 Arquitetura da soluo proposta O mdulo de Produo oferece os servios para os desenvolvedores que produzem os ativos reutilizveis. O mdulo de Gerenciamento concentra os servios que apiam a monitorao das atividades de reuso na organizao e a garantia de qualidade dos ativos disponibilizados. Por fim, o mdulo de Consumo auxilia os usurios na busca e recuperao dos ativos, alm de oferecer outros servios teis para os usurios que reusam os ativos do repositrio. O elemento central da arquitetura, que utilizado pelos trs mdulos de negcio, o Metadata Repository, que funciona como uma base de dados compartilhada para armazenar e recuperar os metadados dos ativos disponibilizados. Ele faz parte do mdulo de infra-estrutura (Infrastructure) que, alm dele, formado por um conjunto compartilhado de componentes e servios que podem ser utilizados por todos os outros mdulos do repositrio. Os detalhes da arquitetura sero descritos na Seo 3.2.

1.4 Escopo negativoComo a soluo proposta por esta dissertao faz parte de um contexto mais amplo, um conjunto de aspectos relacionados no ser tratado no escopo deste trabalho.

7

Captulo 1 Introduo

8

Adicionalmente, os requisitos tratados na soluo no formam um conjunto completo e fechado de funcionalidades que devem sempre estar presentes em qualquer repositrio de reuso, pois isso depender das reais necessidades e do contexto de cada empresa onde o mesmo ser utilizado. Contudo, acredita-se que os requisitos identificados podem servir como base para a construo de repositrios que suportem um processo de reuso em organizaes. Os seguintes aspectos no fazem parte do escopo deste trabalho: Processo de reuso: embora seja feita uma breve explicao de onde um repositrio de reuso se encontra dentro do contexto de reutilizao, e os papis que o mesmo deve desempenhar, no sero tratadas, com detalhe, todas as fases de um processo de reuso a ser suportado pelo repositrio proposto; Funcionalidades: algumas das funcionalidades previstas na arquitetura, tais como, um extrator automtico de ativos [Mendes, 2006], no foram implementadas na verso inicial do repositrio. Estas funcionalidades, embora importantes, consistem em ferramentas de suporte para as funcionalidades principais do repositrio e podem ser gradualmente implementadas em verses futuras do repositrio; Atributos de qualidade: as funcionalidades do repositrio (requisitos funcionais) foram os principais aspectos tratados na especificao de requisitos. Embora considerados na implementao e no processo de avaliao de arquitetura, alguns atributos de qualidade, como, por exemplo, distribuio, performance e escalabilidade no foram detalhados; Busca: as questes relacionadas com busca no repositrio so tratadas de uma maneira geral sem detalhes a respeito dos algoritmos de indexao e classificao. Alm disso, aspectos relacionados a implementao de busca ativa no repositrio [Ye, 2001] [Mascena, 2006] tambm no sero tratados; e Modelo de Negcio: Aspectos relacionados ao suporte a modelos de negcio que permitem a negociao de componentes atravs de repositrios no sero tratados neste trabalho.

8

Captulo 1 Introduo

9

1.5 Principais ContribuiesComo resultado do trabalho apresentado nesta dissertao, as seguintes contribuies podem ser destacadas: Definio de um modelo de ativo: baseado na anlise de como componentes de software so empacotados e caracterizados em algumas abordagens e solues existentes, um modelo de ativo foi definido com o objetivo de possuir as informaes adicionais manipuladas pelo repositrio proposto; Papis de um repositrio de reuso: os principais papis que um repositrio deve desempenhar em um contexto de reutilizao de software foram propostos; Taxonomia das solues existentes: atravs da anlise das ferramentas existentes foi criada uma taxonomia que classifica os tipos de solues que podem ser usadas como repositrios de reuso por empresas; Requisitos de um repositrio de reuso: a partir da anlise das solues existentes e dos papis que um repositrio de reuso deve desempenhar, um conjunto de requisitos para um repositrio de reuso efetivo foram especificados; Arquitetura do repositrio: os detalhes de uma arquitetura extensvel de um repositrio de reuso voltado ao gerenciamento de ativos foi definida; Produto comercial: baseado na proposta desta dissertao um produto comercial foi implementado e est atualmente implantado em fbricas de software brasileiras; Avaliao de arquitetura: O desenvolvimento do produto comercial envolveu, de maneira inovadora, a aplicao de um mtodo formal de avaliao de arquitetura, onde pode ser comprovada a utilidade dessa abordagem dentro de um contexto industrial. Alm das contribuies finais listadas acima, alguns resultados intermedirios deste trabalho esto sendo reportados na literatura, como mostrado a seguir:

9

Captulo 1 Introduo

10

Livro do grupo RiSE, C.R.u.i.S.E.: Component Reuse in Software Engineering, Recife, Brasil, (a aparecer) 2006; V. Burgio, E. Santos, E. Almeida, S. Meira, Industrial Experiment in Software Architecture Evaluation, WICSA2007 Working IEEE/IFIP Conference on Software Architecture, Mumbai, India, 2007 (em avaliao).

V. Burgio, E. Almeida, D. Lucredio, S. Meira, Specification, Design and Implementation of An Industrial Reuse Repository, Journal Software Practice and Experience (SPE), 2006 (em preparao).

V. Burgio, E. Almeida, S. Meira, Industrial Experiences with Software Architecture Evaluation: The Case of the Reuse Tools, Journal System and Software (JSS), 2006 (em preparao).

1.6 Organizao da dissertaoO restante desta dissertao est organizado como se segue: Captulo 2: apresenta a reviso bibliogrfica sobre sistemas de repositrios aplicados ao contexto de reuso de software, com o objetivo de identificar as principais solues existentes na academia e na indstria e analisar como as mesmas desempenham os papis desejados de um repositrio de reuso; Captulo 3: descreve em detalhes os requisitos do repositrio proposto, sua arquitetura e as tecnologias e frameworks adotados na sua implementao; Captulo 4: apresenta alguns exemplos de uso da ferramenta desenvolvida, discute o processo de avaliao de arquitetura realizado durante o desenvolvimento da soluo e apresenta algumas decises tcnicas realizadas durante o desenvolvimento; Captulo 5: conclui esta dissertao atravs de um resumo das principais contribuies desta pesquisa e discusses a respeito de alguns trabalhos relacionados. Por fim, so tambm apresentadas algumas observaes finais e direes para pesquisas futuras.

10

22

Repositrios de Reuso

Como visto no Captulo anterior, acredita-se amplamente que reuso de software, um processo de criao de sistemas de software a partir de software existente, um possvel caminho para melhorar a produtividade e a qualidade do desenvolvimento de software. Porm, antes de desenvolver com reuso, os engenheiros de software devem ser capazes de eficiente e convenientemente adquirir os artefatos que desejam [Pan et al., 2004]. Neste contexto, vrios trabalhos na academia e na indstria tm explorado o uso de sistemas de repositrio como um meio de prover acesso aos artefatos disponveis. Os sistemas de repositrio tratados nestes trabalhos recebem variadas denominaes, tais como: repositrio de componentes, bibliotecas de software, gerenciadores de artefatos reutilizveis, entre outros. Neste Captulo ser usado o termo repositrio de reuso, genericamente, como uma denominao s diversas solues que visam a aplicao de sistemas de repositrios no contexto de reutilizao. Deste modo, este captulo apresenta uma viso geral sobre os diferentes tipos de repositrios de reuso e est organizado da seguinte forma: a Seo 2.1 prope os papis que um repositrio de reuso deve desempenhar. A Seo 2.2 discute alguns trabalhos na academia que tratam questes relacionadas a repositrios de reuso. Na Seo 2.3 as solues prticas existentes so classificadas. A Seo 2.4 apresenta uma comparao dessas solues. A Seo 2.5 examina os principais gerenciadores de componentes do mercado, e finalmente, a Seo 2.6 resume a discusso a respeito de repositrios de reuso.

11

Captulo 2 Repositrios de Reuso

12

2.1 Papis de um RepositrioInicialmente, importante entender onde um repositrio aparece no contexto de um processo baseado em reuso e quais so os papis que o mesmo deve desempenhar de acordo com os interesses das pessoas envolvidas em tal processo (stakeholders). Em qualquer processo de desenvolvimento baseado em reuso, podem ser distinguidas, pelo menos, duas atividades: o desenvolvimento para reuso e o desenvolvimento com reuso. Um bom exemplo de uma tcnica baseada em reuso, na qual estas atividades so bem definidas, o Desenvolvimento Baseado em Componentes (DBC). O DBC surgiu como uma nova perspectiva para o desenvolvimento de software, cujo objetivo a construo de software atravs de componentes interoperveis, reduzindo, desta forma, a complexidade do desenvolvimento, assim como os custos, atravs da utilizao de componentes que, em princpio, seriam adequados para serem utilizados em outras aplicaes [Sametinger, 1997]. Ele ser utilizado aqui para ilustrar mais claramente os papis que um repositrio de reuso deve desempenhar. Segundo Apperly [Apperly, 2001], no DBC tem-se o processo de produogerncia-consumo onde as seguintes atividades so identificadas: Produo: focada na produo e disponibilizao (publicao) de componentes, isto , o desenvolvimento para reuso; Gerncia: direcionada basicamente no monitoramento do reuso e no controle de qualidade dos componentes disponibilizados; e Consumo: concetrada na busca, recuperao e uso dos componentes disponveis (desenvolvimento com reuso).

Em geral, as atividades de produo e consumo so executadas por desenvolvedores identificados como produtores de componentes e consumidores

12


13

de componentes, respectivamente; e as atividades de gerenciamento podem ser executadas, por exemplo, por gerentes de projeto e certificadores de componentes. Portanto, neste contexto, h um requisito essencial para construir um repositrio no s como uma base esttica de componentes, mas tambm como uma ferramenta que suporte as atividades de publicao, consumo e gerncia de tais componentes. A Figura 2.1 mostra onde um repositrio de reuso aparece no processo de produo-gerncia-consumo.

Figura 2.1 Processo de produo-gerncia-consumo

13


14

Como apresentado na Figura 2.1, o repositrio deve conter servios que satisfazem os interesses de trs tipos de stakeholders: produtor, gerentes e consumidor. Baseado em tais interesses e com o objetivo de tornar os benefcios do reuso de software produtividade, alta qualidade e baixos custos mais facilmente alcanveis, podem ser definidos alguns papis que um repositrio deve assumir dentro do contexto de reutilizao. Para a definio desses papis foram levados em considerao aspectos prticos em conjunto com o estado da arte na rea. esperado que estes papis possam desempenhar uma funo relevante no suporte ao reuso sistemtico de software. Os papis propostos so:

2.1.1 Repositrio como um veculo de comunicao entre os stakeholdersEste um dos papis essenciais de um repositrio de reuso. Como apresentado na Figura 2.1, repositrios representam um canal de distribuio de artefatos, portanto, devem servir como um veculo de comunicao em duas direes: 1 desenvolvimento para reuso (produo) e 2 - desenvolvimento com reuso (consumo). Este papel estabelece que um repositrio deve ser visto no s como uma base esttica de componentes, mas tambm como um mecanismo central que permita a interao entre os produtores e os consumidores de componentes. Em [Apperly, 2001], feita uma analogia entre repositrio de componentes e o ptio de uma construo civil. Tal analogia refora a idia que um repositrio pode desempenhar um papel chave quando componentes so negociados entre produtores, que esto interessados em publicar e/ou vender seus componentes, e consumidores, que se preocupam em buscar e recuperar componentes para a construo de novas aplicaes.

2.1.2 Repositrio como assistente no gerenciamentoReuso de artefatos de software constituem oportunidades plausveis para impulsionar a produtividade. Porm, junto com estas oportunidades surge a necessidade de monitorar o reuso no nvel organizacional [Banker et al., 1993]. De fato, as atividades de reuso englobam o envolvimento de mltiplos projetos e

14


15

sistemas de aplicaes. Para gerenciar tais atividades, duas tarefas fundamentais devem ser empregadas no nvel organizacional: a coleta de mtricas e o monitoramanto de software. Neste sentido, repositrios podem ser usados por gerentes como um assistente para controlar e gerenciar o reuso de software na organizao. Um repositrio bem projetado pode, por exemplo, ajudar as organizaes a mapearem a utilizao dos seus componentes com o objetivo de alinhar iniciativas, projetos e auxiliar a medio do impacto provocado pelo reuso nos negcios. Alguns exemplos de informaes que podem ser tratadas incluem: quais projetos esto acessando mais o repositrio, quais os que precisam de mais incentivo, que tipos de ativos esto sendo mais procurados, que ativos foram procurados e no encontrados, etc. Motivado por este problema, Banker et al. [Banker et al., 1993] props o uso de ambientes CASE baseados em repositrio como uma soluo para tornar a coleta de mtricas uma ferramenta a ser utilizada na anlise de reuso de software no nvel de repositrio - o que eles denominaram de "avaliao de repositrio". Pretendendo provar a eficincia da avaliao de repositrio, eles apresentaram uma pesquisa que identificou, durante dois anos, os nveis de reuso de duas grandes organizaes que usavam uma ferramenta CASE baseada em repositrio para manter o software produzido por elas e toda informao relevante a respeito do mesmo. Os resultados obtidos, indicaram que o uso de repositrios de software integrados com ambientes CASE podem ajudar significantemente o gerenciamento de reuso no nvel organizacional e, ao mesmo tempo, tornar possvel responder questes como: Que tipos de objetos so mais reusados? Sob que condies o reuso acontece mais facilmente?

Portanto, a partir desses resultados pode-se concluir que repositrios de reuso devem tambm oferecer servios que permitam aos gerentes monitorar o

15


16

reuso de software atravs de mltiplos projetos e, para isso, faz-se necessrio que um conjunto seja disponibilizado pelo repositrio. A anlise de mtricas pode indicar diversos aspectos teis sobre reuso e podem auxiliar gerentes e desenvolvedores a reduzir custos. Em [Kernebeck, 1997], Kernebeck oferece uma introduo bastante til a respeito de gerenciamento de repositrio de componentes e anlise de reusabilidade de componentes de software atravs de mtricas. Kernebeck mostra que a anlise de reusabilidade permite-nos determinar o esforo necessrio de se reutilizar um componente, o que nos ajuda a decidir entre reusar um dado componente e comear uma nova implementao sem o uso do mesmo. Em resumo, possvel monitorar as atividades de reuso atravs de repositrios de componentes com o intuito de reduzir os custos associados a um processo sistemtico de reuso de software.

2.1.3 Repositrio como um promotor de reusoO sucesso de um programa de reuso depende do nvel de conhecimento que uma organizao tem a respeito do processo de reuso adotado. Conseqentemente, extremamente importante disseminar a cultura de reuso por toda organizao [John & Spiros, 1996]. Sendo assim, repositrios podem prover visibilidade aos seus artefatos atravs da demonstrao de valor de um artefato para desenvolvedores e gerentes. Alm disso, eles podem ser usados para disseminar notcias sobre iniciativas de reuso, melhores desenvolvedores de ativos reutilizveis, componentes mais reusados, entre outros.

2.1.4 Repositrio como um assegurador de qualidadeUm problema que surge quando se reutiliza software como ter certeza da qualidade dos artefatos reusados [Kernebeck, 1997]. Neste contexto, repositrios podem facilitar o objetivo corporativo de manter a qualidade do software

16


17

desenvolvido atravs da disponibilizao de artefatos aprovados por um processo de certificao suportado pelo repositrio. A certificao de software, alm de ser possvel e diretamente aplicvel indstria, proporciona benefcios diretos que podem ser observados em termos de retorno de investimento, qualidade, manutenibilidade, entre outros fatores. Adicionalmente, a certificao parte fundamental para o sucesso de reutilizao de software [Alvaro, 2006].

Na literatura, diversos trabalhos que exploram sistemas de repositrio aplicados no contexto de reuso podem ser encontrados. Uma reviso de alguns destes trabalhos feita na prxima seo.

2.2 Trabalhos na AcademiaOrigem Desde 1968, durante a Conferncia de Engenharia de Software da NATO, o reuso de software foi anunciado como uma possvel maneira de superar a crise de software. Em tal conferncia, McIlroy publicou um dos primeiros artigos sobre reuso de software: Mass Produced Software Components" [McIlroy, 1968]. Neste trabalho, McIlroy discutiu sobre catlogos padronizados de rotinas, classificadas por preciso, robustez, desempenho, limites de tamanho e tempo de ligao dos parmetros. Desde ento, de acordo com Lucrdio et al. [Lucrdio et al., 2004], muitas pesquisas, baseadas nas idias de McIlroy, tm explorado os conceitos de biblioteca e repositrio. Mili et al. [Mili et al., 1998] discutem cerca de 50 abordagens para este problema. Dentre estas abordagens, um foco especial dado aos esquemas de classificao que so usados para armazenar os elementos de um repositrio.

17

Captulo 2 Repositrios de Reuso Repositrios com classificao baseada em facetas

18

O trabalho de Prieto-Diaz e Freeman [Prieto-Diaz & Freeman, 1987] deu uma contribuio importante para esta rea. Neste trabalho, foi proposto o esquema baseado em facetas para classificar componentes de software (ex.: linguagem de programao, sistema operacional, domnio de negcio, entre outros). O esquema de facetas foi baseado nas premissas que colees de componentes reutilizveis so muito grandes e esto continuamente crescendo, e que h grandes grupos de componentes similares. Nesta abordagem, um nmero limitado de caractersticas (facetas) que um componente pode ter definido. Segundo Prieto-Diaz e Freeman, facetas podem ser consideradas como perspectivas, pontos de vista, ou ainda dimenses de um domnio particular. Logo, um conjunto de possveis palavraschave associado a cada faceta e, para descrever um componente, uma ou mais palavras-chave so escolhidas para cada faceta. Repositrios evolutivos Outros pesquisadores tm explorado diferentes aspectos de suportar reuso com repositrios. Em [Henninger, 1997], por exemplo, Henninger apresenta uma abordagem que utiliza uma estrutura mnima de repositrio para apoiar o processo de busca por componentes de software. A abordagem demonstrada por um par de prottipos: PEEL, uma ferramenta para identificar componentes reutilizveis de maneira semi-automtica; e CodeFinder, um sistema de recuperao que permite modificar representaes de um componente enquanto os usurios esto procurando informao. Porm, os prottipos apresentados esto limitados a um repositrio que consiste apenas de funes, variveis, macros e constantes LISP usadas no Emacs.

18

Captulo 2 Repositrios de Reuso A Internet como repositrio

19

Protocolos (http, ftp, pop ) e tecnologias (servidores web, de e-mail, ...) abaixo do termo Internet oferecem uma infra-estrutura poderosa, barata e aberta que pode se tornar o backbone de um repositrio de reuso [Ezran el al., 2002]. De acordo com [Seacord et al., 1998], a infra-estrutura da Internet prov os meios necessrios para consumidores localizarem os componentes disponveis e ento promover reuso. Neste sentido, Seacord et al. apresentam o sistema Agora. O Agora combina introspeco com engenhos de busca Web para automaticamente buscar e registrar componentes atravs da Internet, tornando-os disponveis para reuso. Mesmo sendo considerado uma evoluo dos repositrios especficos, adotando os princpios de repositrios de referncias, o sistema Agora apresentou muitas limitaes. Por basear-se num mecanismo de busca utilizando introspeco computacional, o sistema apresentou limitaes tanto semanticamente, quanto na abrangncia, uma vez que so recuperados apenas componentes binrios. Repositrios de busca ativa Recentemente, um novo tipo de repositrio tem sido tratado, os Sistemas de repositrios de reuso com mecanismos de busca ativa. Ao contrrio dos mecanismos convencionais de acesso a informao, onde os usurios explicitamente iniciam o processo de busca, os mecanismos de busca ativa apresentam informaes relevantes para os usurios sem a necessidade destes efetuarem requisies ao sistema [Ye, 2001]. No sistema CodeBroker, desenvolvido por Ye [Ye, 2001], o sistema infere a necessidade de componentes dos desenvolvedores de software atravs do monitoramento das interaes destes com o ambiente de desenvolvimento. Deste modo, enquanto o desenvolvedor implementa uma aplicao, o sistema apresenta possveis componentes que executam as tarefas desejadas pelo desenvolvedor. Esta abordagem de sistema de repositrio ativo, embora interessante, apresenta alguns problemas. No modelo atual, as inferncias so feitas atravs da assinatura de mtodos e comentrios JavaDoc. O maior problema que os componentes esto

19


20

limitados a cdigo fonte e no representam modelos de alto nvel, logo o nvel de reuso restrito. Este tipo de repositrio parece bastante promissor, porm, uma srie de refinamentos ainda deve ser realizado, a fim de oferecer um melhor rastreamento do conceito de componentes, no apenas como cdigo fonte. Repositrios com suporte a rankeamento Outro aspecto recente de pesquisa est relacionado ao rankeamento de componentes em um repositrio de reuso. Repositrios de reuso usualmente aplicam mtodos de representao [Frakes & Gandel, 1990] para facilitar os usurios no processo de busca e utilizao de componentes. Neste sentido, Pan et al. em [Pan et al., 2004] propuseram uma abordagem para melhorar a interoperabilidade semntica de repositrios de reuso distribudos, chamada de Improved Relevancy Matching and Ranking (IRMR), a qual se baseia na anlise de correlao dos termos usados nos mtodos de representao adotados por repositrios. Baseados no mtodo IRMR, os usurios podem recuperar componentes provenientes de mltiplos repositrios via uma viso de representao simples. Outras abordagens para auxiliar usurios na priorizao (ranking) de componentes recuperados podem ser encontradas na literatura. Isakowit, por exemplo, prope um mtodo que faz uso de hypertexto para organizar a recuperao de componentes [Isakowitz & Kauffman, 1996]. A abordagem Component Rank [Inoue et al., 2003] utiliza um mtodo para priorizar componentes, analisando suas relaes reais de uso e propagando a significncia. Outras questes relacionadas a repositrios Alm destes, existem outros trabalhos focados no uso de repositrios em conjunto com outros aspectos, tais como, mtricas, engenharia reversa e gerncia de configurao. Em um estudo conduzido por Banker et al. [Banker et al., 1993], por exemplo, foi observado que ambientes CASE baseados em repositrio formam uma soluo vivel para uma coleta sistemtica de mtricas de atividades de reuso no

20


21

nvel do repositrio, avaliando a sua eficincia. Adicionalmente, as mtricas coletadas podem ser usadas para determinar os objetos que provavelmente sero mais usados e os contextos onde o reuso provavelmente acontecer mais. Casanova et al. [Casanova et al., 2003], analisa os conceitos de gerenciamento de configurao e verso e os aplica no contexto de DBC usando bibliotecas de componentes. Neste estudo, Casanova et al. descreve a estrutura geral de bibliotecas de componentes seguindo o modelo de configurao proposto por eles.

2.2.1 ConsideraesAnalisando os trabalhos apresentados, pode-se concluir que existem diversos estudos na literatura envolvendo repositrios de reuso, porm, o foco destes estudos , quase sempre, em questes relacionadas busca e recuperao de componentes, conforme tambm constatado por Lucredio et al. [Lucredio et al., 2004]. Assim, diferentes aspectos, tais como os papis que um repositrio deve desempenhar em um processo de reutilizao no so explorados adequadamente. Conseqentemente, difcil encontrar uma soluo completa na literatura que apresente com detalhes como um repositrio de reuso (que suporte os papis propostos na Seo 2.1) deve ser especificado, projetado e ainda implementado. A prxima Seo apresenta uma classificao das solues prticas que comumente so utilizadas como repositrios de reuso pelas organizaes.

21


22

2.3 Solues PrticasNa prtica, a maioria das empresas considera que repositrios so apenas um canal de distribuio de artefatos. Deste modo, repositrios representam, geralmente, simples mecanismos para armazenar, buscar e recuperar artefatos. Como conseqncia, diferentes tipos de ferramentas so usadas como uma opo para armazenar artefatos reusveis e torn-los disponveis aos desenvolvedores. Tais ferramentas, variam desde o uso de sistemas de gerenciamento de configurao (SGC), at solues mais elaboradas como gerenciadores de componentes. De fato, experincias prticas [Ezran el al., 2002] apontaram que muitas empresas analisadas preferem adaptar ferramentas tradicionais de engenharia de software, a comprar uma soluo fechada especfica de reuso. Isso, muitas vezes, se deve ao fato dessas solues serem caras e muitas vezes no atenderem por completo as necessidades da organizao. Nesta Seo, as solues existentes sero listadas e agrupadas por categorias, pois, enquanto ferramentas especficas aparecem e desaparecem continuamente no mercado, categorias so mais estveis [Ezran el al., 2002]. O objetivo desta Seo auxiliar a entender e a classificar os tipos de solues existentes que so freqentemente adotadas por empresas. A classificao apresentada formar a base para uma comparao das solues. Em geral, as solues existentes podem ser divididas em 2 tipos principais: Repositrios de Uso Geral (General-usage) e Repositrios Especficos de Reuso (Reuse-specific).

22


23

2.3.1 Repositrios de Uso GeralEsta classe inclui ferramentas de propsito geral e sistemas usados no desenvolvimento e gerenciamento de aplicaes. Esta categoria est dividida em 4 outras sub-categorias, a saber: Sistemas de gerenciamento de configurao (SGC), Repositrios de metadados, Sistemas Colaborativos e Repositrios de ferramentas CASE. Sistemas de Gerenciamento de Configurao (SGC) Como gerenciamento de configurao de software uma disciplina vital no desenvolvimento de software em larga escala, os sistemas de gerenciamento de configurao so comumente utilizados em organizaes de desenvolvimento de software [Hass, 2003]. Desta forma, SGC podem ser vistos como a primeira alternativa para repositrios de reuso, j que eles podem ser usados para o armazenamento de artefatos reusveis. Exemplos de ferramentas que podem ser usadas para este propsito so: CVS2, PVCS3, Visual Source Safe4, entre outras. Algumas destas ferramentas possuem caractersticas importantes, tais como, controle de acesso, controle de mudanas e gerenciamento de verses. Contudo, elas geralmente possuem APIs limitadas que no permitem, de maneira organizada e eficiente, a definio, a publicao e a busca de ativos reusveis. Segundo Ezran et al. [Ezran et al., 2002], outro problema com este tipo de ferramenta que elas gerenciam elementos de menor granularidade (fine-grained) em uma base de projeto, enquanto ativos reusveis podem possuir uma maior granularidade, contendo composio de elementos de mltiplos projetos.

2 3

http://www.nongnu.org/cvs/ http://www.serena.com/Products/professional/vm/ 4 http://msdn.microsoft.com/vstudio/products/vssafe/

23

Captulo 2 Repositrios de Reuso Repositrios de Metadados

24

A manipulao com grandes volumes de dados, dentro de algumas empresas, tem se tornado uma realidade extremamente comum. Acoplada a ela surgiu uma crescente demanda de uma forma que garantisse o efetivo uso da informao de maneira produtiva e inequvoca. neste contexto que se encaixa os repositrios de metadados. Os repositrios de metadados representam sistemas que geralmente utilizam a tecnologia de Data Warehouse para possibilitar a visualizao integrada de todo o ambiente de dados de uma empresa, explicitando atravs de modelos os inter-relacionamentos existentes entre os dados e as associaes destes com os processos funcionais, bases de dados, fluxos de informaes, infra-estruturas de processamento/comunicao, etc. A maioria das ferramentas de mercado, que se encaixam nesta categoria, permite criar um ambiente tecnolgico para a gesto da informao nas empresas e, consequentemente, facilitar o reuso destas informaes. Algumas dessas ferramentas permitem que os metadados sejam capturados de forma automatizada a partir de bases de dados legadas existentes nas empresas. Uma vez armazenados, os metadados podem ser utilizados para, tambm de modo automtico, disponibilizar diretrios de informao, emitir relatrios e alimentar ferramentas Computer Aided Sotfware Engineering (CASE). Um bom exemplo de uma ferramenta de mercado deste tipo o Rochade da ASG5. Apesar de parecer uma soluo bastante promissora por permitir o reuso e integrao automtica de informaes, este tipo de soluo possui um custo muito elevado. De acordo com uma pesquisa recente realizada pelo Gartner6 [Blechar, 2005], a maioria das empresas interessadas em reuso preferem usar solues mais especficas e focadas em tipos de dados que representem artefatos de software reutilizveis.

5 6

http://www.asg.com/ http://www.gartner.com/

24

Captulo 2 Repositrios de Reuso Sistemas Colaborativos

25

Estes sistemas incluem repositrios de compartilhamento de projetos e sistemas wiki. Repositrios de compartilhamento de projetos: Esta classe de ferramentas representa repositrio para compartilhar projetos de software e permite coordenar o desenvolvimento colaborativo de times distribudos. Em geral, eles possuem um engenho de busca simples, baseado em palavra-chave, para pesquisar projetos e so bem conhecidas nas comunidades de cdigo aberto que compartilham seus projetos na internet. Exemplos de repositrio de compartilhamento de projetos incluem: BerliOS (BerliOS, 2005), Java.Net (Java.net, 2005) e SourceForge (SourceForge, 2005). Alguns desses repositrios, SourceForge, por exemplo, possui 2 tipos de produto: (1) web site pblico para o desenvolvimento open source com mxima transparncia e (2) uma verso corporativa projetada para operar dentro de um contexto organizacional. O principal problema destes repositrios o suporte limitado para explorar e pesquisar componentes de software de alto nvel, cdigo fonte e algoritmos reutilizveis; Sistemas Wiki: Esta categoria representa sistemas que permitem aos usurios adicionar contedo, como em um frum da internet, e tambm habilitar outros usurios para editar o seu contedo. Geralmente, so sistemas web que executam em um ou mais servidores e so teis para troca de informaes atravs de um esforo colaborativo. Desta forma, eles podem ser usados para aumentar o reuso de conhecimento existente incluindo padres e boas prticas que podem ser considerados ativos reusveis. Porm, assim como os repositrios de compartilhamento de projetos, estes sistemas no provem o suporte adequado para explorar componentes de alto nvel, cdigo fonte e algoritmos reutilizveis.

25

Captulo 2 Repositrios de Reuso Repositrios de ferramentas CASE

26

Esta alternativa consiste em construir repositrios para integrar ferramentas CASE. Estes repositrios podem ser usados para auxiliar diferentes atividades no processo de desenvolvimento de software. Banker et al. [Banker et al., 1993], Banker et al. apresentam a idia de ambientes CASE baseados em repositrio e mostra como eles podem ser usados para suportar o gerenciamento de reuso no nvel organizacional. Por outro lado, Blaha et al. [Blaha et al., 1998] analisam o uso deste tipo de repositrio como uma infra-estrutura que facilita as tarefas de engenharia reversa. Em linhas gerais, repositrios de ferramentas CASE devem armazenar arquivos que sero trocados entre ferramentas. Blaha et al. [Blaha et al., 1998], por exemplo, considera modelos de projeto, modelos de anlise, mapeamentos e dados de relatrios de aplicao, como exemplos de arquivos reusveis que podem ser armazenados neste repositrio. Dados tais benefcios, pode-se considerar este tipo de ferramenta como uma boa opo para facilitar o reuso. Contudo, concordando com Ezran et al., a implementao de uma soluo deste tipo requer que as ferramentas CASE envolvidas tenham APIs abertas e que tambm seja necessrio definir protocolos comuns e formatos para troca de dados. De acordo com Ezran et al. [Ezran et al., 2002], alguns exemplos deste tipo de ferramentas incluem: repositrios para integrar ferramentas CASE em uma plataforma especfica (Allegris da Intersolv, Enabler da Softlab, MS-Repository da Microsoft) e repositrios dedicados a ferramentas Upper CASE (IBM Rational Rose, Select/OMT, Paradigm Plus).

26


27

2.3.2 Repositrios especficos de reusoA Segunda categoria das solues prticas formada por ferramentas especficas de reuso, que correspondem, como o nome indica, as ferramentas construdas com o objetivo principal de promover a reutilizao de software. Nesta categoria, tem-se as ferramentas de busca em cdigo e os gerenciadores de componentes. Ferramentas de Busca em Cdigo Devido s limitaes dos sistemas de gerenciamento de configurao, no que se refere ao gerenciamento de ativos reusveis, algumas empresas optam por implementar funcionalidades adicionais sobre essas ferramentas. De fato, como cdigo fonte um dos produtos de software mais reusado, muitas solues intencionadas em buscar cdigo em repositrios existentes tem emergido, cada vez mais, tanto na academia, quanto na indstria. O mecanismo geral dessas ferramentas baseado na indexao de cdigo fonte disponvel em repositrios de controle de verso, beneficiados pelo fato de que tais repositrios so intensivamente usados no desenvolvimento de projetos de software, e provem um servio de busca de cdigo. Algumas dessas ferramentas tais como Codase7 e Koders8, por exemplo, esto disponveis como servios na internet e possuem uma base indexada de cdigo fonte proveniente de mltiplos projetos open source. Em geral, estas ferramentas usam um esquema de busca em texto livre e so baseadas em mecanismos flexveis e adaptveis onde diversos tipos de repositrios de cdigo fonte tais como repositrios de controle de verso (CVS, Subversion) e repositrios de compartilhamento de projetos na internet (SourceForge, Java.Net) podem ser plugados na ferramenta. Exemplos de ferramentas nesta categoria incluem: (i) ferramentas da indstria: Koders e Codase; (ii) ferramentas da academia: CodeFinder [Henninger, 1997], Agora [Seacord et al., 1998], CodeBroker [Ye et al, 2000], SPARS-J [Yokomori et al., 2003], MARACATU [Garcia et al., 2005].7 8

http://www.codase.com/ http://www.koders.com/

27


28

A principal desvantagem dessas ferramentas o fato do reuso ser limitado a cdigo fonte, alm disso, no possuem mecanismos que garantam a qualidade dos artefatos que manipulam; Gerenciadores de Componentes Tipicamente, ferramentas nesta categoria fazem parte de uma soluo corporativa para gerenciar um catlogo de componentes de software reusveis e provem servios para publicar, navegar, buscar e recuperar tais componentes. Elas so, certamente, um tipo de banco de dados que prove uma maneira de identificar e categorizar componentes de software para que os mesmos possam ser compartilhados entre vrios usurios dentro de uma organizao. Algumas delas suportam caractersticas mais sofisticadas, tais como, rastreamento de dependncia entre os componentes e gerao de relatrios que auxiliam no monitoramento do reuso no nvel organizacional. Outras possuem tambm um conjunto de metadados extensvel que pode ser adaptado mais facilmente de acordo com as necessidades das organizaes. A principal desvantagem dessas ferramentas o alto custo associado sua aquisio. Alm disso, as ferramentas de mercado existentes falham em alguns pontos, como, por exemplo, a ausncia de suporte a processos de certificao que garantam a qualidade dos componentes disponibilizados. Exemplos deste tipo de ferramentas so: LogIdex (LogIdex, 2005) da LogicLibrary, MS-Visual Component Manager (MS-VCM, 2005) da Microsoft, e Select Component Manager (SCM, 2005) da Select Software.

28


29

A Tabela 2.1 apresenta uma comparao inicial entre as solues de gerenciadores de componentes citadas. Na prxima Seo os critrios dessa anlise sero detalhados e novos critrios sero apresentados. Alm disso, a anlise ser estendida para todos os tipos de solues existentes, a fim de fornecer uma viso geral das alternativas, sem se prender a ferramentas especficas. Tabela 2.1 - Comparao de gerenciadores de componentes comerciaisFerramentas Requisitos Browsing Busca Relatrios Publicao de componentes Processo de certificao Suporte a mltiplos repositrios Controle de acesso Servios de NotciasSCM MS-VCM LoIdex

Legenda No suporta/no se aplica Suporta parcialmente Suporta satisfatoriamente

Abreviaes SCM Select component manager LL - LogIdex

MS-VCM - MS-Visual Component Manager

29


30

A Figura 2.2 resume a taxonomia das solues que podem ser usadas, na prtica, como repositrios de reuso. A categorizao apresentada bastante til para entender, de uma maneira geral, a variedade das ferramentas existentes.

Figura 2.2 - Taxonomia das Solues A Seo a seguir apresenta algumas questes que devem ser levadas em consideraes ao escolher uma soluo de repositrio de reuso e refora o foco da soluo proposta.

30


31

2.3.3 Consideraes das solues existentesAps a reviso das solues, a primeira questo a ser feita provavelmente: que tipo de repositrio de reuso o mais adequado para uma empresa? Na verdade, a resposta para essa pergunta s pode ser feita em conjunto com uma avaliao do contexto em que o repositrio ser implantado. Em geral, os fatores a serem considerados ao escolher um repositrio de reuso so [Ezran el al., 2002]: A quantidade de desenvolvedores, de equipes de desenvolvimento, de unidades organizacionais existentes na empresa; A quantidade de domnios diferentes em que esses ativos se encontram distribudos; e A existncia na empresa de outros repositrios, tais como, sistemas de gerencia de configurao (SGC) e ferramentas CASE. Neste sentido, pode-se optar por uma estratgia gradual de implantao de um repositrio que, em linhas gerais, funciona da seguinte maneira: Se um repositrio j existe na organizao (SGC ou outros) e ainda no existe nenhum processo sistemtico de reuso implantado, pode-se optar inicialmente por desenvolver uma interface para estes repositrios existentes, que oferea funes especficas para busca e recuperao de artefatos. As ferramentas de busca em cdigo fonte so exemplos deste tipo de soluo; Por outro lado, quando um processo de reuso j est em andamento e o nmero de componentes produzidos comearem a crescer, tanto em quantidade, quanto em granularidade, o caminho natural a implantao de um gerenciador de componentes.

31


32

No caso deste trabalho, o foco voltado para construo de um repositrio de reuso para fbricas de software. Neste contexto, geralmente existem vrios domnios de aplicaes que so desenvolvidas por mltiplas equipes de projetos gerando continuamente componentes reutilizveis. Na prtica, ao invs do termo componente foi preferido adotar o termo ativo, como ser visto no prximo Captulo. Funcionalidades de um repositrio de Reuso Com o objetivo de efetuar uma comparao das funcionalidades suportadas pelas solues descritas, foram levantados alguns requisitos que sero utilizados como base para especificar as funcionalidades do repositrio a ser proposto. Para determinar os requisitos foram analisados os papis de um repositrio (descritos na Seo 2.1), algumas consideraes prticas, relatadas por desenvolvedores de software, juntamente com as funcionalidades observadas nas ferramentas estudadas. Alm disso, foram levados em considerao alguns trabalhos na literatura [Apperly, 2001] [Ezran el al., 2002], que tratam a respeito de requisitos de repositrios aplicados no contexto de reutilizao. Uma breve descrio de cada um dos requisitos feita na Tabela 2.2. importante ressaltar que os requisitos listados na Tabela 2.2 sero detalhados no prximo Captulo.

32


33

Tabela 2.2 Requisitos para comparar as solues de repositrio reuso#Requisito Descrio

1

Descrio

2 3 4

Insero Navegao Busca

importante estabelecer e manter uma descrio comum para os elementos armazenados no repositrio, de modo que todos os membros da organizao se tornem familiar com esta descrio. Alguns atributos so fundamentais para classificar e recuperar os elementos, como, por exemplo, as funcionalidades oferecidas por eles. Produtores de artefatos de software reutilizvel precisam torn-los disponveis para consumo, logo, o repositrio deve oferecer servios que permitam a insero desses artefatos. Deve ser possvel agrupar os artefatos em diferentes categorias de modo a permitir que os usurios possam navegar pelas categorias existentes. Alm da navegao, repositrios com grande quantidade de artefatos devem prover mecanismos de busca que permitam aos usurios encontrar mais facilmente os artefatos que precisam. Os usurios devem ser capazes de gerar relatrios que permitam, entre outras coisas, uma viso geral de como o repositrio est sendo utilizado. Exemplos de relatrios: relatrios que indiquem o grau/perfil de colaborao dos usurios e uso dos artefatos, as buscas mais realizadas, os artefatos mais baixados, entre outros. Os usurios devem ser capazes de registrar interesse em diferentes eventos, com o objetivo de no futuro ser notificado quando, por exemplo, um novo artefato de seu interesse for adicionado. O repositrio deve implementar servios que permitam a manuteno do cadastro de usurios e de outras entidades que so utilizadas pelo sistema. Deve ser possvel definir e gerenciar mltiplas verses de um mesmo artefato. Deve ser possvel que os usurios informem dependncias entre os ativos. Estas dependncias representam relacionamentos, tais como usa ou composto por. Usurios devem ser capazes de fornecer feedback a respeito dos artefatos que utilizou. Os feedbacks fornecidos permitem a identificao, por exemplo, dos artefatos mais bem avaliados. Visando promover a cultura de reuso por toda organizao, o repositrio deve oferecer servios que permitam a manuteno e o destaque de notcias relacionadas a reuso, tais como, iniciativas, melhores produtores de artefatos, tipos de artefatos mais reusados, entre outros. O repositrio deve suportar o armazenamento de artefatos provenientes de multiplas fontes. O repositrio deve suportar um processo de certificao que garanta a qualidade dos artefatos disponibilizados. Os usurios devem ser capazes de definir e capturar mtricas a respeito dos artefatos disponibilizados. Exemplo de mtricas: esforo e custo de desenvolvimento, LOC (para o caso de cdigo fonte). O repositrio deve possuir mecanismos para limitar o acesso dos usurios a alguns servios e recursos. E tambm possibilitar a apresentao (GUI) de diferentes vises do sistema aos diferentes usurios. Os usurios devem ser capazes de requisitar e aceitar mudanas nos seus artefatos. Tais mudanas incluem a reportagem de erros nos artefatos reutilizados.

5

Gerao de Relatrios

6

Notificao de Usurio Servios de Manuteno Gerenciamento de Verso Gerenciamento de Dependncias Servios de Feedback Servios de notcias Mltiplas fontes Processo de Certificao Mtricas

8 9 10

11

12

13 14 15

16

Controle de acesso Controle de Mudanas

17

33


34

A Tabela 2.3 classifica as solues de acordo com os requisitos apresentados. O significado de um campo marcado com que ferramentas em uma dada categoria tipicamente suportam o requisito. Por outro lado, um campo em branco significa que a maioria das ferramentas na categoria analisada no satisfaz o requisito especificado de maneira satisfatria. Tabela 2.3 Anlise das solues de repositrio

A tabela apresentada no pode ser considerada sempre verdadeira, visto que a mesma no completa e que eventualmente ferramentas especficas de uma categoria podem satisfazer de maneira diferente os mesmos requisitos. Porm, essa anlise serve como heurstica para ajudar na escolha do tipo de soluo de repositrio de reuso a ser utilizada em uma empresa.

34


35

2.4 Resumo do captuloEste Captulo props inicialmente os papis que devem ser desempenhados por um repositrio de reuso. Em seguida, foi feita uma analise das solues existentes na academia e na indstria. Essa anlise teve como objetivo definir o foco e o tipo de soluo do repositrio proposto neste trabalho. O prximo Captulo apresenta a especificao dos requisitos, o projeto de arquitetura e a experincia de implementao do repositrio de reuso proposto.

35

3

3

Repositrio de Reuso: Especificao, Projeto e Implementao

Baseado nos papis de um repositrio de reuso, apresentados no Captulo anterior, um conjunto de requisitos para o repositrio proposto foi definido, conforme ser apresentado neste Captulo. O foco da soluo proposta consiste em um repositrio de reuso que possa auxiliar desenvolvedores na produo e consumo de ativos de software, bem como prover meios que apiem gerentes na monitorao das atividades de reuso e permita que certificadores de componentes possam garantir a qualidade dos ativos disponibilizados. Aps a definio dos requisitos, a arquitetura do repositrio proposto ser apresentada e seus mdulos sero detalhados. Por fim, a experincia de implementao de um produto real baseado nesta arquitetura ser ento discutida. O restante do Captulo est organizado da seguinte forma: a Seo 3.1 descreve os requisitos a serem considerados na soluo. A Seo 3.2 apresenta a arquitetura proposta para o repositrio seguida do detalhamento interno de seus mdulos. A Seo 3.3 apresenta a experincia de implementao, discutindo o processo utilizado, as tecnologias e frameworks adotados e os resultados obtidos. E, finalmente, a Seo 3.4 resume o repositrio proposto.

3.1 RequisitosA partir da anlise dos importantes papis que um repositrio deve desempenhar em um processo de reuso, descritos no Captulo 2, e das solues comumente utilizadas na indstria e na academia, pode-se concluir que a maioria das alternativas prticas no suporta eficientemente os papis desejveis para um

36

Captulo 3 Repositrio de Reuso: Especificao, Projeto e Implementao

37

repositrio de reuso. Isto pode explicar porque algumas experincias envolvendo repositrios de reuso tm falhado [Frakes, 1995]. Sendo assim, os requisitos do repositrio proposto esto baseados na experincia do autor em reuso e desenvolvimento de software, nas discusses dos membros do grupo RiSE, nas solues prticas existentes e em alguns trabalhos da literatura que apresentam requisitos para ambientes de reuso [Mascena, 2006], engenhos de busca [Lucrdio et al., 2004] [Garcia et al., 2006] e repositrios [Blaha et al., 1998] [Apperly, 2001] [Ezran el al., 2002] importante ressaltar que os requisitos a seguir no representam um conjunto completo e fechado de funcionalidades que devem sempre estar presentes em qualquer repositrio de reuso, pois isso depender das reais necessidades e do contexto de cada empresa onde o mesmo ser utilizado. Contudo, acredita-se que os requisitos identificados podem servir como base para a construo de repositrios que suportem um processo de reuso em organizaes com nveis de atividade de reuso mais sistemticos. Ou seja, organizaes onde existe o incentivo para a produo de componentes e a incorporao das idias de reuso no desenvolvimento [Lynex & Layzell,1998]. A Seo a seguir discute o contedo que deve ser armazenado em um repositrio. Em seguida, a listagem de funcionalidades, que devem ser satisfeitas pela soluo proposta apresentada e finalmente algumas consideraes so feitas a respeito dos requisitos no funcionais que devem ser considerados.

3.1.1 O armazenamento de ativos em repositriosO desenvolvimento de software envolve um conjunto grande de atividades e diferentes tipos de artefatos so produzidos ao longo deste percurso. Sendo assim, uma empresa que inicia a construo de um repositrio de reuso, provavelmente, possui uma quantidade significativa de artefatos de software, tais como: especificao de casos de uso, unidades de programas, cdigo fonte, modelos de projeto e outros documentos que no necessariamente representam um componente de software, mas podem ser reutilizados em outros contextos ou sistemas.

37


38

Por esta razo, os elementos suportados em um repositrio no podem estar limitados a apenas um tipo de artefato e devem englobar qualquer produto de software que apresente um potencial de reuso significativo. Neste sentido, alguns pesquisadores tm buscado uma definio para artefatos reusveis. DSouza and Wills [DSouza & Wills, 1999], por exemplo, definem artefatos reusveis como sendo qualquer parte do trabalho que possa ser utilizada em mais de um projeto. Eles consideram os seguintes artefatos como candidatos reutilizao: Cdigo compilado; objetos executveis; Cdigo Fonte; classes e mtodos; Casos de testes; Modelos e Projetos: frameworks, padres; Interface de usurio; e Planos, estratgias e regras arquiteturais.

Portanto, o primeiro passo para determinar a estrutura dos elementos armazenados em um repositrio consiste em definir um modelo genrico que possa ser capaz de representar diferentes tipos de unidades de software reutilizveis. Nesta direo, muitos pesquisadores, quando se referem a uma unidade de software reutilizvel, preferem introduzir o conceito de ativo (asset). Em um sentido geral, um ativo representa algo de valor que uma pessoa ou uma empresa possui, ou seja, um bem. E este conceito pode ser adaptado para o contexto de software, onde ento, o termo ativo pode ser definido como uma unidade de software reutilizvel que captura algum conhecimento de negcio e que possui um valor significativo para uma empresa. Sendo assim, segundo Ezran et al. [Ezran et al., 2002], o termo componente de software pode ser visto como um tipo especfico de ativo que pode ser executado. Ainda de acordo com Ezran et al., a representao de um ativo deve incluir duas partes: o contedo (asset body) e os meta-dados (asset description):

38


39

Contedo: pode ser definido como sendo o conjunto de artefatos relacionados (partes reutilizveis). Cada artefato um produto de trabalho do ciclo de vida do software e pode representar a mesma parte do software em diferentes nveis de abstrao. Como exemplos de tipos de artefatos podem ser citados: modelo de anlise, modelo de projeto, cdigo fonte e cdigo executvel;

Metadados: consiste do conjunto de informaes a respeito do contedo do ativo. Esse conjunto de informaes deve incluir atributos, como, por exemplo, identificador do ativo, autor, datas de criao e ltima atualizao do ativo, descrio, conjunto de palavraschave ou facetas. Esse conjunto de atributos torna possvel identificar, descrever e buscar os ativos do repositrio.

O modelo genrico do conceito de ativo pode ser representado com o diagrama UML apresentado na Figura 3.1.

Figura 3.1 Modelo de ativo simplificado

3.1.2 Funcionalidades do Repositrio

39


40

Em linhas gerais, um repositrio deve ser capaz de identificar ativos, associar uma descrio para cada um deles, manter links para os artefatos que os compem, alm de oferecer servios que suportem as atividades de produtores, consumidores, gerentes e certificadores de componentes. Em detalhes, um repositrio deve oferecer as seguintes funcionalidades: 1. Insero.Um usurio (tipicamente um produtor de ativo) precisa tornar seus ativos disponveis para consumo, logo, um repositrio deve oferecer um servio bsico de insero de ativos. A funcionalidade de insero deve englobar o armazenamento dos metadados do ativo e tambm o seu contedo. Os metadados cadastrados devero ser utilizados para organizar o catlogo de elementos do repositrio. J o cadastro do contedo dever suportar tanto a insero dos artefatos localmente (basicamente uma operao de upload dos artefatos), como tambm a insero de referncias para artefatos remotos, localizados em outras fontes externas, como, por exemplo, repositrios de controle de verso ou at mesmo a internet; 2. Navegao. Deve ser possvel agrupar os ativos em diferentes categorias e deve existir um mecanismo que permita a navegao pelos ativos atravs destas categorias. Isto tem por finalidade oferecer uma viso mais simplificada do conjunto de catlogos de componentes presentes no repositrio. De acordo Ezran et al., o servio de navegao suficiente para ajudar os desenvolvedores a encontrar os ativos que precisam, quando a quantidade de ativos no repositrio relativamente pequena (na ordem de dezenas); 3. Classificao e busca. Repositrios com uma quantidade muito grande de ativos devem prover mecanismos de busca que permitam aos usurios encontrar o que precisam, uma vez que a navegao em catlogos no se mostra suficiente neste contexto. Existem vrias tcnicas que podem ser utilizadas com o objetivo de facilitar o processo de classificao e busca de ativos, essas tcnicas incluem busca textual, palavras-chave e classificao baseada em facetas;

40


41

Busca textual. Nesta tcnica, os usurios devem ser capazes de buscar no catlogo por um string de texto contida em qualquer parte da descrio do ativo. O resultado de tal busca um conjunto de uma ou mais descries de ativos. Uma variao desta funcionalidade pode tambm levar em considerao a busca no contedo dos ativos; Palavras-chave. Nesta tcnica, cada ativo descrito por uma ou mais palavras-chave, por exemplo, uma implementao em Java de uma lista de objetos pode ser descrita pelas seguintes palavras-chave: cdigo, estrutura de dados e Java. Essas palavras-chave so informadas pelos usurios produtores de ativos e o processo de busca consiste do usurio informar uma ou mais palavras-chave como entrada, e receber zero ou mais descries de ativos como sada; Classificao baseada em facetas. Cada ativo descrito por um conjunto de pares, atributo-valor, exemplificando, a lista de objetos poderia ser descrita por Tipo de ativo: cdigo fonte; Funcionalidade: estrutura de dados; Linguagem de programao: Java. Classificao por facetas [Prieto-Diaz, 1991] uma tcnica mais rigorosa do que palavraschave. Na busca, o usurio informa um filtro composto de um ou mais pares de atributo-valor, e recebe como sada, zero ou mais descries de ativos. Uma variao mais poderosa da classificao por facetas define estrutura de rvores para os valores da faceta [Ezran et al., 2002]. Por exemplo, a faceta Linguagem de programao poderia ter os valores procedural ou orientada a objetos. O valor procedural poderia ser especializado como Pascal, Fortran e C e o valor orientada a objetos como Smalltalk, C++ e Java. O processo de busca nesse caso deve levar em considerao qualquer nvel da rvore. Por exemplo, a busca com linguagem de programao = procedural retorna todos os ativos que possuem os valores Pascal, Fortran e C, e a busca com linguagem de programao = Java restringe o escopo de busca aos ativos que possuem o valor Java.

41


42

importante ressaltar que o requisito de busca extremamente crucial e complexo em um ambiente de repositrio. Um dos principais pesquisadores envolvidos com repositrios, Ali Mili [Mili et al., 1998], resume as pesquisas envolvendo mecanismos de armazenamento e busca de artefatos do seguinte modo: Apesar das contnuas pesquisas, o problema do armazenamento e recuperao de artefatos de software continua como um problema em aberto. Mesmo existindo uma grande variedade de solues para este problema, nenhuma soluo oferece a combinao de eficincia, preciso e facilidade de utilizao para permitir otimizar a reutilizao de software. Em um trabalho mais recente, Lucrdio et al. apresentam um exaustivo estudo sobre busca e recuperao de artefatos em sistemas de repositrio e ratificam a concluso de Ali Mili [Lucrdio et al., 2003], [Lucrdio et al., 2004]. 4. Gerao de Relatrios. O repositrio deve prover servios para a gerao de relatrios que permitam, entre outras coisas, obter uma viso geral de como o repositrio est sendo utilizado. Como exemplos de relatrios que devem ser suportados, pode-se citar: relatrios que indiquem o grau/perfil de colaborao dos usurios e uso dos componentes, as buscas mais realizadas, os componentes mais baixados, os componentes mais recentes, entre outros. Um detalhamento dos possveis tipos de relatrios com exemplos dos mesmos, podem ser vistos no Apndice B. 5. Notificao dos usurios. Os usurios devem ser capazes de registrar interesse em diferentes eventos ou conjunto de informaes do repositrio, com o objetivo de, no futuro, serem notificados quando, por exemplo, um novo ativo for adicionado, novas verses de ativos existentes forem criadas e informaes em geral do repositrio, como, por exemplo, a adio de notcias ou artigos em geral; 6. Servios de Administrao. O repositrio deve implementar servios que permitam a manuteno do cadastro de usurios e de outras entidades que

42


43

so utilizadas pelo sistema. Estas entidades podem incluir os tipos de artefatos, tipos de ativos, os classificadores (facetas), entre outras. 7. Gerenciamento de verso. O repositrio deve ser capaz de armazenar mltiplas verses de um mesmo ativo, a fim de permitir que os usurios sejam capazes de recuperar verses antigas de um ativo e manter verses variantes, ou seja, implementaes alternativas do mesmo ativo; 8. Gerenciamento de dependncia. Deve ser possvel que os usurios informem dependncias entre os ativos. Estas dependncias representam relacionamentos, tais como, usa ou composto por; 9. Suporte a Feedback. O sistema deve permitir que os usurios dos ativos registrem suas impresses a respeito dos componentes que utilizaram. Os feedbacks permitem, por exemplo, a identificao dos componentes mais bem avaliados e tambm o rastreamento de uso dos ativos (o contexto em que o ativo foi usado, os problemas encontrados, entre outros). O mecanismo de feedback tambm pode ser utilizado para gradualmente melhorar a qualidade do resultado das buscas feitas no sistema. Um exemplo citado por Mascena [Mascena, 2006] o fato do mecanismo de busca atribuir maior prioridade aos ativos que foram reusados com sucesso por outros programadores. Alm disso, o conjunto de feedbacks pode ser usado juntamente com polticas de incentivo, como, por exemplo, bonificao para os desenvolvedores dos componentes mais bem avaliados. Uma discusso til a respeito de polticas de incentivo aplicadas a reutilizao pode ser encontrada em [Poulin, 1995]; 10. Servios de marketing. Visando promover a cultura de reuso por toda organizao, o repositrio deve oferecer servios que permitam a manuteno e o destaque de notcias relacionadas a reuso, tais como, iniciativas, melhores produtores de ativos, componentes mais reusados, entre outros; 11. Suporte a mltiplas fontes de ativos. O repositrio deve suportar mltiplas fontes de ativos, isto , deve ser possvel armazenar ativos cujos artefatos (contedo) estejam armazenados em diferentes fontes externas. Isto facilita a integrao com diferentes tipos de fontes de ativos que possam

43


44

existir no contexto onde o repositrio ser implantado, como, por exemplo, repositrio de controle de verso e diretrios compartilhados na rede; 12. Suporte a um processo de certificao. O repositrio deve oferecer um servio de certificao que perm

reuse repository-specification design implementation

Documents