Uma vez definida a estrutura da abordagem e sua codificação, o cenário de uso fica definido como na Figura 13. Os passos são descritos em detalhes após a Figura.
Figura 13: Diagrama de Cenário de Uso
Inicia-se a execução da abordagem (Passo 0) com a definição de um 5 token de acesso, provido pelo GitHub, a fim de obter-se autorização ao acesso de informação do repositório e usuário ou organização que o
41
possuem. Caso não se execute este passo, certas informações privadas do
repositório não podem ser acessadas, como por exemplo, usuários
colaboradores do repositório. Executa-se então a consulta à API do GitHub, uma vez autorizado,
onde serão recolhidas as informações definidas no tópico anterior(Passo 1).
Faz-se necessário então a execução de outro código, dessa vez na linguagem
cypher , própria do Neo4j a fim de termos o carregamento da informação
contida em cada arquivo csv(Passo 2) como um nó com atributos na base de
dados orientada a grafos. Uma vez definido os vértices do grafo e seus
atributos, definimos as relações entre esses vértices, baseando-se em
atributos comuns. Essas relações serão as arestas no grafo(Passo 3). Tem-se então todo o grafo montado com as informações. Pode-se agora
realizar uma consulta por certos elementos ou exibir todos os dados
carregados(Passo 4). Considerando o tamanho de certos projetos e a
incapacidade da abordagem de exibir grafos com elevado número de vértices
devido a restrições de memória, recomenda-se a execução de consultas.
4.1 Descrição do Projeto
O projeto inicialmente escolhido como exemplo foi um projetogovernamental brasileiro, com marcação por estrelas (indicando interesse) de
mais de 10 usuários, com alterações no código no espaço de um mês da
análise, demonstrando que o projeto estava ativo. Assim, selecionamos o projeto da conta govbr, intitulado barra.govbr.
42
e padronizando sites do Governo Federal . O projeto conta com 396 commits, 6
24 issues, 6 colaboradores e não utiliza algumas features do GitHub, como
releases e projects.
4.2 Descrição da execução da abordagem
Primeiramente executamos o código python para extração deinformação através do uso da API do GitHub, produzindo os arquivos csv
referente a cada nó definido. Conforme definimos na seção 3.3, a execução
da abordagem se inicia com a execução do código, definindo o repositório a
ser acessado e um token de acesso para a operação. Caso o token não seja
definido, utilizamos um token padrão. Nesse caso, é possível que certas
informações referentes ao repositório de caráter privado não possam ser
acessadas, tal como usuários contribuidores, como exibido na Figura 14. Figura 14: Execução do código para coleta de dados Com estes passos executados, geramos os arquivos necessários para a
criação dos nós e relacionamentos presentes no grafo (Figura 15),
43 necessitando agora carregá-los no Neo4j, conforme os passos 2 e 3 (Figura 16). Isso ocorre com a execução de um script cypher próprio do Neo4j. A Figura abaixo mostra a execução deste passo.
Figura 15: Arquivos gerados e trecho do arquivo de dados referente às issues
Figura 16: Criação dos nós e relacionamentos e trecho do código cypher
Por fim, resta apenas delimitar as consultas através de comandos no terminal do Neo4j, executado diretamente do Browser. Esse passo é extremamente importante em caso de um projeto de maior tamanho, a fim de prover melhor legibilidade ao usuário.
44
Figura 17: Representação em grafo do projeto barra.govbr
Uma vez gerada a visualização, é possível manipular e movimentar os
nós, selecionar um nó para acessar seus atributos, mudar o tamanho dos
nós e utilizar opções de zoom in e zoom out. Na Figura 17, por exemplo,
45
(através das arestas), suas ligações e situação do artefato (Através dos
atributos dos nós). Com relação ao passo 4, foram definidas diferentes consultas a serem
realizadas. Essas consultas são definidas utilizando a linguagem cypher ,
própria do Neo4j. A primeira, representada na Figura 17, é definida como
" match (n) return n " , buscando todos os nós e relacionamentos criados e
exibindo todos simultaneamente. Em comparação, a visão original provida
pelo github não expressa diretamente o tamanho do projeto, exibindo-o como
uma lista (Figura 18). Figura 18: Visão do projeto barra.govbr no site do GitHub Útil e simples em projetos de menor tamanho, como o projeto
46
barra.govbr, essa consulta tende a ser menos legível conforme o tamanho
dos projetos e o número de artefatos neles aumentam, uma vez que o grafo
se torna mais denso e complexo, além do maior consumo de memória para
um grande número de nós (a conFiguração inicial do neo4j limita esse
número em mil unidades). Procurando prover um grafo detalhado referente ao requisito R6 ,
podemos criar uma consulta a fim de restringir artefatos com determinado
status, executando a consulta " match (n:issues),(r) where n.state = 'open'
return (n)-[]-(r) " como é o caso de issues, como mostrado na Figura 19. Figura 19: Issues com estado aberto Já a visão presente no site do GitHub de issues em estado aberto se
47
issue, para isso torna-se necessário selecionar uma issue em específico e
abrir sua página. Figura 20: Issues abertas do projeto barra.govbr na visão do GitHub Afim de se atender aos requisitos R8 e R9 podemos escolher um único
usuário a fim de visualizar os artefatos criados por ele, através da consulta
" match (n:Users_contributors),(m) where n.login='caduvieira' return (n)-[]-(m)" (Figura 21) . No caso do próprio GitHub tal visualização não é possível. No lugar
dela, podemos ver um gráfico específico do número de commits feitos por
tempo ou selecionar o usuário e obter informações dos repositórios que ele
48 como atributo do nó repositório.
Figura 21: Artefatos criados pelo usuário caduvieira
Outra consulta realizada busca atender ao requisito R10 , representada na Figura 22, e é descrita como " match (n),(m) where exists(n.created_at) or exists(n.author_date) and n.created_at<= ('2016-01-29T00:00:00Z') and (n.created_at >= '2015-01-29T00:00:00Z') or n.author_date<= ('2016-01-29T00:00:00Z') and (n.author_date >= '2015-01-29T00:00:00Z') return (n)-[]-(m)" .
49 de tempo. O GitHub não possui uma visão para artefatos dessa forma, ou seja, não é possível delimitar todos os artefatos produzidos em uma janela de tempo. No exemplo apresentado na Figura 22, retiramos os artefatos criados entre 2015 e 2016:
Figura 22: Consulta com tempo delimitado
50 produzidos pelo GitHub, assim como a estruturação do projeto de uma forma alternativa a visão em listagens oferecida pelo próprio GitHub.
Assim, um gerente ou líder de equipe terá uma alternativa de visualização, geral ou específica, dos atributos produzidos. Por fim, com essa automatização do processo de rastreabilidade, podemos reduzir os custos de documentação, ao mesmo tempo que provemos essas visualizações.
51
5 Trabalhos relacionados
Neste capítulo dedicamo-nos a explorar ferramentas ou abordagens
que também procurem prover uma visualização aos dados presentes no
GitHub. Realizamos então uma comparação com a abordagem aqui presente
e ressaltamos seus pontos fortes e fracos com relação a abordagem aqui
apresentada. Não conseguimos localizar uma outra ferramenta ou
abordagem que também levasse em consideração a noção de rastreabilidade
explicitamente e procurasse prover uma visualização dos links e artefatos
presentes, simultaneamente. Boa parte das ferramentas dedica-se unicamente a prover uma
interface gráfica de usuário para representar dados do GitHub, mas não
evidencia a relação entre diversos artefatos do projeto ou não procura criar
uma visualização do relacionamento entre eles, optando ao invés disso, por
prover informação sobre commits ou branches do projeto. Selecionamos dois projetos mais próximos ao que procuramos realizar
no trabalho, ambos representando dados do GitHub em formato de grafo,
para sua seleção definimos projetos que utilizassem dados do GitHub,
providenciassem uma visualização deles em formato de grafo.
5.1 GitHub Visualizer
GitHub visualizer (Figura 23) é uma aplicação web que permite a52 projeto e os usuários que a realizaram, criando uma animação demonstrando a evolução do projeto. Essa apresentação ocorre em três passos: a seleção de um usuário, a seleção de um repositório e a definição de parâmetros para visualização dinâmica.
São utilizadas a API do GitHub e a biblioteca D3, uma biblioteca do JavaScript para manipulação de documentos baseada em dados, além de Canvas e SVG, para visualização dinâmica em HTML5 e produção de gráficos interativos.
Figura 23: Uso do GitHub Visualizer aplicado ao projeto Barra.govbr. Fonte:
53
Com relação à abordagem aqui apresentada, o GitHub Visualizer
demonstra características interessantes, como a animação da construção do
projeto no decorrer do tempo, o que não é possível no nosso caso, em que
apresentamos imagens do projeto em um dado momento. Outro ponto
positivo é a identificação dos arquivos atualizados e adicionados, além das
linguagens de programação presentes nos mesmos. Apesar disso, essa é a única visualização presente na ferramenta,
ignorando outros artefatos interessantes que podem prover informações do
projeto, como issues e pull requests.
5.2 Gource
Gource (Figura 24) é um programa que permite a visualização7do desenvolvimento de um sistema através de uma árvore de diretórios
animada. Nele diretórios aparecem como galhos e arquivos como folhas.
Desenvolvedores são identificados ao contribuírem no projeto e os arquivos contribuídos são destacados.
54
Figura 24: Primórdio do desenvolvimento do sistema operacional Linux.
Fonte: Gource
Comparativamente à abordagem aqui apresentada, ela possui vantagens e desvantagens similares a ferramenta anteriormente apresentada. Animações e identificação de arquivos tornam a visualização mais fluida, ao tratar-se do desenvolvimento do projeto, mas ignora outros artefatos presentes no GitHub, como issues e pull requests, perdendo detalhes do projeto que trazem informação diversa.
55
6 Considerações Finais
O trabalho de Trindade (2018) mostrou que a rastreabilidade em
projetos ágeis é um desafio crescente. Isto motivou o presente trabalho cujo
objetivo foi investigar potenciais rastros entre artefatos disponíveis em
projetos do GitHub. Escolhemos o GitHub como foco deste trabalho por
possuir diversos projetos e respectivos artefatos identificáveis e analisáveis.
Inicialmente realizamos a seleção e discussão de quais artefatos do projeto
seriam realmente úteis para um gerente de projeto - tomando como base o
trabalho de Trindade (2018). Tendo realizado esse passo, investigamos
então a visualização dos dados e como seus relacionamentos se dariam,
levando em consideração os dados obtidos, utilizando um banco de dados
em Grafo (i.e., Neo4j). Definimos então uma abordagem que foi então comparada as duas
alternativas, GitHub Visualizer e Gource, onde foi possível notar a maior
riqueza de dados e informação na abordagem aqui apresentada, no lugar da
alternativa animada e dedicada a arquivos presentes em ambas as outras
alternativas.
6.1 Limitações e Ameaças
A abordagem aqui apresentada é limitada tanto pelas tecnologiasescolhidas, quanto pela estrutura do projeto(Como dados incompletos ou
não utilizados como esperado). Quanto ao GitHub, não é possível acessar
todos os dados de um projeto sem a utilização de um token do administrador
e a obtenção desse token não é intuitiva ao utilizador. Além disso muitas das
56
usadas erroneamente pelo usuário, levando a produção de dados confusos
ou incompletos, como se deu no caso do projeto barra.govbr, em que contas
deletadas do GitHub mas que contribuíram no projeto geraram artefatos sem
relacionamentos. Quanto ao Neo4j para projetos de maior tamanho, nossa abordagem é
limitada tanto pelo custo em memória para a criação do alto número de nós,
assim como a reduzida visibilidade, uma vez que os nós e suas interações
começam a se sobrepor e formar uma imagem confusa. Ao se tratar das ameaças temos alterações na API do GitHub, que já
conta com um protótipo próprio para visualização, além outras alterações
possíveis, que não puderam ser acompanhadas uma vez que o trabalho foi
baseado no glossário feito e analisado, que não se mantém atualizado com a
API.
6.2 Trabalhos futuros
Trabalhos futuros que merecem atenção incluem: (i) a validação daabordagem frente a gerentes de projeto - durante a validação da abordagem
poderemos refinar as consultas utilizadas, podendo trazer assim mais
informações úteis ao gerentes que utilizem a abordagem; (ii) avaliação da
escalabilidade da abordagem aplicando a mesma projetos de maiores
proporções; (iii) a criação de uma interface para o usuário e (iv)
automatização do processo, de forma que não seja mais necessária a
execução de cada passo tratado no cenário de uso, mas sim um único processo automático.
57
7 Referências
ANTONINO, P., et al. A Non-invasive Approach to Trace Architecture Design, Requirements Specification and Agile Artifacts . 2014 23rd Australian Software Engineering Conference, IEEE, 2014, p. 220–29.
GENVIGIR, E. C. (2009). Um modelo para rastreabilidade de requisitos de software baseado em generalização de elos e atributos. Instituto Nacional de Pesquisas Espaciais.
GOTEL, O. C.; FINKELSTEIN, C. W. (1994, April). An analysis of the requirements traceability problem . In Requirements Engineering, 1994., Proceedings of the First International Conference on (pp. 94-101). IEEE.
GOTEL, O. et al. Glossary of traceability terms (v1. 0) . Software and Systems Traceability, Springer, 2012, p. 413.
KALLIAMVAKOU, E. The Promises and Perils of Mining GitHub. Proceedings of the 11th Working Conference on Mining Software Repositories , p. 92-101,2014.
58 KANNENBERG, A.; SAIEDIAN, H. Why Software Requirements Traceabiity Remains a Challenge. CrossTalk The Journal of Defense Software Engineering , 2009.
POHL, Klaus. Requirements engineering: fundamentals, principles, and techniques . Heidelberg ; New York: Springer,p. 606-625, 2010,
TRINDADE, G.; LUCENA, M. Rastreabilidade de Requisitos em Metodologias Ágeis: um Estudo Exploratório. XII Brazilian Symposium on Information Systems , Florianópolis, SC, 2016.
TRINDADE, G. Requisitos para Ferramenta de Gerenciamento de Requisitos em Desenvolvimento Ágil a partir de um Estudo Exploratório. Tese (Graduação) - Universidade Federal do Rio Grande do Norte, 2015.
TRINDADE, G. Visualização da Rastreabilidade em Projetos Ágeis através de Dados contidos em Ferramentas de Apoio à Gerência de Projetos . Tese (Mestrado) - Universidade Federal do Rio Grande do Norte, 2018.
59