| Summary: | Submitted by Pedro Barros (pedro.silvabarros@ufpe.br) on 2018-06-25T19:24:26Z
No. of bitstreams: 2
license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5)
DISSERTAÇÃO Roberto Souto Maior de Barros Filho.pdf: 2025451 bytes, checksum: c2b9e33188a5a0b43ea456fefd1fcbc6 (MD5) === Made available in DSpace on 2018-06-25T19:24:26Z (GMT). No. of bitstreams: 2
license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5)
DISSERTAÇÃO Roberto Souto Maior de Barros Filho.pdf: 2025451 bytes, checksum: c2b9e33188a5a0b43ea456fefd1fcbc6 (MD5)
Previous issue date: 2017-03-31 === CNPQ === In a collaborative software development environment, developers often implement their contributions (or tasks) independently using local versions of the files of a system. However, contributions from different developers need to be integrated (merged) to a central version of the system, which may lead to different types of conflicts such as syntactic, static semantic or even dynamic semantic conflicts. The first two types are more easily identifiable as they lead to syntactically incorrect programs and to programs with compilations problems, respectively. On the other hand, dynamic semantic conflicts, which may be caused by subtle dependencies between contributions, may not be noticed during the integration process. This type of conflict alters the expected behaviour of a system, leading to bugs. Thus, failing to detect dynamic semantic conflicts may affect a system’s quality. Hence, this work’s main goal is to understand if Information Flow Control (IFC), a security technique used for discovering leaks in software, could be used to indicate the presence of dynamic semantic conflicts between developers contributions in merge scenarios. However, as defining if a dynamic semantic conflict exists involves understanding the expected behaviour of a system, and as such behavioural specifications are often hard to capture, formalize and reason about, we instead try to detect a code level adaptation of the notion of interference from Goguen and Meseguer. Actually, we limit our scope to interference caused by developers contributions on the same method. More specifically, we want to answer if the existence of information flow between developers same-method contributions of a merge scenario can be used to estimate the existence of interference. Therefore, we conduct an evaluation to understand if information flow may be used to estimate interference. In particular, we use Java Object-sensitive ANAlysis (JOANA) to do the IFC for Java programs. JOANA does the IFC of Java programs by using a System Dependence Graph (SDG), a directed graph representing the information flow through a program. As JOANA accepts different options of SDG, we first establish which of these SDG options (instance based without exceptions) is the most appropriate to our context. Additionally, we bring evidence that information flow between developers same-method contributions occurred for around 64% of the scenarios we evaluated. Finally, we conducted a manual analysis, on 35 scenarios with information flow between developers same-method contributions, to understand the limitations of using information flow to estimate interference between same-method contributions. From the 35 analysed scenarios, for only 15 we considered that an interference in fact existed. We found three different major reasons for detecting information flow and no interference: cases related to the nature of changes, to excessive annotation from our strategy and to the conservativeness of the flows identified by JOANA. We conclude that information flow may be used to estimate interference, but, ideally, the number of false positives should be reduced. In particular, we envisage room for solving around three quarters of the obtained false positives. === Em um ambiente de desenvolvimento colaborativo, desenvolvedores frequentemente implementam suas contribuições independentemente usando versões locais dos arquivos de um sistema. No entanto, contribuições de diferentes desenvolvedores precisam ser integradas a uma versão central do sistema, o que pode levar a diferentes tipos de conflitos de integração como conflitos sintáticos, de semântica estática ou até de semântica dinâmica. Os dois primeiros tipos são mais fáceis de identificar dado que levam a programas sintaticamente incorretos e a erros de compilação, respectivamente. Por outro lado, conflitos de semântica dinâmica, que são em geral causados por dependências sutis entre as contribuições, podem passar despercebidos durante o processo de integração. Esse tipo de conflito altera o comportamento esperado de um sistema, o que leva a bugs. Portanto, falhar em detectar estes conflitos pode afetar negativamente a qualidade de um sistema. Tendo isso em mente, o principal objetivo deste trabalho é entender se Information Flow Control (IFC), uma técnica de segurança utilizada para descobrir vazamentos de segurança em software, pode ser utilizado para indicar a presença de conflitos de semântica dinâmica entre contribuições de cenários de integração. Porém, a definição da existência de um conflito de semântica dinâmica envolve o entendimento do comportamento esperado de um sistema. Como especificações desse tipo de comportamento são geralmente difíceis de capturar, formalizar e entender, nós na realidade utilizamos uma adaptação a nível de código da noção de interferência de Goguen e Meseguer. Na verdade, nós limitamos o nosso escopo a interferência causada por contribuições de desenvolvedores nos mesmos métodos. Especificamente, nós desejamos responder se a existência de fluxo de informação entre duas contribuições no mesmo método pode ser utilizada para estimar a existência de interferência. Portanto, nós realizamos uma avaliação com o intuito de entender se fluxo de informação pode ser usado para estimar interferência. Em particular, nós utilizamos o Java Object-sensitive ANAlysis (JOANA) para fazer o IFC de programas Java. O JOANA faz IFC desses programas usando uma estrutura chamada System Dependence Graph (SDG), um grafo direcionado representando o fluxo de informação em um programa. Como o JOANA aceita diferentes opções de SDG, primeiro nós estabelecemos qual destas é a mais apropriada para o nosso contexto. Adicionalmente, trazemos evidência que fluxo de informação entre contribuições de desenvolvedores no mesmo método aconteceram para cerca de 64% dos cenários que avaliamos. Finalmente, realizamos uma análise manual, em 35 cenários de integração com fluxo de informação entre contribuições no mesmo método, para entender as limitações de utilizar fluxo de informação para estimar interferência entre contribuições. Dos 35 cenários analisados, para apenas 15 consideramos que interferência existia de fato. Nós achamos três razões principais para fluxo de informação ser detectado e não existir interferência: casos relacionados a natureza das mudanças, a limitações da nossa estratégia de anotação e a natureza conservadora dos fluxos identificados pelo JOANA. Nós concluímos que fluxo de informação pode ser utilizado para estimar interferência, mas, idealmente, o número de falsos positivos precisa ser reduzido. Em particular, nós enxergamos espaço para reduzir até três quartos dos falsos positivos.
|
|---|
