1. INFORMAÇÕES DE SISTEMAS DE CONTROLE DE VERSÃO - CONT
I. Contexto
Nos últimos anos temos observados diversas pesquisas que consolidam dados vindos de
sistemas de controle de versões para gerar informações úteis para a tomada de decisões por
parte de gerentes de projeto.
Um destes ramos de pesquisa envolve a detecção de mudanças conjuntas entre os arquivos
que compõem um projeto de software, como forma de predizer mudanças futuras no projeto
ou indicar mudanças que deveriam ter ocorrido, mas não foram observadas.
II. Identificando Mudanças Conjuntas
Partindo do terceiro trabalho, vocês já têm classes que representam os principais conceitos
envolvidos em sistemas de controle de versão: o log de um sistema, os arquivos que compõem
o sistema e as revisões sofridas por estes arquivos. Identificar mudanças conjuntas significa
analisar que arquivos mudaram em conjunto quando um ou mais arquivos foram alterados.
Para saber quantos e quais arquivos foram alterados em conjunto precisamos dividir o tempo
entre o início e o final do projeto em fatias. Uma fatia representa um pedaço de tempo e, para
simplificar o problema, consideraremos fatias de tempo uniformemente divididas. Por exemplo,
se um projeto durou uma semana (madrugada de segunda até a noite de sexta) e dividirmos
este tempo em cinco fatias, teremos a primeira fatia começando às 00:00 hr de segunda-feira
e terminando às 23:59hr da própria segunda; a segunda fatia cobrirá a terça-feira; a quarta
fatia cobrirá a quarta-feira; e assim sucessivamente, até sexta-feira.
Em cada fatia de tempo devemos registrar os arquivos que foram alterados durante aquela
fatia. Identificar estes arquivos é uma tarefa simples: lembrem-se que temos a data de cada
revisão (commit) sofrido pelos arquivos. Desta forma, basta marcarmos as faixas de tempo em
que cada arquivo sofreu pelo menos um commit. Assim, teremos uma matriz de alterações
como a apresentada abaixo:
Faixa de tempo a.java b.java c.java d.java
17/11/2009, 00:00 hr a 00:30 hr X X
17/11/2009, 00:30 hr a 01:00 hr X X
...
17/11/2009, 06:00 hr a 06:30 hr X X X
...
Pelas marcações apresentadas na matriz acima, vemos que o arquivo A sofreu alguma revisão
no período entre 00:00hr e 00:30hr do dia 17/Novembro/2009 (alguém anda trabalhando de
madrugada ...). Vemos também que este arquivo voltou a sofrer revisões entre 06:00hr e
06:30hr do mesmo dia (... e a noite foi longa!).
Além disso, vemos que sempre que o arquivo A foi alterado, o arquivo B também foi alterado.
Por outro lado, somente duas a cada três vezes em que o arquivo B foi alterado, o arquivo A
também foi alterado. Podemos concluir que 100% das vezes em que o arquivo A foi alterado, o
arquivo B também foi. Por outro lado, apenas 66% das vezes em que o arquivo B foi alterado,
o arquivo A também foi. Para cada arquivo, podemos identificar o percentual de chances de
cada um dos outros arquivos ser alterado quando o primeiro sofrer alterações.
O cálculo do percentual de chances de alteração conjunta entre os pares de arquivos resulta na
seguinte matriz de probabilidade de alteração conjunta. Naturalmente, esta matriz será mais
precisa se tivermos mais faixas de tempo para comparar.

2. Faixa de tempo a.java b.java c.java d.java
a.java 100% 100% 50% 0%
b.java 66% 100% 33% 33%
c.java 100% 100% 100% 0%
d.java 0% 100% 0% 100%
Agora, considere que um gerente de projeto determinou que o arquivo A sofrerá alterações ...
o que você pode dizer ao gerente sobre as possíveis alterações sofridas por outros arquivos?
Eu diria que o arquivo B provavelmente será alterado: não podemos ter certeza absoluta, pois
as alterações passadas podem ter tido objetivos diferentes da nova alteração. Diria também
que existe grande chance do arquivo C ser alterado (50% de chance).
E o que dizer quando o gerente informar que dois arquivos sofrerão alterações, por exemplo, A
e B. Neste caso, vamos adotar um critério conservador. Por exemplo, diríamos que existe uma
probabilidade de 50% de alterarmos o arquivo C (embora a probabilidade deste arquivo ser
alterado seja de apenas 33% por conta de B). Na mesma linha, diríamos que existe uma
probabilidade de 33% de alterarmos o arquivo D, muito embora a probabilidade de alterarmos
D seja 0% em função de A.
III. Objetivos do Trabalho
O quarto trabalho de Programação Modular tem como objetivo utilizar as informações
capturadas do log de um sistema de controle de versão para identificar mudanças conjuntas
em arquivos do projeto e predizer mudanças futuras.
Vocês deverão construir um programa que funcione por linha de comando (nada de interface
gráfica com o usuário ou interfaces textuais) e receba os seguintes parâmetros: nome do
arquivo de log, tamanho da fatia de tempo e nome de um arquivo complementar.
O arquivo complementar será um arquivo texto, onde cada linha terá o caminho completo (a
partir da raiz do projeto no sistema de controles de versão) de um arquivo que deve ser
considerado na identificação das mudanças conjuntas. Linhas em branco e começadas pelo
caractere # devem ser ignoradas na leitura deste arquivo.
O trabalho será avaliado da seguinte maneira: a implementação correta, com casos de teste
que demonstrem o funcionamento do programa, vale até 2,5 pontos. Identação, bons nomes
para os elementos do programa, comentários e organização geral vale 1 ponto. O último meio
ponto é deixado para a surpresa: surpreendam-me com alguma funcionalidade interessante
para o programa e ganhem este último meio ponto.
Acompanhem o Moodle com frequência para novidades sobre o quarto trabalho, pois novidades
vão aparecer ...