Báo cáo Nghiên cứu các độ đo mã nguồn cho bài toán dự đoán lỗi phần mềm

Nội dung text: Báo cáo Nghiên cứu các độ đo mã nguồn cho bài toán dự đoán lỗi phần mềm

1. ĐẠI HỌC ĐÀ NẴNG TRƯỜNG CĐ CƠNG NGHỆ THƠNG TIN BÁO CÁO TỔNG KẾT ĐỀ TÀI KHOA HỌC VÀ CƠNG NGHỆ CẤP CƠ SỞ NGHIÊN CỨU CÁC ĐỘ ĐO MÃ NGUỒN CHO BÀI TỐN DỰ ĐỐN LỖI PHẦN MỀM Mã số: T2018-07-07 Chủ nhiệm đề tài: ThS. Hà Thị Minh Phương Đà Nẵng, 12/2018
2. ĐẠI HỌC ĐÀ NẴNG TRƯỜNG CĐ CƠNG NGHỆ THƠNG TIN BÁO CÁO TỔNG KẾT ĐỀ TÀI KHOA HỌC VÀ CƠNG NGHỆ CẤP CƠ SỞ NGHIÊN CỨU CÁC ĐỘ ĐO MÃ NGUỒN CHO BÀI TỐN DỰ ĐỐN LỖI PHẦN MỀM Mã số: T2018-07-07 Xác nhận của cơ quan chủ trì đề tài Chủ nhiệm đề tài Đà Nẵng, 12/2018
3. MỤC LỤC MỤC LỤC MỤC LỤC I DANH MỤC HÌNH VẼ 1 DANH MỤC TỪ VIẾT TẮT 2 THƠNG TIN KẾT QUẢ NGHIÊN CỨU 3 MỞ ĐẦU 5 I. TỔNG QUAN TÌNH HÌNH NGHIÊN CỨU THUỘC LĨNH VỰC ĐỀ TÀI TRONG VÀ NGỒI NƯỚC 5 1. NGỒI NƯỚC 5 2. TRONG NƯỚC 5 II. TÍNH CẤP THIẾT CỦA ĐỀ TÀI 5 III. MỤC TIÊU CỦA ĐỀ TÀI 5 IV. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU 6 1. ĐỐI TƯỢNG NGHIÊN CỨU 6 2. PHẠM VI NGHIÊN CỨU 6 V. NỘI DUNG NGHIÊN CỨU 6 CHƯƠNG 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM 7 1.1. TỔNG QUAN VỀ LỖI PHẦN MỀM 7 1.2. MỐI LIÊN HỆ GIỮA ĐỘ ĐO VÀ LỖI PHẦN MỀM 8 1.3. ĐỘ ĐO PHẦN MỀM 8 1.3.1. Độ đo mã nguồn (Code Metrics) 8 1.3.2. Độ đo quy trình (Process Metrics) 11 1.4. ÁP DỤNG CÁC ĐỘ ĐO PHẦN MỀM 11 1.5. KỸ THUẬT HỌC MÁY TRONG DỰ ĐỐN LỖI PHẦN MỀM 12 1.5.1. Cây quyết định (Decision Tree Classification) 12 1.5.2. Nạve Bayes 13 1.5.3. K-nearest Neighbor 13 1.5.4. Support Vector Machine (SVM) 15 1.6. XỬ LÝ DỮ LIỆU 16 1.6.1. Chuẩn hĩa dữ liệu 16 1.6.2. Giảm tiếng ồn (Noise reduction) 17 1.6.3. Lựa chọn thuộc tính (Attribute Selection) 18 1.7. CÁC ĐÁNH GIÁ ĐỘ ĐO 18 1.7.1. Phân loại đo lường 18 1.7.2. Thảo luận về các độ đo 22 CHƯƠNG 2: ĐỘ ĐO TRONG DỰ ĐỐN LỖI PHẦN MỀM 24 2.1. GIỚI THIỆU 24 2.2. ĐỘ ĐO HƯỚNG ĐỐI TƯỢNG (OBJECT ORITEND METRICS) 24 2.2.1. Độ đo kích thước (Size) 25 2.2.2. Độ đo phụ thuộc (coupling) 25 2.2.3. Độ đo gắn kết (cohesion) 26 2.2.4. Độ đo thừa kế (Inheritcance Metrics) 26 2.2.5. Độ đo đa hình (Polymorphism Metrics) 27 2.2.6. Độ đo tái sử dụng (Reuse metrics) 27 CHƯƠNG 3: KẾT QUẢ THỰC NGHIỆM 28 1.1. CÂU HỎI NGHIÊN CỨU 28 1.2. CÁC GIẢ THUYẾT NGHIÊN CỨU 28 1.3. BIẾN PHỤ THUỘC (DEPENDENT VARIABLE) 28 i
4. MỤC LỤC 1.4. BIẾN ĐỘC LẬP (INDEPENDENT VARIABLES) 29 1.5. THU THẬP DỮ LIỆU 29 KẾT LUẬN 33 KIẾN NGHỊ 33 TÀI LIỆU THAM KHẢO 34 ii
5. DANH MỤC HÌNH VẼ DANH MỤC HÌNH VẼ Hình 1.1 Tần suất sử dụng độ đo phần mềm trong các nghiên cứu 11 Hình 1.2 Cây quyết định đơn giản 13 Hình 1.3 Ví dụ K-Nearest Neighbor 14 Hình 1.4 Ví dụ về ROC 21 Hình 1.5 Đường cong Cost-effective curve 22 Hình 1.6 Tổng số các biện pháp đánh giá độ đo được sử dụng trong các nghiên cứu dự đốn lỗi phần mềm (Nam, 2009) 23 Hình 3.1 Kỹ thuật phân tích của OSSGrab 29 Hình 3.2 Tìm kiếm đơn giản trong kho OSS 30 Hình 3.3 Tìm kiếm nâng cao trong kho OSS 31 Trang 1
6. DANH MỤC TỪ VIẾT TẮT DANH MỤC TỪ VIẾT TẮT Từ viết tắt Tiếng Anh Tiếng Việt OSS Open Source System Hệ thống mã nguồn mở OO Object Oriented Hướng đối tượng CK Chidamber-Kemerer Độ đo Chidamber-Kemerer SVM Support Vector Machine Máy vector hỗ trợ DT Decision Tree Cây quyết định RF Random Forest Rừng ngẫu nhiên Trang 2
7. THƠNG TIN KẾT QUẢ NGHIÊN CỨU ĐẠI HỌC ĐÀ NẴNG CỘNG HỊA XÃ HỘI CHỦ NGHĨA VIỆT NAM TRƯỜNG CĐ CƠNG NGHỆ THƠNG TIN Độc lập – Tự do – Hạnh phúc THƠNG TIN KẾT QUẢ NGHIÊN CỨU 1. Thơng tin chung: - Tên đề tài: Nghiên cứu các độ mã nguồn cho bài tốn dự đốn lỗi phần mềm - Mã số: T2018-07-07 - Chủ nhiệm: HÀ THỊ MINH PHƯƠNG - Thành viên tham gia: khơng - Cơ quan chủ trì: Trường Cao đẳng Cơng nghệ thơng tin – Đại học Đà Nẵng - Thời gian thực hiện: từ tháng 04/2018 đến tháng 12/2018 2. Mục tiêu: Nghiên cứu lý thuyết: Tìm hiểu độ đo mã nguồn hướng cấu trúc Tìm hiểu độ đo mã nguồn hướng đối tượng Nghiên cứu áp dụng các độ hướng đối tượng vào việc dự đốn lỗi phần mềm Áp dụng lý thuyết vào xây dựng cơng cụ dự đốn lỗi phần mềm nhằm tạo điều kiện để tiếp tục nghiên cứu và xây dựng các hệ thống dự đốn lỗi phần mềm dựa trên máy học để dự đốn được số lỗi của phần mềm . 3. Tính mới và sáng tạo: - Lỗi phần mềm sẽ tác động mạnh đến các hệ thống phần mềm trong quá trình phát triển cũng như quá trình triển khai - Để dự đốn được các khả năng xảy ra lỗi, tác giả đã nghiên cứu các độ đo (metrics, từ đĩ cĩ thể lựa chọn các độ đo cĩ mối liên hệ với khả năng xả ra lỗi với từng ngơn ngữ lập trình cụ thể. 4. Tĩm tắt kết quả nghiên cứu: - Trình bày tổng quan các độ đo trong bài tốn giải quyết lỗi phần mềm cụ thể là độ đo cấu trúc (Structure metrics) và độ đo hướng đối tượng (Object Oriented metrics). Trang 3
8. THƠNG TIN KẾT QUẢ NGHIÊN CỨU - Đề tài cũng trình bày việc mơ phỏng thực nghiệm áp dụng các độ đo hướng đối tượng trong việc đưa ra mỗi liên hệ giữa các độ đo trên với khả năng xảy ra lỗi trong cáchệ thống mã nguồn mở OSS được viết bằng C++ 5. Tên sản phẩm: - Báo cáo tổng kết đề tài; - Bài báo đăng trên kỷ yếu hội thảo cấp trường. 6. Hiệu quả, phương thức chuyển giao kết quả nghiên cứu và khả năng áp dụng: - Về mặt giáo dục - đào tạo: phục vụ cơng tác giảng dạy, nghiên cứu. - Về mặt khoa học: đĩng gĩp đáng kể của đề tài là trình bày các độ đo liên quan mật thiết đến lỗi phần mềm, qua đĩ cĩ thể đưa ra được các độ đo cĩ tính hiệu quả trong việc nhận biết lỗi phần mềm. - Về sản phẩm ứng dụng: xây dựng được các hệ thống dự đốn được lỗi phần mềm trong cơng nghệ phần mềm. 7. Hình ảnh, sơ đồ minh họa chính: Độ đo Lỗi CBO RFC NOC WMC LCOM Lỗi 1 0.038 0.495 0.36 0.17 0.058 (0.84) (0.005) (0.05) (0369) (0.76) CBO - 1 0.528 0.306 0.278 0.423 (0.003) (0.10) (0.137) (0.02) RFC - - 1 0.38 0.533 0.244 (0.038) (0.002) (0.195) NOC - 1 -0.305 -0.032 (0.101) (0.867) WMC - - - - 1 0.544 (0.002) LCOM - 1 Bảng 0.1: Phân tích tương quan Spearman giữa các độ đo Đà Nẵng, ngày 08 tháng 12 năm 2018 Cơ quan chủ trì Chủ nhiệm đề tài Hà Thị Minh Phương Trang 4
9. MỞ ĐẦU MỞ ĐẦU I. TỔNG QUAN TÌNH HÌNH NGHIÊN CỨU THUỘC LĨNH VỰC ĐỀ TÀI TRONG VÀ NGỒI NƯỚC 1. Ngồi nước Độ đo (metric) đĩng một vai trị rất quan trọng để phát triển một phần mềm cĩ chất lượng tốt. The IEEE Standard Glossary of Software Engineering Terms đã định nghĩa độ đo như là thước đo định lượng đến một hệ thống, một thành phần hoặc một quá trình cĩ một thuộc tính nhất định. Cĩ rất nhiều loại độ đo khác nhau được trình bày trong các tài liệu để đo lường các sản phẩm phần mềm. Trong sự phát triển phần mềm hiện nay, ngơn ngữ hướng đối tượng (Object Oriented) được sử dụng do các đặc tính cơ bản của chúng như lớp, đối tượng, che dấu thơng tin, thừa kế, đĩng gĩi, trìu tượng và đa hình. Ngồi ra, độ đo của hướng đối tượng cĩ sẵn được sử dụng để đo chất lượng của các hệ thống hướng đối tượng. 2. Trong nước Hiện nay đã cĩ nhiều nghiên cứu về độ đo hướng đối tượng trên các ngơn ngữ lập trình như C++, Java, . Các độ đo cĩ ích cho việc đánh giá sự phát triển cơ trúc cĩ thể khơng ảnh hưởng đến thiết kế mà sử dụng ngơn ngữ OO. Cĩ rất nhiều mơ hình độ đo hướng đối tượng cĩ sẵn và một số tác giả đã đề xuất cách để đo lường giá trị của độ đo mã nguồn hướng đối tượng. Một nghiên cứu ước tính tiết kiệm chi phí bảo trì sửa chữa là 42% bằng cách sử dụng độ đo mã nguồn hướng đối tượng. II. TÍNH CẤP THIẾT CỦA ĐỀ TÀI Việc đo lường phần mềm cĩ tầm quan trọng trong việc phát triển phần mềm. Nhiều độ đo đã được đề xuất lien quan đến cấu trúc khác nhau như lớp, phụ thuộc, thừa kế, che dầu thơng tin và đa hình. Rất khĩ để xác định độ đo nào tốt nhất. Do đĩ, rất khĩ cho các nhà quản lý và người thực hiện dự án lựa chọn các độ đo cho các hệ thống hướng đối tượng. Trong đĩ, độ đo OO (Object Oriented) là độ đo trong một hệ thống hướng đối tượng để xác định sự thành cơng hay thất bại của một quy trình, để xác định cĩ định lượng sự cải tiến trong một quy trình phần mềm. Độ đo này được sử dụng để cải tiến kỹ thuật lập trình hướng đối tượng tăng tính tin cậy của mã nguồn. Xét thấy như vậy, chúng tơi nghiên cứu các độ đo mã nguồn hướng đối tượng cũng như so sánh với độ đo mã nguồn hướng cấu trúc. Từ đĩ cĩ thể đưa ra được dự đốn lỗi phần mềm dựa trên các độ đo trên. III. MỤC TIÊU CỦA ĐỀ TÀI Nghiên cứu lý thuyết: Trang 5
10. MỞ ĐẦU Tìm hiểu độ đo mã nguồn hướng cấu trúc Tìm hiểu độ đo mã nguồn hướng đối tượng Nghiên cứu áp dụng các độ hướng đối tượng vào việc dự đốn lỗi phần mềm Áp dụng lý thuyết vào xây dựng cơng cụ dự đốn lỗi phần mềm nhằm tạo điều kiện để tiếp tục nghiên cứu và xây dựng các hệ thống dự đốn lỗi phần mềm dựa trên máy học để dự đốn được số lỗi của phần mềm . IV. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU 1. Đối tượng nghiên cứu - Độ đo mã nguồn cấu trúc và độ đo mã nguồn hướng đối tượng: Sách, báo, - Giá trị các độ đo trên. 2. Phạm vi nghiên cứu Nghiên cứu các độ đo mã nguồn dựa trên - Tiếp cận dựa vào lý luận. - Tiếp cận dựa vào thống kê. - Tiếp cận dựa trên cả hai phương pháp trên. V. NỘI DUNG NGHIÊN CỨU 1. Tìm hiểu độ đo mã nguồn hướng cấu trúc và độ đo mã nguồn hướng đối tượng 2. Nghiên cứu và phân tích các giá trị của các độ đo trên trong dự đốn lỗi phần mềm 3. Xây dựng cơng cụ dự đốn lỗi phần mềm dựa trên độ đo mã nguồn hướng đối tượng 4. Viết báo cáo tổng kết đề tài. Trang 6
11. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM 1.1. TỔNG QUAN VỀ LỖI PHẦN MỀM Trong lĩnh vực cơng nghệ phần mềm, các hệ thống phần mềm được sản xuất và bảo trì bởi con người vì vậy việc duy trì phần mềm rất phức tạp, lỗi luơn luơn xuất hiện tại các hệ thống này. Hầu hết các cơng ty phần mềm chi tiêu rất nhiều tiền và nhân lực để phát hiện lỗi trong một hệ thống phần mềm trước khi được triển khai cho khách hàng. Phần mềm càng phức tạp thì lỗi càng xuất hiện nhiều. Lỗi tác động tới phần mềm hoặc hệ thống đang xây dựng hoặc vận hành theo nhiều cách khác nhau. Do vậy để giảm thiểu các hậu quả do lỗi gây ra để tiết kiệm chi phí thì các nhà phát triển cố gắng phát hiện lỗi trong giai đoạn sớm. Theo các thống kê, lỗi phần mềm tạo thành một gánh nặng rất lớn cho cơng ty phần mềm phát triển. Việc xác minh phần mềm là một quá trình khĩ khăn. Để quản lý tốt hơn lỗi lập trình do con người tạo ra, nhân sự kiểm thử phần mềm được phát triển lên số lượng lớn. Do đĩ, việc xác định các mơ-đun bị lỗi sớm sẽ hỗ trợ sự phát triển của các hệ thống đáng tin cậy thơng qua việc cải tiến lập lịch và kiểm sốt chất lượng phần mềm. Thơng tin bị lỗi cĩ thể cung cấp dữ liệu cĩ giá trị để cải thiện hiệu quả lỗi phần mềm. Từ những yếu tố trên các phương pháp dự đốn lỗi phần mềm được ra đời. Như nhiều nghiên cứu cho thấy các phần mềm kiểm thử trung bình tiêu thụ ít nhất 50% hiệu suất trong phát triển [1, 2], việc xác định các mơ-đun bị lỗi cĩ thể cĩ tác động tiết kiệm chi phí đáng kể đối với phát triển phần mềm. Một loạt các mơ hình dự đốn lỗi đã được đề xuất [3,4]. Thơng thường chúng ta phát triển các mơ hình dự đốn lỗi phần mềm theo hướng thống kê các mơ-đun bị lỗi cĩ khả năng xảy ra trong quá trình triển khai phần mềm hoặc trong một khoảng thời gian cụ thể sau khi triển khai. Các mơ hình dự báo dựa trên dữ liệu lỗi đã được thu thập và lựa chọn mơ hình đánh giá chất lượng phù hợp, định lượng đánh giá một số khía cạnh của chất lượng hệ thống. Chất lượng hệ thống, chẳng hạn như bảo trì [5], được mơ tả nhiều nhất về độ đo phức tạp trong bài tốn dự đốn lỗi. Nhiều nghiên cứu nghiên cứu Basili et al. [6], Emam al. [7], Gyimothy[8], và Olague [9], cho thấy rằng các mơ hình dự đốn lỗi thống kê cĩ thể cung cấp đánh giá hợp lý khi dự đốn các mơ-đun hệ thống bị lỗi bằng cách sử dụng các độ đo hướng đối tượng (Object Oriented). Tuy nhiên, khi các độ đo thì cĩ hiệu quả khác nhau từ nhiều dự án khác nhau, việc dự đốn lỗi là khĩ khăn để đạt được. Mơ hình dự đốn thu được từ một dự án này hiếm khi mang lại hiệu quả trong việc dự đốn các mơ-đun dễ bị lỗi thuộc các dự án khác bởi vì khơng cĩ dữ liệu lịch sử lỗi [10]. Trang 7
12. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Theo Zhang [11] trong khi một số ít lỗi là do các trình biên dịch tạo ra, nhiều lỗi xuất phát từ lỗi do các lỗi do lập trình viên trong quá trình thiết kế và lập trình tạo ra. Những vấn đề này khơng chỉ làm giảm chất lượng của phần mềm mà cịn đẩy chi phí kiểm tra [12]. Thật vậy, nhiều cơng ty phát triển phần mềm bao gồm Microsoft đã dành một lượng tiền lớn và nỗ lực để thử nghiệm các sản phẩm phần mềm của họ trước khi phát hành chúng cho khách hàng[13]. Bằng cách tập trung vào các trường hợp bị lỗi, các cơng ty phát triển phần mềm cĩ thể giảm chi phí và nâng cao hiệu quả tổng thể của quá trình thử nghiệm thơng qua phân bổ tài nguyên thơng tin. 1.2. MỐI LIÊN HỆ GIỮA ĐỘ ĐO VÀ LỖI PHẦN MỀM Quá trình xác định các mơ-đun phần mềm dễ bị lỗi tại giai đoạn đầu được gọi là dự đốn lỗi phần mềm. Nhiều nghiên cứu đã được cơng bố trong tài liệu, hầu hết trong số họ nhằm mục đích xây dựng mơ hình dự đốn lỗi bằng cách sử dụng các độ đo phần mềm (ví dụ: số dịng mã lệnh – Line Of Code LOC), dữ liệu lịch sử và thuật tốn phân loại để khai thác dữ liệu. Với sự phát triển khơng ngừng của máy tính và dữ liệu, các kĩ thuật học máy đang từng bước được áp dụng rộng rãi trong mọi lĩnh vực của cuộc sống, trong đĩ cĩ lĩnh vực phát triển phần mềm. Cho đến hiện nay, đã cĩ một số cơng trình nghiên cứu áp dụng các kĩ thuật học máy vào dự đốn lỗi như Nạve Bayes, rừng ngẫu nhiên (Random Forest), Máy vector hỗ trợ SVM, Một số nghiên cứu đã cài đặt và đánh giá hiệu quả của các kĩ thuật trên trong dự đốn lỗi cho các phần mềm mã nguồn Java, dựa trên các độ đo trích xuất từ mã nguồn phần mềm 1.3. ĐỘ ĐO PHẦN MỀM Độ đo phần mềm cĩ thể được coi là một độ đo định lượng gán các ký hiệu hoặc số cho các đặc điểm của các trường hợp được dự đốn [14]. Trên thực tế, chúng là các tính năng các thuộc tính, mơ tả nhiều thuộc tính như độ tin cậy, nỗ lực, độ phức tạp và chất lượng của các sản phẩm phần mềm. Những độ đo này đĩng một vai trị quan trọng trong việc xây dựng một bộ dự báo lỗi phần mềm hiệu quả. Chúng cĩ thể được chia thành hai loại chính: độ đo mã nguồn và độ đo quá trình [15]. 1.3.1. Độ đo mã nguồn (Code Metrics)  Độ đo mã nguồn (Code Metrics) Độ đo mã nguồn cịn được gọi là độ đo sản phẩm, được thu thập trực tiếp từ mã nguồn hiện tại. Những độ đo này đo độ phức tạp của mã nguồn dựa trên giả định rằng các thành phần phần mềm phức tạp cĩ nhiều khả năng chứa lỗi hơn. Trong suốt lịch sử kỹ thuật phần mềm, nhiều độ đo mã khác nhau đã được sử dụng để dự đốn lỗi phần mềm. Trang 8
13. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Kích thước (Size): độ đo đầu tiên là độ đo kích thước được giới thiệu bởi Akiyama [16]. Để dự đốn số lỗi, tác giả sử dụng số dịng mã lệnh làm độ đo duy nhất. Sau đĩ, nhiều nghiên cứu dự đốn lỗi phần mềm đã áp dụng độ đo này để xây dựng các dự đốn [17,18,19,20]. Tuy nhiên, chỉ sử dụng độ đo này quá đơn giản để đo độ phức tạp của sản phẩm phần mềm. Halstead và McCabe: Vì lý do này, các độ đo hữu ích, được sử dụng rộng rãi và dễ sử dụng khác đã được áp dụng để tạo ra các tiên đốn lỗi [17,21,22]. Các độ đo này được gọi là các thuộc tính mã tĩnh được giới thiệu bởi McCabe (1976) và Halstead (1977). Các thuộc tính Halstead được chọn dựa trên độ phức tạp đọc của mã nguồn. Chúng được xác định bằng cách sử dụng một số độ đo cơ bản được thu thập từ phần mềm bao gồm: Ký hiệu Mơ tả µ1 Số tốn tử riêng µ2 Số tốn hạng riêng N1 Tổng số tốn tử N2 Tổng số tốn hạng ∗ µ1 Số lượng nhỏ nhất số tốn tử ∗ µ2 Số lượng nhỏ nhất số tốn hạng Bảng 1.1 Độ đo Halstead ∗ ∗ Bốn độ đo đầu tiên tự giải thích trong khi µ1 và µ2 là tốn tử tiềm năng và tốn ∗ hạng được đếm trong một cá thể phần mềm. Ví dụ, µ1= 2 là số lượng tốn tử tối thiểu cho hàm mặc định với tên hàm. Độ đo Halstead được xác định bằng cách sử dụng các độ đo ở trên bao gồm: Tên Mơ tả Length: N = N1+N2 Độ dài chương trình Vocabulary: µ= µ1+ µ2 Kích thước Volume V = N log2 µ Thơng tin nội dung của chương trình Measure D= (N1/2) * (N2/2) Độ khĩ của chương trình Measure E= D*V Yêu cầu thực thi chương trình Measure B= ^(2/3)/3000 Số lượng lỗi mong muốn trong chương trình Measure T=E/18 Thời gian để thực thi chương trình Bảng 1.2 Mơ tả độ đo Halstead Các thuộc tính của McCabe là các độ đo chu trình thể hiện sự phức tạp của một sản phẩm phần mềm. Khác với các thuộc tính Halstead, các thuộc tính của McCabe đo độ phức tạp của cấu trúc mã nguồn. Chúng thu được bằng cách tính số lượng các thành phần, vịng cung và nút được kết nối trong các biểu đồ luồng điều khiển của mã nguồn. Trang 9
14. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Mỗi nút của biểu đồ luồng biểu diễn một câu lệnh chương trình trong khi một cung là luồng của kiểm sốt từ một câu lệnh khác. Các độ đo của McCabe, Halstead và của Akiyama là những độ đo tiêu biểu của các độ đo hướng phương thức.  Độ đo hướng lớp Bên cạnh các độ đo hướng phương thức, từ khi các ngơn ngữ lập trình hướng đối tượng trở nên phổ biến, các độ đo hướng lớp cũng đã được đề xuất và tiêu biểu nhất là độ đo của Chidamber-Kemerer (CK) [23]. Các độ đo này được thiết kế từ những đặc trưng hướng đối tượng như tính phụ thuộc (coupling), tính gắn kết (cohension), tính thừa kế (inheritance), tính che giấu dữ liệu (information hide). Các độ đo CK bao gồm số phương thức cĩ trọng số trong lớp, độ sâu của cây thừa kế, số con, tính liên kết giữa các lớp đối tượng, tính đáp ứng của một lớp, sự thiếu hụt tính gắn kết trong phương thức. Ký hiệu Mơ tả WMC Weighted methods per class DIT Depth of inheritance tree NOC Number of children CBO Coupling between object classes RFC Response for a class LCOM Lack of cohesion of methods Bảng 1.3. Độ đo Chidamber & Kemerer, 1994 (CK) Các độ đo trong bảng 3 được mơ tả như sau: Weighted methods per class (WMC): Độ đo này đo lường sự phức tạp của một lớp riêng lẻ. Nĩ là một tổng trọng số của tất cả các phương thức trong một lớp. Depth of inheritance tree(DIT): Độ đo này đo chiều dài của đường dẫn trong cây thừa kế dài nhất ở một lớp. Nếu cây thừa kế cho lớp được đo sâu hơn thì sẽ khĩ ước lượng được hành vi của lớp. Number of children (NOC): Độ đo này tính số lượng các lớp con kế thừa ngay từ lớp hiện tại. Coupling between object classes (CBO): Độ đo này đo lường sự phụ thuộc của một lớp đối với những người khác bằng cách đếm số lượng các lớp khác phụ thuộc với lớp được đo. Một lớp phụ thuộc với các lớp khác nếu nĩ gọi các biến hoặc các hàm của các lớp khác [24]. Response for a class (RFC): độ đo đếm số phương thức cĩ khả năng được thực thi để đáp ứng với một thơng điệp nhận được bởi một đối tượng của một lớp [25] Lack of cohesion of methods (LCOM): Độ đo này là hiệu số cặp phương thức khơng chia sẻ biến thành viên từ số cặp phương thức chia sẻ ít nhất một biến thành viên. Trang 10
15. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM 1.3.2. Độ đo quy trình (Process Metrics) Ngồi các độ đo mã nguồn trên trên, lịch sử của dự đốn lỗi phần mềm cũng đã chứng kiến sự xuất hiện của các độ đo quy trình. Giống như các độ đo mã nguồn, các độ đo quy trình cũng được sử dụng rộng rãi để xây dựng các mơ hình dự đốn lỗi [26] Tuy nhiên, thay vì được tính trực tiếp từ mã nguồn hiện tại, các độ đo quy trình được tạo từ các kho phần mềm như hệ thống theo dõi lỗi và các hệ thống kiểm sốt phiên bản. Các độ đo này tập trung vào các thuộc tính liên quan đến quá trình phát triển phần mềm; ví dụ, thay đổi mã nguồn, chi phí hoặc hiệu quả của các phương pháp được sử dụng. 1.4. ÁP DỤNG CÁC ĐỘ ĐO PHẦN MỀM Hình 1.1 cho thấy tần suất sử dụng các độ đo phần mềm trong tài liệu. Như sự xuất hiện trước đĩ của độ đo phần mềm trong lịch sử dự đốn lỗi phần mềm, khơng ngạc nhiên khi các độ đo mã nguồn được sử dụng thường xuyên hơn so với các độ đo quá trình[15]. Hơn nữa, khi một loại độ đo mới được tạo ra, nĩ thường được so sánh với các độ đo mã nguồn để làm sáng tỏ hiệu suất. Trong khi đĩ, các độ đo quy trình đã được giới thiệu sau khi các kho phần mềm bao gồm các hệ thống theo dõi lỗi, các thay đổi mã nguồn, lưu trữ thư, khai thác dữ liệu và các hệ thống kiểm sốt phiên bản được sử dụng rộng rãi. Hình 1.1 Tần suất sử dụng độ đo phần mềm trong các nghiên cứu Trong lĩnh vực dự đốn lỗi phần mềm, cũng cĩ rất nhiều cuộc tranh luận về loại độ đo nào hoạt động tốt hơn. Trong khi Menzies [18] nĩi rằng các độ đo mã nguồn tĩnh vẫn hiệu quả để tạo ra các yếu tố dự báo lỗi; Rahman và Devanbu [27] tin rằng gần đây, các độ đo quy trình hữu ích hơn do sự trì trệ của các độ đo mã nguồn. Trên thực tế, hiệu quả của các độ đo quy trình để dự đốn lỗi phần mềm đã được xác nhận trong một số nghiên cứu [27,28,29]. Mặc dù vậy, chỉ sử dụng các độ đo phần mềm là Trang 11
16. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM khơng đủ để xây dựng các yếu tố dự đốn hiệu quả. Trong văn học, nhiều nhà nghiên cứu đã chứng minh rằng các yếu tố dự đốn lỗi phần mềm hoạt động tốt hơn khi sử dụng các kỹ thuật học máy để học từ dữ liệu lịch sử [15]. 1.5. KỸ THUẬT HỌC MÁY TRONG DỰ ĐỐN LỖI PHẦN MỀM Học máy là một ngành khoa học khám phá việc xây dựng và nghiên cứu các kỹ thuật cho phép các chương trình máy tính học hỏi từ dữ liệu mà khơng được lập trình rõ ràng [30]. Về cơ bản, máy học tập cung cấp các chương trình máy tính với khả năng bắt chước quá trình học tập của con người. Quá trình này là quan sát hiện tượng và tổng quát từ các quan sát [31]. Học máy thường được chia thành hai loại chính: học tập cĩ giám sát và khơng giám sát. Trong học tập khơng giám sát, các thuật tốn được sử dụng để tìm hiểu các yếu tố dự đốn từ dữ liệu khơng được dán nhãn. Trong khi đĩ, học tập cĩ giám sát học các mơ hình dự đốn dựa trên một tập hợp dữ liệu đầu vào với thơng tin nhãn. Trong học tập cĩ giám sát, các kết quả đầu ra cĩ thể là các số thực trong các hồi quy hoặc các nhãn lớp trong phân loại. Khi phân loại đầu vào thành hai hoặc nhiều lớp, việc học được giám sát đơi khi được gọi là phân loại. Cĩ một loạt các kỹ thuật phân loại đã được khai thác rộng rãi trong các tài liệu để ghi nhãn các thể hiện phần mềm là lỗi hoặc khơng lỗi. 1.5.1. Cây quyết định (Decision Tree Classification) Cây quyết định là một trong những thuật tốn dự đốn phổ biến được áp dụng cho một loạt các tác vụ trong thống kê, khai phá dữ liệu và học máy. Thuật tốn này nhằm mục đích xây dựng một cây quyết định để phân loại một cá thể đích dựa trên các tính năng đầu vào. Nĩ cũng cĩ thể được biểu diễn như là câu lệnh if else để tăng cường khả năng đọc của con người Một ví dụ về cây quyết định, để hỗ trợ quá trình ra quyết định, được trình bày trong hình 1.2. Cây quyết định trước hết được xây dựng bằng cách phân loại các đặc điểm từ gốc xuống một số lá. Mỗi nút lá đại diện cho một thử nghiệm trên một đối tượng địa lý trong khi mỗi nhánh là kết quả cĩ thể cĩ của phép thử. Để gắn nhãn một thể hiện, các phép thử được thực hiện tại mỗi nút từ gốc đến các nút lá thơng qua các nhánh thích hợp [32]. Trang 12
17. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Hình 1.2 Cây quyết định đơn giản Cĩ nhiều mơ hình được phát triển bằng cách sử dụng cây quyết định để dự đốn các lỗi phần mềm [18,33,34]. Người học J48, là một triển khai JAVA của thuật tốn C4.5 [35], cĩ thể được xem là thuật tốn được sử dụng rộng rãi nhất. Là một thuật tốn cây quyết định bình thường, J48 phân tách đệ quy một tập dữ liệu dựa trên các thử nghiệm về các giá trị tính năng để tách các kết quả cĩ thể cĩ. 1.5.2. Nạve Bayes Một cách khác để xây dựng các mơ hình dự đốn lỗi phần mềm là sử dụng một kỹ thuật học máy rất hữu ích, Nạve Bayes. Kỹ thuật này là một trong các phân loại xác suất dựa trên định lý Bayes với các giả định độc lập giữa các thuộc [36]. Khơng cĩ ước lượng tham số lặp phức tạp, một trình phân loại Nạve Bayes dễ xây dựng và phù hợp với dữ liệu đầu vào. Mặc dù đơn giản, các nghiên cứu so sánh của Langley và Sage [37] đã chỉ ra rằng Nạve Bayes cĩ hiệu quả đối với các tập dữ liệu lớn và thường hoạt động tốt hơn các trình phân loại phức tạp hơn như cây quyết định trong các miền học được giám sát. 1.5.3. K-nearest Neighbor Ngồi cây quyết định J48 và Nạve Bayes, K-Nearest Neighbor [38], một trong những thuật tốn dựa trên khoảng cách đơn giản, cũng thường được áp dụng cho phân loại mẫu. Trong lĩnh vực dự đốn lỗi phần mềm, nhiều nghiên cứu cũng đã sử dụng K- Nearest Neighbor để phân loại các bộ dữ liệu thử nghiệm [39]. Mặc dù sự đơn giản của nĩ, Weinberger và Saul nĩi rằng thuật tốn K-Nearest Neighbor thường hoạt động tốt và tạo ra kết quả cạnh tranh trong thực tế. Đáng chú ý, thuật tốn cĩ thể được cải thiện đáng kể khi kết hợp với kiến thức trước thu được từ giai đoạn học dữ liệu [40]. Trang 13
18. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Hình 1.3 Ví dụ K-Nearest Neighbor Thuật tốn K-Nearest Neighbor phân loại một cá thể mới dựa trên việc đo sự giống nhau giữa nĩ và mọi cá thể hiện cĩ khác. Sự tương tự được đo bằng các hàm khoảng cách như khoảng cách Manhattan [41], khoảng cách Euclide [42] và khoảng cách Mahalanobis [43]. Khi nĩi đến K-Nearest Neighbor, số lượng cá thể gần nhất được sử dụng để dự đốn cĩ thể ảnh hưởng đến hiệu suất dự đốn. Thơng thường, con số này là số lẻ nếu phân loại các cá thể thử nghiệm thành hai loại. Các trường hợp thử nghiệm sẽ được dán nhãn dựa trên đa số phiếu. Khoshgoftaar [44] và Ganesan[45] đã xây dựng các hệ thống lý luận dựa trên trường hợp (Case Base Reasoning CBR) để phân loại các thành phần phần mềm bằng cách chỉ chọn k=1 là đơn vị lân cận gần nhất. El-Emam và cộng sự, vào năm 2001, đã cải thiện bộ phân loại CBR bằng cách sử dụng đa số phiếu trong các trường hợp của ba và năm cá thể gần nhất. Trong khi lựa chọn một số lượng nhỏ các cá thể gần nhất cĩ thể dẫn đến một tác động lớn hơn đến phân loại tiếng ồn, sẽ làm tăng chi phí tính tốn. Do đĩ, một cách tiếp cận đơn giản là đặt số lượng hàng xĩm gần nhất thành căn bậc hai của số lượng các cá thể huấn luyện(k=√n). Một phần mở rộng đơn giản khác, cĩ thể cải thiện độ chính xác của các mơ hình dự báo, là áp dụng các trọng số. Lý do cho việc sử dụng trọng số là mức độ khác nhau về sự giống nhau giữa cá thể được phân loại và hàng xĩm của nĩ. Như vậy, thay vì đưa ra trọng số bằng nhau cho tất cả các láng giềng gần nhất [45], trọng số của các cá thể huấn luyện được thiết lập khác nhau tùy thuộc vào khoảng cách của chúng đến cá thể thử nghiệm [44]. Cĩ nhiều cách để đạt được trọng lượng. Theo đề xuất của Cunningham và Delany [46], một kỹ thuật khá chung là sử dụng nghịch đảo của khoảng cách là trọng lượng của từng trường hợp. Điều này cĩ nghĩa là những người hàng xĩm gần gũi hơn cĩ trọng lượng cao hơn những người cha. Một cách khác để đặt trọng số dựa trên số lượng cá thể của mỗi lớp trong dữ liệu huấn luyện. Bằng cách chia Trang 14
19. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM đơn giản số lượng hàng xĩm gần nhất của một lớp cho số lượng cá thể của lớp này trong tập dữ liệu huấn luyện, phương pháp này cĩ thể trở thành một giải pháp tốt để giảm thiểu vấn đề mất cân bằng lớp. 1.5.4. Support Vector Machine (SVM) SVM là một trình phân loại khác thường được sử dụng trong nhiều ứng dụng. SVM là một kỹ thuật học tập dựa trên lõi do Boser, Guyon và Vapnik đề xuất vào năm 1992, về cơ bản đề cập đến các vấn đề nhận dạng mẫu hai lớp [47]. Để thực hiện phân loại, thuật tốn SVM tìm thấy siêu kết nối tối ưu phân tách tất cả các cá thể của một lớp từ lớp kia. Siêu kết nối tối ưu, được xác định bởi một số vectơ hỗ trợ [48], thu được khi tối đa hĩa chiều rộng của lề giữa hai lớp. Các vectơ hỗ trợ là các điểm dữ liệu nằm trên ranh giới của đường biên. Ánh xạ tập dữ liệu vào khơng gian nhiều chiều, bản chất của phương pháp SVM là chuyển khơng gian dữ liệu ban đầu thành một khơng gian mới hữu hạn chiều mà ở đĩ cho khả năng phân lớp dễ dàng hơn. Một quả bất kì nằm trên mặt bàn sẽ được gắn với một tọa độ cụ thể. Ví dụ, quả táo nằm cách mép trái 2cm và cách mép dưới 5cm được thể hiện trên trục tọa độ (x, y) tương ứng là (2, 5). x và y chính là tọa độ trong khơng gian hai chiều của quả táo. Khi đưa lên chiều thứ 3 là z(x, y), ta cĩ thể tính được tọa độ của z trong khơng gian 3 chiều dựa vào tọa độ x,y ban đầu. Điểm làm SVM hiệu quả hơn các phương pháp khác chính là việc sử dụng Kernel Method giúp cho SVM khơng cịn bị giới hạn bởi việc phân lớp một cách tuyến tính, hay nĩi cách khác các siêu phẳng cĩ thể được hình thành từ các hàm phi tuyến. Smola [30] lập luận rằng chức năng cơ sở xuyên tâm là hạt nhân phổ biến nhất được sử dụng trong SVM vì mang lại hiệu suất tốt hơn so với những người khác. Xét về dự đốn, sử dụng SVM mang lại một số lợi thế [47] khiến SVM trở thành một trình phân loại hữu ích để dự đốn các lỗi phần mềm. Ưu điểm của SVM • Xử lý trên khơng gian số chiều cao: SVM là một cơng cụ tính tốn hiệu quả trong khơng gian chiều cao, trong đĩ đặc biệt áp dụng cho các bài tốn phân loại văn bản và phân tích quan điểm nơi chiều cĩ thể cực kỳ lớn • Tiết kiệm bộ nhớ: Do chỉ cĩ một tập hợp con của các điểm được sử dụng trong quá trình huấn luyện và ra quyết định thực tế cho các điểm dữ liệu mới nên chỉ cĩ những điểm cần thiết mới được lưu trữ trong bộ nhớ khi ra quyết dịnh • Tính linh hoạt - phân lớp thường là phi tuyến tính. Khả năng áp dụng Kernel mới cho phép linh động giữa các phương pháp tuyến tính và phi tuyến tính từ đĩ khiến cho hiệu suất phân loại lớn hơn. Trang 15
20. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Nhược điểm của SVM là gì? • Bài tốn số chiều cao: Trong trường hợp số lượng thuộc tính (p) của tập dữ liệu lớn hơn rất nhiều so với số lượng dữ liệu (n) thì SVM cho kết quả khá tồi • Chưa thể hiện rõ tính xác suất: Việc phân lớp của SVM chỉ là việc cố gắng tách các đối tượng vào hai lớp được phân tách bởi siêu phẳng SVM. Điều này chưa giải thích được xác suất xuất hiện của một thành viên trong một nhĩm là như thế nào. Tuy nhiên hiệu quả của việc phân lớp cĩ thể được xác định dựa vào khái niệm margin từ điểm dữ liệu mới đến siêu phẳng phân lớp mà chúng ta đã bàn luận ở trên. 1.6. XỬ LÝ DỮ LIỆU Các kỹ thuật tiền xử lý dữ liệu rất quan trọng và được sử dụng rộng rãi trong học máy, nền tảng của hầu hết các nghiên cứu dự đốn lỗi phần mềm Nam [15]. Cĩ nhiều yếu tố ảnh hưởng tiêu cực đến hiệu suất của thuật tốn học máy như thơng tin khơng đáng tin cậy và khơng liên quan hoặc dữ liệu nhiễm ồn [49]. Những vấn đề này cĩ thể được giải quyết bằng cách sử dụng tiền xử lý dữ liệu cung cấp các kỹ thuật bao gồm làm sạch dữ liệu, chuẩn hĩa, lựa chọn thuộc tính và trích xuất. Vì sự khác biệt trong việc lựa chọn mơ hình, đối tượng và độ đo giữa các nghiên cứu, kỹ thuật tiền xử lý dữ liệu cĩ thể hoặc khơng được sử dụng và chúng được áp dụng theo nhiều cách khác nhau tùy thuộc vào từng nghiên cứu. 1.6.1. Chuẩn hĩa dữ liệu Chuẩn hĩa dữ liệu là một nhiệm vụ tiền xử lý cơ bản trong học máy và khai thác dữ liệu [50], nhằm cải thiện hiệu suất của các mơ hình phân loại bằng cách đưa ra trọng số bằng nhau cho tất cả các thuộc tính của tập dữ liệu. Cĩ rất nhiều phương pháp chuẩn hĩa cĩ thể sử dụng được. Một trong số đĩ là sử dụng bộ tiền xử lý nhật ký lọc được trình bày bởi Menzies [18] để bình thường hĩa các giá trị của các thuộc tính mã tĩnh cĩ phân phối số mũ. Trong phương pháp này, bộ lọc logarit được sử dụng để thay thế tất cả các giá trị số n với logarit của n. Các thí nghiệm được thực hiện bởi Menzies [18] cho thấy rằng sau khi được lọc, các giá trị này trở nên thậm chí nhiều hơn và do đĩ dễ dàng hơn cho các mơ hình dự đốn hoạt động trên chúng. Phương pháp lọc log cũng đã được áp dụng trong một số nghiên cứu khác cĩ cùng chủ đề thí nghiệm [21]. Ngồi kỹ thuật lọc log, các phương pháp chuẩn hĩa dữ liệu khác là sự khác biệt [51] và tính năng nhân rộng [52]. Các phương thức này chuyển đổi các giá trị của một tập dữ liệu gốc thành một phạm vi từ 0 đến 1 và đảm bảo rằng mỗi thuộc tính nhận được một trọng số bằng nhau. Trong khi trước đây là phân chia đơn giản mọi giá trị số của từng thuộc tính theo difference=x_max - x_min, sau đĩ trừ giá trị nhỏ nhất từ mỗi Trang 16
21. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM thuộc tính trước khi thực hiện phép chia. Trong tài liệu, phương pháp chuẩn hĩa dữ liệu bằng cách chia tỷ lệ tính năng cịn được gọi là min-max [53] và cơng thức của nĩ được hiển thị như sau: Một phương pháp chuẩn hĩa khác cĩ ích cho các quần thể phân bố thơng thường, là điểm chuẩn, cịn được gọi là điểm số bình thường hoặc điểm z [49] Phương pháp tính tốn điểm chuẩn được dựa trên trung bình phân phối và độ lệch chuẩn cho mỗi thuộc tính. Sau khi xác định giá trị trung bình và độ lệch chuẩn, giá trị trung bình được trừ từ mỗi thuộc tính. Sau đĩ, các giá trị thu được từ các phép trừ của mỗi thuộc tính được chia cho độ lệch chuẩn của nĩ. Theo Nam [15], phương pháp chuẩn hĩa này rất phổ biến trong nhiều kỹ thuật học máy, và nĩ dẫn đến độ chính xác cao hơn trong việc dự đốn các lỗi phần mềm. 1.6.2. Giảm tiếng ồn (Noise reduction) Để xây dựng và đánh giá các mơ hình dự đốn, dữ liệu lỗi thường được trích xuất từ các tệp nhật ký, các phiên bản và báo cáo lỗi trong cơ sở dữ liệu theo dõi lỗi một cách tự động bằng cách sử dụng các cơng cụ. Tuy nhiên, các nghiên cứu gần đây đã chỉ ra rằng dữ liệu được thu thập từ các điều khiển phiên bản, báo cáo lỗi và nhật ký thay đổi cĩ thể bị nhiễu. Ví dụ, các nghiên cứu về Aranda và Venolia đã chứng minh rằng rất nhiều thơng tin bị thiếu trong các báo cáo lỗi. Trong năm 2009, Bird cũng đã tìm thấy sự thiên vị cĩ hệ thống trong lịch sử phiên bản mã và các hệ thống theo dõi lỗi, đĩ là nguyên nhân dẫn đến kết quả dự đốn sai. Để đo khả năng chống nhiễu của các yếu tố dự đốn lỗi, Kim [29] trước hết đề xuất thêm thơng tin tiêu cực và sai lệch trong tập dữ liệu huấn luyện trong khi vẫn khơng thay đổi dữ liệu thử nghiệm. Điều này nhằm đo lường tính chính xác của các thuật tốn dự đốn. Các tác giả sau đĩ tạo ra một phương pháp phát hiện tiếng ồn được gọi là nhận dạng tiếng ồn gần nhất. Phương pháp này sử dụng khoảng cách Euclide để tính tỷ lệ tương tự giữa dữ liệu huấn luyện và danh sách các thành phần ồn ào. Các thành phần sẽ được coi là ồn nếu tỷ lệ đạt đến một ngưỡng nhất định. Theo Kim et al. [29] phương pháp này cĩ lợi vì dữ liệu thu thập sẽ phù hợp hơn với dự đốn lỗi khi tiếng ồn cĩ thể được phát hiện và loại bỏ trước đĩ. Trang 17
22. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM 1.6.3. Lựa chọn thuộc tính (Attribute Selection) Ngồi dữ liệu ồn ào, hiệu suất kém của các yếu tố dự đốn lỗi cũng được gây ra bởi sự dư thừa của các thuộc tính huấn luyện [54]. Để đạt được các dự đốn chính xác, tất cả các tốn tử, chú thích, tên lớp, các biến và các từ khĩa ngơn ngữ lập trình cĩ thể được xem xét như là các thuộc tính cho việc huấn luyện các bộ dự đốn. Hơn nữa, các độ đo mã nguồn tĩnh, độ đo hướng đối tượng và các độ đo khác cũng cĩ thể được sử dụng cùng nhau để tập hợp các tập dữ liệu. Những điều này dẫn đến một tập hợp thuộc tính lớn. Tuy nhiên, nĩ thường khơng khả thi đối với các mơ hình dự đốn để xử lý một tập thuộc tính lớn được thiết lập cùng với sự cĩ mặt của tiếng ồn và các tương tác phức tạp[54]. Một giải pháp cĩ thể cho vấn đề này là chọn một tập hợp con các thuộc tính cung cấp hiệu suất tốt nhất của các dự đốn. Phương thức này được gọi là lựa chọn thuộc tính. Cĩ một số lượng lớn các phương pháp đã được đề xuất trong lĩnh vực học máy để lựa chọn thuộc tính Hầu hết trong số đĩ là các loại thành hai loại: phương pháp lọc và trình bao bọc. Bộ lọc tiếp cận, chẳng hạn như Chi-Squared, Gain Ratio và đánh giá thuộc tính ý nghĩa (SAE), loại bỏ các thuộc tính cĩ ý nghĩa thấp nhất cho đến khi đạt được hiệu suất dự đốn tối ưu. Họ sử dụng các chẩn đốn dựa trên các đặc tính của dữ liệu để đánh giá các thuộc tính. Trong khi đĩ, cách tiếp cận wrapper đánh giá các thuộc tính dựa trên điểm số được đưa ra bởi các thuật tốn học tập như Nạve Bayes và Suppport Vector Machine Theo lập luận của Hall [55] các phương pháp lọc phù hợp hơn cho các tập dữ liệu với một số lượng lớn các thuộc tính. Một ưu điểm khác của việc sử dụng các phương pháp lọc là khả năng làm việc kết hợp với bất kỳ thuật tốn học máy nào trong khi các cách tiếp cận wrapper sử dụng các thuật tốn học tập giống nhau cho cả lựa chọn và phân loại thuộc tính . Tuy nhiên, giới hạn của các phương pháp lọc là chúng cĩ thể gây ra sự dư thừa của các thuộc tính được chọn. Ví dụ, phương pháp lọc truyền thống là tập trung vào việc giữ lại các thuộc tính liên quan. Sau khi gán giá trị phù hợp cho từng thuộc tính, kỹ thuật sẽ đánh giá từng thuộc tính riêng lẻ bằng cách sử dụng hàm đánh giá. Thuộc tính được chọn nếu giá trị độ liên quan của chúng lớn hơn ngưỡng đã cho. Cách tiếp cận này khơng tính đến sự phụ thuộc giữa các thuộc tính. Do đĩ, họ cĩ xu hướng chọn các thuộc tính dư thừa. 1.7. Các độ đo đánh giá 1.7.1. Phân loại đo lường Để đánh giá mơ hình dự đốn lỗi phần mềm, các biện pháp đánh giá bao gồm false positive rate, độ chính xác (accuracy), precision, recall, balance and F-measure [59] được áp dụng. Trang 18
23. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Trước đĩ, các ký hiệu A, B, C, D được sử dụng trong đĩ: A là số lượng mơ-đun bị lỗi được dự đốn là lỗi. B là số mơ-đun bị lỗi được phân loại là khơng cĩ lỗi. C là số mơ-đun khơng cĩ lỗi được dự đốn là lỗi. D là số mơ-đun khơng cĩ lỗi được dự đốn là khơng cĩ lỗi. Độ chính xác (accuracy): Tỷ lệ là số lượng mơ đun được dự đốn chính xác trên tổng số mơ-đun. Từ phương trình, độ chính xác bị ảnh hưởng nặng nề bởi sự cân bằng của lớp. Tuy nhiên, các bộ dữ liệu phần mềm thường thì nhiều mơ-đun khơng cĩ lỗi nhiều hơn các mơ-đun bị lỗi. Nếu một mơ hình dự đốn tất cả các mơ-đun khơng bị lỗi, độ chính xác sẽ rất cao mặc dù khơng cĩ mơ-đun bị lỗi nào được dự đốn chính xác. Ví dụ, tỷ lệ lỗi trung bình của bộ dữ liệu PROMISE là 18%. Nếu một mơ hình dự đốn tuyên bố tất cả các mơ-đun là khơng cĩ lỗi, độ chính xác của nĩ sẽ là 82% mà khơng dự đốn chính xác bất kỳ mơ-đun bị lỗi nào. Do sự mất cân đối giữa các lớp trong tập dữ liệu, độ chính xác khơng thể được coi là thước đo thích hợp để so sánh các mơ hình dự báo [15]. False positive rate: tỉ lệ báo động nhầm cũng được biết là xác suất báo động nhầm [17]. Tỷ lệ này là số mơ-đun khơng cĩ lỗi được dự đốn sai như số lỗi của các mơ-đun khơng cĩ lỗi. Recall: Recall cịn được gọi là báo động đúng hoặc xác suất phát hiện (probability of detection) [17]. Recall được tính bằng tỷ lệ là số lượng mơ-đun bị lỗi được dự đốn chính xác là bị lỗi với số lượng mơ-đun bị lỗi. Balance: Để chọn một cặp xác suất tối ưu của báo động giả và xác suất phát hiện lỗi (pf, pd), Menzies et al. [17] đề xuất một biện pháp được gọi là balance (bal). Biện pháp này là khoảng cách Euclide chuẩn hĩa từ điểm mong muốn (pd = 1, pf = 0) thành một cặp (pf, pd). Mặc dù balance là một biện pháp khá hữu ích được sử dụng trong việc đánh giá các yếu tố dự báo lỗi [17], nĩ khơng phổ biến và vẫn cĩ những hạn chế. Khi balance là Trang 19
24. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM khoảng cách, các mơ hình dự đốn cĩ giá trị khác nhau của (pf, pd) cĩ thể cĩ cùng giá trị của balance. Tuy nhiên, điều này khơng cĩ nghĩa là những mơ hình đĩ cĩ hiệu suất ngang nhau trong thực tế, Menzies nhấn mạnh rằng sử dụng một cặp (pf, pd) là khơng thực tế trong việc phân loại các tập dữ liệu mất cân bằng vì tỷ lệ chính xác thấp. Precision: Tỷ lệ là số lượng mơ-đun bị lỗi được dự đốn chính xác là bị lỗi với số lượng mơ-đun được dự đốn là lỗi. Một mơ hình dự đốn trình bày một hiệu suất tốt nếu đạt được các giá trị thu hồi (recall), độ chính xác (accuracy) và giá trị thấp hơn của độ báo động giả (False positive rate). Tuy nhiên, người ta biết rằng việc recall cĩ thể được cải thiện bằng cách giảm accuracy và ngược lại [62]. Bởi vì sự cân bằng giữa accuracy và recall, khơng dễ so sánh các hiệu năng của bộ dự đốn lỗi dựa trên chỉ recall hoặc accuracy. Kết quả là, F- measure, một thước đo tổng hợp recall và accuracy, đã được sử dụng để so sánh kết quả dự đốn [59]. F- measure: Chức năng hài hịa của recall và accuracy [59]. F-measure đã được sử dụng trong nhiều bài báo dự đốn lỗi [29,59] Độ đo này trình bày một điểm thống nhất để đánh giá mơ hình dự đốn sau khi cân bằng sự cân bằng giữa recall và accuracy. Giá trị của F-measure tỷ lệ thuận với hiệu suất của một mơ hình. Rõ ràng là tất cả các biện pháp trên được tính dựa trên các giá trị của A, B, C, D, là kết quả của các quyết định nhị phân từ người dự đốn. Tuy nhiên, nhiều mơ hình dự đốn lỗi phân loại một mơ hình bằng cách đưa ra xác suất lỗi thay vì quyết định nhị phân. Điều này đặt ra một câu hỏi về cách xác định cụ thể hĩa xác suất liên tục. Để giải quyết câu hỏi này, Rahman et al. [60] đề xuất sử dụng một ngưỡng xác suất trong đĩ một mơ-đun được coi là bị lỗi nếu xác suất lỗi của nĩ đạt đến ngưỡng. Nếu khơng, module được phân loại là khơng cĩ lỗi. AUC: AUC biểu thị khu vực theo đường cong (ROC). AUC là một thước đo khơng tham số độc lập với ngưỡng và khơng bị ảnh hưởng bởi sự mất cân bằng trong lớp. ROC là một đường cong hai chiều được vẽ theo xác suất của báo động giả (trục x) và xác suất phát hiện (trục y). Theo Rahman và Devanbu một mơ hình tốt hơn khi đường cong ROC của nĩ gần với điểm pd = 1 và pf = 0. Một bộ dự báo hồn hảo, cĩ AUC là 1. Ngược lại, một đường cong phủ định minh họa mơ hình khơng tốt với xác suất báo động giả và xác suất phát hiện thấp. Ở những nghiên cứu khác đã phát hiện ra rằng nếu mơ hình phủ nhận kết quả dự đốn của nĩ, đường cong âm sẽ trở thành Trang 20
25. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM đường cong ưu tiên đại diện cho một bộ dự đốn tốt. Một mơ hình ngẫu nhiên khơng cung cấp thơng tin luơn cĩ AUC là 0,5 vì nĩ cĩ xu hướng gần với đường chéo pd = pf,. Xác suất báo động giả và xác suất phát hiện khác nhau tùy thuộc vào ngưỡng dự đốn xác suất của từng mơđun dự đốn [15]. Tuy nhiên, AUC cĩ tất cả các giá trị ngưỡng cĩ thể xem xét hiệu suất dự đốn. Do đĩ, AUC là độc lập với ngưỡng, và nĩ là một biện pháp ổn định. Hình 1.4 Ví dụ về ROC AUCEC: Mặc dù AUC là một biện pháp hữu ích để đánh giá hiệu suất của các phần mềm dự đốn lỗi, nhưng nĩ khơng tính đến tính hiệu quả về chi phí. Do đĩ, Arisholm, Briand và Fuglerud trình bày một biện pháp được gọi là khu vực dưới đường cong AUCEC (area under cost-effectiveness curve). Hiệu quả chi phí trong dự đốn lỗi được xác định dựa trên tỷ lệ phần trăm lỗi cĩ thể được tìm thấy trong một tỷ lệ nhất định các dịng mã lệnh được kiểm tra [15]. Cụ thể hơn, một mơ hình sẽ hiệu quả về chi phí hơn nếu nĩ cĩ thể tìm thấy nhiều lỗi hơn với ít nỗ lực cố gắng kiểm tra hơn. Một ví dụ về các đường cong hiệu quả về chi phí AUCE được thể hiện trong Hình 2.13 trong đĩ trục x đại diện cho tỷ lệ phần trăm của các dịng mã lệnhvà trục y là tỷ lệ lỗi tìm thấy. Biểu đồ bên trái cho thấy các yếu tố dự đốn ngẫu nhiên, thực tế và tối ưu được biểu thị bằng đường cong R, P và O tương ứng. Vì một bộ dự đốn ngẫu nhiên sẽ chọn các mơ-đun ngẫu nhiên là bị lỗi, tỷ lệ phần trăm các lỗi được tìm thấy và các dịng mã được kiểm tra là như nhau. Trong trường hợp này, nĩ cĩ AUCEC là 0,5. Trong khi đĩ, theo Rahman [27], AUCEC của dự đốn tối ưu là cao nhất so với Trang 21
26. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM những người khác. AUCEC cao hơn cĩ nghĩa là bộ dự đốn cĩ thể tìm thấy nhiều lỗi hơn bằng cách thử nghiệm ít dịng mã lệnh hơn. Hình 1.5 Đường cong Cost-effective curve Biểu đồ bên phải minh họa các đường cong hiệu quả về chi phí của hai dự đốn khác nhau, P1 và P2. Hai mơ hình cĩ hiệu suất tổng thể giống nhau vì AUCEC của chúng bằng nhau khi kiểm tra tồn bộ các dịng mã. Tuy nhiên, với ngưỡng 20% số dịng, P2 cĩ AUCEC cao hơn P1. Điều này cĩ nghĩa là nếu chỉ kiểm tra 20% dịng mã, P2 sẽ hoạt động tốt hơn P1. Kết quả là, để áp dụng AUCEC như một biện pháp dự đốn lỗi, cần phải xem xét một ngưỡng cụ thể cho tỷ lệ phần trăm của các dịng mã [15]. 1.7.2. Thảo luận về các độ đo Các thống kê được thực hiện bởi Nam [15] cho thấy số lượng của mỗi độ đo được sử dụng trong các nghiên cứu dự đốn lỗi phần mềm điển hình để đánh giá các mơ hình phân loại. Như được minh họa trong Hình 1.6, F-measure là cơng cụ thường được sử dụng nhất để đánh giá mơ hình dự đốn lỗi. Trên thực tế, điều này là hợp lý bởi vì sự đối ngược giữa recall và accuracy gây ra những khĩ khăn để đánh giá hiệu suất của các mơ hình dự đốn với recall nhưng accuracy thấp và ngược lại. Do đĩ, F- measure, một sự trung hịa của hai biện pháp, đã được chọn trong nhiều nghiên cứu dự đốn lỗi [19,27]. Tuy nhiên, các ngưỡng là khác nhau cho việc dự đốn lỗi phần mềm làm cho độ đo F-measure thay đổi. Khi bộ dự đốn phân loại một thành phần là lỗi, nĩ đưa ra xác suất dự đốn là lớn hơn ngưỡng. Lessmann [63] đã chỉ ra rằng, trong tài liệu dự đốn lỗi phần mềm, các ngưỡng thường bị bỏ qua. Điều này dẫn đến kết quả dự đốn khơng nhất quán trong các nghiên cứu. Để giải quyết vấn đề này, các biện pháp AUC và AUCEC, khơng phụ thuộc vào ngưỡng, đã được sử dụng[34,63]. Trang 22
27. Chương 1: TỔNG QUAN VỀ ĐỘ ĐO PHẦN MỀM Hình 1.6 Tổng số các biện pháp đánh giá độ đo được sử dụng trong các nghiên cứu dự đốn lỗi phần mềm (Nam, 2009) Trang 23
28. Chương 2: ĐỘ ĐO TRONG DỰ ĐỐN LỖI PHẦN MỀM Chương 2: ĐỘ ĐO TRONG DỰ ĐỐN LỖI PHẦN MỀM 2.1. GIỚI THIỆU Nhiều nhà nghiên cứ đã xuất bản nhiều nghiên cứu về các đánh giá độ đo phần mềm (software metrics). Trong số các độ đo hướng đối tượng được giới thiệu, độ đo Chidamber và Kemerer hoặc CK được các nhà nghiên cứu trước đĩ đánh giá là được sử dụng và cĩ hiệu quả nhất. Nghiên cứu này tập trung vào các độ đo CK OO được sử dụng làm độ đo để thiết kế cho một nhĩm các hệ thống C ++. Một số nghiên cứu đã áp dụng các độ đo của CK OO để đo lường các độ đo cho hai dự án, UGC và SEQGEN được viết bằng C ++. Họ thấy rằng các độ đo đã cho kết quả tốt và hiểu biết sâu sắc về việc so sánh độ phức tạp của hai dự án và cả sự phức tạp của các lớp riêng lẻ trong một dự án. Tang et al. [24] đã cố gắng tìm ra tương quan các độ đo CK với các lỗi và họ nhận thấy WMC là một yếu tố dự báo tốt về các lớp bị lỗi và RFC là một độ đo tốt cho các lỗi. Li và Henry đã sử dụng các độ đo CK OO cộng với một số độ đo khác bao gồm một số độ đo kích thước (chẳng hạn như số lượng thuộc tính cộng với số phương thức cục bộ), để xác định xem liệu độ đo hướng đối tượng cĩ thể dự đốn khả năng lỗi của chương trình khơng. Đối với các trọng số trong WMC, họ đã sử dụng các số chu kỳ. Trên cơ sở một nghiên cứu thực nghiệm sử dụng phân tích hồi quy, họ đã kết luận rằng các biện pháp này là hữu ích. Ngồi ra, họ cho rằng độ đo Chidamber-Kemerer gĩp phần việc dự đốn chính xác hơn hơn và vượt xa những gì cĩ thể dự đốn bằng cách sử dụng chỉ độ kích thước (size). Một các nghiên cứu gần đây của điều tra khả năng sử dụng lại của các hệ thống hướng đối tượng bằng cách sử dụng các độ đo CK. Họ lựa chọn tập trung vào ba chương trình để kiểm tra các nghiên cứu của họ, chương trình đầu tiên sử dụng kế thừa đa mức, chương trình thứ hai sử dụng đa kế thừa và chương trình thứ ba sử dụng kế thừa phân cấp. Cuối cùng, họ kết luận rằng thừa kế đa mức cĩ tác động nhiều hơn đến khả năng sử dụng lại. Một cơng trình khác cố gắng so sánh một số chương trình được viết bằng C ++ và Java bằng cách sử dụng các đo của CK và họ thấy rằng Java chứng minh được cĩ tính hướng đối tượng hơn so với C ++. So với nghiên cứu trước đây, nghiên cứu này tập trung vào việc tìm ra độ đo nào cĩ ảnh hưởng lớn nhất đến mật độ lỗi trong các hệ thống. Hơn nữa, hầu hết các cơng việc trước đĩ sử dụng dữ liệu từ các hệ thống thương mại / cơng nghiệp, trong khi đĩ, cơng việc này sử dụng dữ liệu từ các dự án nguồn mở. 2.2. ĐỘ ĐO HƯỚNG ĐỐI TƯỢNG (OBJECT ORITEND METRICS) Việc đo lường của các hệ thống hướng đối tượng được bắt nguồn từ các kỹ thuật thiết kế truyền thống, ví dụ, coupling và cohesion và sau đĩ được thơng dịch cho các Trang 24
29. Chương 2: ĐỘ ĐO TRONG DỰ ĐỐN LỖI PHẦN MỀM phương pháp tiếp cận hướng đối tượng. Chidamber và Kemerer đã đề xuất đo lường cho các hệ thống hướng đối tượng, cịn được gọi là độ đo hướng đối tượng Chidamber và Kemerer (độ đo CK OO). Trong các nghiên cứu tiếp theo thì hướng đối tượng được dựa trên một lớp là một tập hợp các đối tượng cĩ các thuộc tính chung và một phương thức là một hoạt động trên một đối tượng được xác định là một phần của khai báo của lớp. Các thuộc tính như coupling và cohesion, độ phức tạp của đối tượng và phạm vi của các thuộc tính sau đĩ được xác định theo các thuật ngữ “ontological ubological” của Bunge. Chẳng hạn, theo thuật ngữ của Bunge, hai đối tượng được phụ thuộc với nhau khi và chỉ khi một trong số chúng cĩ sự tác động qua lại lẫn nhau. X được cho là hành động theo Y nếu khai báo Y bị phụ thuộc vào X. Chidamber và Kemerer (CK) sử dụng các khái niệm hướng đối tượng để xác định một số độ đo được cho là cĩ liên quan đến một số thuộc tính của bản thể học của Bunge. Độ đo OO được chia thành các loại khác nhau bao gồm kích thước(size), sự phụ thuộc(coupling), sự gắn kết(cohesion), tính kế thừa(inheritance), ẩn thơng tin (information hide), tính đa hình(polymorphism) và độ đo tái sử dụng(reuse). 2.2.1. Độ đo kích thước (Size) Bốn độ đo kích thước được trình bày để đo kích thước của hệ thống và cho thấy mức độ phức tạp của lớp. Đo kích thước dựa trên các thuộc tính và phương pháp. Số lượng thuộc tính trên mỗi lớp (NOA) được tính theo số lượng thuộc tính trong một lớp. Số lượng phương thức cho mỗi lớp (NOM) là tổng số phương thức trong một lớp. Các phương thức cĩ trọng số trên mỗi lớp (WMC): độ đo này nhằm liên quan đến khái niệm về độ phức tạp. Đối với một lớp C với các phương thức M1; M2; ; Mn; trọng số tương ứng với độ phức tạp c1, c2, ,cn được tính như sau: Phản hồi cho một lớp (RFC) được tạo bởi RFC = | RS | với RS là tập phản hồi của một lớp. Với số lượng phương thức trong một lớp, Ri = {Rij} là tập của các phương thức được gọi bởi Mi. 2.2.2. Độ đo phụ thuộc (coupling) Sự phụ thuộc giữa các đối tượng (Coupling Between Objects - CBO) cho một sự đo lường lớp cho biết một lớp phụ thuộc vào lớp khác [Chidamber & Kemerer]. Trang 25
30. Chương 2: ĐỘ ĐO TRONG DỰ ĐỐN LỖI PHẦN MỀM Coupling cĩ nghĩa là một đối tượng của một lớp sử dụng các phương thức hoặc thuộc tính của một đối tượng trong một lớp khác. Sự phụ thuộc trừu tượng dữ liệu (Data Abstraction Coupling - DAC) đo độ phức tạp của sự phụ thuộc gây ra bởi các kiểu dữ liệu trừu tượng (ADT). Sự phụ thuộc thơng điệp (Message passing Coupling - MPC) đo số lượng cuộc gọi phương thức trong các phương thức của một lớp với các phương thức trong các lớp khác. 2.2.3. Độ đo gắn kết (cohesion) Thiếu sự gắn kết trong các phương thức (Lack of Cohesion in Methods LCOM) được đo bằng số lượng phương thức trong một lớp truy cập vào một hoặc nhiều thuộc tính giống nhau. LCOM của một lớp đạt giá trị cao cĩ nghĩa rằng các lớp ít gắn kết hơn. Do đĩ LCOM mong muốn một giá trị thấp. Gắn kết lớp chặt chẽ (Tight Class Cohesion - TCC) được sử dụng để xác định tỷ lệ phần trăm của các cặp phương thức là public cĩ thuộc tính chung trong một lớp. Gắn kết lớp lỏng lẻo (Loose Class Cohesion - LCC) trình bày tỷ lệ phần trăm của các cặp phương thức là public được kết nối trực tiếp hoặc gián tiếp trong một lớp. Sự gắn kết dựa trên luồng thơng tin (Information flow based Cohesion - ICH) xác định số lượng các phương thức khác được gọi trong một phương thức của cùng một lớp. 2.2.4. Độ đo thừa kế (Inheritcance Metrics) Độ sâu của cây thừa kế (DIT - Depth of Inheritance Tree): Trong một hướng đối tượng, miền ứng dụng được mơ hình hĩa như là hệ thống phân cấp của các lớp. Hệ thống phân cấp này cĩ thể được biểu diễn dưới dạng cây, được gọi là cây thừa kế. Các nút trong cây, được gọi là cây thừa kế. Các nút trong cây đại diện cho các lớp và đối với mỗi lớp như vậy, độ đo DIT là độ dài lớn nhất của đường dẫn tối đa từ nút đến gốc của cây. Biện pháp này liên quan đến khái niệm phạm vi của các thuộc tính. DIT là thước đo xem cĩ bao nhiêu lớp tổ tiên cĩ khả năng ảnh hưởng đến lớp này. Số nút con (Number of Children - NOC) là tổng số nút con cho mỗi lớp. Yếu tố kế thừa phương pháp (Method Inheritance Factor MIF) đo lường số lượng phương thức được kế thừa trên tỷ lệ của tổng số phương thức và được đưa ra như sau: Trong đĩ Ma(Ci) = Mi(Ci) +Md(Ci) TC=tổng số lớp Md(Ci)= số lớp được khai báo Trang 26
31. Chương 2: ĐỘ ĐO TRONG DỰ ĐỐN LỖI PHẦN MỀM Mi(Ci)= số lượng lớp thừa kế trong một lớp Hệ số thừa kế thuộc tính (Attribute Inheritance Facto - AIF) số lượng các thuộc tính được kế thừa trên tỷ lệ của tổng số thuộc tính và được tính như sau: Trong đĩ Aa (Ci) = Ai(Ci) + Ad (Ci) TC= tổng số lớp Ad(Ci) = số thuộc tính được khai báo trong lớp Ai(Ci)= số thuộc tính thừa kế trong lớp 2.2.5. Độ đo đa hình (Polymorphism Metrics) Độ đo đa hình (PF) đo lường mức độ một loại dẫn xuất ghi đè một phương thức từ lớp cơ sở. PF được tính bằng: Mn(Ci) = Số lượng phương thức mới Mo(Ci) = Số lượng phương thức ghi đè DC(Ci) = Descendent Count 2.2.6. Độ đo tái sử dụng (Reuse metrics) Hệ thống hướng đối tượng hỗ trợ các nhà phát triển thiết kế và sử dụng lại mã nguồn, Yap và Henderson-sell thảo luận về hai biện pháp tái sử dụng các độ đo. Tỉ lệ tái sử dụng (Reuse Ratio (U))được định nghĩa như sau Number of super classes U = Total number of classes Tỉ lệ Specialization Ratio (S) được định nghĩa như sau Number of subclasses S = Number of super classes Trang 27
32. Chương 3: KẾT QUẢ THỰC NGHIỆM Chương 3: KẾT QUẢ THỰC NGHIỆM 1.1. CÂU HỎI NGHIÊN CỨU Trong lĩnh vực cơng nghệ phần mềm, để tiến hành các thực nghiệm liên quan đến các hệ thống phần mềm thì chúng ta thu thập và phân tích lượng lớn dữ liệu từ nhiều nguồn mã nguồn mở (open source systems -OSS) khác nhau. Do đĩ, nĩ địi hỏi một quá trình tự động hĩa trong quá trình thu thập và phân tích dữ liệu. Các nhà nghiên cứu tiến hành thực nghiệm phụ thuộc chủ yếu vào dữ liệu được cơng khai trong các kho khác nhau. Kho phần mềm chứa rất nhiều thơng tin về các dự án phần mềm. Sử dụng thơng tin được lưu trữ trong các kho lưu trữ này, các nhà nghiên cứu cĩ thể phụ thuộc ít hơn vào trực giác và kinh nghiệm của họ, và phụ thuộc nhiều hơn vào dữ liệu lịch sử và thực địa. Kho dữ liệu thường được sử dụng như các kho lưu trữ mã như Sourceforge.net và mã Google chứa mã nguồn của các ứng dụng khác nhau được phát triển bởi một số nhà phát triểng Trong nghiên cứu này chúng tơi dựa trên thực nghiệm của Normi là điều tra chất lượng chung của các chương trình mã nguồn mở OSS tương quan với mật độ lỗi của các hệ thống. Nghiên cứu này Normi chủ yếu tập trung vào việc áp dụng độ đo CK OO cho OSS được viết bằng C ++. Với mục đích này, 30 chương trình C ++ đã được tải xuống từ SourceForge.net, đây là kho lưu trữ OSS lớn nhất. Để tải xuống các hệ thống từ SourceForge, Normi đã phát triển một cơng cụ, OSSGrab để tự động hĩa việc tìm kiếm và truy xuất hệ thống. Dựa trên cơng cụ OSSGrab, chúng tơi tiến hành các thực nghiệm để trả lời 2 câu hỏi sau: 1. Những độ đo hướng đối tượng nào cĩ liên quan mật thiết đến mật độ lỗi trong kho dữ liệu mã nguồn mở? 2. Chất lượng của hệ thống mã nguồn mở được viết trong ngơn ngữ C++ là gì? Trên cơ sở các kỹ thuật giảm nhiễu đã so sánh, đánh giá, trong đề tài sử dụng ngơn ngữ lập trình C để thực hiện các thuật tốn giảm nhiễu trên nền tảng phần cứng arduino, qua đĩ cũng tiến hành đánh giá trên mơ hình phần cứng thực nghiệm. 1.2. CÁC GIẢ THUYẾT NGHIÊN CỨU H1. Phân tích giá trị của độ đo CBO cĩ liên quan đến mật độ lỗi. H2. Phân tích giá trị của độ đo LCBO cĩ liên quan đến mật độ lỗi. H3. Phân tích giá trị của độ đo DIT cĩ liên quan đến mật độ lỗi. H4. Phân tích giá trị của độ đo NOC cĩ liên quan đến mật độ lỗi. H5. Phân tích giá trị của độ đo RFC cĩ liên quan đến mật độ lỗi. H6. Phân tích giá trị của độ đo WMC cĩ liên quan đến mật độ lỗi. 1.3. Biến phụ thuộc (Dependent Variable) Trang 28
33. Chương 3: KẾT QUẢ THỰC NGHIỆM Mặc dù cĩ những tiến bộ gần đây trong cơng nghệ lập trình cũng như về chất lượng của kỹ sư lập trình nhưng các nhà lập trình vẫn chưa thể lập trình tạo ra những mã nguồn khơng cĩ lỗi một cách nhất quán. Một sản phẩm phần mềm được coi là bị lỗi khi nĩ khơng thực hiện các chức năng của nĩ theo mong đợi của người dùng đồng thời trong quá trình triển khai cũng phát sinh nhiều lỗi về mã nguồn. Trong nghiên cứu này, lỗi mã nguồn liên quan mật thiết đến lỗi trong tồn hệ thống, dẫn đến sau này sẽ gây ra lỗi trong hệ thống trong thời gian vận hành. Biến phụ thuộc được sử dụng trong nghiên cứu này là các lỗi xảy ra được thu thập từ báo cáo theo dõi lỗi trong SourceForge. 1.4. Biến độc lập (Independent Variables) Các biến độc lập được chọn cho nghiên cứu này là một tập hợp các độ đo được gọi là bộ độ đo hướng đối tượng Chidamber và Kemerer (độ đo CK OO). Để cĩ được dữ liệu độ đo, mã nguồn của hệ thống đã được tải xuống từ SourceForge đã được phân tích bằng một cơng cụ trích xuất độ đo cĩ tên Understand C++ Sau khi tất cả các số liệu thu được, chúng được phân tích bằng phần mềm thống kê SPSS. 1.5. Thu thập dữ liệu Để giảm bớt quá trình thu thập dữ liệu từ SourceForge.net, Normi sử dụng cơng cụ OSSGrab đã được phát triển bằng kỹ thuật Python và Biểu thức chính quy, được giới thiệu ở trên. s Hình 3.1 Kỹ thuật phân tích của OSSGrab Trang 29
34. Chương 3: KẾT QUẢ THỰC NGHIỆM Các kỹ thuật phân tích cú pháp được hiển thị trong hình 3.2. Ứng dụng nhận được một truy vấn từ người dùng với các tiêu chí để tìm kiếm trong kho lưu trữ. Sau đĩ, truy vấn được chuyển đến cơng cụ trình thu thập dữ liệu web web-crawler và bắt đầu thu thập dữ liệu các trang từ API của kho lưu trữ trực tuyến tương ứng. Sau khi tải các trang từ cơng cụ thu thập dữ liệu web, sẽ chuyển các trang đĩ xuống cơng cụ phân tích cú pháp, sau đĩ sẽ thu được dữ liệu truy vấn dưới dạng khối văn bản. Sau khi phân tích xong, chương trình sẽ ghi dữ liệu được thu thập ở định dạng HTML và CSV để sử dụng cho nghiên cứu. Định dạng CSV cho phép người dùng thao tác thêm dữ liệu bằng các chức năng phong phú của bảng tính. Các tập lệnh Java được thêm vào HTML để làm cho dữ liệu tương tác và hữu ích hơn. Đầu tiên, người dùng cĩ thể chọn tìm kiếm các hệ thống trong SourceForge. Quá trình tìm kiếm được hiển thị trong Hình 3.2 và Hình 3.3. Hình 3.2 hiển thị một tìm kiếm đơn giản, trong đĩ người dùng tìm kiếm tên của hệ thống họ muốn tìm. Trình phân tích cú pháp sẽ tìm kiếm thơng qua kho lưu trữ SourceForge và sẽ trả về kết quả cho người dùng. Hình 3.2 Tìm kiếm đơn giản trong kho OSS Hình 3.3 cho thấy tùy chọn tìm kiếm nâng cao nơi người dùng cĩ thể chọn các hệ thống dựa trên Danh mục, Ngơn ngữ lập trình, Trạng thái phát triển và Số lượt tải xuống. Từ khĩa Số trang cĩ nghĩa là người dùng cĩ thể chọn số lượng hệ thống sẽ được Trang 30
35. Chương 3: KẾT QUẢ THỰC NGHIỆM hiển thị trên trang kết quả, nếu người dùng chọn số lượng trang lớn hơn, thời gian tìm kiếm sẽ lâu hơn. Hình 3.3 Tìm kiếm nâng cao trong kho OSS Các kết quả đầu ra được tạo ra trong cả CSV và HTML định dạng. Người dùng cĩ thể sắp xếp đầu ra dựa trên tiêu đề của cột. Liên kết tải xuống cột sẽ kết nối người dùng tải xuống hệ thống trong SourceForge. Điều này sẽ cung cấp quyền truy cập nhanh vào hệ thống và người dùng cĩ thể trực tiếp tải xuống hệ thống. Từ quan điểm nghiên cứu, điều này cơ sở sẽ cung cấp cho các nhà nghiên cứu nhiều lựa chọn về hệ thống để lựa chọn. Trong kỹ thuật phần mềm thực nghiệm, các nhà nghiên cứu cần tìm nhiều dữ liệu nhất cĩ thể, đặc biệt khi họ muốn xây dựng mơ hình dự báo, để đảm bảo rằng các mơ hình cĩ thể được tổng quát hơn cho tổng thể nĩi chung. Sau đĩ, mã nguồn của các hệ thống được chọn sẽ là được tải xuống và thực thi thơng qua một cơng cụ cĩ tên là Understand [16], sẽ tạo ra một tập hợp các độ đo i. e., CBO, WMC, DIT, LCOM, NOC và RFC. Kết quả sau được phân tích sử dụng một phần mềm thống kê, SPSS. Thống kê mơ tả cho các biến độc lập là thể hiện trong Bảng 3.1. Số lượng quan sát hoặc cỡ mẫu cho nghiên cứu này là 30 hệ thống. Cột “Std. Dev”, “Min”, “Max” đại diện cho giá trị trung bình, độ lệch chuẩn, giá trị tối thiểu và tối đa cho mỗi độ đo được xem xét, tương ứng. Trang 31
36. Chương 3: KẾT QUẢ THỰC NGHIỆM Bảng 3.1. Thống kê kết quả theo SPSS Độ đo Mean Std.Dev. Min Max CBO 0.63 48.33 5.90 8.28 WMC 0.24 21 12.47 4.71 LCOM 14.50 367.67 54.83 60.25 DIT 0.18 24 1.55 4.26 NOC 0.00 27.33 1.31 4.92 RFC 3.33 88.65 23.48 15.67 Phân tích ban đầu về dữ liệu cho thấy phân phối là khơng bình thường. Do đĩ, để phân tích tương quan, Spearman phân tích tương quan đã được thực hiện. Kết quả tổng thể của phân tích spearman được thể hiện trong bảng 3.1. Trong bảng 3.2, hàng trên đại diện cho các giá trị cho hệ số tương quan Spearman giữa hai biến, trong khi hàng dưới cùng (trong ngoặc đơn) đại diện cho giá trị p cho tương quan. Kết quả trong Bảng II cho thấy chỉ cĩ RFC và NOC cĩ ý nghĩa quan trọng trong việc dự đốn các lỗi (Spearman corr. = 0.495, p-value = 0.005) và (Spearman corr. = 0.36, p-value = 0.05). Bảng 3.2. Phân tích tương quan Spearman giữa các biến Độ đo Lỗi CBO RFC NOC WMC LCOM Lỗi 1 0.038 0.495 0.36 0.17 0.058 (0.84) (0.005) (0.05) (0369) (0.76) CBO - 1 0.528 0.306 0.278 0.423 (0.003) (0.10) (0.137) (0.02) RFC - - 1 0.38 0.533 0.244 (0.038) (0.002) (0.195) NOC - 1 -0.305 -0.032 (0.101) (0.867) WMC - - - - 1 0.544 (0.002) LCOM - 1 Dựa trên kết quả, cĩ thể kết luận rằng các giả thuyết nghiên cứu H4 và H5 được hỗ trợ. Tuy nhiên, kết quả là H1, H2, H3 và H6 khơng được hỗ trợ. Trang 32
37. KẾT LUẬN VÀ KIẾN NGHỊ KẾT LUẬN Đề tài đã nghiên cứu các độ đo (metrics) để tìm ra được mối liên hệ giữa các độ đo với lỗi cĩ khả năng xảy ra trong hệ thống. Mặc dù cĩ rất nhiều độ đo đã được đề xuất như độ đo mã nguồn, độ đo quy trình Trong nghiên cứu này, chúng tơi tập trung vào độ đo hướng đối tượng Chidamber và Kemerer để đo lường hệ thống mở và khả năng xảy ra lỗi.Việc áp dụng các độ đo thiết kế hướng đối tượng (OO) để đo lường chất lượng của các hệ thống nguồn mở đã giúp hiểu các mối quan hệ của các độ đo với khả năng xảy ra lỗi của các hệ thống. Chúng tơi tìm cách kiểm tra các độ đo cĩ thể được sử dụng để dự đốn lỗi trong các hệ thống hướng đối tượng (Object Oriented), đặc biệt là những hệ thống được viết bằng C ++. Kết quả cho thấy độ đo RFC và NOC cĩ ý nghĩa quan trọng trong việc dự đốn khả năng xảy ra lỗi. Tuy nhiên nghiên cứu này mới chỉ sử dụng được tập hợp dữ liệu từ các mã nguồn mở để kiểm tra một số độ đo cơ bản cĩ mối quan hệ với khả năng xảy ra lỗi phần mềm trong ngơn ngữ lập trình C++, chưa đưa ra được các đề xuất mang tính cụ thể như sau: - Chưa nghiên cứu các kỹ thuật học máy và ứng dụng để kiểm tra độ đo nào cĩ mối tương quan với lỗi. - Chưa đề xuất được những độ đo nào phù hợp với khả năng dự báo lỗi đối với từng ngơn ngữ khác nhau như Java, C#,C++ KIẾN NGHỊ Từ kết quả đạt được, tác giả kiến nghị các hướng nghiên cứu tiếp theo như sau: Thu thập độ đo phần mềm và dữ liệu lỗi cĩ thể được thực hiện. Đơi khi dữ liệu lỗi khơng cĩ sẵn. Các nghiên cứu trong tương lai cĩ thể cố gắng trả lời câu hỏi liệu mơ hình dự đốn lỗi cĩ thể được học trên những dữ liệu đã cĩ bằng việc áp dụng các kỹ thuật máy học. Chúng tơi nghiên cứu các kỹ thuật học máy trong việc dự đốn lỗi với dựa trên các độ đo. Hiện nay cĩ rất nhiều kỹ thuật học máy được áp dụng như cây quyết định (decision tree), Bayesian network, Nạve Bayes, Bayesian Regularization (BR), Support Vector Machine (SVM), Dựa trên những kết quả thu được của các nghiên cứu về các kỹ thuật học máy trên, chúng tơi cĩ kế hoạch cải tiến thuật tốn SVM để xây dựng được một mơ hình dự đốn lỗi đồng thời đưa ra được các đề xuất cho các độ đo nào sẽ phù hợp với từng ngữ cảnh cụ thể và ngơn ngữ lập trình cụ thể. Trang 33
38. TÀI LIỆU THAM KHẢO TÀI LIỆU THAM KHẢO Tiếng Anh: [1]. Mary Jean Harrold. Testing: a roadmap. In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering, pages 61–72, New York, NY, USA, 2000. ACM. [2]. Rupa Mahanti and Jiju Antony. Confluence of six sigma, simulation and software development. Managerial Auditing Journal, 20(7):739–762, 2005. [3]. Salah Bouktif, Danielle Azar, Doina Precup, Houari Sahraoui, and Balazs Kegl. Improving rule set based software quality prediction: A genetic algorithm-based approach. Journal of Object Technology, 3(4):227–241, 2004. [4]. Norman E. Fenton and Niclas Ohlsson. Quantitative analysis of faults and failures in a complex software system. IEEE Trans. Softw. Eng., 26(8):797– 814, 2000. [5]. Manfred Broy, Florian Deissenboeck, and Markus Pizka. Demystifying maintainability. In WoSQ ’06: Proceedings of the 2006 international workshop on Software quality, pages 21–26, New York, NY, USA, 2006. ACM. [6]. Victor R. Basili, Lionel C. Briand, and Walc´elio L. Melo. A validation of object-oriented design metrics as quality indicators. IEEE Trans. Softw. Eng., 22(10):751–761, 1996. [7]. Khaled El Emam, Walcelio Melo, and Javam C. Machado. The prediction of faulty classes using object-oriented design metrics. J. Syst. Softw., 56(1):63– 75, 2001. [8]. Tibor Gyimothy, Rudolf Ferenc, and Istvan Siket. Empirical validation of objectoriented metrics on open source software for fault prediction. IEEE Trans. Softw. Eng., 31(10):897–910, 2005. [9]. Hector M. Olague, Letha H. Etzkorn, Sampson Gholston, and Stephen Quattlebaum. Empirical validation of three software metrics suites to predict faultproneness of object-oriented classes developed using highly iterative or agile software development processes. IEEE Trans. Softw. Eng., 33(6):402– 419, 2007. [10]. Nachiappan Nagappan, Thomas Ball, and Andreas Zeller. Mining metrics to predict component failures. In ICSE ’06: Proceedings of the 28th international Trang 34
39. TÀI LIỆU THAM KHẢO conference on Software engineering, pages 452–461, New York, NY, USA, 2006. ACM [11]. Zheng, J. (2010). Cost-sensitive boosting neural networks for software defect prediction. Expert Systems with Applications, 37(6), 4537-4543. [12]. Whittaker, J. (2000). What is software testing? And why is it so hard?. Software, IEEE, 17(1), 70-79. [13]. Cem Kaner, J. D., Hendrickson, E., & Smith-Brock, J. (2001). MANAGING THE PROPORTION OF TESTERS TO (OTHER) DEVELOPERS. [14]. Bieman, J. M. (1997). Software Metrics: A Rigorous & Practical Approach. IBM Systems Journal, 36(4), 594. [15]. Nam, J. (2009). Survey on Software Defect Prediction. Master's Thesis. [16]. Akiyama, F. (1971). An Example of Software System Debugging. In Proceedings of the International Federation of Information Processing Societies Congress, pages 353–359. [17]. D’Ambros, M., Lanza, M., & Robbes, R. (2012). Evaluating defect prediction approaches: a benchmark and an extensive comparison. Empirical Software Engineering, 17(4-5), 531-577. [18]. Menzies, T., Dekhtyar, A., Distefano, J., & Greenwald, J. (2007). Problems with precision: A response to “comments on ‘data mining static code attributes to learn defect predictors’”. IEEE Transactions on Software Engineering, 33(9), 637. [19]. Shihab, E., Mockus, A., Kamei, Y., Adams, B., & Hassan, A. E. (2011). High- impact defects: a study of breakage and surprise defects. Paper presented at the Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering. [20]. Song, Q., Jia, Z., Shepperd, M., Ying, S., & Liu, S. Y. J. (2011). A general software defect-proneness prediction framework. Software Engineering, IEEE Transactions on, 37(3), 356-370. [21]. Turhan, B., Menzies, T., Bener, A. B., & Di Stefano, J. (2009). On the relative value of cross-company and within-company data for defect prediction. Empirical Software Engineering, 14(5), 540-578. [22]. Song, Q., Jia, Z., Shepperd, M., Ying, S., & Liu, S. Y. J. (2011). A general software defect-proneness prediction framework. Software Engineering, IEEE Transactions on, 37(3), 356-370. [23]. Chidamber, S. R., & Kemerer, C. F. (1994). A metrics suite for object oriented design. Software Engineering, IEEE Transactions on, 20(6), 476-493. Trang 35
40. TÀI LIỆU THAM KHẢO [24]. Tang, M. H., Kao, M. H., & Chen, M. H. (1999). An empirical study on object-oriented metrics. In Proceedings of the 1999 international workshop on Software metric symposium (pp. 242-249). IEEE. [25]. Subramanyam, R., & Krishnan, M. S. (2003). Empirical analysis of ck metrics for objectoriented design complexity: Implications for software defects. Software Engineering, IEEE Transactions on, 29(4), 297-310. [26]. D’Ambros, M., Lanza, M., & Robbes, R. (2012). Evaluating defect prediction approaches: a benchmark and an extensive comparison. Empirical Software Engineering, 17(4-5), 531-577. [27]. Rahman, F., Posnett, D., & Devanbu, P. (2012). Recalling the imprecision of crossproject defect prediction. Paper presented at the Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering [28]. Moser, R., Pedrycz, W., & Succi, G. (2008). A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction. Paper presented at the Software Engineering, 2008. ICSE'08. ACM/IEEE 30th International Conference on. [29]. Lee, T., Nam, J., Han, D., Kim, S., & In, H. P. (2011). Micro interaction metrics for defect prediction. Paper presented at the Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering [30]. Smola, A., & Vishwanathan, S. V. N. (2008). Introduction to machine learning. Cambridge University, UK, 32-34. [31]. Japkowicz, N., & Shah, M. (2011). Evaluating learning algorithms: a classification perspective. Cambridge University Press. [32]. Quinlan, J. R. (1986). Induction of decision trees. Machine learning, 1(1), 81- 106. [33]. "Knab, P., Pinzger, M., & Bernstein, A. (2006, May). Predicting defect densities in source code files with decision tree learners. In Proceedings of the 2006 international workshop on Mining software repositories (pp. 119-125). ACM." [34]. Giger, E., D'Ambros, M., Pinzger, M., & Gall, H. C. (2012). Method-level bug prediction. Paper presented at the Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement. [35]. Quinlan, J. R. (1986). Induction of decision trees. Machine learning, 1(1), 81- 106. Trang 36
41. TÀI LIỆU THAM KHẢO [36]. Bishop, C. M. (2006). Pattern recognition and machine learning. springer. [37]. Langley, P., & Sage, S. (1994, July). Induction of selective Bayesian classifiers. In Proceedings of the Tenth international conference on Uncertainty in artificial intelligence (pp. 399-406). Morgan Kaufmann Publishers Inc [38]. Cover, T., & Hart, P. (1967). Nearest neighbor pattern classification. Information Theory, IEEE Transactions on, 13(1), 21-27. [39]. Turhan, B., Menzies, T., Bener, A. B., & Di Stefano, J. (2009). On the relative value of cross-company and within-company data for defect prediction. Empirical Software Engineering, 14(5), 540-578 [40]. Belongie, S., Malik, J., & Puzicha, J. (2002). Shape matching and object recognition using shape contexts. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 24(4), 509-522 [41]. Black, P. E. (2006). Manhattan distance. Dictionary of Algorithms and Data Structures, 18, 2012 [42]. Deza, M. M., & Deza, E. (2009). Encyclopedia of distances (pp. 1-583). Springer Berlin Heidelberg. [43]. Mahalanobis, P. C. (1936). On the generalized distance in statistics. Proceedings of the National Institute of Sciences (Calcutta), 2, 49-55. [44]. Khoshgoftaar, T. M., & Seliya, N. (2003). Analogy-based practical classification rules for software quality estimation. Empirical Software Engineering, 8(4), 325-350. [45]. Ganesan, K., Khoshgoftaar, T. M., & Allen, E. B. (2000). Case-based software quality prediction. International Journal of Software Engineering and Knowledge Engineering, 10(02), 139-152. [46]. Cunningham, P., & Delany, S. J. (2007). k-Nearest neighbour classifiers. Multiple Classifier Systems, 1-17. [47]. Elish, K. O., & Elish, M. O. (2008). Predicting defect-prone software modules using support vector machines. Journal of Systems and Software, 81(5), 649- 660. [48]. Cristianini, N., & Shawe-Taylor, J. (2000). An introduction to support vector machines and other kernel-based learning methods. Cambridge university press [49]. Kotsiantis, S., Kanellopoulos, D., & Pintelas, P. (2006). Data preprocessing for supervised leaning. International Journal of Computer Science, 1(2), 111- 117. Trang 37
42. TÀI LIỆU THAM KHẢO [50]. Graf, A. B., & Borer, S. (2001). Normalization in support vector machines Pattern Recognition (pp. 277-282): Springer [51]. Boetticher, G. D. (2005). Nearest neighbor sampling for better defect prediction. ACM SIGSOFT Software Engineering Notes, 30(4), 1-6. [52]. Juszczak, P., Tax, D., & Duin, R. P. W. (2002). Feature scaling in support vector data description. In Proc. ASCI (pp. 95-102). [53]. Han, J., Kamber, M., & Pei, J. (2012), Data mining : concepts and techniques, 3rd ed. Waltham, Mass.: Elsevier/Morgan Kaufmann. [54]. Shivaji, S., Whitehead, E. J., Akella, R., & Kim, S. (2013). Reducing features to improve code change-based bug prediction. Software Engineering, IEEE Transactions on, 39(4), 552-569. [55]. Hall, M. (2000). Correlation-based feature selection for discrete and numeric class machinelearning,! Proceedings of th7 IntentionalConference onMachine Learning,.Stanford University Trang 38
43. ĐẠI HỌC ĐÀ NẴNG CỘNG HỒ XÃ HỘI CHỦ NGHĨA VIỆT NAM TRƯỜNG CĐ CƠNG NGHỆ THƠNG TIN Độc lập - Tự do - Hạnh phúc THUYẾT MINH ĐỀ TÀI KHOA HỌC & CƠNG NGHỆ CẤP CƠ SỞ (DO TRƯỜNG CAO ĐẲNG CƠNG NGHỆ THƠNG TIN QUẢN LÝ) 1. TÊN ĐỀ TÀI: Nghiên cứu các độ đo mã nguồn cho bài tốn dự 2. MÃ SỐ T2018-07-07 đốn lỗi phần mềm 3. LĨNH VỰC NGHIÊN CỨU 4. LOẠI HÌNH NGHIÊN CỨU Mơi Cơ Ứng Triển Tự nhiên Kỹ thuật x trường bản dụng Khai Kinh tế; Nơng Lâm ATLĐ XH-NV x x Sở hữu Giáo dục Y Dược trí tuệ 5. THỜI GIAN THỰC HIỆN 9 tháng Từ tháng 04 năm 2018 đến tháng 12 năm 2018 6. CƠ QUAN CHỦ TRÌ ĐỀ TÀI (đơn vị thành viên ĐHĐN) Tên cơ quan: Trường Cao đẳng Cơng nghệ Thơng tin Điện thoại: 0511.3667117 E-mail: Địa chỉ: Làng Đại học, Phường Hịa Quý, Q. Ngũ Hành Sơn, TP. Đà Nẵng Họ và tên thủ trưởng cơ quan chủ trì: PGS.TS. Huỳnh Cơng Pháp 7. CHỦ NHIỆM ĐỀ TÀI Họ và tên: Hà Thị Minh Phương Học vị: Thạc sĩ Chức danh khoa học: Năm sinh: 08/05/1986 Địa chỉ cơ quan: Địa chỉ nhà riêng: Điện thoại cơ quan: 02366552688 Điện thoại nhà riêng : Di động: 0987710719 Fax: E-mail: htmphuong@sict.udn.vn 8. NHỮNG THÀNH VIÊN THAM GIA NGHIÊN CỨU ĐỀ TÀI Đơn vị cơng tác và Nội dung nghiên cứu cụ thể TT Họ và tên Chữ ký lĩnh vực chuyên mơn được giao 1 2 3 9. ĐƠN VỊ PHỐI HỢP CHÍNH Tên đơn vị Họ và tên người đại Nội dung phối hợp nghiên cứu trong và ngồi nước diện đơn vị
44. 10. TỔNG QUAN TÌNH HÌNH NGHIÊN CỨU THUỘC LĨNH VỰC CỦA ĐỀ TÀI Ở TRONG VÀ NGỒI NƯỚC 10.1. Ngồi nước (phân tích, đánh giá tình hình nghiên cứu thuộc lĩnh vực của đề tài trên thế giới, liệt kê danh mục các cơng trình nghiên cứu, tài liệu cĩ liên quan đến đề tài được trích dẫn khi đánh giá tổng quan) Độ đo (metric) đĩng một vai trị rất quan trọng để phát triển một phần mềm cĩ chất lượng tốt. The IEEE Standard Glossary of Software Engineering Terms đã định nghĩa độ đo như là thước đo định lượng đến một hệ thống, một thành phần hoặc một quá trình cĩ một thuộc tính nhất định. Cĩ rất nhiều loại độ đo khác nhau được trình bày trong các tài liệu để đo lường các sản phẩm phần mềm. Trong sự phát triển phần mềm hiện nay, ngơn ngữ hướng đối tượng (Object Oriented) được sử dụng do các đặc tính cơ bản của chúng như lớp, đối tượng, che dấu thơng tin, thừa kế, đĩng gĩi, trìu tượng và đa hình. Ngồi ra, độ đo của hướng đối tượng cĩ sẵn được sử dụng để đo chất lượng của các hệ thống hướng đối tượng. 10.2. Trong nước (phân tích, đánh giá tình hình nghiên cứu thuộc lĩnh vực của đề tài ở Việt Nam, liệt kê danh mục các cơng trình nghiên cứu, tài liệu cĩ liên quan đến đề tài được trích dẫn khi đánh giá tổng quan) Hiện nay đã cĩ nhiều nghiên cứu về độ đo hướng đối tượng trên các ngơn ngữ lập trình như C++, Java, . Các độ đo cĩ ích cho việc đánh giá sự phát triển cơ trúc cĩ thể khơng ảnh hưởng đến thiết kế mà sử dụng ngơn ngữ OO. Cĩ rất nhiều mơ hình độ đo hướng đối tượng cĩ sẵn và một số tác giả đã đề xuất cách để đo lường giá trị của độ đo mã nguồn hướng đối tượng. Một nghiên cứu ước tính tiết kiệm chi phí bảo trì sửa chữa là 42% bằng cách sử dụng độ đo mã nguồn hướng đối tượng. 10.3. Danh mục các cơng trình đã cơng bố thuộc lĩnh vực của đề tài của chủ nhiệm và những thành viên tham gia nghiên cứu (họ và tên tác giả; bài báo; ấn phẩm; các yếu tố về xuất bản) 11. TÍNH CẤP THIẾT CỦA ĐỀ TÀI Việc đo lường phần mềm cĩ tầm quan trọng trong việc phát triển phần mềm. Nhiều độ đo đã được đề xuất lien quan đến cấu trúc khác nhau như lớp, phụ thuộc, thừa kế, che dầu thơng tin và đa hình. Rất khĩ để xác định độ đo nào tốt nhất. Do đĩ, rất khĩ cho các nhà quản lý và người thực hiện dự án lựa chọn các độ đo cho các hệ thống hướng đối tượng. Trong đĩ, độ đo OO (Object Oriented) là độ đo trong một hệ thống hướng đối tượng để xác định sự thành cơng hay thất bại của một quy trình, để xác định cĩ định lượng sự cải tiến trong một quy trình phần mềm. Độ đo này được sử dụng để cải tiến kỹ thuật lập trình hướng đối tượng tăng tính tin cậy của mã nguồn. Xét thấy như vậy, chúng tơi nghiên cứu các độ đo mã nguồn hướng đối tượng cũng như so sánh với độ đo mã nguồn hướng cấu trúc. Từ đĩ cĩ thể đưa ra được dự đốn lỗi phần mềm dựa trên các độ đo trên. 12. MỤC TIÊU ĐỀ TÀI Nghiên cứu lý thuyết:  Tìm hiểu độ đo mã nguồn hướng cấu trúc  Tìm hiểu độ đo mã nguồn hướng đối tượng  Nghiên cứu áp dụng các độ hướng đối tượng vào việc dự đốn lỗi phần mềm Áp dụng lý thuyết vào xây dựng cơng cụ dự đốn lỗi phần mềm nhằm tạo điều kiện để tiếp tục nghiên cứu và xây dựng các hệ thống dự đốn lỗi phần mềm dựa trên máy học để dự đốn được số lỗi của phần mềm . 13. ĐỐI TƯỢNG, PHẠM VI NGHIÊN CỨU 13.1. Đối tượng nghiên cứu Độ đo mã nguồn cấu trúc và độ đo mã nguồn hướng đối tượng: Sách, báo, Giá trị các độ đo trên Một số tập dữ liệu NASA và open source trong PROMISE
45. 13.2. Phạm vi nghiên cứu: Độ đo mã nguồn cấu trúc và độ đo mã nguồn hướng đối tượng, tập dữ liệu NASA và PROMISE 14. CÁCH TIẾP CẬN, PHƯƠNG PHÁP NGHIÊN CỨU 14.1. Cách tiếp cận Nghiên cứu các độ đo mã nguồn dựa trên  Tiếp cận dựa vào lý luận.  Tiếp cận dựa vào thống kê.  Tiếp cận dựa trên cả hai phương pháp trên. 14.2. Phương pháp nghiên cứu: Với các phương pháp tiếp cận trên chúng tơi lựa chọn phương pháp thống kê để đưa ra được giá trị của các độ đo trong việc dự đốn lỗi của phần mềm. 15. NỘI DUNG NGHIÊN CỨU VÀ TIẾN ĐỘ THỰC HIỆN 15.1. Nội dung nghiên cứu (trình bày dưới dạng đề cương nghiên cứu chi tiết)  Tìm hiểu độ đo mã nguồn hướng cấu trúc và độ đo mã nguồn hướng đối tượng  Nghiên cứu và phân tích các giá trị của các độ đo trên trong dự đốn lỗi phần mềm  Xây dựng cơng cụ dự đốn lỗi phần mềm dựa trên độ đo mã nguồn hướng đối tượng  Viết báo cáo tổng kết đề tài 15.2. Tiến độ thực hiện Các nội dung, cơng việc Sản phẩm Thời gian Người thực STT thực hiện (bắt đầu-kết thúc) hiện 1 Nghiên cứu tổng quan độ đo mã Báo cáo 04/2018- Hà Thị Minh nguồn hướng cấu trúc và độ đo 05/2018 Phương mã nguồn hướng đối tượng 2 Nghiên cứu và phân tích các giá Báo cáo 06/2018- Hà Thị Minh trị của các độ đo trên trong dự 07/2018 Phương đốn lỗi phần mềm 3 Xây dựng cơng cụ dự đốn lỗi Báo cáo 08/2018- Hà Thị Minh phần mềm dựa trên độ đo mã Phần mềm 09/2018 Phương nguồn hướng đối tượng 4 Ứng dụng nguồn dữ liệu thử Báo cáo 10/2018- Hà Thị Minh nghiệm cho bài tốn dự đốn lỗi Phần mềm 11/2018 Phương phần mềm 5 Viết báo cáo tổng kết đề tài Báo cáo 11/2018- Hà Thị Minh 12/2018 Phương
46. 16. SẢN PHẨM 16.1. Sản phẩm khoa học Bài báo đăng tạp chí nước ngồi Bài báo đăng tạp chí trong nước x Bài đăng kỷ yếu hội nghị, hội thảo quốc tế Sản phẩm khác (giáo trình, tài liệu tham khảo 16.2. Sản phẩm đào tạo Cao học NCS 16.3.Sản phẩm ứng dụng Mẫu Vật liệu Thiết bị máy mĩc Giống cây trồng Giống vật nuơi Qui trình cơng nghệ Tiêu chuẩn Qui phạm Sơ đồ, bản thiết kế Tài liệu dự báo Đề án Luận chứng kinh tế Phương pháp Chương trình máy tính Bản kiến nghị Dây chuyền cơng nghệ Báo cáo phân tích Bản quy hoạch 16.4. Các sản phẩm khác 16.5. Tên sản phẩm, số lượng và yêu cầu khoa học đối với sản phẩm Stt Tên sản phẩm Số lượng Yêu cầu khoa học 1 Bài báo Hội thảo CITA hoặc tương 01 Cĩ chất lượng đương hoặc quốc tế 2 Phần mềm dự đốn lỗi (C++) 01 Dự đốn lỗi hiệu quả 3 Báo cáo tổng kết 01 Cĩ chất lượng, đầy đủ 17. HIỆU QUẢ (giáo dục và đào tạo, kinh tế - xã hội) - Về mặt giáo dục - đào tạo: phục vụ cơng tác giảng dạy, nghiên cứu. - Về mặt khoa học: đĩng gĩp đáng kể của đề tài là trình bày các độ đo liên quan mật thiết đến lỗi phần mềm, qua đĩ cĩ thể đưa ra được các độ đo cĩ tính hiệu quả trong việc nhận biết lỗi phần mềm. - Về sản phẩm ứng dụng: xây dựng được các hệ thống dự đốn được lỗi phần mềm trong cơng nghệ phần mềm. 18. PHƯƠNG THỨC CHUYỂN GIAO KẾT QUẢ NGHIÊN CỨU VÀ ĐỊA CHỈ ỨNG DỤNG Phần mềm cài đặt trên máy tính. Tư liệu và cơng cụ phục vụ cho việc dự đốn lỗi phần mềm, đặc biệt là ngơn ngữ lập trình hướng đối tượng với C++.
47. 19. KINH PHÍ THỰC HIỆN ĐỀ TÀI VÀ NGUỒN KINH PHÍ Tổng kinh phí: 8.900.000 VNĐ Trong đĩ: Ngân sách Nhà nước: 8.900.000 VNĐ Các nguồn kinh phí khác: Dự trù kinh phí theo các mục chi (phù hợp với nội dung nghiên cứu): Đơn vị tính: đồng Stt Khoản chi, nội dung chi Tổng Nguồn kinh phí Ghi chú kinh phí Kinh phí từ Các NSNN nguồn khác 1 Chi tiền cơng lao động trực tiếp 6.240.000 6.240.000 2 Chi mua vật tư, nguyên, nhiên, vật liệu 3 Chi sửa chữa, mua sắm tài sản cố định 4 Chi hội thảo KH, cơng tác phí 5 Chi trả dịch vụ thuê ngồi phục vụ hoạt động nghiên cứu 6 Chi điều tra, khảo sát thu thập số liệu 7 Chi văn phịng, phẩm, thơng tin liên lạc, in 935.000 935.000 ấn 8 Chi nghiệm thu đề tài 1.280.000 1.280.000 9 Chi quản lý chung 445.000 445.000 10 Chi khác Tổng cộng 8.900.000 8.900.000 Ngày tháng năm 2018 Ngày tháng năm 2018 TM. HỘI ĐỒNG KH&ĐT ĐƠN VỊ Chủ nhiệm đề tài (ký, họ và tên) (ký, họ và tên) Đà Nẵng, ngày tháng năm Cơ quan Chủ trì duyệt HIỆU TRƯỞNG
48. DỰ TỐN KINH PHÍ ĐỀ TÀI KH&CN CẤP CƠ SỞ NĂM 2018 Tên đề tài: Nghiên cứu các độ đo mã nguồn cho bài tốn dự đốn lỗi phần mềm Đơn vị tính: VN đồng Dự tốn kinh phí Nguồn kinh phí STT Các khoản chi phí Kinh phí Các nguồn Số ngày cơng Tổng kinh phí từ NSNN khác 1 Chi tiền cơng lao động trực tiếp 24 6.240.000 6.240.000 2 Chi mua vật tư, nguyên vật liệu Chi sửa chữa, mua sắm tài sản cố 3 định Chị hội thảo khoa học, cơng tác 4 phí Chi trả dịch vụ thuê ngồi phục 5 vụ nghiên cứu Chi điều tra, khảo sát thu thập số 6 liệu Văn phịng phẩm, thơng tin liên 7 935.000 935.000 lạc, in ấn 8 Chi nghiệm thu đề tài 1.280.000 1.280.000 9 Quản lý chung nhiệm vụ KHCN 445.000 445.000 10 Chi khác liên quan Tổng cộng 8.900.000 8.900.000 BẢNG CHI TIẾT SỐ CƠNG THỰC HIỆN ĐỀ TÀI CỦA CÁC THÀNH VIÊN STT Họ và tên Chức danh Hệ số Ngày cơng Thành tiền 1 Hà Thị Minh Phương Chủ nhiệm 0,2 24 6.240.000 Tổng cộng 6.240.000 Thời gian Cá nhân thực hiện – STT Nội dung, cơng việc Kết quả, sản phẩm thực hiện Số ngày thực hiện 1 Nghiên cứu tổng quan độ đo Hà Thị Minh Phương - 5 mã nguồn hướng cấu trúc và 04/2018 – Báo cáo độ đo mã nguồn hướng đối 05/2018 tượng 2 06/2018- Hà Thị Minh Phương Nghiên cứu và phân tích các Báo cáo 07/2018 – 3 giá trị của các độ đo trên trong 6
49. Thời gian Cá nhân thực hiện – STT Nội dung, cơng việc Kết quả, sản phẩm thực hiện Số ngày thực hiện dự đốn lỗi phần mềm 3 Xây dựng cơng cụ dự đốn lỗi 08/2018- Hà Thị Minh Phương Báo cáo 09/2018 – 8 phần mềm dựa trên độ đo mã Phần mềm nguồn hướng đối tượng 4 10/2018- Hà Thị Minh Phương Ứng dụng nguồn dữ liệu thử Báo cáo 11/2018 - 6 nghiệm cho bài tốn dự đốn Phần mềm lỗi phần mềm 5 11/2018- Hà Thị Minh Phương Viết báo cáo tổng kết đề tài Báo cáo 12/2018 -2 Đà Nẵng, ngày 2 tháng 4 năm 2018 Cơ quan Chủ trì Chủ nhiệm đề tài HIỆU TRƯỞNG 7