Index - Introduction - Preliminaries and Example - Approach

Presentation on theme: "Index - Introduction - Preliminaries and Example - Approach"— Presentation transcript:

1 ICPC 2014 Proceedings of the 22nd International Conference on Program Comprehension

2 Index - Introduction - Preliminaries and Example - Approach
- Experiments - Conclusion

3 Introduction

4 Introduction - One of the most time consuming task to resolve a bug report is to find the buggy files that are responsible for a reported bug. - Lucia et al. analyze 374 bugs from Rhino, AspectJ and Lucene and find that 84-93% of the bugs reside in 1-2 source code files. - To address the above mentioned challenge a number of studies have proposed ways to identify buggy program files given a bug report. - Many of these approaches are information retrieval-based and they work by computing similarities between a reported bug and source code files. 버그 보고서를 해결하는 데 가장 시간이 많이 걸리는 작업 중 하나는보고 된 버그를 담당하는 버그가 많은 파일을 찾는 것입니다. Lucia et al. Rhino, AspectJ 및 Lucene의 374 개의 버그를 분석하고 버그 중 %가 1-2 개의 소스 코드 파일에 있다는 사실을 알게되었습니다. 위에서 언급 한 문제를 해결하기 위해 많은 연구에서 버그 보고서가있는 버그가있는 프로그램 파일을 식별하는 방법을 제안했습니다. 이러한 접근 방식 중 많은 것은 정보 검색 기반이며보고 된 버그와 소스 코드 파일 간의 유사점을 계산하여 작동합니다.

5 Introduction (TFIDF-DHbPd)
- Sisman and Kak leverage version history data for bug localization. - Their approach makes use of history data to compute a probability score of a file to be buggy. - They also compute a similarity score between a file and a bug report. - The probability and the similarity scores are then added up, and the resultant score is used to rank source code files. Sisman과 Kak은 버그 지역화에 대한 버전 기록 데이터를 활용합니다. 그들의 접근 방식은 히스토리 데이터를 사용하여 버그가있는 파일의 확률 점수를 계산합니다. 또한 파일과 버그 보고서 간의 유사성 점수를 계산합니다. 그런 다음 확률 및 유사성 점수가 합산되고 결과 점수가 소스 코드 파일 순위를 결정하는 데 사용됩니다.

6 Introduction (Bug Locator)
- Zhou et al. leverage similarities among bug reports for bug localization. - Given a new bug report, their approach, named BugLocator, finds files that are fixed to resolve similar older bug reports. - Based on the similarity of the new and older bug reports, and the number of files that are fixed in each of the older bug reports, their proposed approach computes a bugginess score (referred to as SimiScore) for each source code file. - They also compute a similarity score between a file and a bug report (referred to as rVSMScore). - Weighted SimiScore and rVSMScore are then added up, and the resultant score is used to rank source code files. Zhou et al. 버그 지역화에 대한 버그 보고서 간의 유사점을 활용하십시오. 새로운 버그 보고서가 주어지면 BugLocator라는 이름의 접근법은 유사한 이전 버그 보고서를 해결하기 위해 수정 된 파일을 찾습니다. 새로운 버그 리포트와 이전 버그 리포트의 유사성과 이전 버그 리포트에서 수정 된 파일의 수를 기반으로 제안 된 접근법은 각 소스 코드 파일에 대한 버그 점수 (SimiScore라고 함)를 계산합니다. 또한 파일과 버그 보고서 (rVSMScore라고 함) 간의 유사성 점수를 계산합니다. 그런 다음 가중치 SimiScore와 rVSMScore가 합산되고 결과 점수가 소스 코드 파일 순위를 결정하는 데 사용됩니다.

7 Analyzing Structured Source File Information (rVSM)
propose a modified rVSM model as (6) to calculate a similarity between source files and bug report by utilizing structured information of source files.

8 Introduction (BLUiR & BLUiR+)
- To measure similarity between a bug report and a file, Sa- ha et al. propose an approach named BLUiR which leverages the structure of a bug report and a source code file. - A bug report has many fields (description and summary) and a file has many parts (class names, method names, variable names, and comments). - They thus transform a bug report and a file to structured documents and employ structured information retrieval. - In structured information retrieval, textual contents of each field in a bug report and each part of a source code file are considered separately. - Each field of a bug report is compared to each part of a source code file, and a similarity score is computed for each comparison. The summation of these scores is then used to rank source code files. - Saha et al. also creates an extension of BLUiR, we refer to as BLUiR+, which integrates similar report information into BLUiR, in the same manner as BugLocator integrates SimiScore to rVSMScore. 버그 리포트와 파일 간의 유사성을 측정하기 위해, Sa ha et al. 버그 보고서와 소스 코드 파일의 구조를 활용하는 BLUiR이라는 접근 방식을 제안합니다. 버그 보고서에는 많은 필드 (설명 및 요약)가 있고 파일에는 많은 부분 (클래스 이름, 메소드 이름, 변수 이름 및 설명)이 있습니다. 따라서 버그 보고서와 파일을 구조화 된 문서로 변환하고 구조화 된 정보 검색을 사용합니다. 구조적 정보 검색에서 버그 보고서의 각 필드와 소스 코드 파일의 각 부분에 대한 텍스트 내용은 별도로 고려됩니다. 버그 보고서의 각 필드는 소스 코드 파일의 각 부분과 비교되고 유사성 점수는 각 비교에 대해 계산됩니다. 이 점수의 합계는 소스 코드 파일의 순위를 매기는데 사용됩니다. Saha et al. 또한 BLUiR의 확장을 생성합니다. BLUiR +는 유사한 보고서 정보를 BLUiR에 통합합니다. BugLocator는 SimScore와 rVSMScore를 통합합니다.

9 Introduction (AmaLgam)
1. Our approach uses a well-tested bug prediction formula that is used in Google and it takes into consideration the effect of change burst. 2. Sisman and Kak consider the complete version history to compute a probability. Our approach only considers very recent version history and totally discards histor- ical information that are more than k days away from the time a new bug report is submitted. 3. Sisman and Kak simply sums up the probability of a file to be buggy and the similarity of a bug report to the file. Our approach assigns weights that govern the contribution of the probability of a file to be buggy (computed by the bug prediction technique) and the similarity of a bug report to a file (computed by integrating BugLocator and BLUiR). 1. 우리의 접근 방식은 Google에서 사용되는 잘 테스트 된 버그 예측 공식을 사용하며 변경 버스트의 영향을 고려합니다. 2. Sisman과 Kak은 확률을 계산하기 위해 전체 버전 기록을 고려합니다. 우리의 접근 방식은 최신 버전 기록만을 고려하고 새로운 버그 보고서가 제출 된 시점으로부터 k 일 이상 떨어진 역사적인 정보를 완전히 버립니다. 3. Sisman과 Kak은 버그가있는 파일의 확률과 파일에 대한 버그 보고서의 유사성을 간단히 요약합니다. 우리의 접근 방식은 버그 예측 기법으로 계산 된 파일의 버그 확률 및 버그 보고서와 BugLocator 및 BLUiR 통합으로 계산 된 유사성을 결정하는 가중치를 할당합니다.

10 Introduction (AmaLgam)

11 Introduction (AmaLgam)
- Comparing our approach’s MAP scores to those of Saha et al.’s, on average, we can improve their approach’s MAP score by 12.5%. (BLUiR) - Comparing our approach’s MAP scores to those of Zhou et al.’s, on average, we can improve their approach’s MAP score by 24.4%. (Bug Locator) - Comparing our approach’s MAP scores to those of Sisman and Kak’s, we can improve their approach’s MAP score on the AspectJ bug reports by 46.1%. (TFIDF-DHbPd)

12 Preliminaries and Example
.사전 준비, 예제

13 Bug Reports - A bug report is a document submitted by users to describe an error that they experience when they use a system. - A bug report contains a number of fields; we are particularly interested on 4 of them, namely bug identifier (id), the date a bug report was submitted (open date), summary of the error (summary), and more detailed description of the error (description). - The bug id provides a reference number that can be used to identify commits in version control systems that fix it. - The open date helps us to identify bug reports that are submitted a number of days prior to bug. - The summary and description fields help us to understand the error that the user experienced. 버그 보고서는 사용자가 시스템을 사용할 때 발생하는 오류를 설명하기 위해 제출 된 문서입니다. 버그 보고서에는 많은 필드가 있습니다. 우리는 특히 버그 식별자 (id), 버그 보고서가 제출 된 날짜 (열린 날짜), 오류 요약 (요약) 및 오류에 대한 자세한 설명 (설명) 중 4 개에 특히 관심이 있습니다. 버그 ID는 그것을 수정하는 버전 제어 시스템에서 커밋을 식별하는 데 사용할 수있는 참조 번호를 제공합니다 공개 날짜는 버그 이전에 제출 된 버그 보고서를 식별하는 데 도움이됩니다. 요약 및 설명 입력란은 사용자가 경험 한 오류를 이해하는 데 도움이됩니다.

14 Bug Reports

15 Text Pre-Processing - First, text normalization would be performed which involves the removal of punctuation marks, tokenization (i.e., extraction of words from paragraphs or identifiers from source code), and identifier splitting. - Second, we remove stopwords such as “on”, “the”, “are”, “is”, and so on. These stopwords carry little meaning and thus we remove them. - Finally, we perform stemming which reduces inflected or derived words into a common root form. 첫째, 문장 부호의 제거, 토큰 화 (즉, 소스 코드로부터의 단락 또는 식별자로부터의 단어 추출) 및 식별자 분할을 포함하는 텍스트 정규화가 수행 될 것이다. 둘째, "on", "the", "are", "is"등과 같은 불용어를 제거합니다. 이러한 불용어는 의미가 거의 없으므로이를 제거합니다. 마지막으로 우리는 변형되거나 파생 된 단어를 공통 루트 형태로 줄이는 형태소 분석을 수행합니다.

16 Version History - There are lots of historical data of changes to source code files that are stored in a version control system during program evolution. - This historical data can be used to improve bug localization performance. - Kim et al. found that bugs happen in bursts, and not in isolation. - The files responsible for a bug recently are more likely to be responsible for other bugs in the near future. 프로그램이 진화하는 동안 버전 제어 시스템에 저장된 소스 코드 파일의 변경 사항에 대한 많은 기록 데이터가 있습니다. 이 기록 데이터는 버그 지역화 성능을 향상시키는 데 사용될 수 있습니다. Kim et al. 버그가 폭발적으로 발생하고 고립되지 않는 것으로 나타났습니다 [15]. 버그에 책임이있는 파일은 가까운 장래에 다른 버그에 책임이 있습니다

17 Version History

18 Similar Reports - User often submit many similar bug reports that correspond to different errors that affect the same buggy program elements. - For example, Figure 3 shows an older report with identifier , which were reported 9 months before bug report - Note that this report shares the common words “ant” and “editor” with bug report 사용자는 종종 동일한 버그가있는 프로그램 요소에 영향을 미치는 여러 가지 오류에 해당하는 많은 유사한 버그 보고서를 제출합니다. 예를 들어, 그림 3은 버그 리포트 이전 9 개월 전에보고 된 식별자 의 이전 보고서를 보여줍니다. 이 보고서는 버그 리포트 76138과 함께 일반적인 단어 "ant"와 "editor"를 공유합니다.

19 Structure - Bug reports and source code files have structures.
- Bug reports have several fields including summary and description. - Source code files can be split into class names, method names, variable names, and comments. - This structural information can be leveraged for bug localization. - Traditional IR-based bug localization approaches compute the similarity between a bug report and the entire content of a source code file (which contains a class name, many variable names, and many comments). 버그보고와 소스 코드 파일에는 구조가 있습니다. 버그 보고서에는 요약 및 설명을 포함한 여러 필드가 있습니다. 소스 코드 파일은 클래스 이름, 메소드 이름, 변수 이름 및 주석으로 나눌 수 있습니다. 이 구조 정보는 버그 지역화를 위해 활용 될 수 있습니다. 전통적인 IR 기반 버그 지역화 접근법은 버그 보고서와 소스 코드 파일의 전체 내용 (클래스 이름, 많은 변수 이름 및 많은 의견이 포함되어 있음) 간의 유사성을 계산합니다. - BLUiR (Saha et al. 의 논문에서 제안한 소스파일의 정보를 구조화 하는 방법) 에서는 소스파일을 Class, Method, Variable, Comments 4개의 문서로 분리하고 Bug Report를 Summary 와 Description의 두개의 쿼리로 구분함

20 Approach .사전 준비, 예제

21 Approach

22 Approach (BLIA)

23 Version History Component
The commit log must match the following regular expression regex: (. * fix. *) | (. * bug. *) This regular expression species that all commit logs containing the word “fix” or “bug” would be matched. R 은 연관 커밋, 즉 k 일 동안의 커밋의 집함 K는 커밋을 가져올 일 수 f가 대상 소스 파일 그림 1의 입력 버그 보고서와 그림 2의 두 커밋 로그를 생각해보십시오. 간략하게하기 위해 다른 커밋 로그가 없다고 가정 해 봅시다. 방정식 1을 사용하여 AntEditor.java 및 AntEdi- torSourceViewerConfiguration.java 파일의 의심스러운 점수를 계산하는 방법을 설명하고자합니다. 과 3d1a68b 식별자를 가진 커밋은 모두 "bug"라는 단어를 포함하고 있으며, 버그 리포트 76138이 제출 된 (즉, 2004 년 10 월 12 일 21:53:00) 시간보다 15 일 이내에 커밋된다면 관련 버그로 간주됩니다 고쳐 커밋. 커밋 에 대한 (k-tc) / k의 값은 0.95입니다 (버그 리포트 76138이 제출되기 전에 커밋이 약 17 시간, 즉 0.7 일이 경과했기 때문에). 따라서 AntEditor.java의 의심 점수는 1.82입니다. AntEditorSourceViewerConfiguration.java의 의심스런 점수는 비슷한 방식으로 계산할 수 있으며 0.009입니다.

24 Similar Report Component
Similar Report Component analyzes the similarity between the new bug report and fixed reports. It calculates the similarity score of fixed previous bug reports. B is the set of fixed bug reports before new bug report. b is new bug report. b’ is the fixed bug report in B. b’.fix represents the fixed files of b’. B는 기존에 보고되어 수정된 Bug Report와 새로 보고된 Bug Report이며 b’은 B에서 기존에 보고되어 수정된 Bug Report이며 b’. fix 는 b’의 수정된 소스 파일임 특정 문서 내에서 단어 빈도가 높을 수록, 그리고 전체 문서들 중 그 단어를 포함한 문서가 적을 수록 TF-IDF값이 높아진다. 따라서 이 값을 이용하면 모든 문서에 흔하게 나타나는 단어를 걸러내는 효과를 얻을 수 있다.

25 Structure Component BLUiR breaks a bug report into 2 parts: summary and description. It breaks a source code file into 4 parts: class names, method names, variable names, and comments. The suspiciousness score of a source code file f given an input bug report b can then be computed as: BLUiR은 버그 보고서를 요약 및 설명의 두 부분으로 나눕니다. 소스 코드 파일을 클래스 이름, 메소드 이름, 변수 이름 및 설명의 네 부분으로 나눕니다. 입력 버그 리포트 b가 주어진 소스 코드 파일 f의 의심스런 점수는 다음과 같이 계산 될 수 있습니다 : - 𝑓 𝑝 는 소스 파일의 구조화된 정보를 나타내는 벡터, 𝑏 𝑝 는 Bug Report의 필드를 나타내는 벡터 f는 소스파일, b는 버그 리포트

26 Composer Component 𝑆𝑢𝑠𝑝 𝑆 = Structure Component Score 𝑆𝑢𝑠𝑝 𝑅 = Similar Report Component Score 𝑆𝑢𝑠𝑝 𝐻 = Version History Component Score S = 구조 정보 R = 시밀리러티 H = 버전 히스토리 a, b는 임의의 값

27 Experiments .사전 준비, 예제

28 Dataset R 은 연관 커밋, 즉 k 일 동안의 커밋의 집함 K는 커밋을 가져올 일 수 f가 대상 소스 파일
그림 1의 입력 버그 보고서와 그림 2의 두 커밋 로그를 생각해보십시오. 간략하게하기 위해 다른 커밋 로그가 없다고 가정 해 봅시다. 방정식 1을 사용하여 AntEditor.java 및 AntEdi- torSourceViewerConfiguration.java 파일의 의심스러운 점수를 계산하는 방법을 설명하고자합니다. 과 3d1a68b 식별자를 가진 커밋은 모두 "bug"라는 단어를 포함하고 있으며, 버그 리포트 76138이 제출 된 (즉, 2004 년 10 월 12 일 21:53:00) 시간보다 15 일 이내에 커밋된다면 관련 버그로 간주됩니다 고쳐 커밋. 커밋 에 대한 (k-tc) / k의 값은 0.95입니다 (버그 리포트 76138이 제출되기 전에 커밋이 약 17 시간, 즉 0.7 일이 경과했기 때문에). 따라서 AntEditor.java의 의심 점수는 1.82입니다. AntEditorSourceViewerConfiguration.java의 의심스런 점수는 비슷한 방식으로 계산할 수 있으며 0.009입니다.

29 Evaluation Metrics - Top N Rank - Mean Average Precision (MAP)
- Mean Reciprocal Rank (MRR) - MAP은 IR은 Ranking Approach 에서 가장 일반적으로 사용되는 Metric임 - 순위가 매겨진 모든 파일을 고려하며 모든 쿼리의 평균 밀도값의 평균임 k는 파일의 순위이며 d는 파일의 수. pos(k)는 k 순위의 파일이 버그가 있던 파일인지에 대한 이진값이며 P(k)는 주어진 k순위 내에서 버그 파일이 있는지에 대한 정확도임 P(k) 는 - MRR은 쿼리 집합 Q의 결과에 대한 순위의 평균임

30 Result

31 Result (Compare with BLIA)

32 Conclusion .사전 준비, 예제

33 Conclusion - A large number of bug reports are submitted during the evolution of a software system. - For a large system, locating the source code files responsible for a bug is a tedious and expensive work. - Thus, there is a need to develop a technique that can automatically figure out these buggy files given a bug report. - A number of bug localization tools have been proposed in recent years. - However, the accuracy of these tools still need to be improved. 많은 버그 리포트가 소프트웨어 시스템의 발전 중에 제출됩니다. 대형 시스템의 경우, 버그의 원인이되는 소스 코드 파일을 찾는 것이 지루하고 값 비싼 작업입니다. 따라서 버그 리포트가 주어진다면이 버그가있는 파일을 자동으로 찾아 낼 수있는 기술을 개발할 필요가 있습니다. 최근 여러 가지 버그 지역화 도구가 제안되었습니다. 그러나 이러한 도구의 정확성을 향상시킬 필요가 있습니다.

34 Conclusion - Compared with the state-of-the-art bug localization approaches, BLUiR+ and BLUiR, our approach, on average, achieves 12.5% and 16.4% improvements in terms of mean average precision (MAP). - Compared with BugLocator which considers similar reports, our approach, on average, achieves a 24.4% improvement in terms of MAP. - Compared with a history-aware bug localization approach proposed by Sisman and Kak, our approach achieves a 46.1% improvement in terms of MAP. - In the future, we would like to reduce the threats to external validity further by applying our approach on more bug reports from various systems. 최첨단 버그 로컬라이제이션 접근 방식 인 BLUiR + 및 BLUiR과 비교할 때 우리의 접근 방식은 평균 평균 정밀도 (MAP)가 평균 12.5 % 및 16.4 % 향상되었습니다. 유사한 보고서를 고려한 BugLocator와 비교할 때, 우리의 접근 방식은 평균적으로 MAP 측면에서 24.4 %의 향상을 달성합니다. Sisman과 Kak이 제안한 히스토리 인식 버그 지역화 접근법과 비교할 때 MAP 접근 방식은 46.1 % 향상되었습니다. 앞으로는 다양한 시스템의 버그 리포트에 대한 접근 방식을 적용하여 외부 유효성에 대한 위협을 더욱 줄이고 자합니다.