Melhor tratamento de falsos negativos

[pauloborba]

No description provided.

[guilhermejccavalcanti]

Incorporar scripts de detecção de falso negativo de ooplsa (parametrizado): https://github.com/guilhermejccavalcanti/sourceeis/blob/master/MergeConflictParserAndAnalyser/src/cin/ufpe/br/app/Main.java

[pauloborba]

• confirmar hipótese de que FNs são devido à questão de espaçamento
• apresentar mais 5 tipos de FNs (verificar no artigo as razoes)

[pauloborba]

@leoribeiro36 resume aqui porque, dentro dos métodos, há divergência de resultado entre as duas ferramentas. diferença de encoding? whitespace? texto do conflito ligeiramente diferente?

[pauloborba]

@leoribeiro36 aquele FN que te mostrei, com herança, ocorre sem herança também. base m(){0}, left m(){1}, e right, na mesma linha de left, adiciona um novo método n(){this.m()}

[leoribeiro36]

Professor, eu analisei o caso que discutimos na ultima reunião, o caso 4, e percebi não se tratava de rename como suspeitávamos, mas sim de uma modificação nos parâmetros. Isso pode fazer com que o semi estruturado identifique a função inteira como conflito?

Parte do conflito reportado pelo semi estruturado:

MINE
private void validacaoFinal(SituacaoEspecialFaturamentoInformarActionForm form, Fachada fachada, String url) {
...
MINE
YOURS
@SuppressWarnings({ "unchecked", "rawtypes" })
private void validacaoFinal(SituacaoEspecialFaturamentoActionForm form, Fachada fachada) {
...
YOURS

[pauloborba]

sim @leoribeiro36. renaming, apesar do nome, é considerando tanto a mudança do nome do método quanto dos seus parâmetros porque, em Java, o que identifica unicamente um método é a sua assinatura (o nome mais lista de parâmetros). ou seja, esse é mesmo um caso de renaming.

[leoribeiro36]

Nas últimas análises feitas o que foi percebido é que problemas de encode e renaming eram os mais recorrentes no projeto analisado. A proposta de solução, ao problema do encode, enviada por Guilherme obteve resultados diferentes em um dos arquivos gerados na análise, mas sem impacto nos falsos negativos ou positivos.
Acredito que o problema do encode seja algo mais simples de se resolver, pois pelos resultados analisados, aparenta ser algum problema na leitura dos arquivos, já o do renaming aparenta ser mais complexo, pois aparenta ser algo relacionado ao modo que as funções são estruturados e analisados pelo algoritmo, isso requer uma análise mais aprofundada.

[pauloborba]

@leoribeiro36 não entendo porque a solução de @guilhermejccavalcanti não resolveu os casos de encode. a solução está bugada? os FNs de encoding não foram eliminados? qual a sua explicação?

sobre os casos de renaming, o que combinamos na última reunião? esses não podem ser automaticamente subtraídos da conta de FN? acho que eles já são, não @guilhermejccavalcanti?

que outros casos de FN você detectou. lista aqui, por favor, indicando se há uma forma fácil de detectá-los automaticamente.

[leoribeiro36]

Sim, os problemas de encode ainda continuam, acredito que a ferramenta esteja lendo corretamente e escrevendo de forma distina no arquivo, o que possa vir a gerar a diferença.
Na ultima reunião ficou acordado de verificar se se tratava mesmo de um problema de renaming, o que veio a ser confirmado.
Os outros problemas detectados também se caracterizaram como encode e renaming, o renaming eu ainda quero confirmar se é um FN e o encode acredito tenha formas de verificar se é ou não, mas acredito que alinhar a forma de escrita seja o mais correto a ser feito.

[pauloborba]

@leoribeiro36 não há outros casos devido a whitespace? texto do conflito ligeiramente diferente? nenhuma outra razão?

nesse caso de renaming que você ainda quer confirmar, abstraindo os detalhes, o que ocorre é que um cara renomeou o método e alterou o corpo dele, e o outro alterou o corpo do mesmo método?

[guilhermejccavalcanti]

Pessoal, mantenham essa conta aqui registrada para saber o que é contabilizado ou não como FN do S3M.

O que torna o número de FNs do S3M super alto é o acidentalConflicts. Esse acidentalConflicts é computado em função de orderingConflicts que também é impreciso. orderingConflicts por sua vez desconta os semistructuredNumberOfConflicts. Este último inclui os renamings, então por isso eles são descontados também.

Os logs, no entanto, não fazem essa distinção, lá vai aparecer conflito de renaming mesmo ele não tenha sido contabilizado como FN.

equalConflicts também é impreciso, porque a comparação textual não leva em consideração textos diferentes mas que são semanticamente equivalentes. Assim, essa composição de variáveis imprecisas que é torna a métrica falha.

[pauloborba]

@leoribeiro36 o pessoal da disciplina descobriu outros tipos de FN:

1. left removeu atributo (e parte do código de um método), right adicionou referencia para atributo (no mesmo metodo) e mexeu no espaçamento do atributo
2. um desenvolvedor incluiu método m com tag spring que define rota X, o outro incluiu método n na mesma área, com mesma rota
3. viram alguns casos que não eram FN mesmo, era apenas texto do conflito ligeiramente diferente
4. um desenvolvedor renomeou um método e alterou o corpo dele, o outro alterou o corpo do mesmo método, na mesma área
5. dois desenvolvedores mudaram o tipo de retorno do mesmo método
6. casos de conflito de renaming (aparecem na lista mas nao sao FNs)
7. encoding
8. outros casos de FN do artigo de oopsla
   preciso que você monte uma tabela indicando quantos de cada um desses tipos (ou de novo tipos que voce tenha identificado) aparecem na sua amostra, e quantos deles sao realmente FN ou apenas falsos alarmes de FN

[leoribeiro36]

Sobre os resultados analisados.
-na primeira execução tivemos 45 arquivos com conflitos no arquivo conflicts.unstructured e 31 possíveis falsos negativos, na segunda análise, que desconsiderava os espaços em brancos em ambas as abordagens de merge, tivemos 42 arquivos com conflitos no arquivo conflicts.unstructured e 22 falsos positivos. (obs. alguns dos arquivos conflitantes que deixaram de aparecer na nova execução tinha comportamento idênticos aos outros reportados)
-Comparando as diferenças entre cada um dos resultados, todos os conflitos da segunda execução apareciam também apareciam na primeira (sem potencial FN adicionado) e alguns novos cenários de merge, que não apareceram no conflicts.unstructured da execução anterior, vieram a aparecer, porém não contabilizados como FN.
-Alguns resultados informavam que o left ou o right continha conflitos, reproduzindo o merge original e observando o left o right e o base isso não se confirmou.

[pauloborba]

@leoribeiro36 o que você quer dizer com "alguns dos arquivos conflitantes que deixaram de aparecer na nova execução tinha comportamento idênticos aos outros reportados"?

também não entendi exatamente isto: "Alguns resultados informavam que o left ou o right continha conflitos, reproduzindo o merge original e observando o left o right e o base isso não se confirmou"

[leoribeiro36]

"alguns dos arquivos conflitantes que deixaram de aparecer na nova execução tinha comportamento idênticos aos outros reportados"

• na primeira execução ele informou que houveram no mesmo merge 5 arquivos com conflitos e no novo resultado houveram 4 arquivos conflitantes, ambos com o memso ID do conflito.

"Alguns resultados informavam que o left ou o right continha conflitos, reproduzindo o merge original e observando o left o right e o base isso não se confirmou"

• nos resultados apresentados, a ferramenta indicava, que em alguns casos, o left ou o right continham conflitos, como se o conflito fosse uma submissão do usuário. Para verificar isso eu reanalisei o merge original para confirmar se o left ou o right realmente tinha sido enviado com conflito, mas isso não se confirmou

[pauloborba]

deal with that together with #98