4. Presley
4.2. Arquitetura e Implementação
O projeto de arquitetura tem o papel de aprofundar os resultados obtidos com a análise dos requisitos, o foco desse processo está nos requisitos mais influentes na estrutura do sistema
31 (Larman, 2004). O objetivo dessa etapa no projeto de software é estabelecer a estrutura básica do sistema, isso envolve a identificação dos principais componentes e a forma como eles se comunicam (Sommerville, 2003).
Para atender os requisitos anteriormente descritos, a arquitetura do Presley foi definida em componentes e camadas. A seção seguinte apresenta uma descrição geral da arquitetura e os detalhes dos principais componentes.
4.2.1.
Framework Conceitual
A arquitetura do Presley é baseada no framework descrito por Ye e colegas (2007), que realiza união entre elementos de conhecimento (os desenvolvedores, os documentos e os códigos-fonte) envolvidos na realização do projeto, para obter o ecossistema entre estes e selecionar os especialistas que possam responder aos problemas enfrentados pelos desenvolvedores na fase de implementação. Os nós da rede (representados por código- fonte, documento e desenvolvedor) mostram o relacionamento entre as pessoas e as informações geradas durante o projeto, como apresentado na Figura 4-1.
Além do código-fonte e dos documentos, o Presley também faz uso da comunicação ocorrida no projeto entre os desenvolvedores através de listas de discussão e mensagens na própria ferramenta. Desta forma, o Presley recebe como parâmetros o código-fonte, os artefatos e registros de comunicação. A partir destas entradas são criados os seguintes relacionamentos:
• Desenvolvedor - Código-fonte: Formados pelos registros encontrados na ferramenta de controle de versão;
• Código-Fonte - Código-fonte: Formados pelas dependências entre códigos-fonte;
• Desenvolvedor - Desenvolvedor: Formados através da comunicação realizada em listas de discussões e na ferramenta.
32
Figura 4-1: Rede de atores de um projeto de software, extraído de (Ye et al., 2007)
Os parâmetros escolhidos trazem indícios dos detentores de conhecimento envolvidos com esses elementos desde sua concepção. A relação entre a execução das atividades do projeto e seus respectivos artefatos fornecem ao Presley as informações necessárias para inferir quem é o especialista em cada parte (pacote, classe, método) do software. Além disso, a interação ocorrida entre os indivíduos permite o sistema identificar quais são seus interesses dentro do projeto, contribuindo na inferência realizada.
4.2.2.
Arquitetura
Como mostrada na Figura 4-2, a arquitetura geral do Presley foi desenvolvida com base na arquitetura cliente-servidor.
33
Figura 4-2: Framework Arquitetural da Ferramenta
O cliente é responsável por coletar e enviar as informações fornecidas pelo usuário para o servidor. Já no lado servidor, existe uma divisão de papeis entre os seguintes componentes: Usuários, Mensagem, Conhecimento, Inferência e Persistência.
O componente Usuário é responsável por administrar as atividades pessoais envolvidas no projeto e o seu cadastro no sistema. O componente Mensagem permite a troca de mensagens entre os desenvolvedores e tem a responsabilidade de anexar do seu conteúdo os comentários dos arquivos fornecidos pelo cliente. O componente
Conhecimento é responsável por gerenciar os conhecimentos envolvidos no projeto e os
documentos que os descrevem. Por fim, o componente Inferência faz a análise dos conteúdos das mensagens e dos documentos fornecidos, identifica o assunto abordado nas mensagens e identifica as pessoas mais qualificadas a respondê-las.
4.2.3.
Cliente
Este componente é responsável pela interface gráfica com o usuário e por enviar as informações fornecidas pelos usuários para o servidor, que iniciará o processo de identificação dos especialistas.
O Cliente foi desenvolvido como um plug-in para a IDE Eclipse (www.eclipse.org), como uma perspectiva deste ambiente de desenvolvimento. Através dessa camada, o
34 desenvolvedor informa os seus dados pessoais e informações sobre o projeto em desenvolvimento, os conhecimentos envolvidos, as dúvidas geradas e as respostas fornecidas. Maiores detalhes sobre a interface gráfica do Presley serão descritos na seção 4.4.
O usuário ao escrever uma mensagem sobre seu problema pode informar o código- fonte relacionado e o Cliente encarrega-se de buscar os arquivos que fazem referência ao código indicado, antes de enviá-los ao servidor.
O motivo desse procedimento está nas dependências técnicas dos componentes de software também criarem dependências sociais entre os desenvolvedores (Souza et al., 2007) e porque a estrutura de relacionamentos pode indicar elementos importantes que contribuíram no desenvolvimento do código-fonte (Robillard, 2008). Como exemplo, um usuário pode ter dúvidas sobre a classe Pessoa classe herdada por Professor, o desenvolvedor de Professor pode ser tão qualificado quanto o desenvolvedor de Pessoa para ajudar na dúvida.
O componente JayFx foi incorporado e adaptado ao Cliente como responsável o por analisar as classes presentes nas mensagens escritas pelos desenvolvedores e retornar as demais classes.
Os demais componentes descritos são referentes a camada Servidor.
4.2.4.
Componente Usuário
O componente Usuário gerência os dados cadastrais dos desenvolvedores envolvidos no projeto. Outra função do componente está em coletar a participação dos desenvolvedores na implementação dos códigos-fonte do projeto. A extração dessas informações é feita através dos registros contidos na ferramenta de controle de versão, como o Subversion.
A Figura 4-3 apresenta as tabelas do banco de dados, no servidor, responsáveis por manter as informações descritas.
35
Figura 4-3: Tabelas Utilizadas pelo Componente Usuário
4.2.5.
Componente Conhecimento
O componente Conhecimento é responsável por administrar o conteúdo dos documentos que descrevem os tópicos implementados no código-fonte.
A construção de software envolve competência em três domínios: Engenharia de Software, Problema e Aplicação. O Domínio da Engenharia de Software compreende o conhecimento de técnicas, métodos, processos e ferramentas para a construção de software economicamente viável, confiável e eficiente. Este domínio diz como devemos construir o software. O Domínio do Problema diz respeito ao entendimento de requisitos, regras de negócio, necessidades e desejos do usuário. Ele informa o que deve ser construído. Por fim, o Domínio da Aplicação consiste de todo conhecimento necessário para compreender como o Domínio do Problema está sendo transformado em software, isto é, transcrito e codificado nos artefatos e código-fonte do projeto. O último domínio reflete as características e propriedades do software em construção.
Como o Presley busca pelos especialistas no Domínio da Aplicação, o usuário deve fornecer os tópicos que formam esse conhecimento e os documentos relacionados.
O componente conhecimento ao receber um documento associado a algum tópico faz uso do sub-componente Classificador, descrito posteriormente na seção Inferência, para retirar as stopwords do texto (palavras que carregam pouco significado) e obter a freqüência de cada termo.
36 Estas informações são armazenadas nas tabelas do banco de dados, presentes na Figura 4-4.
Figura 4-4: Tabelas Utilizadas pelo Componente Conhecimento
4.2.6.
Componente Mensagem
O componente Mensagem é responsável por receber os problemas e as soluções propostas pelos desenvolvedores da camada Cliente. Ele retornará ao Cliente os especialistas indicados pelo componente Inferência aos problemas cadastrados.
A comunicação realizada através do componente Mensagem é tratada da seguinte forma: as dúvidas ou perguntas dos desenvolvedores são os problemas ocorridos durante a implementação do software e as respostas as solicitações de ajuda são as possíveis soluções indicadas pelos especialistas.
A Figura 4-5 apresenta a tabela problema, com os dados sobre as dúvidas fornecidas pelos usuários, mensagem, com as pessoas indicadas pelo Presley a respondê-las, e solução, com as respostas dos especialistas indicados. As demais tabelas são relacionadas com os arquivos de código-fonte anexados a mensagem.
37
Figura 4-5: Tabelas Utilizadas pelo Componente Mensagem
Em anexo ao conteúdo do problema, o Cliente também envia os arquivos de código- fonte relacionado ao texto. O componente Mensagem extrai os comentários presentes nesses códigos e soma-os ao conteúdo do problema que será enviado para o componente
Inferência determinar o conhecimento abordado e recomendar os especialistas mais
indicados na resolução do problema.
4.2.7.
Componente Inferência
O componente Inferência dividi-se em três sub-componentes (Classificador, Identificador e Recomendador) para atingir o objetivo de encontrar os especialistas. A Figura 4-6 ilustra o fluxo de informação pelos componentes.
38
Figura 4-6: Sub-Componentes da Inferência
Todo conteúdo da mensagem e dos documentos são processados pelo Classificador. Esse componente calcula a quantidade de palavras utilizadas e retira do texto as stopwords e os caracteres inválidos. Para extração dessas palavras, foi criada uma lista, chamada de
stoplist, com todas as stopwords a serem excluídas do texto. A stoplist utilizada no Eurekha
(Wives, 1999) foi adotada pelo Presley, sendo composta por artigos, advérbios, conjunções, preposições, pronomes e interjeições.
Após a identificação das palavras-chave, o componente Classificador calcula a freqüência das palavras no texto. Ao fim, as mensagens processadas são enviadas ao componente Identificador para classificá-las em alguns dos conhecimentos existentes.
No Identificador é feito uma análise de todo o conteúdo da mensagem e dos arquivos textuais registrados pela ferramenta, com o objetivo de identificar as suas semelhanças.
Existem vários métodos para determinar a similaridade entre dois documentos. No componente Identificador foi adotada a técnica de similaridade difusa. Este método permite modelar documentos textuais cuja linguagem e os processos de recuperação são imprecisos (Wives, 2002). Outro fator positivo foram os resultados obtidos por Wives (1999) em experimentos para agrupamento de documentos textuais, por Loh (2001), na descoberta de conhecimento em textos baseados em conceitos e também por Galho (2003) para a categorização automática de documentos em textos. Os bons resultados desses trabalhos motivaram a utilização dessa técnica na modelagem no componente.
Para classificar as mensagens recebidas, a técnica de similaridade difusa determina o grau de semelhança da lista de termos da mensagem com a lista de termos de cada
39 conhecimento. Para cada termo comum entre as listas, calcula-se o grau de igualdade de seus escores de relevância através da função apresentada na Figura 4-7. As varáveis a e b representam os escores de relevância do termo.
Figura 4-7: Fórmula do cálculo do grau de igualdade (Galho e Moraes, 2004)
Supondo que o termo comum em análise seja "extração", sendo encontrado 2 vezes na mensagem e 5 no documento analisado. Aplicando a fórmula apresentada com a = 2 e b = 5, conforme os cálculos abaixo se têm a → b = 2,5 e b → a= 0,4. Os valores calculados devem pertencer entre 0 e 1, caso não aconteça deve-se normalizá-los, assumindo o valor 1 quando o resultado for maior que 1 e 0, quando for menor que 0. Deste modo, a → b será 1.
Ao efetuar os demais cálculos, tem-se:
25 , 0 1 4 1 1 1 = → = → − = − = − = − = a b b a b b a a
Após obter esses resultados, calcula-se o grau de igualdade do termo:
( )
2,5 =[
min( )
1,1]
+min(
0.4,0.25)
/2=[
1+0.25]
/2=0.625gi
Desta forma, o termo "extração" da mensagem obteve um grau de igualdade de 0,625 com o mesmo termo do documento arquivado. O resultado obtido indica a importância do termo e varia entre zero e um, o quanto mais próximo de um mais relevante é o termo.
Ao término dos cálculos de igualdade entre os termos, calcula-se o grau de similaridade entre o texto e os arquivos através da soma dos resultados obtidos anteriormente, conforme a fórmula na Figura 4-8.
40
Figura 4-8: Fórmula da média por operadores "fuzzy" (Galho e Moraes, 2004)
Esse cálculo é repetido em cada documento existente no banco de dados. Aquele que obtiver o maior grau de similaridade estará relacionado com o conhecimento definido para a mensagem.
Após a identificação do conhecimento da mensagem, o componente Recomendador analisa as participações dos usuários para determinar os especialistas. Este processo inicia-se com a busca dos usuários que mais tiveram problemas ou deram soluções referentes ao mesmo conhecimento encontrado no passo anterior. O cálculo apresentado na Figura 4-9 demonstra o passo necessário para descobrir a quantidade de participações do usuário u (em análise) sobre o conhecimento c.
Figura 4-9: Cálculo de Participação dos Desenvolvedores nas Interações
O cálculo acima é repetido com todos os usuários u que enviaram alguma mensagem, dentro do período de um ano antes do envio da solicitação de ajuda, formando uma lista com a quantidade de participação na comunicação de todos os participantes sobre o conhecimento determinado.
41 Em seguida é obtido o nível de participação dos desenvolvedores nos arquivos anexos à mensagem, através do histórico da ferramenta de controle de versões. A Figura 4-10 apresenta o cálculo realizado.
Figura 4-10: Cálculo de Participação dos Desenvolvedores no Código-Fonte
O cálculo acima é repetido com todos os usuários u que contribuíram no desenvolvimento dos arquivos A dentro do período de um mês antes do envio da solicitação de ajuda, formando uma lista de todos os contribuintes destes códigos-fonte.
Após coletar as participações, o componente soma a participação de cada lista e os cinco melhores classificados serão recomendados para responder a mensagem enviada pelo usuário.
4.2.8.
Detalhes da Implementação
O Presley é uma ferramenta desenvolvida em Java com arquitetura cliente-servidor. A camada cliente foi implementada como um Plug-in do Eclipse que envia as informações fornecidas pelos usuários para a camada Servidor. A camada de persistência utiliza o padrão SQL ANSI para manipular os dados e o banco de dados utilizado no desenvolvimento do projeto foi o MySQL. A implementação do Presley contém 12.213 linhas de código (Java, SQL e XML).
4.3.Uso do Presley
42
Figura 4-11: Presley em destaque na IDE Eclipse
Para inserir os tópicos de conhecimento do Domínio da Aplicação o usuário deve ir a aba Domínio mostrada na Figura 4-12.
43 Nessa aba o analista deverá cadastrar os conhecimentos envolvidos no projeto em desenvolvimento. Na região (1), os itens de domínio serão informados seguindo uma estrutura de árvore de conhecimentos, onde os conhecimentos filhos fazem parte do conhecimento pai. Para incluir documentos base dos itens, o usuário deve selecioná-lo e seguir para (2), que abrirá uma tela onde poderá selecionar o arquivo desejado.
Após informar os conhecimentos envolvidos no projeto já é possível utilizar a aba para o envio de mensagens. Essa aba pode ser dividida em três partes como mostra a Figura 4-13.
Figura 4-13: Aba Mensagem de Problema
Os três primeiros botões da região (1) são responsáveis pelo logon, inclusão e exclusão de usuários do sistema. Com identificação do usuário feita, a ferramenta permite o uso dos botões de controle de mensagem: inserir (que solicita o título e o texto da mensagem para o envio), excluir, validar resposta do usuário (para casos da mensagem enviada receber alguma solução válida) e encerrar (para informar ao sistema que o problema já foi resolvido).
Na região (2) as mensagens encaminhadas para o desenvolvedor identificado são mostradas e assim como em (1) as mensagens são acompanhadas pelos sinais (mensagem
44 de problema), (solução enviada) e (resposta a solução). Para o desenvolvedor enviar uma solução para algum problema recebido, ele deve clicá-lo duas vezes para aparecer uma tela solicitando o texto a ser enviado.
Por fim, todas as vezes que uma mensagem ou resposta for selecionada essas poderão ser lidas na região (3).