Bài toán định vị lỗi phần mềm ra đời nhắm giúp các lập trình viên tiết kiệm thời gian và công sức trong việc xác định nơi nào để bắt đầu bắt tay vào sửa lỗi. Bài toán giống như một hệ thống gợi ý đưa ra các đề xuất tệp mã nguồn có liên quan nhất với báo cáo lỗi cho lập trình viên, qua đó làm giảm không gian tìm kiếm và tiết kiệm thời gian cho những người lập trình. Nhưng để bài toán được đưa vào ứng dụng thực tế, những yếu tố như tính ổn định và sự tin cậy được các nhà phát triển quan tâm. Điều này đặt ra việc những mô hình giải quyết bài toán phải đạt được độ chính xác cao và có tính ổn định qua những lần dự đoán. Mô hình SVMBugRanking là một mô hình kế thừa Learn to rank, nhưng khắc phục nhược điểm về sự mất cân bằng trong tập dữ liệu đào tạo bằng cách thay đổi mẫu. Có hai chiến lược được đề xuất đó là lấy mẫu dưới hoặc đồng thời kết hợp giữa việc tạo dữ liệu giả và lấy mẫu dưới. Đối với những dự án có số lượng báo cáo lỗi đủ tốt thì việc tạo dữ liệu giả cho lớp thiểu số có thể làm tăng số lượng điểm nhiễu đáng kể, từ đó làm giảm hiệu suất phân loại của SVM. Nên sự kết hợp cả hai chiến lược là điều cần thiết. Kết quả của từng chiến lược đều cho kết quả tốt hơn mô hình SVMBugRanking khi chưa cải thiện trên cả ba độ đo topk@accuracy, MRR và MAP.
Giới thiệu đề tài
Đặt vấn đề
Trong quá trình phát triển phần mềm, kiểm thử, sửa lỗi và bảo trì phần mềm chiếm hơn 50% thời gian của dự án Để tăng hiệu quả của công việc, các tác vụ khác nhau trong quá trình phát triển dự án phần mềm sẽ được quản lý bằng các công cụ đặc biệt, ví dụ quản lý mã nguồn bằng các công cụ quản lý phiên bản (Version Control System), quản lý lỗi sử dụng các hệ thống theo dõi lỗi (Bug Tracking System) Các Bug Tracking System như Jira, Bugzilla, cho phép quản lý và theo vết quá trình sửa các lỗi trong hệ thống cũng như các tệp mã nguồn có liên quan và đã được cập nhật thay đổi để sửa các lỗi đó Khi có một lỗi (bug) xảy ra, người phát hiện lỗi sẽ thông báo lỗi trên hệ thống bao gồm các mô tả về lỗi, ngữ cảnh xảy ra, các thông tin cụ thể để có thể tái tạo lại lỗi trên hệ thống Khi lỗi được xác nhận (confirmed), một hoặc một vài kỹ sư phát triển sẽ được chỉ định để sửa lỗi Qúa trình sửa lỗi đó bao gồm công việc phải xác định được các tệp (file) mã nguồn có liên quan để tiến hành sửa lỗi Khi lỗi đã được sửa, các file mã nguồn liên quan sẽ được hệ thống Bug Tracking System ghi nhận cùng với các commit tương ứng mà kỹ sư phát triển đã tạo ra để ghi nhận vết của lỗi Quá trình định vị các file mã nguồn có liên quan đến lỗi được gọi là bug localization Bug localization là một tác vụ phức tạp, đòi hỏi rất nhiều công sức của con người và không hề dễ dàng nhất là khi dự án phần mềm chứa hàng nghìn file mã nguồn từ đó làm nảy sinh nhu cầu cấp thiết cho vấn đề định vị lỗi phần mềm tự động Đối với bài toán định vị lỗi phần mềm tự động, việc xác định một cách chính xác các file mã nguồn có lỗi là một việc vô cùng khó khăn Do đó, các nghiên cứu hiện tại về định vị lỗi phần mềm chỉ dừng lại ở bước gợi ý các file mã nguồn có thể liên quan đến bug Bug Localization do đó có thể được xem xét như một bài toán phân loại, ứng với mỗi bug report, các file mã nguồn sẽ được phân vào hai nhóm (i) có liên quan đến bug và (ii) không có liên quan đến bug Để giải quyết cho bài toán phân loại nói trên, các nghiên cứu tập trung vào trích xuất các mối liên quan giữa bug report và các source files Các source files nào có mối liên quan nhiều nhất sẽ được phân vào nhóm có liên quan đến bug Vấn đề trích xuất thông tin để xác định các mối liên quan trong các văn bản (text document) được nghiên cứu từ rất lâu và đã
Chương 1 Giới thiệu đề tài
2 có rất nhiều thành tựu Tuy nhiên thách thức lớn nhất đối với bài toán định vị lỗi phần mềm đến từ sự khác biệt về mặt ngôn ngữ giữa bug report và source file Cụ thể, các bug report thì thường được mô tả bằng ngôn ngữ tự nhiên trong khi các source file lại được viết bằng ngôn ngữ lập trình Sự khác biệt về mặt ngữ nghĩa và từ vựng giữa hai loại ngôn ngữ dẫn tới việc xác định mối liên quan trở nên khó khăn và có kết quả không cao
Thách thức tiếp theo đối với bài toán phân loại trong bug localization đến từ sự mất cân bằng dữ liệu giữa hai nhóm (i) có liên quan đến bug và (ii) không liên quan đến bug Đối với một bug report, số lượng source file có liên quan đến bug ít hơn rất rất nhiều so với các source file không liên quan đến bug Độ chính xác của mô hình phân loại phụ thuộc rất nhiều vào sự cân bằng giữa các nhóm vì khi mất cân bằng, mô hình phân loại sẽ có xu hướng dự đoán vào nhóm có dữ liệu lớn (majority class) hơn là vào nhóm có dữ liệu ít (minority class) Các vấn đề này đến nay vẫn là thách thức lớn của bài toán bug localization.
Các giải pháp hiện tại và hạn chế
Các nghiên cứu hiện nay tiếp cận giải quyết bài toán bug localization theo hai hướng (i) học máy có giám sát và (ii) học máy không giám sát Đối với hướng tiếp cận học máy không giám sát, mô hình sẽ tính điểm số (score) cho mức độ liên quan giữa mỗi báo cáo lỗi và với tệp mã nguồn để đưa ra phân loại tệp nằm đâu trong hai cụm: có liên quan đến lỗi hoặc không liên quan đến lỗi Tệp có điểm số cao sẽ thuộc về nhóm “có liên quan đến lỗi” và các tệp còn lại thuộc nhóm “không liên quan đến lỗi” Đối với hướng tiếp cận học máy có giám sát, một mô hình huấn luyện được xây dựng với đầu vào dữ liệu là các cặp bug-source được gán nhãn (“có liên quan”-1 và “không liên quan”-0) Mô hình được huấn luyện xong sẽ được dùng để dự đoán đối với 1 bug mới, những file mã nguồn nào có liên quan So với cách tiếp cận học ko giám sát, các mô hình học có giám sát phức tạp hơn rất nhiều và đòi hỏi quá trình huấn luyện với dữ liệu gán nhãn trước nhưng bù lại kết quả của các mô hình học giám sát thường cao hơn
Trong khuôn khổ đồ án của mình, em tập trung vào hướng thứ 2, tìm hiểu các mô hình học giám sát để giải quyết bài toán định vị lỗi phần mềm Các nghiên cứu hiện tại áp dụng các mô hình mạng nơ-ron hoặc các thuật toán học máy như Learn-2-Rank, Support Vector Machine – SVM,… Hai vấn đề chính được tập trung giải quyết trong hướng nghiên cứu này (1) Trích xuất đặc trưng để có thể phát hiện được các mối liên quan tiềm ẩn giữa bug và source khi ngôn ngữ biểu diễn hai đối tượng này có sự khác biệt khá lớn, (2) Cải tiến độ chính xác của các mô hình bằng cách giải quyết vấn đề mất cân bằng dữ liệu Đối với vấn đề thứ nhất, các đặc trưng hiện nay được đề xuất được xếp loại vào 3 nhóm: (i) đặc trưng từ vựng (lexical feature) (ii) đặc trưng ngữ nghĩa (semantic feature) (iii) đặc trưng về domain
3 liên quan đến tần suất lỗi, lịch sử sửa lỗi… Cách kết hợp các đặc trưng thì dựa trên hai hướng (i) kết hợp tuyến tính và (ii) kết hợp phi tuyến Các nghiên cứu hiện nay tập trung vào đề xuất các mô hình để có thể kết hợp tốt nhất các đặc trưng này nhằm phát hiện rõ hơn mối liên quan tiềm ẩn giữa bug và source Tuy nhiên việc kết hợp các đặc trưng vẫn là một vấn đề cần phải giải quyết để có thể trích xuất tốt hơn mối quan hệ giữa bug và source Đối với vấn đề thứ hai, chưa có nhiều nghiên cứu hiện tại xử lý vấn đề mất cân bằng dữ liệu cho bài toán định vị lỗi phần mềm, tuy nhiên giải pháp chung để giải quyết vấn đề này có thể được chia thành 2 hướng: (i) Xử lý mẫu (sampling) để thay đổi sự mất cân bằng dữ liệu mẫu (ii) Áp dụng thêm các thuật toán học tăng cường hoặc thay đổi kiến trúc mô hình để có thể đưa thêm trong số nhằm định hướng lại mô hình khi phân loại
Nghiên cứu của em tập trung vào hướng thứ nhất trong xử lý mất cân bằng dữ liệu và đề xuất mô hình kết hợp tuyến tính các đặc trưng của bug-source Chi tiết về giải pháp được giới thiệu trong phần tiếp theo.
Mục tiêu và định hướng giải pháp
Từ các vấn đề về hiện trạng và hạn chế đã được giới thiệu ở trên, trong đồ án này của mình em tập trung vào đề xuất mô hình học máy giám sát để định vị lỗi phần mềm, trong đó xử lý vấn đề mất cân bằng dữ liệu thông qua xử lý mẫu với hai giải pháp (1) undersampling và (2) oversampling
Cụ thể, giải thuật học máy đề xuất là Support Vector Machine cho phép xây dựng mô hình phân loại source cho các bug với các đặc trưng đề xuất sử dụng thuộc cả 3 nhóm đã đề cập trong phần trước: (1) Độ tương đồng từ vựng (2) Độ tương đồng ngữ nghĩa (3) Các đặc trưng về tần suất sửa lỗi, độ tương quan giữa các bug Trên thực tế việc lựa chọn các đặc trưng đóng vai trò khá quan trọng trong các bài toán phân loại, các nghiên cứu liên quan xử lý đặc trưng riêng lẻ với các đề xuất khác nhau Trong đồ án này của mình em kết hợp các đặc trưng được đề xuất này và sử dụng mô hình SVM để huấn luyện sự kết hợp giữa các đặc trưng Đối với vấn đề mất cân bằng dữ liệu, trong nghiên cứu của mình em kết hợp mô hình SVM đã đề xuất với hai kỹ thuật xử lý mẫu là undersampling và oversampling và đánh giá sự hiệu quả của hai kỹ thuật này đối với bài toán định vị lỗi phần mềm.
Đóng góp của đồ án
Đồ án tốt nghiệp có 3 đóng góp chính như sau:
1 Đề xuất xây dựng mô hình SVM và triển khai mô hình cho bài toán định vị lỗi phần mềm trong đó kết hợp nhiều nhóm đặc trưng với nhau để có thể trích xuất hiệu quả mối tương quan của các cặp bug-source
2 Đánh giá vai trò và mức độ tác động của các đặc trưng và các nhóm đặc trưng đối với hiệu năng của mô hình
3 Đề xuất chiến lược giải quyết vấn đề mất cân bằng dữ liệu trong bài toán phân loại dựa trên việc thay đổi mẫu.
Bố cục đồ án
Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau
Chương 2 em trình bày về những nghiên cứu liên quan trong việc giải quyết bài toán định vị lỗi phần mềm Trong chương này em sẽ tập trung vào hai hướng tiếp cận chính: áp dụng mô hình học máy có giám sát và mô hình học máy không giám sát Ngoài ra, em trình bày những nghiên cứu liên quan đến những nghiên cứu liên quan đến làm giảm mất cân bằng dữ liệu trong các bài toán phân loại
Chương 3 em trình bày các kiến thức cơ sở của mô hình, các đặc trưng trích xuất được giữa bug và source
Chương 4 trình bày giải pháp đề xuất về mô hình SVM và việc xử lý mất cân bằng dữ liệu Chương 5 trình bày các thực nghiệm để đánh giá giải pháp đề xuất
Chương 6 đưa ra những kết luận về mô hình SVMBugRanking và sau đó trình bày về tương lai của bài toán định vị lỗi phần mềm
Trong chương này, em sẽ trình bày về hai hướng nghiên cứu liên quan trong bài toán định vị lỗi phần mềm, áp dụng mô hình học không giám sát và mô hình học có giám sát
2.1 Nhóm nghiên cứu liên quan áp dụng mô hình học không giám sát
Nhóm tác giả Jian Zhou và cộng sự [11] đã đề xuất mô hình Bug Locator, một phương pháp dựa trên việc trích xuất thông tin để xác định đâu là tệp có liên quan đến báo cáo lỗi cần phải sửa Bug Locator xếp hạng các tệp mã nguồn dựa trên độ tương đồng về mặt từ ngữ giữa báo cáo lỗi và tệp nguồn, sử dụng revised Vector Space Model (rVSM) và những báo cáo lỗi đã được sửa trong quá khứ Bug Locator tính toán và tổng hợp 2 ranking scores: rVSM và Simiscore Đầu tiên, để tối ưu lại mô hình cổ điển Vector Space Model, rVsm chú trọng đến độ dài của tài liệu Nếu một tệp có kích thước càng lớn thì sẽ tổn tại nhiều rủi ro hơn, chứa nhiều lỗi hơn các tệp có kích thước nhỏ Mô hình sẽ tính mức độ liên quan giữa truy vấn đó với toàn bộ tệp nguồn (source files) Mỗi truy vấn và tệp nguồn đều được biểu diễn dưới dạng vector, được thực hiện bởi sự kết hợp giữa việc tính toán 2 đại lượng: tần suất xuất hiện các thuật ngữ (Term Frequency) và tần suất của tài liệu chứa thuật ngữ đó (Inverse Document Frequency) RVSM score được tính bằng cosin giữa 2 vector biểu diễn báo cáo lỗi và tệp thu được
Tiếp đến, Bug Locator tính độ tương đồng cosine giữa báo cáo lỗi S với những báo cáo lỗi đã được sửa trước khi S báo cáo Giả sử một báo cáo lỗi B có sự tương đồng với báo cáo lỗi
S Khi đó, tất cả những tệp nguồn gây ra báo cáo lỗi B hình thành một mối liên kết tới S Đối với mỗi tệp nguồn s, ta thu được danh sách các báo cáo lỗi {𝐵 1 , 𝐵 2 , , 𝐵 𝑛 } có hình
Các nghiên cứu liên quan cho bài toán định vị lỗi
Nhóm nghiên cứu liên quan áp dụng mô hình học không giám sát
Nhóm tác giả Jian Zhou và cộng sự [11] đã đề xuất mô hình Bug Locator, một phương pháp dựa trên việc trích xuất thông tin để xác định đâu là tệp có liên quan đến báo cáo lỗi cần phải sửa Bug Locator xếp hạng các tệp mã nguồn dựa trên độ tương đồng về mặt từ ngữ giữa báo cáo lỗi và tệp nguồn, sử dụng revised Vector Space Model (rVSM) và những báo cáo lỗi đã được sửa trong quá khứ Bug Locator tính toán và tổng hợp 2 ranking scores: rVSM và Simiscore Đầu tiên, để tối ưu lại mô hình cổ điển Vector Space Model, rVsm chú trọng đến độ dài của tài liệu Nếu một tệp có kích thước càng lớn thì sẽ tổn tại nhiều rủi ro hơn, chứa nhiều lỗi hơn các tệp có kích thước nhỏ Mô hình sẽ tính mức độ liên quan giữa truy vấn đó với toàn bộ tệp nguồn (source files) Mỗi truy vấn và tệp nguồn đều được biểu diễn dưới dạng vector, được thực hiện bởi sự kết hợp giữa việc tính toán 2 đại lượng: tần suất xuất hiện các thuật ngữ (Term Frequency) và tần suất của tài liệu chứa thuật ngữ đó (Inverse Document Frequency) RVSM score được tính bằng cosin giữa 2 vector biểu diễn báo cáo lỗi và tệp thu được
Tiếp đến, Bug Locator tính độ tương đồng cosine giữa báo cáo lỗi S với những báo cáo lỗi đã được sửa trước khi S báo cáo Giả sử một báo cáo lỗi B có sự tương đồng với báo cáo lỗi
S Khi đó, tất cả những tệp nguồn gây ra báo cáo lỗi B hình thành một mối liên kết tới S Đối với mỗi tệp nguồn s, ta thu được danh sách các báo cáo lỗi {𝐵 1 , 𝐵 2 , , 𝐵 𝑛 } có hình
Chương 2 Các nghiên cứu liên quan cho bài toán định vị lỗi
6 thành liên kết đến S tương tự như B Điểm số tương đồng Simiscore cho báo cáo lỗi S với mỗi tệp nguồn s được tính bằng tổng cosine giữa S với từng báo cáo lỗi 𝐵 𝑖 với 𝑖 = 1 𝑛
Final score sẽ là tổng hợp điểm số của rVsm và Simiscore Từ đó Bug Locator đề xuất danh sách tệp nguồn có điểm số cao nhất, chính là những tệp có khả năng cao gây ra lỗi nhất
Tác giả đã đánh giá hiệu suất của mô hình dựa trên bốn dự án: Eclipse, SWT, AspectJ và Zxing và sử dụng 3 độ đo Top N Rank, Mean Reciprocal Rank (MRR), Mean Average và Precision (MAP) Kết quả thực nghiệm cho thấy Bug Locator cho hiệu suất cao hơn các phương pháp hiện có LDA thực hiện bởi Lukins et al [12], SUM thực hiện bởi Rao và Kak [13], VSM được thực hiện bởi Rao and Kak [13], LSI được thực hiện bởi Poshyvanyk et al [14], [15]
2.1.2 Công trình nghiên cứu của Gharibi và cộng sự
Mô hình tiếp cận của công trình nghiên cứu [19] :
Hình 1 Mô hình đề xuất của Gharibi và cộng sự Đầu tiên là quá trình tiền xử lý Mỗi tệp nguồn sẽ được trích xuất ra những thông tin quan trọng: tên lớp, tên thuộc tính, tên phương thức và khai báo biến Trong khi đó mỗi báo cáo lỗi được trích xuất để có được mô tả, tóm tắt và ngày báo cáo Sau đó, nếu mô tả của báo cáo lỗi có truy vết (stack traces) thì nó sẽ được trích xuất Kết quả thu được lần lượt sẽ được chuẩn hóa để thu được các cụm từ có sự thống nhất cao, giúp nâng cao hiệu suất phân tích sự tương đồng về từ ngữ
Sau giai đoạn tiền xử lý là 5 đặc trưng (component) sẽ tính điểm cho tệp nguồn với mỗi báo cáo lỗi Các đặc trưng gồm có: token matching component, VSM similarity component, stack trace component, semantic similarity component và fixed bug reports component Sau đó, điểm số cuối cùng cho mô hình là một hàm tuyến tính tổng hợp 5 components, mỗi component tương ứng như một biến có trọng số riêng Mục tiêu ở đây là tối ưu tham số (trọng số) sao cho tổng giá trị MRR và MAP đạt giá trị lớn nhất
Bài báo sử dụng thuật toán tiến hóa vi phân (DE) [20] để tối ưu hóa hàm mục tiêu và ước tính các tham số DE là một phương pháp dựa trên quần thể ngẫu nhiên được sử dụng cho bài toán tối ưu hóa toàn cục và có thể tìm kiếm các vùng rộng lớn trong không gian các ứng cử viên Nó cố gắng lặp đi lặp lại để cải thiện kết quả bằng cách trộn chúng với nhau để tạo ra một ứng cử viên thử nghiệm
Bài báo sử dụng tập dữ liệu chuẩn do Zhou và cộng sự cung cấp với ba dự án: AspectJ, SWT, ZXing và sử dụng 3 độ đo chuẩn Top@N, MRR, and MAP Kết quả cho thấy cách tiếp cận của nghiên cứu tốt hơn hẳn những phương pháp hiện thời bao gồm BugLocator (Zhou et al., 2012) [11], BLUiR (Saha et al., 2013) [16], BRTracer (Rahman et al., 2015; Wong et al., 2014) [21], và AmaLgam (Wang & Lo, 2014) [22]
Saha và các cộng sự đề xuất mô hình BLUiR (Improving bug localization using structured information retrieval) [16] giúp tự động định vị lỗi dựa trên việc trích xuất thông tin có cấu trúc Thay vì xây dựng lại từ đầu, tác giả sử dụng một toolkit trích xuất thông tin mã nguồn mở có khả năng tinh chỉnh cao như Indri [17]
A Kiến thức nền tảng về IR:
Ví dụ cơ bản về việc định vị lỗi dựa trên IR đó là việc 1 số thuật ngữ được trích xuất từ báo cáo bug có được tìm thấy trong tệp mã nguồn cần sửa cho lỗi đó hay không Kỹ thuật sẽ tìm thấy các từ phù hợp tồn tại cả trong báo cáo lỗi và một trong tệp mã nguồn tương ứng được sửa cuối cùng cho lỗi đó Từ đó hệ thống có thể đưa ra các dự đoán xếp hạng cho các tệp nguồn cần được sửa
Một hệ thống IR thường bắt đầu với ba bước tiền xử lý: text normalization (việc loại bỏ các dấu câu, thực hiện chuẩn hóa các chữ cái về cùng dạng), stop-word removal (những từ không liên quan, không quan trọng) và stemming (vụ hợp nhất biến thể khác nhau ví dụ như “play”,
Sau khi tiền xử lý xong, các số liệu thống kê khác nhau như: tần suất thuật ngữ (TF, số lần thuật ngữ xuất hiện trong một tài liệu nhất định), tần suất tài liệu (DF, số lượng tài liệu trong đó thuật ngữ xuất hiện), IDF (tần suất xuất hiện tài liệu chứa thuật ngữ đó) được thu thập
Từ đó chúng ta thu được TF-IDF, một thống kê phản ánh tầm quan trọng một từ đối với một văn bản trong một tập hợp văn bản
B Cách tiếp cận mô hình
Kiến trúc mô hình BLUiR
Hình 2: Mô hình BLUiR Đầu tiên, đầu vào là mã nguồn của các báo cáo lỗi tương ứng Sau đó cây cú pháp trừu tượng (AST) được khởi tạo cho mỗi tệp mã nguồn sử dụng công cụ JDT, trích xuất được các thông tin: tên lớp, tên phương thức, tên biến và các chú thích Tất cả thông tin thu được sẽ được tokenize và lưu dưới dạng cấu trúc XML Và chúng cũng được loại bỏ stopword, stemming và đánh chỉ mục
Mỗi báo cáo lỗi tương tự cũng được tokenize, sau đó loại bỏ stopword, stemming và trích xuất thông tin
C Mô hình trích xuất thông tin
Nhóm nghiên cứu liên quan áp dụng mô hình học có giám sát
Bài báo đề xuất mô hình BugScout [1] một cách tiếp cận tự động giúp các nhà phát triển dễ dàng trong việc định vị lỗi bằng cách thu hẹp không gian tìm kiếm các tệp lỗi Mô hình xây dựng các kỹ thuật dưới dạng chủ đề trong nội dung văn bản của báo cáo lỗi và tập nguồn,
10 đồng thời so sánh báo cáo lỗi và tệp lỗi tương ứng thông qua các chủ đề được chia sẻ BugScout có thể đề xuất các tệp lỗi một cách chính xác lên đến 45% các trường hợp với top10 ranking
Trong số các loại thực thể khác trong hệ thống, BugScout sử dụng đến hai loại thực thể: tệp nguồn và báo cáo lỗi Mô hình BugScout có hai thành phần cho hai loại đó: Thành phần S cho các tệp nguồn và Thành phần B cho các báo cáo lỗi
Thành phần S trong BugScout là một mô hình LDA (Latent Dirichlet Allocation) [2] Mỗi tệp nguồn thì được coi là một tài liệu s Nội dung từ chú thích (comments) và định danh (identifiers) được trích xuất để tạo thành các từ có trong tài liệu s
Topic Vector Một tài liệu s có 𝑁 𝑠 từ Mỗi từ trong 𝑁 𝑠 được coi là miêu tả một chủ đề kỹ thuật cụ thể Cho nên chúng ta có vector chủ đề 𝑧 𝑠 với độ dài 𝑁 𝑠
Topic Proportion Để thể hiện tầm quan trọng của nhiều chủ đề trong tài liệu 𝜃 𝑠 là một vector có k phần tử tương ứng với k chủ đề có trong tài liệu s, giá trị mỗi phần đại diện cho tỷ lệ chủ đề tương ứng trong s
Vocabulary and Word Selection Vocabulary là tập hợp các từ có trong dự án, được gọi là
𝑉 𝑜𝑐 𝑣ớ𝑖 kích thước là 𝑉 Mỗi từ trong 𝑉 𝑜𝑐 có tần suất xử dụng khác nhau để mô tả một chủ đề k và một chủ đề có thể chứa một hoặc nhiều từ Mỗi chủ đề k sẽ có tương ứng một vector chọn từ (vector word-selection) 𝜙 𝑘 , kích thức 𝑉 Mỗi phần tử đại diện cho tần suất sử dụng của từ trong V oc để mô tả chủ đề k Ví dụ, đối với chủ đề k, 𝜙 𝑘 = [0,3, 0,2, 0,4, ] Nghĩa là, trong 30% trường hợp, từ đầu tiên trong V oc được sử dụng để mô tả chủ đề k,
20% trường hợp từ thứ hai được sử dụng để mô tả k Đối với một hệ thống phần mềm, mỗi chủ đề k có vectơ riêng 𝜙 𝑘 thì k chủ đề có thể được biểu diễn bằng ma trận K × V 𝜙 𝑠𝑟𝑐 , được gọi là phân phối từ theo chủ đề
Thành phần B cũng được mở rộng từ LDA [2] Tương tự như thành phần S, thành phần B cũng coi mỗi báo cáo lỗi b là một tài liệu với ba biến 𝑧 𝑏 , 𝜃 𝑏 , 𝜙 𝐵𝑅 Chú ý rằng 𝜙 𝐵𝑅 áp dụng cho tất cả các báo cáo lỗi và nó khác với 𝜙 𝑠𝑟𝑐 Báo cáo lỗi b không chỉ bị ảnh hưởng bởi phân phối chủ đề của chính nó mà còn bởi các tham số phân phối chủ đề của các tệp nguồn lỗi tương ứng với báo cáo lỗi đó
Ví dụ 𝑠 1 , 𝑠 2 , , 𝑠 𝑀 để biểu thị các tệp nguồn (lỗi) có liên quan đến một báo cáo lỗi b Ta có: 𝜃 𝑏 ∗ = 𝜃 𝑠1 𝜃 𝑠2 𝜃 𝑠𝑀 𝜃 𝑏 Phương trình trên đại diện cho việc chia sẻ các chủ đề lỗi trong báo cáo lỗi và các tệp nguồn tương ứng
Thành phần S và thành phần B được kết hợp thành BugScout Đối với báo cáo lỗi b, trong mặt thành phần B, có 3 biến của b: 𝑧 𝑏 , 𝜃 𝑏 , 𝜙 𝐵𝑅
Tuy nhiên, nếu các tệp nguồn 𝑠 1 , 𝑠 2 , , 𝑠 𝑀 được xác định là gây ra lỗi được báo cáo trong báo cáo lỗi b, vectơ chủ đề 𝑧 𝑏 sẽ bị ảnh hưởng bởi tỷ lệ chủ đề của các tệp nguồn đó Tức là có các liên kết từ 𝜃 𝑠1 , 𝜃 𝑠2 , , 𝜃 𝑠𝑀 đến 𝑧 𝑏 Đối với mỗi tài liệu nguồn, có 3 biến: 𝑧 𝑠 , 𝜃 𝑠 , 𝜙 𝑠𝑟𝑐
𝛼 𝑣à 𝛽 là hai tham số được giả đinh như trong LDA
Dữ liệu bao gồm tệp nguồn, báo cáo lỗi và liên kết giữa báo cáo lỗi và tệp nguồn tương ứng sẽ được cho vào đào tạo Các biến của BugScout sẽ được đào tạo để lấy các tham số sao làm cho mô hình phù hợp nhất với tập dữ liệu đầu vào Để dự đoán, mô hình sẽ được áp dụng cho một báo cáo lỗi mới qua các tham số được đào tạo từ trước Từ đó ước tính tỷ lệ chủ đề mới 𝜃 𝑏 𝑛𝑒𝑤 Tỷ lệ chủ đề này được dùng để tìm các
12 tệp nguồn tương ứng mà chia sẻ cùng chủ đề nhiều nhất Chủ đề của báo cáo lỗi đó được so sánh với các chủ đề từ tất cả tệp nguồn, các tệp đã chia sẻ chủ đề với báo cáo lỗi mới sẽ được xếp hạng và đề xuất cho nhà phát triển
Mục tiêu của thuật toán là ước lượng những tham số của BugScout trong việc đào tạo dữ liệu Thuật toán được dựa trên phương pháp Gibbs sampling [3] Sau đây là các bước chi tiết:
Bước 1: Ước tính việc phân phối chủ đề cho các tài liệu nguồn trong S
Với mỗi tài liệu s trong S, BugScout ước tính 𝑧 𝑠 [𝑖] cho vị trí i
Bước 2: Ước tính tỷ lệ chủ đề 𝜃 𝑠 cho một tệp nguồn
Tỷ lệ chủ đề 𝜃 𝑠 [𝑘] của chủ đề k trong tài liệu đó có thể được tính gần đúng bằng cách chỉ cần tính tỷ lệ giữa số lượng từ mô tả chủ đề k và độ dài của tài liệu
Bước 3: Ước tính phân phối từ 𝜙 𝑠𝑟𝑐
Nhóm nghiên cứu liên quan đến xử lý mất cân bằng dữ liệu đối với các mô hình phân loại 15
Imam và cộng sự đề xuất một chiến lược [23] giúp làm giảm sự mất cân bằng dữ liệu bằng cách tự động điều chỉnh mặt siêu phẳng và giảm độ lệch về lớp thiểu số
Vector trọng số được học trong SVM:
𝑤 = ∑ 𝛼 𝑝 𝛾 𝑝 ∅(𝑥 𝑝 ) + 𝛼 𝑛 𝛾 𝑛 ∅(𝑥 𝑛 ) Công thức 1 Vector trọng số trong SVM Hàm quyết định phân loại:
Công thức 2 Hàm decision function trong SVM
Từ đó Imam và cộng sự đề xuất thêm tham số z Để làm giảm độ lệch của SVM được đào tạo với lớp đa số cho dữ liệu không cân bằng, bài báo giới thiệu trọng số nhân, z, được liên kết với mỗi vectơ hỗ trợ lớp dương
Công thức 3 Hàm cải tiến tham số z-SVM Điều chỉnh giá trị của tham số z để thay đổi siêu phẳng sao cho Gmean đạt cực đại với dữ liệu đào tạo Sở dĩ dùng Gmean vì độ đo này trừng phạt nặng với sự nhận biết sai các class thiểu số, từ đó cải thiện tính mất cân bằng dữ liệu
Tham số z được tìm bằng cách tăng z từ từ xuất phát từ 0 đến một giá trị M Sau đó mô hình SVM mới được sử dụng để phân loại dữ liệu Nếu z = 0 thì phân loại thuộc lớp âm, z = M phân loại thuộc lớp dương Giá trị Gmean sẽ tăng từ 0 đến một giá trị cực trị rồi rơi giảm về
0 Từ đó ta tìm được cực trị z* là giá trị z cần tìm
2.3.2 Chiến lược lấy mẫu dưới quá mức GSVM-RU
Tang và cộng sự đề xuất một chiến lược Lỗi! Không tìm thấy nguồn tham chiếu lấy mẫu dưới dựa trên mô hình SVM
Cách tiếp cận: GSVM-RU có thể cải thiện hiệu suất phân loại bằng cách sau:
1) trích xuất các mẫu thông tin cần thiết để phân loại
2) loại bỏ một lượng lớn các mẫu dư thừa, hoặc thậm chí nhiễu
- Tính toán dạng hạt thể hiện thông tin dưới dạng một số tập hợp (được gọi là hạt thông tin) như tập hợp con
- Có 2 nguyên tắc trong tính toán dạng hạt Nguyên tắc đầu tiên là chia để trị, nghĩa là một tập dữ liệu lớn được chia nhỏ thành tập hợp các tập dữ liệu nhỏ Mỗi tập dữ liệu nhỏ được coi là một hạt Tiếp theo, hạt đó sẽ được xác định kích thước phù hợp bằng cách làm sạch dữ liệu, loại bỏ đi những thông tin không cần thiết mà không ảnh hưởng đến tính chất của hạt thông tin
- Mô hình học dựa trên tính toánh chuỗi hạt được hình thành nhờ việc sử dụng thông tin hoặc những giả định trước đó vào quá trình tạo hạt cho model dữ liệu
- GSVM trích xuất một chuỗi các hạt thông tin, với sự phân chia hạt và / hoặc thu nhỏ, sau đó xây dựng SVM trên một số hạt này nếu cần
Mô hình thuật toán GSVM-RU đề xuất:
Hình 5: Mô hình thuật toán GSVM-RU Đầu tiên, giả định rằng tất cả các mẫu dương tính đều là thông tin để tạo thành một hạt thông tin tích cực Các mẫu âm tính được trích xuất bởi SVM dưới dạng SVs cũng có thể có nhiều
18 thông tin để tạo thành một hạt thông tin tiêu cực, gọi là (NLSV) Sau đó, những NLSV này được xóa khỏi tập dữ liệu đào tạo ban đầu để tạo ra một tập dữ liệu đào tạo nhỏ hơn Mô hình SVM mới được thành lập để trích xuất nhóm NLSV khác Quá trình này lặp lại 1 số lần để tâp thành nhiều hạt thông tin tiêu cực Tất cả các mẫu phủ định khác còn lại trong tập dữ liệu đào tạo đơn giản bị loại bỏ Một hoạt động tổng hợp có chọn lọc các mẫu trong các hạt thông tin tiêu cực (NLSVs) với các mẫu tích cực để hoàn thành quá trình undersampling Cuối cùng, một SVM tiếp tục được mô hình hóa trên tập dữ liệu sau tổng hợp để đưa ra kết quả
3.1.1 Tổng quan về mô hình Support Vector Machine (SVM)
SVM là một thuật toán học máy thuộc nhóm học có giám sát được sử dụng để giải quyết các bài toán phân lớp dữ liệu (classification) hay hồi quy (Regression) SVM dạng chuẩn nhận dữ liệu đầu vào và phân loại chúng thành hai lớp khác nhau Vì vậy SVM là một thuật toán phân loại nhị phân
Cho trước một tập dữ liệu huấn luyện, được biểu diễn trong không gian vector, mỗi điểm thể hiện một vector đặc trưng, SVM sẽ tìm ra một siêu phẳng quyết định tốt nhất để phân loại tất cả các điểm trên không gian này thành hai lớp riêng biệt tương ứng là lớp + và lớp - Mặt siêu phẳng này được xác định tốt hay không dựa trên độ dài của khoảng cách biên Khoảng cách biên chính bằng khoảng cách của điểm dữ liệu gần nhất của mỗi lớp đến mặt phẳng này Khoảng cách biên càng lớn thì mặt phẳng quyết định càng tốt, do đó việc phân loại càng chính xác
3.1.2 Phân loại bằng Support Vector Machine (SVM) a) Khoảng cách từ một điểm đến siêu phẳng
Trong không gian d chiều, khoảng cách từ một điểm (vector) có tọa đọ x 0 tới siêu mặt phẳng có phương trình w T x 0 + b = 0 được tính bởi:
Trong đó: b) Bài toán phân chia hai classes
Các kiến thức nền tảng
Mô hình SVM
3.1.1 Tổng quan về mô hình Support Vector Machine (SVM)
SVM là một thuật toán học máy thuộc nhóm học có giám sát được sử dụng để giải quyết các bài toán phân lớp dữ liệu (classification) hay hồi quy (Regression) SVM dạng chuẩn nhận dữ liệu đầu vào và phân loại chúng thành hai lớp khác nhau Vì vậy SVM là một thuật toán phân loại nhị phân
Cho trước một tập dữ liệu huấn luyện, được biểu diễn trong không gian vector, mỗi điểm thể hiện một vector đặc trưng, SVM sẽ tìm ra một siêu phẳng quyết định tốt nhất để phân loại tất cả các điểm trên không gian này thành hai lớp riêng biệt tương ứng là lớp + và lớp - Mặt siêu phẳng này được xác định tốt hay không dựa trên độ dài của khoảng cách biên Khoảng cách biên chính bằng khoảng cách của điểm dữ liệu gần nhất của mỗi lớp đến mặt phẳng này Khoảng cách biên càng lớn thì mặt phẳng quyết định càng tốt, do đó việc phân loại càng chính xác
3.1.2 Phân loại bằng Support Vector Machine (SVM) a) Khoảng cách từ một điểm đến siêu phẳng
Trong không gian d chiều, khoảng cách từ một điểm (vector) có tọa đọ x 0 tới siêu mặt phẳng có phương trình w T x 0 + b = 0 được tính bởi:
Trong đó: b) Bài toán phân chia hai classes
Chương 3 Các kiến thức nền tảng
Giả sử có hai classes khác nhau được mô tả bởi các điểm trong không gian nhiều chiều, và tồn tại một siêu phẳng phân chia hai classes đó Tức là mọi điểm của một class sẽ nằm cùng về một phía của siêu phẳng và các điểm thuộc class còn lại cùng thuộc về phía đối lập
Hình 6: Mô hình classes cho SVM Với một cặp dữ liệu bất kỳ (x n, y n), khoảng cách từ điểm đó tới siêu phẳng là:
Margin được tính là khoảng cách gần nhất từ một điểm nào đó tới siêu phẳng (bất kỳ điểm nào từ hai classes):
Bài toán tối ưu SVM chính là bài toán đi tìm hai tham số w và b sao cho margin này đạt giá trị lớn nhất:
Nếu ta thay vector hệ số w bởi kw và b bởi kb trong đó k là một hằng số dương thì mặt phân chia không thay đổi, tức khoảng cách từ từng điểm đến mặt phân chia không đổi, tức margin không đổi Nên ta có thể giả sử như sau:
Hình 7 : Mô hình classes cho SVM Như vậy với mọi n thì
Do đó, ta có thể đưa bài toán tối ưu SVM thành bài toán sau đây: c) Bài toán tổng quan SVM
SVM là bộ phân loại lớp tập trung vào việc tìm kiếm siêu phẳng phân tách lớp một cách tối ưu nhất giữa các mẫu đào tạo bằng cách đưa ra lời giải cho bài toán tối ưu sau
- Tham số C là sự đánh đổi giữa tối đa hóa margin và tối thiểu hóa sai sót Nếu giá trị của C càng cao thì mô hình sẽ tập trung vào việc tối thiểu hóa sai sót
Ranh giới quyết định được tối ưu là:
SVM sử dụng hàm quyết định sau: Đây là Soft Margin SVM Khác với Hard Margin SVM hoạt động không hiệu quả khi có nhiễu ở biên, trong đó Soft Margin SVM chấp nhận lỗi xảy ra ở một vài điểm dữ liệu Lỗi này được tính bằng khoảng cách từ điểm đó tới đường biên tương ứng Bài toán tối thiểu lỗi này bằng cách dùng thêm các biến gọi là slack variables
Tuy nhiên trong Soft Margin SVM, có một hằng số C phải chọn Hằng số C này sẽ ảnh hưởng tới độ rộng của margin của siêu phẳng d) So sánh với hai thuật tốn K-means, Nạve Bayes:
SVM có thể làm việc với bộ dữ liệu lớn, tham số điều chỉnh truyền vào chỉ có một và không ảnh hưởng quá nhiều đến kết quả mô hình so với K-means, phải dự đoán k cluster và tọa độ trung tâm SVM dễ dàng điều chỉnh, thay đổi và ổn định hơn
Nạve Bayes tuy đơi khi cho kết quả thực tế khá bất ngờ nhưng khơng phù hợp với những bài toán có dữ liệu lớn.
Tổng quan về các đặc trưng sử dụng
Mỗi feature là một đặc trưng riêng cho thấy mức độ tương đồng giữa báo cáo lỗi và tệp nguồn về những mặt khác nhau Mỗi đặc trưng sẽ tính ra điểm số và mô hình Learn to rank sử dụng những điểm số đó để xây dựng một vector về mối tương quan giữa mỗi báo cáo lỗi và tệp nguồn
3.2.1 Cấu trúc dữ liệu bug report và source file
Cấu trúc dữ liệu của một bug report bao gồm năm thành phần cơ bản như sau:
Hình 8 : Cấu trúc dữ liệu của một bug report
Trong đó “bug id” dùng để định danh một báo cáo lỗi Trong khi “summary” cung cấp những mô tả vắn tắt về báo cáo lỗi thì “description” cung cấp một mô tả chi tiết hơn Bên cạnh mỗi đó báo cáo lỗi sẽ lưu lại tất cả đường dẫn của những tệp nguồn (source files) gây ra lỗi đã được sửa, gọi là “fixed files”
Cấu trúc dữ liệu của một source file bao gồm năm thành phần cơ bản như sau:
Hình 9 : Cấu trúc dữ liệu của một source file
Trong một source file, nội dung trong file được trích xuất thông tin có cấu trúc (IR) [10] Có
6 thành phần chính trong một tệp nguồn được trích xuất: nhận xét (comments), tên lớp (class
Bug report description summary report time fixed files comments
Source file class name file name attributes method names api methods
24 name), tên tệp (file name), thuộc tính (attributes), tên phương thức (method names) và api methods Api methods là những đặc tả cho phương thức, được dùng để làm cầu nối giúp liên kết thông tin giữa một báo cáo lỗi và tệp nguồn
A Ý tưởng của Vector Space Model
Với mỗi truy vấn (query), mô hình muốn đo đạt sự tương đồng giữa câu truy vấn với tài liệu (docs), từ đó lấy kết quả để đưa ra xếp hạng Ý tưởng của VSM là biểu diễn câu truy vấn và tài liệu dưới dạng một vector
Ta cần tính được sim (q, d) để tìm ra được docs nào phù hợp với truy vấn
Trước hết query và docs được biến đổi dưới dạng vector:
Ta sẽ có nhiều docs và muốn xếp hạng sự liên quan của từng docs với truy vấn đã có, vì vậy ta cần một độ đo khoảng cách giữa q và d Độ đo có thể được tính bằng bất cứ độ đo trên vector nào: euclidean, consine similarity, …
Câu truy vấn và docs được biểu diễn dưới dạng vector cùng chiều, cùng biểu diễn trọng số gọi là concept vector
Hình 10 : Vector đại diện cho truy vấn và docs
B Cách xác định trọng số weight
Có nhiều kỹ thuật giúp xác định trọng số này Kỹ thuật xác định trọng số rất quan trọng, có ảnh hưởng trực tiếp đến kết quả xếp hạng cho model Ở đây em sẽ trình bày 3 kỹ thuật chính:
25 a) Term Frequency (Tần suất thuật ngữ)
TF sẽ đếm tần suất xuất hiện của từ trong câu theo quan điểm là từ nào xuất hiện trong câu thì sẽ quan trọng
Normalization TF: do sự chênh lệch độ dài ngắn khác nhau của câu, mà việc đếm tần suất không công bằng, từ đó một số kỹ thuật chuẩn hóa để giảm tránh điều này:
𝑚𝑎𝑥 𝑡∈𝑑 𝑡𝑓 𝑡,𝑑 Công thức 4 Tần suất xuất hiện của một từ văn bản b) Inverse document frequency
Từ xuất hiện nhiều quá cũng không tốt, vì chúng không thực sự mang ý nghĩa (ví dụ như: a, an, the, ) Nên IDF là nghịch đảo tần suất xuất hiện của từ trong docs
Công thức 5 Giá trị idf của một từ Trong đó:
- N = | D |: số tài liệu trong tập corpus N
- Mẫu số thể hiện số docs mà từ t xuất hiện, cộng 1 để tránh trường hợp chia cho 0 c) TF-IDF
Phép nhân TF với IDF cho thấy ta muốn tìm từ thỏa mãn hai điều kiện, vừa xuất hiện nhiều lần trong câu mà phải là từ mang ý nghĩa
𝑡𝑓𝑖𝑑𝑓(𝑡, 𝑑, 𝐷) = 𝑡𝑓(𝑡, 𝑑) 𝑖𝑑𝑓(𝑡, 𝐷) Công thức 6 Giá trị tf-idf của một từ trong tập văn bản
* Sau khi biểu diễn query và docs dưới dạng vector, sau đó tính khoảng cách giữa chúng, ta tính được mức độ tương đồng sim để đưa ra kết quả xếp hạng các tài liệu tìm kiếm với từng truy vấn
3.2.3 API-Enriched Lexical Similarity Score
Ye và cộng sự [9] đã đề xuất đặc trưng API-Enriched Lexical Similarity Ý tưởng của API- Enriched Lexical Similarity sinh ra để giải quyết vấn đề nếu như giữa một truy vấn - bug report so với một tài liệu như source file, lập trình viên có thể sử dụng những đối tượng được định nghĩa ở các tệp khác Nhưng thực chất đối tượng ấy có thể là cầu nối giữa truy vấn đó với tài liệu nếu được giải thích ngữ nghĩa đầy đủ Điều này được thực hiện bởi một bên thứ ba đứng ra làm trung gian có tên API Specification
Ví dụ một file java gây ra bug có biến tên window loại MtrimmedWindow Summary của bug đó có các từ như: toolbars, menus, Nếu đơn thuần nhìn qua thì chả thể thấy sự liên hệ nào giữa bug và file gây ra lỗi
Nhưng nhờ có một cầu nối, API Specification, nó cho ta biết thêm thông tin mô tả hơn về loại interface MtrimmedWindow, lúc này từ menus, toolbars có xuất hiện trong đặc tả và ta có thể xác định sự liên quan giữa chúng
Ye và cộng sự [9] đã đề xuất đặc trưng Collaborative Filtering Ý tưởng của đặc trưng này bắt nguồn từ việc truy xuất lịch sử các bug report được báo cáo của tệp mã nguồn gây ra lỗi Nếu một tệp mã nguồn gây ra một lỗi mới, thì có khả năng lỗi mới có liên quan với các lỗi trước đó mà tệp mã nguồn đã gây ra
Giá trị của feature này là sự tương đồng về mặt từ ngữ giữa báo cáo lỗi hiện tại với tất cả các bug report được báo cáo trong quá khứ từ các tệp nguồn gây lỗi Công thức tính điểm đặc trưng cho collaborative filtering score:
𝜙 3 (𝑟 , 𝑠) = sim (r, br (r, s)) Công thức 7 Giá trị điểm collaborative filtering score
Trong đó br (r, s) là tập tất cả các báo cáo lỗi được mà tệp nguồn s gây ra trước khi báo cáo lỗi r được phát hiện Mức độ tương quan được tính dựa trên summary của báo cáo lỗi r với toàn bộ summary của các báo cáo lỗi trong đó br (r, s)
Giải pháp đề xuất
Tổng quan về mô hình SVMBugRanking
Mô hình SVMBugRanking sử dụng SVM và tính điểm cho từng cặp bug-source dựa trên các đặc trưng trình bày trong chương 3 Hàm tính điểm f (r, s) là sự kết hợp tuyến tính của
6 đặc trưng với công thức dưới đây:
Công thức 11 Hàm score function của mô hình SVMBugRanking
Trong đó, wi là trọng số thể hiện sự đóng góp của từng đặc trưng, 𝜙 𝑖 (𝑟, 𝑠) là đặc trưng trong số 6 đặc trưng trình bày trong chương 3 Dựa vào thông tin của các bug reports được báo cáo trong quá khứ với các source files có liên quan, mô hình sẽ được đào tạo để đưa ra một bộ tham số 𝑤 𝑖 tối ưu Từ đó tính được điểm 𝒇 (𝒓, 𝒔), đại diện cho mức độ tương đồng giữa một báo cáo lỗi và tệp nguồn Dựa trên điểm số đó mà mô hình sẽ đề xuất được các tệp mã nguồn liên quan nhất khi một bug report được phát hiện cho nhà phát triển
Kiến trúc tổng quan của mô hình SVMBugRanking được trình bày trong Hình 10
Chương 4 Giải pháp đề xuất
Hình 11 : Mô hình tổng quan SVMBugRanking
Kiến trúc của mô hình gồm 4 khối xử lý:
Calculate feature scores rVsm score
Show topK, MRR, MAP K-fold
• Khối tiền xử lý dữ liệu
• Khối tính toán đặc trưng
• Khối dự đoán mô hình và đánh giá
Giai đoạn tiền xử lý
4.2.1 Tiền xử lý cho các source files
Biểu diễn văn bản cho một source file được tạo ra bằng cách trích xuất từ mã nguồn các thông số sau:
Quá trình tiền xử lý cho một docs:
Pos tagging là quá trình gắn thẻ một từ theo định dạng văn bản được quy ước dựa trên ngữ cảnh trong câu Đây là quá trình gắn thẻ ngữ pháp Ví dụ từ ‘everything’ sẽ được gắn thẻ
‘NN’ (thẻ danh từ), ‘permit’ được gắn thẻ ‘VB’ (thẻ động từ)
Tokenize là quá trình trích xuất một chuỗi các ký tự thành những từ đơn lẻ có một âm tiết
Ví dụ chuỗi ‘aitidises’ sẽ được tokenize thành các từ đơn ‘an’, ‘ti’, dis’, ‘es’
Thường những tên class sẽ được quy ước đặt tên dưới dạng CamelCase như:
“NameOfClass”, split CamelCase sẽ phân tách được chúng thành các từ riêng lẻ có ý nghĩa:
Nomalize là việc loại bỏ các dấu câu, thực hiện việc chuẩn hóa các chữ cái về cùng một dạng (viết hoa hoặc viết thường), chia văn bản thành các đơn vị riêng lẻ
Stopword chính là những từ không liên quan, không quan trọng trong việc giúp nhận biết ý nghĩa của câu như: “to”, “the”, “be”, sẽ được lọc ra để cải thiện hiệu quả và giảm nhiễu không cần thiết
Trong tiếng anh, một từ có thể có nhiều biến thể khác nhau ví dụ như: “play”, “playing”,
“played” Stemming sẽ làm nhiệm vụ hợp nhất biến thể lại để tăng hiệu suất matching giữa các văn bản
4.2.2 Tiền xử lý cho bug files
Quá trình tiền xử lý cho một lỗi báo cáo cũng gần tương tự như file nguồn, chỉ khác là với bug file thì được loại bỏ tất cả stack traces trước khi làm các bước như trên Biểu diễn văn bản của một bug report được tạo thành từ việc kết hợp hai trường bug_summary và bug_description
Quá trình tiền xử lý cho một văn bản biểu diễn bug report:
Đánh giá mô hình
4.3.1 Evaluation metrics a) Accuracy@k Độ chính xác Accuracy@k đo tỷ lệ phần trăm các báo cáo lỗi cái mà được đưa ra ít nhất một dự đoán đúng trong bảng xếp hạng top k file b) Mean Reciprocal Rank (MRR)
MRR là một thống kê để đánh giá một quy trình tạo ra danh sách những phản hồi tích cực cho một truy vấn Thứ hạng nghịch đảo của một truy vấn là giá trị nghịch đảo của thứ hạng của câu trả lời đúng đầu tiên Ở đây một truy vấn tương ứng với một báo cáo lỗi Mỗi báo cáo lỗi có thể có một hoặc nhiều source file gây ra Ta sẽ xác định thứ hạng cao nhất của các source files gây ra bug được dự đoán đúng và rồi lấy giá trị nghịch đảo của nó MRR là giá trị trung bình của các giá trị nghịch đảo đó trên tập hợp các truy vấn Q
Công thức 12 Công thức tính MRR
Nếu giá trị MRR càng cao thì độ chính xác định vị lỗi càng tốt c) Mean Average Precision
MAP một công cụ cung cấp thước đo về chất lượng trích xuất thông tin, khi một truy vấn có nhiều tài liệu liên quan Độ chính xác trung bình của một truy vấn là giá trị trung bình của các độ chính xác thu được cho truy vấn ứng với mỗi tài liệu liên quan:
Công thức 13 Công thức tính MAP
Mô hình xếp hạng f (r, s) được tính dựa trên sự kết hợp của các features có trọng số Mỗi feature đại diện cho mối quan hệ tương đồng giữa một báo cáo lỗi r và tệp nguồn s Các tham số mô hình wi được huấn luyện bằng cách sử dụng kỹ thuật tiếp cận learn-to-rank, được triển khai trong mô hình Support Vector Machine (SVM)
Mục tiêu của quy trình là tối ưu hóa tham số sao cho f (r, s1) > f (r, s2) Trong đó s1 được biết là tệp nguồn có liên quan đến báo cáo lỗi r, còn s2 được biết là không liên quan đến cùng báo cáo lỗi đó Với một báo cáo lỗi bất kỳ, số lượng tệp mã nguồn là rất lớn, nên nếu ta đào tạo trên tất cả mã nguồn thì thời gian đào tạo sẽ không khả thi Do đó, với mỗi báo cáo lỗi r, mô hình sẽ đưa ra 300 tệp không liên quan nhất được sắp xếp theo giá trị của rVSM để đưa vào đào tạo
Mô hình xếp hạng được chia thành 10 folds, trong đó 9 folds để train còn một fold để test Đối với mỗi báo cáo lỗi từ một fold, việc kiểm thử mô hình có nghĩa là tính toán hàm tính điểm có trọng số f (r, s) trên tất cả tệp mã nguồn bằng cách sử dụng trọng số đã học từ data training, sau đó xếp hạng tất cả tệp theo thứ tự giảm dần kết quả của chúng Các tệp có liên quan nhất sẽ được liệt kê trên cùng Cuối cùng, báo cáo lỗi từ tất cả 10 folds test được tổng hợp lại và được đánh giá kết quả theo các evaluation metrics kể trên: MRR, MAP, topk
Em áp dụng 2 chiến lược để giải quyết vấn đề về mất cân bằng dữ liệu: undersampling và oversampling cho mô hình SVMBugRanking a) Undersampling Đây là phương pháp lấy mẫu dưới quá mức Ở đây em áp dụng phương pháp này với lớp đa số (lớp chiếm số lượng lớn), để loại bỏ những điểm dữ liệu dư thừa trong việc đào tạo Kỹ thuật Undersampling sử dụng ở đây là RandomUnderSampler
Random sampling là một kỹ thuật đơn giản bỏ qua ngẫu nhiên các điểm dữ liệu từ lớp đa số cho đến khi đạt được sự cân bằng mong muốn giữa các lớp trong dữ liệu đào tạo
Thuật toán yêu cầu đầu vào là dữ liệu đào tạo của cả lớp thiểu số và lớp đa số, đầu ra là một cặp dữ liệu mà số lượng phần tử của lớp đa số bằng với kích thước của lớp thiểu số b) Oversampling
Trái ngược với undersampling, nghĩa là thay vì giảm số lượng của lớp chiếm phần đa, oversampling sẽ sinh dữ liệu giả, làm tăng số lượng cho lớp thiểu số Kỹ thuật em áp dụng ở đây là Smote
Smote là một phương pháp dựa vào những điểm dữ liệu sẵn có để tạo ra những hàng xóm có liên quan với chúng, dựa vào thuật toán K-means để tạo dữ liệu tổng hợp Khoảng cách được sử dụng trong K-means đó là khoảng cách Euclid Đầu vào của Smote là tập hợp các điểm dữ liệu của lớp thiểu số Giá trị tham số truyền vào là biến K và N K là số lần muốn tăng kích thước, N là số hàng xóm lấy ngẫu nhiên Đầu ra là một tập hợp các điểm dữ liệu mới sau khi được lấy mẫu quá mức c) Phương pháp giải quyết vấn đề mất cân bằng dữ liệu
Phương pháp 1: SVMBugRanking kết hợp với Smote và RandomUnderSampler Đầu tiên các dữ liệu của lớp thiểu số sẽ được Smote để tăng độ dày đặc của những điểm dữ liệu tốt, giúp mô hình SVM phân loại hiệu quả hơn
Sau đó tập dữ liệu mới cho lớp thiểu số vừa thu được cùng với tập dữ liệu cho lớp đa số được RandomUnderSampler, để làm giảm sự mất cân bằng giữa 2 lớp Kết quả thu được là
2 tập dữ liệu có kích thước bằng nhau và được sử dụng để làm dữ liệu đào tạo cho mô hình SVM
Phương pháp 2: SVMBugRanking kết hợp với RandomUnderSampler
Có những dự án khi mà số lượng phần tử của lớp thiểu số đã đủ lớn để SVM hình thành siêu phẳng đáng tin cậy, việc lấy mẫu quá mức trở lên không còn tốt bởi vì có thể sẽ tạo ra những điểm dữ liệu nhiễu cho việc phân loại
Tập dữ liệu cho lớp thiểu số và lớp đa số sẽ được lấy mẫu dưới trực tiếp và kết quả thu được sẽ được SVM sử dụng làm dữ liệu đào tạo
Đánh giá thực nghiệm
Tập dữ liệu sử dụng
Bộ dữ liệu để đánh giá dựa trên 6 các dự án mã nguồn mở được công khai và được nhiều bài báo sử dụng làm bộ dữ liệu chuẩn:
- Aspect: một extension cho for Java
- Birt: một công cụ báo cáo tài chính kinh doanh trên nền tảng Eclipse
- Eclipse Platform UI: giao diện người dùng cho một nền tảng phát triển tích hợp
- JDT: một công cụ phát triển Java cho Eclipse
- SWT: một công cụ widget cho Java
- Tomcat: một máy chủ ứng dụng web dùng Java
Tất cả dự án trên đều sử dụng GIT làm hệ thống kiểm soát phiên bản Các báo cáo lỗi, kho mã nguồn và đặc tả API đều có thể truy cập công khai Đối với từng dự án và tập dữ liệu tương ứng, bảng sau đây thống kê các số liệu như: phạm vi thời gian cho báo cáo lỗi, số lượng báo cáo lỗi, số lượng tệp nguồn được sửa trên một báo cáo lỗi, quy mô dự án và số lượng thành phần từ đặc tả API
Hình 12 : Tập dữ liệu trên 6 dự án
Chương 5 Đánh giá thực nghiệm
Kết quả thực nghiệm
5.2.1 RQ1: Những cách tiếp cận khác nhau tác động thế nào đến hiệu suất phân loại?
Thí nghiệm so sánh Learn to Rank với các tiếp cận bao gồm: Nạve Bayes bởi Kim, và BugLocator bởi Zhou:
Hình 13 : Bảng dữ liệu so sánh Learn to rank với Bug Locator và Nạve Bayes
NB là một cách tiếp cận dựa vào học máy, còn Bug Locator dựa trên hệ thống trích xuất thông tin IR Với cách tiếp cận NB, mô hình được triển khai có 2 pha như đã trình bày trong chương 2 Đầu tiên xác định liệu báo cáo lỗi “có thể dự đoán” hay “thiếu thông tin” Pha sau sẽ dự đoán xếp hạng các báo cáo lỗi có nhãn là “có thể dự đoán” Đầu tiên, so với BugLocator, LR đạt được kết quả cao hơn trung bình khoảng 10% so ở độ chính xác top1 Với độ chính xác top 5 thì LR cũng cải thiện hơn từ 5-20% trên đa số các dự án (trừ AspectJ) Hơn thế nữa, LR cũng đưa ra những đề xuất đúng hơn cách tiếp cận NB vì cách tiếp cận đó bị thiếu thông tin khi không sử dụng dữ liệu từ những tệp nguồn đã được sửa lỗi trước đó LR cao hơn NB 9.5%-41% Đồng thời, xét về MRR và MAP trên 6 dự án, cách tiếp cận LR cũng nhỉnh hơn Bug Locator
Ví dụ trên dự án Eclipse Platform UI, kết quả MAP và MRR cho cách tiếp cận LR lần lượt là 0.40 và 0.47, cao hơn so với Bug Locator (0.31 và 0.37), NB (0.07 và 0.06)
5.2.2 RQ2: Mỗi feature đóng góp như thế nào đến hiệu suất của mô hình?
Sau đây là bảng thống kê top 1 accuracy của từng feature trên từng dự án, mỗi feature được chạy một cách độc lập
Hình 14: Top1 trên từng đặc trưng trên dự án Tomcat
39 Hình 15: Top1 accuracy của từng đặc trưng trên dự án AspectJ
Hình 16: Top1 accuracy của từng đặc trưng trên dự án SWT
40 Hình 17: Top1 accuracy của từng đặc trưng trên dự án Eclipse
Hình 18: Top1 accuracy của từng đặc trưng trên dự án JDT
Hình 19: Top1 accuracy của từng đặc trưng trên dự án Birt
Các bảng trên cho thấy mức độ ảnh hưởng của từng feature đến mô hình Có thể thấy rVsm và Collaborative Simi là 2 đặc trưng đạt được độ chính xác cao nhất Đặc trưng rVsm dẫn đầu trong 3 dự án Tomcat, AspectJ và Eclipse, trong khi Collaborative Simi chiếm ưu thế trong 3 dự án còn lại Đặc trưng có ảnh hưởng ít nhất đối với mô hình là Bug recency simi
5.2.3 RQ3: Những chiến lược giải quyết vấn đề mất cân bằng dữ liệu cải thiện như thế nào đối với mô hình?
Em sẽ đánh giá mô hình SVMBugRanking thuần so với 2 cách cải tiến sau để giải quyết vấn đề mất cân bằng:
- SVMBugRanking kết hợp với Undersampling và Oversampling
- SVMBugRanking kết hợp với Undersampling
So sánh với mô hình SVMBugRanking, phương pháp cải tiến SVMBugRanking kết hợp với Smote và RandomUnderSampler đạt kết quả MRR cao hơn từ 0.4%-5.8%, còn giá trị MAP cao hơn từ 0.1%-5.4% So với dự án với số lượng báo cáo lỗi và tệp mã nguồn còn nhỏ, tỷ lệ độ chính xác top1(47,32%) và top15 (85,6%) khá cao như Tomcat, thì ta không thấy sự chênh lệch rõ rệt sau khi giảm sự mất cân bằng dữ liệu, sở dĩ các kết quả ban đầu đã khá tốt và gần chạm ngưỡng Đối với 5 dự án còn lại, giá trị MRR và MAP được cải thiện rõ rệt Ví dụ như với dự án JDT, giá trị MRR đã tăng 5,8% (46,8% - 52,6%), trong đó MAP tăng 5,4% (40% - 45,4%)
So sánh giữa 2 phương pháp cải tiến thì, SVMBugRanking kết hợp với Smote và RandomUnderSampler cho kết quả tốt hơn ở 2 dự án quy mô nhỏ Tomcat và AspectJ, trong khi SVMBugRanking chỉ với RandomUnderSampler cho kết quả cao hơn ở 4 dự án còn lại, những dự án mà số lượng báo cáo lỗi và tệp nguồn lớn Cụ thể, với dự án Tomcat, giá trị MRR và MAP của phương pháp cải tiến thứ nhất cao hơn lần lượt 0.8% (58,5%-59,3%) và 0.9% (53,4%-54,5%) Tuy nhiên với dự án JDT, việc chỉ sử dụng RandomUnderSampler cho kết quả MRR và MAP nhỉnh hơn 1.9% (52,6%-54,5%) và 1,6% (45,5%-47,1%)
Hình 20: Giá trị MRR trên SVMBugRanking và 2 chiến lược cải thiện
Hình 21: Giá trị MAP trên SVMBugRanking và 2 chiến lược cải thiện
Tóm lại, trung bình sự chênh lệch giữa 2 cách cải tiến này cho MRR và MAP khoảng 1% trên các dự án, và cả 2 phương thức cải tiến đều cho hiệu suất đánh giá tăng đáng kể so với mô hình SVMBugRanking ban đầu
Bài toán định vị lỗi phần mềm ra đời nhắm giúp các lập trình viên tiết kiệm thời gian và công sức trong việc xác định nơi nào để bắt đầu bắt tay vào sửa lỗi Bài toán giống như một hệ thống gợi ý đưa ra các đề xuất tệp mã nguồn có liên quan nhất với báo cáo lỗi cho lập trình viên, qua đó làm giảm không gian tìm kiếm và tiết kiệm thời gian cho những người lập trình Nhưng để bài toán được đưa vào ứng dụng thực tế, những yếu tố như tính ổn định và sự tin cậy được các nhà phát triển quan tâm Điều này đặt ra việc những mô hình giải quyết bài toán phải đạt được độ chính xác cao và có tính ổn định qua những lần dự đoán Mô hình SVMBugRanking là một mô hình kế thừa Learn to rank, nhưng khắc phục nhược điểm về sự mất cân bằng trong tập dữ liệu đào tạo bằng cách thay đổi mẫu Có hai chiến lược được đề xuất đó là lấy mẫu dưới hoặc đồng thời kết hợp giữa việc tạo dữ liệu giả và lấy mẫu dưới Đối với những dự án có số lượng báo cáo lỗi đủ tốt thì việc tạo dữ liệu giả cho lớp thiểu số có thể làm tăng số lượng điểm nhiễu đáng kể, từ đó làm giảm hiệu suất phân loại của SVM Nên sự kết hợp cả hai chiến lược là điều cần thiết Kết quả của từng chiến lược đều cho kết quả tốt hơn mô hình SVMBugRanking khi chưa cải thiện trên cả ba độ đo topk@accuracy, MRR và MAP
Mô hình SVMBugRanking cũng được so sánh với các phương pháp tiếp cận khác như BugLocator, Nạve Bayes trên cùng 6 tập dữ liệu Kết quả thực nghiệm cho thấy mơ hình đạt được độ chính xác cao hơn tất cả các phương pháp khác
6.2 Hướng phát triển trong tương lai
Trong mô hình đề xuất, có những dự án hoạt động tốt với chiến lược đầu tiên (chỉ lấy mẫu dưới) nhưng lại có những dự án cần được tạo dữ liệu giả rồi sau đó mới lấy mẫu dưới Tuy sự chênh lệch kết quả giữa hai chiến lược này là không nhiều nhưng nó vẫn chưa phù hợp nhất Trong tương lai hi vọng có chiến lược giúp làm mất tính cân bằng dữ liệu hiệu quả hơn cho bài toán định vị lỗi phần mềm.
