Đánh giá phần mềm hướng đối tượng

Lời cảm ơn Để có được đồ án tốt nghiệp này, tôi xin bày tỏ lòng biết ơn sâu sắc tới tập thể các thầy giáo, cô giáo trường Đại học Bách khoa Hà Nội nói chung và khoa Công nghệ thông tin nói riêng đã tận tình giảng dạy truyền đạt cho tôi những kiến thức, kinh nghiệm quý báu trong suốt những năm học vừa qua. Tôi xin chân thành cảm ơn thầy giáo tiến sĩ Huỳnh Quyết Thắng, bộ môn Công nghệ Phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách khoa Hà Nội đã khuyến khích, góp ý và rất tận tình hướng dẫn tôi trong suốt quá trình làm đồ án. Nhờ sự quan tâm chỉ bảo và những ý kiến đóng góp quý báu của thầy, tôi mới có thể hoàn thành đồ án này. Trong thời gian sửa chữa hoàn thiện đồ án, tôi đã nhận được sự chỉ bảo tận tình của thầy giáo tiến sĩ Nguyễn Ngọc Bình, trưởng bộ môn Công nghệ Phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách khoa Hà Nội. Tôi xin chân thành cảm ơn thầy đã dành cho tôi sự quan tâm và những ý kiến quý báu để tôi có thể hoàn thành đồ án này. Đồ án này cũng không thể hoàn thành nếu thiếu sự hỗ trợ về tư liệu và cơ sở vật chất từ phía trung tâm xuất khấu phần mềm Fsoft-fpt Hà Nội, tôi xin chân thành cảm ơn anh Phan Phương Đạt đã khuyến khích, động viên, giúp đỡ và tạo mọi điều kiện để tôi hoàn thành đồ án này. Cuối cùng, xin chân thành cảm ơn gia đình và bạn bè, những người đã luôn ở bên tôi trong suốt những năm học vừa qua. MỤC LỤC DANH MỤC CÁC HÌNH VẼ Hình 1.1: Ví dụ về phép đo kích thước chương trình 11 Hình 1.2: Ví dụ kết quả phép đo phần mềm (Fsoft-fpt) 17 Hình 1.3: Mô hình FCM 21 Hình 1.4: Mô hình đánh giá phần mềm ISO 9126 22 Hình 1.5: Mô hình đánh giá khả năng bảo trì của IEEE 23 Hình 1.6: Đánh giá độ phức tạp qua lưu đồ chương trình 25 Hình 2.1: Ví dụ minh họa về các phép đo CK 41 Hình 2.2: Mô hình REBOOT 43 Hình 2.3: Mô hình QMOOD. 46 Hình 3.1: Quy trình đo phần mềm hướng đối tượng 49 Hình 3.2: Sơ đồ hoạt động của chương trình 50 Hình 3.3: Các chức năng chính của chương trình 51 Hình 3.4: Các bảng trong cơ sở dữ liệu của chương trình 52 Hình 3.5: Chức năng nhập dữ liệu của chương trình 63 Hình 3.6: Chức năng tính toán và hiển thị độ đo trên mô hình 64 Hình 3.7: Chức năng tạo mới và sửa đổi mô hình 65 Hình 3.8: Chức năng mở CSDL 66 Hình 3.9: Chức năng phân tích kết quả đo. 67 Hình 4.1: Kết quả độ đo LCOM 71 Hình 4.2: Kết quả độ đo DIT 72 Hình 4.3: Kết quả độ đo CBO 73 Hình 4.4: Kết quả độ đo NOC. 74 Hình 4.5: Kết quả độ đo RFC 76 Hình 4.6: Kết quả độ đo WMC 77 Hình 4.7: Biểu đồ độ đo CK của các phần mềm 78 Hình 4.8: Dự đoán thuộc tính chất lượng dựa trên các độ đo CK 81 Hình 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD 84 DANH MỤC CÁC BẢNG Bảng 1.1: Phân công nhiệm vụ đo trong một tổ chức phần mềm 16 Bảng 1.2: Các hệ số trong mô hình COCOMO 20 Bảng 1.3: Các nhân tố chất lượng và tiêu chuẩn chất lượng trong ISO 9126. 23 Bảng 2.1: Vai trò của các độ đo CK trong các giai đoạn thiết kế lớp 40 Bảng 2.2: Các dạng hàm chuẩn hóa độ đo 44 Bảng 2.3: Các tiêu chuẩn và độ đo trong mô hình QMOOD. 45 Bảng 2.4: Mối liên hệ giữa các thuộc tính ngoài và thuộc tính trong của mô hình QMOOD 46 Bảng 3.1: Một số công cụ đo phần mềm hướng đối tượng 49 Bảng 3.2: Công thức tính tham số cho các dạng hàm chuẩn hóa 58 Bảng 4.1: Danh sách các dự án được đo 69 Bảng 4.2: Tổng cộng số lớp các dự án được đo 69 Bảng 4.3: Kết quả độ đo CK của các phần mềm 78 Bảng 4.4: Hệ số tương quan giữa các độ đo CK và các chỉ số chất lượng. 80 Bảng 4.5: Các hệ số của phương trình tuyến tính biểu diễn phụ thuộc giữa thuộc tính chất lượng và độ đo 81 Bảng 4.6: Kết quả các độ đo của mô hình QMOOD 82 Bảng 4.7: Lựa chọn ngưỡng cho các hàm chuẩn hóa các độ đo 83 Bảng 4.8: Ngưỡng cho các hàm chuẩn hóa các độ đo QMOOD. 83 Bảng 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD 84 Bảng 4.10: Hệ số tương quan giữa các thuộc tính của mô hình QMOOD với các thuộc tính chất lượng khác 85 Bảng 4.11: Hệ số tương quan giữa các độ đo và các chỉ số chất lượng 86 Bảng 4.12: Mối quan hệ ảnh hưởng giữa các độ đo và các chỉ số chất lượng 86 BẢNG GHI CHÚ CÁC THUẬT NGỮ Viết tắt Viết đầy đủ Giải nghĩa ADO Active Data Object Đối tượng để truy cập cơ sở dữ liệu ANA Average Number of Ancesters Trung bình số các lớp cha API Application Programming Interface Giao diện lập trình ứng dụng CAM Cohesion Among Methods in Class Tính cố kết giữa các phương thức trong cùng một lớp CBO Coupling Between Object class Độ kết dính giữa các lớp CIS Class Interface Size Kích thước giao diện lớp (số phương thức public) CK Chidamber, Kemerer Bộ các phép đo hướng đối tượng do Chidamber, Kemerer đề xuất [6] COCOMO Constructive Cost Model Mô hình ước tính chi phí cho các dự án phần mềm CSDL Cơ sở dữ liệu DAM Data Access Metric Khả năng truy cập dữ liệu (tỷ lệ số thuộc tính public) DCC Direct Class Coupling Số lớp có tính kết dính với một lớp DIT Depth of Inheritance Tree Độ sâu cây thừa kế DSC Design Size in Classes Số lớp của chương trình FCM Factor-Criteria-Metrics Mô hình nhân tố-tiêu chuẩn-độ đo để đánh giá chất lượng phần mềm GNU GNU Library General Public License Thư viện C++ của cộng đồng mã nguồn mở ISO 9126 International Standard Organization Mô hình đánh giá chất lượng phần mềm của tổ chức tiêu chuẩn quốc tế JBOOMT Jade Bird Object Oriented Metric Tool Công cụ đo phần mềm hướng đối tượng JDK Java Developer Kit Thư viện lập trình Java của Sun Microsystem LCOM Lack of Cohesion among Methods Độ thiếu cố kết giữa các phương thức (trong cùng 1 lớp) LOC Lines of code Số dòng mã lệnh MFA Measure of Functional Abstraction Độ đo mức độ sử dụng thừa kế của một lớp MFC Microsoft Foundation Class Thư viện lập trình C++ của Microsoft MFM Measure of Functional Modularity Độ đo về tính độc lập chức năng MOA Measure of Aggregation Sự tổ hợp giữa các lớp MTBF Mean Time Between Failure Thời gian giữa các sai hỏng MTTF Mean Time To Failure Thời gian đến sai hỏng MTTR Mean Time To Repair Thời gian để sửa chữa NOC Number Of Children Số con trực tiếp của một lớp NOH Number Of Hierarchies Số các mức phân cấp NOM Number of Methods Số phương thức trong lớp (độ phức tạp của lớp) NOP Number of Polymorphic Methods Số phương thức đa hình ODBC Open Database Connectivity Đối tượng để truy cập cơ sở dữ liệu OLEDB Object Linking Embedding – Database Đối tượng để truy cập cơ sở dữ liệu QMOOD Quality Model for Object Oriented Design Mô hình chất lượng cho phần mềm hướng đối tượng REBOOT ReusE Based on Object Oriented Technology Mô hình sử dụng lại cho phần mềm hướng đối tượng RFC Responce set For Class Tập trả lời của lớp (các phương thức bị gọi bởi lớp đó) STL Standard Template Library Thư viện lập trình C++ cung cấp các tính năng mở rộng WMC Weight Metric per Class Độ phức tạp của một lớp MỞ ĐẦU 1. Đặt vấn đề Đo phần mềm là một trong những nhiệm vụ đóng vai trò quan trọng trong các hoạt động kỹ thuật phần mềm. Trong khi kỹ nghệ phần mềm đề cập đến các hoạt động liên quan đến quá trình phát triển phần mềm, đo phần mềm liên quan đến các đối tượng trong kỹ nghệ phần mềm mà có thể định lượng được. Một số ví dụ điển hình là đo và dự đoán chi phí dự án, đo và dự đoán chất lượng của sản phẩm phần mềm. Tất cả các ngành công nghệ đều xác định rõ vai trò quan trọng của phép đo khi tiến hành bất kỳ một hoạt động sản xuất nào. Một dự án phần mềm được tiến hành mà không gắn liền với quá trình đo có thể dẫn tới không thể kiểm soát được thời gian hoàn thành sản phẩm, chất lượng sản phẩm bàn giao cho khách hàng không được đảm bảo. Nếu không thể đánh giá một sản phẩm, chúng ta cũng không thể đánh giá một phương pháp phát triển phần mềm mới là tốt hay không tốt. Như vậy, có thể nói đo phần mềm đóng một vai trò quan trọng trong kỹ nghệ phần mềm. Thực hiện đo phần mềm trong các dự án phần mềm nhằm các mục đích: kiểm soát quá trình xây dựng phần mềm, đảm bảo hoàn thành sản phẩm đúng thời hạn, kiểm soát chất lượng sản phẩm, dự đoán khắc phục các sự cố có thể xảy ra, cải tiến quy trình sản xuất phần mềm. Các hệ thống thông tin ngày nay ngày càng có độ lớn độ phức tạp, yêu cầu phải được xây dựng trong một thời gian ngắn mà vẫn phải đảm bảo chất lượng. Trước yêu cầu đó, kỹ nghệ phần mềm đã đưa ra những phương pháp phát triển mới nhằm đáp ứng những đòi hỏi bức xúc đó. Phương pháp phát triển phần mềm hướng đối tượng là một trong những cách tiếp cận cho phép rút ngắn thời gian phát triển phần mềm qua việc sử dụng lại mã. Mỗi phương pháp phát triển mới đều đòi hỏi có những phương tiện đánh giá phù hợp (đánh giá về quá trình, đánh giá sản phẩm). Các phép đo phần mềm trước đây như đo số dòng mã lệnh không thể hiện được tính chất hướng đối tượng của sản phẩm. Như vậy cần có những phương pháp, công cụ phù hợp để đánh giá phần mềm hướng đối tượng. Xuất phát từ các yêu cầu thực tiễn nêu trên, trong đồ án này, chúng tôi tập trung nghiên cứu phép đo sản phẩm phần mềm được xây dựng trong môi trường hướng đối tượng. Cơ sở lý thuyết của đề tài dựa trên lý thuyết đo phần mềm nói chung và đo phần mềm hướng đối tượng nói riêng (các phép đo CK và mô hình chất lượng ISO 9126). Phần phát triển của chúng tôi là đề xuất quy trình đo phần mềm gồm 4 pha, xây dựng công cụ trợ giúp đo phần mềm hướng đối tượng, tiến hành đo và phân tích kết quả đo một số phần mềm hướng đối tượng. 2. Nhiệm vụ và bố cục của đồ án Đồ án này tập trung vào các vấn đề xoay quanh phép đo phần mềm hướng đối tượng: lý thuyết đo phần mềm, tổng hợp các kết quả nghiên cứu về đo phần mềm hướng đối tượng, đề xuất hướng nghiên cứu và phân tích các kết quả đo thực nghiệm. Ba nhiệm vụ chính của đồ án như sau: Tìm hiểu lý thuyết đo phần mềm, tổng hợp các kết quả nghiên cứu trên thế giới về đo phần mềm. Chương 1 trình bày các vấn đề: cách tiếp cận lý thuyết đo phần mềm dựa trên lý thuyết đo nói chung; các yêu cầu, vai trò, mục đích đối với một phép đo phần mềm; một số kết quả nghiên cứu trên thế giới và các phương pháp đo phần mềm được sử dụng rộng rãi trong công nghệ phần mềm. Tìm hiểu lý thuyết đo phần mềm hướng đối tượng, các kết quả nghiên cứu về đo phần mềm hướng đối tượng. Chương 2 trình bày về các phép đo hướng đối tượng, các mô hình đánh giá phần mềm hướng đối tượng. Đề xuất và xây dựng công cụ trợ giúp cho quá trình đo phần mềm hướng đối tượng (chương 3). Nhiệm vụ đặt ra là đề xuất một khung cho quá trình đo phần mềm và xây dựng công cụ trợ giúp quy trình đó. Quy trình đo phần mềm được đề xuất gồm có 4 bước: chọn lựa mô hình, thu thập dữ liệu, tính toán trên mô hình và phân tích kết quả. Công cụ trợ giúp đo phần mềm hướng đối tượng được xây dựng nhằm mục đích hỗ trợ quy trình đo phần mềm đó. Các mô hình và độ đo được lưu trữ trong cơ sở dữ liệu, người sử dụng có thể sửa đổi mô hình hoặc xây dựng mô hình mới. Tiến hành đo thực nghiệm và phân tích các kết quả đo được. Các kết quả đo phần mềm được trình bày trong chương 4 là kết quả đo 8 dự án phần mềm ở trung tâm xuất khẩu phần mềm Fsoft-fpt Hà Nội và 4 thư viện lập trình hướng đối tượng gồm có MFC, JDK, GNU, STL. Công cụ xây dựng ở trên được sử dụng để trợ giúp cho quá trình đo. Các kết quả đo được phân tích về các khía cạnh: so sánh các giá trị đo giữa hai nhóm phần mềm, mối liên quan ảnh hưởng giữa các độ đo và chất lượng phần mềm. Quá trình phân tích cho thấy các kết quả đo phù hợp với lý thuyết về các phép đo hướng đối tượng của Chidamber và Kemerer, rút ra những nhận xét về mối quan hệ ảnh hưởng giữa các độ đo và chất lượng phần mềm. Các số liệu thống kê được chúng tôi trình bày trên bảng và biểu đồ nhằm thể hiện tính trực quan tới người đọc. Nội dung của đồ án được chia thành 4 chương như trên, phần cuối là kết luận, đánh giá các kết quả đạt được và đề ra phương hướng phát triển tiếp theo của đề tài trong tương lai. CHƯƠNG 1: TỔNG QUAN VỀ LÝ THUYẾT ĐO PHẦN MỀM 1.1 Lý thuyết đo Trong cuộc sống hàng ngày chúng ta luôn luôn gặp các tình huống phải sử dụng các phép đo. Tuy nhiên có thể do quá quen với các phép đo, chúng ta ít chú ý đến bản chất của phép đo : Đo là một quá trình mà kết quả là các ký hiệu được gán cho các thuộc tính của thực thể theo một tập các luật được định nghĩa rõ ràng [10]. Như vậy phép đo liên quan đến thuộc tính của thực thể. Thực thể có thể là một sự vật, một con người hay là pha kiểm tra của một dự án phần mềm .v.v. Thuộc tính của thực thể có thể là chiều cao, chỉ số thông minh hay là độ phức tạp, độ tin cậy .v.v. Chúng ta cần lưu ý là thực tế chúng ta không đo thực thể mà đo các thuộc tính của thực thể. Phép đo gán các ký hiệu cho các thuộc tính của thực thể để mô tả chúng. Chẳng hạn khi đo chiều cao của người ta gán giá trị lớn hơn cho người cao hơn, không phụ thuộc vào việc chúng ta sử dụng đơn vị đo là inches, metres hay feet. Trong vật lý, y học, kinh tế xã hội ngày nay chúng ta đã có thể đo được các thuộc tính mà trước đây người ta chưa thể nghĩ là có thể đo được. Dựa trên kết quả các phép đo về trí thông minh, chất lượng không khí, tỷ lệ lạm phát, . . . người ta có thể đưa ra các quyết định quan trọng. Những phép đo như thế không phải là cố định mà vẫn không ngừng được cải tiến. Trong phần này chúng ta trình bày những vấn đề cơ bản của lý thuyết đo phần mềm. Những vấn đề này sẽ là cơ sở cho các phần tiếp theo của đồ án. 1.1.1 Cơ bản về lý thuyết đo Ở trên chúng ta đã nêu khái niệm về phép đo. Từ đó chúng ta đi đến khái niệm sau: Đo là việc gán một giá trị số (hay ký hiệu) cho một thực thể để mô tả một thuộc tính [10]. Như vậy phép đo bản thân nó là một ánh xạ từ tập thực thể vào tập độ đo để mô tả thuộc tính. Ví dụ: X 100 3000 Số câu lệnh Số byte Chương trình Hình 1.1: Ví dụ về phép đo kích thước chương trình Giả sử chúng ta muốn đo thuộc tính độ lớn của chương trình X. Phép đo có thể được thực hiện bằng việc ánh xạ từ mã nguồn vào số câu lệnh của chương trình. Kết quả của phép ánh xạ đó (100 trong ví dụ ở hình 1.1) để biểu diễn độ lớn của chương trình. Tuy nhiên ngoài ra còn có thể có các phép đo khác ví dụ như ánh xạ từ mã nguồn vào số bytes của chương trình (3000 trong ví dụ ở hình 1.1). Để thực hiện phép đo chúng ta phải có một số hiểu biết về thuộc tính của thực thể sắp tiến hành đo. Khi đã xác định được thực thể và có phương tiện (độ đo, công cụ đo) thì mới có thể tiến hành đo. Phân tích kết quả đo giúp chúng ta có hiểu biết về thuộc tính của thực thể, có thể có những cải tiến về độ chính xác, đơn vị của phép đo. Phép đo trực tiếp và phép đo gián tiếp Chúng ta có thể đo các thuộc tính như là khối lượng và độ dài mà không cần thông qua một thuộc tính nào khác. Trong khi đó việc đo thuộc tính mật độ yêu cầu phải thông qua các thuộc tính khác (khối lượng và độ dài). Để phân biệt hai phép đo này chúng ta có khái niệm: Phép đo trực tiếp một thuộc tính là phép đo không phụ thuộc vào phép đo một thuộc tính nào khác. Phép đo gián tiếp một thuôc tính là phép đo liên quan đến phép đo một số thuộc tính khác [10]. Một số thuộc tính, chẳng hạn nhiệt độ, chỉ có thể đo thông qua các thuộc tính khác (trong trường hợp này là chiều cao của cột thủy ngân). Việc phân loại phép đo trực tiếp và gián tiếp đề cập đến việc ánh xạ các qua lại giữa các độ đo hơn là bản thân thuộc tính. Lý thuyết quan hệ về phép đo được trình bày sau đây ban đầu chỉ liên quan đến các phép đo trực tiếp. Khi chúng ta cần nghiên cứu các thuôc tính của thực thể mà trước đây chưa có phép đo nào để đo các thuộc tính đó, chẳng hạn trong trường hợp các thuộc tính của phần mềm, mà bản thân các thuộc tính như độ tin cậy, khả năng tái sử dụng, tính tiện dụng giao diện người sử dụng cũng chưa được hiểu một cách xác đáng, thì cách tiếp cận theo phương pháp đo gián tiếp là thích hợp. 1.1.2 Lý thuyết đo – cách tiếp cận Phần này chúng ta trình bày phương pháp biểu diễn phép đo. Phép đo được mô hình hóa dựa trên các khái niệm : tập hợp, quan hệ và ánh xạ. Các thành phần cơ bản của lý thuyết đo gồm có: Hệ thống quan hệ: Xác định tính chất của các thuộc tính (tiên đề) qua các kết quả quan sát trực giác hay là các hiểu biết ban đầu về thuộc tính. Các tính chất này thường được thể hiện qua các quan hệ giữa các thực thể. Ví dụ như thuộc tính độ nóng của dung dịch có mối quan hệ “nóng hơn” giữa các dung dịch và quan hệ này thỏa mãn tính bắc cầu. Biểu diễn thay thế: Các thuộc tính có thể được biểu diễn bằng một hệ thống trị số thích hợp bảo toàn các tính chất và quan hệ, việc biểu diễn này thực hiện như là một ánh xạ từ tập thực thể vào tập trị số. Tiếp tục ví dụ độ nóng ở trên, dung dịch A ánh xạ vào số x, dung dịch B ánh xạ vào số y, khi đó quan hệ “nóng hơn” được chuyển thành quan hệ “>”, ta phải có x>y. Quan hệ chuyển đổi: Hai hàm bất kỳ từ thực thể sang trị số để biểu diễn thuộc tính đều có một mối quan hệ nào đó. Chẳng hạn tất cả những gì chúng ta biết về độ nóng của dung dịch là dung dịch này thì nóng hơn dung dịch kia và mối quan hệ nóng hơn này có tính bắc cầu. Hai hàm bất kỳ thể hiện độ nóng được liên hệ bởi một sự chuyển đổi. Một điểm lưu ý là mặc dù mong muốn của chúng ta là phép đo được thực hiện khách quan nhưng các quan hệ ban đầu được thiết lập một cách chủ quan. Chẳng hạn đo độ dài khi chưa có đơn vị đo thì đó là cách đánh giá chủ quan cái này dài hơn cái kia. Khi nào các quan hệ chưa được xác lập một cách rõ ràng thì chỉ có cách đánh giá chủ quan, ví dụ như việc đánh giá chất lượng rượu hay đánh giá độ phức tạp của một chương trình. Cách làm có thể là đưa cho một nhóm các chuyên gia phân nhóm chương trình theo tính phức tạp từ 1 đến 5. Mặc dù việc đánh giá đó chưa phải là phép đo theo đúng nghĩa của nó nhưng việc đánh giá như thế là cần thiết, dần dần khi đã có sự nhất trí về phân loại các thực thể dựa trên tính chất, có thể dẫn đến một phép đo khách quan. Hệ thống quan hệ Giả sử tính chất của thuộc tính được biểu diễn bởi tập các quan hệ R, gọi tập các thực thể là C, ta gọi hệ thống quan hệ là x = (C,R). Ví dụ : Xét thuộc tính độ nghiêm trọng của sai hỏng phần mềm. Gọi C là tập các sai hỏng phần mềm, ta xem xét 3 hệ thống quan hệ như sau: Hệ thống quan hệ đơn giản trong đó chỉ có sự phân loại các sai hỏng phần mềm chẳng hạn như: cú pháp, logic, đổ vỡ hệ thống. Giả thiết rằng các sai hỏng phần mềm chỉ thuộc một trong ba loại trên. Điều đó có nghĩa là chúng ta có một hệ thống quan hệ (C,R) trong đó R gồm 3 quan hệ đơn: quan hệ R1 “là cú pháp”, R2 “là logic”, R3 “là đổ vỡ hệ thống”. Giả thiết rằng với mọi xÎC thì x là R1, R2, hoặc R3. Trong hệ thống quan hệ này chúng ta chưa có đánh giá về trị số để so sánh tương đối về tính nghiêm trọng giữa các sai hỏng, chúng ta chỉ biết rằng đó là các loại sai hỏng khác nhau. Chúng ta thêm vào quan hệ cũ một quan hệ mới R4 “nghiêm trọng hơn”. Thông thường ta quan niệm: các đổ vỡ hệ thống thì nghiêm trọng hơn sai hỏng cú pháp và logic, các sai hỏng logic thì nghiêm trọng hơn sai hỏng về cú pháp. R4 gồm các cặp sai hỏng (x, y) trong đó hoặc: i)xÎR3 và yÎR2 hay R1, ii) xÎR2 và yÎR1. Hệ thống quan hệ mới cho tính nghiêm trọng các sai hỏng phần mềm là (C, R’) trong đó R’ = {R1, R2, R3, R4}. Nhằm đạt mục tiêu biểu hiện các hiểu biết sâu hơn về tính nghiêm trọng của các sai hỏng phần mềm, chúng ta thêm vào hệ thống quan hệ R’ một quan hệ mới: sự chênh lệch về độ nghiêm trọng giữa sai hỏng cú pháp và sai hỏng logic cũng bằng với sự chênh lệch về độ nghiêm trọng giữa sai hỏng logic và sai hỏng đổ vỡ hệ thống. Chúng ta có quan hệ R5 với (x,y,x’,y’) Î R5 nghĩa là chênh lệch về độ nghiêm trọng giữa x và y bằng chênh lệch về độ nghiêm trọng giữa x’ và y’ trong đó x là sai hỏng đổ vỡ hệ thống, y và x’ là sai hỏng cú pháp còn y’ là sai hỏng logic. Chúng ta có hệ thống quan hệ mới (C, R’’) trong đó R’’ = {R1, R2, R3, R4, R5}. Hệ thống quan hệ dựa trên trị số (biểu diễn thay thế) Sau khi tìm được hệ thống quan hệ cho thuộc tính, chúng ta cần tìm một ‘hệ thống số, chẳng hạn như tập các số thực Â, để thực hiện ánh xạ các thực thể. Nói đúng hơn chúng ta cần hệ thống quan hệ dựa trên trị số gồm có một tập hợp trị số và các quan hệ trên tập đó. Mỗi quan hệ trong hệ thống cũ đều đòi hỏi một quan hệ tương ứng trong hệ thống quan hệ dựa trên số. Đó gọi là điều kiện biểu diễn thay thế cho hệ thống quan hệ. Ký hiệu N là tập trị số và P là tập quan hệ giữa các trị số ta có hệ thống mới (N, P) . Việc bảo toàn tất cả các quan hệ trong hệ thống số cho phép chúng ta định nghĩa ánh xạ từ tập thực thể vào tập trị số N là một phép đo. Ta nói M là phép đo một thuộc tính nếu đó là một ánh xạ từ hệ thống quan hệ (C, R) sang hệ thống quan hệ dựa trên số (N, P). M thực hiện ánh xạ một thực thể thuộc C sang một trị số thuộc N, và một quan hệ thuộc R sang một quan hệ thuộc P. Ví dụ: Tiếp tục ví dụ về độ nghiêm trọng sai hỏng phần mềm ở trên. Chúng ta tìm hệ thống quan hệ dựa trên trị số cho thuộc tính sai hỏng phần mềm. Để tìm một biểu diễn thay thế cho R trong dạng số thực, ta lấy ba số phân biệt bất kỳ, chẳng hạn 6, 2, 69. Chúng ta ánh xạ tất cả các sai hỏng cú pháp (các thành phần của R1) vào số 6, các sai hỏng logic (thuộc R2) vào số 2, các sai hỏng đổ vỡ hệ thống (thuộc R3) vào số 69. Để thỏa mãn điều kiện biểu diễn thay thế, chúng ta chuyển các quan hệ R1, R2, R3 thành các quan hệ P1, P2, P3 đối với các số trong đó P1 là quan hệ “là 6”, P2 là quan hệ “là 2” và P3 là quan hệ “là 69”. Để tìm một biểu diễn thay thế cho R’ chúng ta cần xem xét cẩn thận hơn khi gán các trị số. Trước hết chúng ta cần tìm quan hệ P4 tương ứng với R4. Quan hệ P4 đương nhiên là >. Để hệ thống mới thỏa mãn quan hệ P4 chúng ta cần ánh xạ sai hỏng đổ vỡ hệ thống vào số lớn hơn sai hỏng logic và sai hỏng logic vào số lớn hơn sai hỏng cú pháp. Như vậy có thể biểu diễn như sau: sai hỏng cú pháp ®1, sai hỏng logic®6, sai hỏng đổ vỡ hệ thống® 7. Để tìm biểu diễn thay thế cho R’’, chúng ta cần bảo toàn cả quan hệ R5, nghĩa là sai khác giữa các trị số mà sai hỏng đổ vỡ hệ thống và sai hỏng logic ánh xạ vào bằng sai khác giữa các trị số mà sai hỏng logic và sai hỏng cú pháp ánh xạ vào. Một ánh xạ thỏa mãn là: cú pháp ®6, logic®8, đổ vỡ hệ thống®10. 1.2 Cơ sở lý thuyết về phép đo phần mềm Phép đo phần mềm là phương tiện mà nhờ đó các kỹ sư phần mềm tính toán và dự đoán được các khía cạnh khác nhau về các quá trình, tài nguyên, sản phẩm liên quan tới hoạt động kỹ thuật phần mềm [7]. 1.2.1. Vai trò của phép đo phần mềm. “Chúng ta không thể kiểm soát cái mà chúng ta không thể đo được” [4]. Việc phát triển phần mềm có chất lượng là rất cần thiết. Để đảm bảo chất lượng phần mềm cần tiến hành các phép đo trong quá trình phát triển phần mềm. Chúng ta đã biết rằng việc bảo dưỡng các hệ thống thông tin chiếm một tỷ lệ tài chính khá lớn trong các dự án. Hệ thống có chất lượng kém cần phải bảo dưỡng nhiều hơn hệ thống có chất lượng tốt. Một hệ thống được xây dựng mới mà không kèm theo sự kiểm soát chất lượng chặt chẽ sẽ dẫn đến những yêu cầu bảo dưỡng tốn kém sau này. Mọi ngành công nghệ như điện, cơ khí, xây dựng không thể phát triển như ngày nay nếu thiếu vai trò của đo đạc. Đối với ngành công nghệ phần mềm cũng vậy, phép đo đóng một vai trò quan trọng. Những thiếu sót mà chúng ta thường mắc phải khi phát triển phần mềm mà không sử dụng phép đo là: Khi phát triển một sản phẩm phần mềm, chúng ta không đặt một mục tiêu rõ ràng có thể đo được. Chúng ta nói rằng sản phẩm có tính “thân thiện người sử dụng”, “tin cậy cao”, “khả năng bảo trì tốt” nhưng không định nghĩa rõ những thuộc tính này có ý nghĩa như thế nào xét trên khía cạnh đo đạc. Như vậy không thể khẳng định sự thành công của dự án nếu mục tiêu của nó là “mờ”. Chúng ta không thể hiện chất lượng phần mềm dưới dạng lượng. Chúng ta không thể nói với khách hàng rằng phần mềm mà chúng ta sản xuất sẽ chạy trong bao lâu không bị sai hỏng với một độ tin cậy nào đó, hoặc là cần bao nhiêu chi phí nhân lực để chuyển sản phẩm đó sang chạy ở một môi trường khác. Chúng ta hoàn toàn bị thuyết phục bởi việc sử dụng những phương pháp hay công cụ mới được phát triển sẽ nâng cao chất lượng sản phẩm mà chúng ta sản suất. Thiếu sót của ngành công nghệ phần mềm là các phép đo được tiến hành không thường xuyên, không phù hợp và không hoàn chỉnh. Phép đo phần mềm phải được dựa trên những luận điểm cơ bản của lý thuyết đo. Chúng ta có thể thấy những báo cáo khoa học công bố “80% chi phí sản xuất phần mềm là dành cho pha bảo trì” hay “cứ 1000 dòng lệnh thì có khoảng 55 lỗi”. Nhưng chúng ta không biết những thí nghiệm đó được tiến hành như thế nào, vì thế ta không thể lặp lại những nghiên cứu như thế trong môi trường của chúng ta để có kết quả so sánh. Vậy vấn đề của phép đo phần mềm là thiếu một cách tiếp cận thống nhất được áp dụng rộng rãi, dẫn đến các kết quả đo được thực hiện và công bố không nhiều. Thật không may là những nỗ lực nghiên cứu đánh giá về hiệu năng phần cứng, đánh giá độ phức tạp tính toán cho ta những đánh giá rất tốt về những chương trình nhỏ, những thuật toán nhưng không đánh giá được những hệ thống lớn phức tạp là lĩnh vực của công nghệ phần mềm. Có thể nói nếu chúng ta không xác định vai trò quan trọng của phép đo phần mềm thì cuộc khủng hoảng phần mềm có thể ngày càng gay gắt hơn. 1.2.2. Mục đích và đối tượng của phép đo phần mềm Sản xuất phần mềm đang gặp phải các vấn đề: chi phí sản xuất lớn (đặc biệt là pha bảo trì), năng suất thấp và vấn đề đáng quan tâm là chất lượng kém. Nói tóm lại sản xuất phần mềm không được kiểm soát chặt chẽ bởi vì chúng ta không tiến hành đo đạc. Chúng ta có thể tóm tắt mục đích của phép đo phần mềm trong các cụm từ: kiểm soát, đánh giá, dự đoán, cải tiến. Đối tượng đo không chỉ có sản phẩm phần mềm mà gồm tất cả những thực thể liên quan đến hoạt động sản xuất phần mềm như quy trình, nguồn lực. Ví dụ sau sẽ giúp chúng ta có những ý tưởng ban đầu về các phép đo phần mềm: Nhóm người Nhiệm vụ đo Mục đích Nhà quản lý Chi phí cho các pha của dự án Kiểm soát chi phí nhằm thu được lợi nhuận Năng suất (năng lực sản suất) của nhân viên Trả tiền công cho nhân viên Chất lượng phần mềm được sản xuất So sánh các dự án, dự đoán, thiết lập ranh giới và mục tiêu cải tiến. Đề xuất các phép đo sử dụng cho dự án. Nhân viên của dự án tiến hành đo và báo cáo Hiệu quả quy trình, nguồn lực Nhân tố nào ảnh hưởng đến hiệu quả sản suất. Hiệu quả của các phương pháp, công cụ Giới thiệu phương pháp công cụ với cả công ty. Kỹ sư phần mềm Quá trình: thay đổi ở pha thiết kế, lỗi ở pha kiểm tra... Kiểm soát tiến triển của hệ thống. Cụ thể hóa các yêu cầu đo từ nhà quản lý và tiến hành đo: lỗi / yêu cầu, kích thước, chi phí, ... Thông báo cho người quản lý để có những quyết định kịp thời. Bảng 1.1: Phân công nhiệm vụ đo trong một tổ chức phần mềm (a) Mức độ hoàn thành đúng thời gian (Timeliness) (b) Tỷ lệ chi phí cho việc đảm bảo chất lượng (Quality cost) Hình 1.2: Ví dụ kết quả phép đo phần mềm (Fsoft-fpt) Hình 1.2 là một ví dụ minh họa kết quả đo phần mềm được thể hiện trên đồ thị. Hình 1.2a thể hiện độ đo mức độ hoàn thành đúng thời gian của các dự án phần mềm, trục nằm ngang là các dự án, trục đứng thể hiện độ đo mức độ hoàn thành đúng thời gian. Ý nghĩa của độ đo này như sau: giả sử một dự án phần mềm phải thực hiện 5 lần bàn giao sản phẩm cho khách hàng, mỗi lần giao đúng hạn thì được 20%, nếu dự án giao hàng chậm một lần thì dự án đạt 80%. Trong hình 1.2a có các dự án Pay&Go và NS Wap 2.5 có kết quả độ đo này là 0% nghĩa là giao hàng chậm trong tất cả các lần chuyển giao cho khách hàng. Hình 1.2b thể hiện kết quả phép đo tỷ lệ các chi phí cho việc đảm bảo chất lượng, gồm có chi phí cho việc đảm bảo quy trình (Process Cost – PCost), chi phí cho việc kiểm định chất lượng sản phẩm (Assurance Cost – ACost), chi phí cho việc chữa lỗi (Correction Cost). 1.2.3 Các yêu cầu đối với một phép đo phần mềm Đơn giản để có thể tính toán một cách dễ dàng. Có tính thực tế và tính thuyết phục cao (ví dụ giá trị đo được tỷ lệ với chất lượng sản phẩm). Thể hiện tính khách quan (khi tiến hành bởi nhiều người khác nhau, bằng thủ công hay bằng máy tính phải cho những kết quả tương tự nhau). Có đơn vị đo được chuẩn hóa (ví dụ giá trị đo được nằm trong khoảng 0..1, càng gần 1 tức là chất lượng càng cao). Độc lập với ngôn ngữ lập trình. Có tính tích cực đối với quá trình nâng cao chất lượng sản phẩm (cung cấp những thông tin phản hồi có giá trị cho nhóm phát triển phần mềm). 1.2.4 Các bước của quá trình đo phần mềm Như phần 1.1.1 đã nói, khi muốn đo một thuộc tính của một thực thể nào đó, chúng ta cần phải có một số hiểu biết về thuộc tính của thực thể sắp tiến hành đo, sau đó cần có phương tiện để thực hiện phép đo (độ đo, công cụ đo). Khi cần tiến hành đo phần mềm, chúng ta có thể tiến hành theo những bước sau [7]: Lựa chọn phép đo. Tùy mục đích và môi trường phần mềm mà chúng ta lựa chọn phép đo phù hợp. Tiến hành đo trong môi trường phần mềm đó. Đánh giá kết quả đo và có những cải tiến phép đo. 1.2.5 Một ví dụ về phép đo phần mềm Trong phần này chúng ta đưa ra một ví dụ về phép đo của Halstead [5]. Phép đo này dựa trên số toán tử và toán hạng có trong chương trình để đưa ra ước tính về chi phí thời gian để viết đoạn chương trình đó. Một chương trình P là tập hợp các ký hiệu, gồm có toán tử và toán hạng. Các phép đo ban đầu được định nghĩa: m1 = số toán tử phân biệt m2 = số toán hạng phân biệt N1 = tổng số toán tử N2 = tổng số toán hạng Độ dài của chương trình P được định nghĩa là N=N1+N2. Lượng từ vựng của P là m=m1+m2. Chi phí công sức (effort) để xây dựng chương trình P được ước tính như sau: Thời gian thực sự cần để viết đoạn chương trình P được ước tính dựa trên kết quả nghiên cứu của John Stroud [8]: T = E / 18 (giây). Ví dụ: Xét đoạn chương trính viết bằng FORTRAN sau: SUBROUTINE SORT (A, N) INTEGER A(100), N, I, J, SAVE, M ROUTINE SORTS ARRAY A INTO DESCENDING ORDER IF (N.LT.2) GO TO 40 DO 30 I=2, N M=I-1 DO 20 J=1, M IF (A(I).GT.A(J)) GO TO 10 GO TO 20 10 SAVE = A(I) A(I) = A(J) A(J) = SAVE 20 CONTINUE 30 CONTINUE 40 RETURN END m1 = 14 m2 = 13 N1 = 51 N2 = 42 N = N1 + N2 = 93 m = m1 + m2 = 27 = 10045 T = E / 18 = 10045 / 18 = 558 giây » 10 phút. 1.2.6 Một số mô hình đo phần mềm Chúng ta đã biết tại sao trong công nghệ phần mềm cần tiến hành các phép đo. Bây giờ chúng ta xem xét một số kết quả nghiên cứu đã đạt được trong phép đo phần mềm. Các kết quả này bao gồm các vấn đề sau: Mô hình đo và ước tính chi phí và nhân lực. Mô hình đo năng suất. Mô hình đánh giá chất lượng phần mềm. Mô hình đánh giá độ tin cậy. Mô hình đánh giá hiệu năng. Độ phức tạp tính toán. Độ phức tạp cấu trúc chương trình. Ước tính chi phí và nhân lực Yêu cầu này xuất phát từ phía nhà quản lý. Người quản lý muốn dự đoán sớm chi phí cho các dự án sắp tiến hành. Một số mô hình đã được đ._.ề xuất là COCOMO (Boehm) [1], Function Point (Albrecht) [6]. Dựa vào kết quả nghiên cứu các dự án phần mềm, người ta đưa ra các công thức có thể ước tính trước chi phí cho các dự án sắp tiến hành. Mô hình COCOMO (Constructive Cost Model) đưa ra công thức cơ bản của nó như sau : trong đo E là chi phí về nhân lực – tháng D là thời gian cần để hoàn thành sản phẩm KLOC là ước tính số nghìn mã lệnh Các hệ số ai, bi, ci, di được cho trong bảng 1.3, các dự án phần mềm được chia thành ba loại: loại dự án nhỏ và đơn giản, loại dự án trung bình về mặt kích cỡ và độ phức tạp, loại dự án lớn và phức tạp có sự ràng buộc giữa phần cứng và phần mềm. Dự án ai bi ci di Nhỏ 2.4 1.05 2.5 0.38 Trung bình 3.0 1.12 2.5 0.35 Lớn 3.6 1.20 2.5 0.32 Bảng 1.2: Các hệ số trong mô hình COCOMO Function Point tính dựa trên trọng số của các thông tin về : số đầu vào, số đầu ra, số yêu cầu của người sử dụng, số file, số giao diện với bên ngoài.Trọng số (weighting factor) này biểu hiện các thực thể trên là thuộc loại đơn giản, trung bình hay phức tạp, lấy giá trị trong khoảng từ 3 đến 15. Ngoài ra người ta còn phải trả lời 14 câu hỏi khác để thu được một giá trị gọi là trị số ảnh hưởng (influence). Function point được tính như sau: function point = SUM(weighting factor) * [0.65 + 0.01 * SUM(influence)] Function point cũng là một thông số tốt để chỉ kích thước phần mềm. Phương pháp này không phụ thuộc vào quy trình phát triển phần mềm và ngôn ngữ được sử dụng. Tuy nhiên điểm yếu của phép đo này là sự đánh giá chủ quan khi trả lời các câu hỏi và nó không thể tính tự động được. Mô hình đánh giá chất lượng Một số mô hình đánh giá chất lượng được sử dụng rộng rãi trong công nghệ phần mềm gồm có: mô hình FCM, mô hình ISO 9126, ... Mô hình đánh giá nhân tố - tiêu chuẩn (Factor-Criteria-Metrics, FCM) được xem là một thành phần cơ bản để đánh giá chất lượng phần mềm. Nguyên tắc cơ bản của mô hình này là mỗi thuộc tính được chia thành một tập các nhân tố mà bản thân chúng có thể được chia thành một tập các tiêu chuẩn và các tiêu chuẩn được tính toán qua các độ đo (metrics). Các mô hình chất lượng phần mềm của ISO và IEEE được xây dựng dựa trên mô hình FCM. Hình 1.3: Mô hình FCM Các nhân tố, tiêu chuẩn và độ đo được sử dụng như sau : khách hàng và người giám đốc chỉ quan tâm đến mức thuộc tính và mức nhân tố (factor, ví dụ như độ tin cậy), người quản lý và điều hành dự án làm việc với mức tiêu chuẩn (criteria, ví dụ như tính chính xác của kết quả thực thi chương trình), họ phải xem xét những tiêu chuẩn nào ảnh hưởng đến nhân tố nào; ở mức sản xuất phần mềm, nhân viên của dự án phải thu thập các độ đo (metric, ví dụ như số lỗi trong quá trình kiểm tra). Chất lượng phần mềm, theo ISO 9126, được hiểu là “tất cả các tính chất hay thuộc tính của sản phẩm phần mềm làm cho nó có khả năng thích ứng với các tình huống hay là thỏa mãn các yêu cầu”. Ngoài ra, ISO 9126 cũng nêu ra chất lượng phần mềm có 6 nhân tố sau: Chức năng (Functionality) : là khả năng thực thi của phần mềm đáp ứng những yêu cầu của người sử dụng. Độ tin cậy (Reliability) : sự đảm bảo được thực thi trong các tình huống khác nhau Tiện dụng (Usability) : làm cho người sử dụng có thể hiểu, học và sử dụng được phần mềm, có tính hấp dẫn đối với họ. Hiệu năng (Efficiency) : năng suất của hệ thống so với tài nguyên sử dụng Bảo trì (Maintainability) : Khả năng chữa lỗi, thay đổi, nâng cấp khi có yêu cầu Tương thích (Portability) : khả năng chuyển đổi môi trường giữa các nền tảng phần cứng hay phần mềm. ISO/IEC 9126 Tương thích (Portability) Độ tin cậy (Reliability) Tính tiện dụng (Usability) Chức năng (Functionality) Bảo trì (Maintainability) Hiệu năng (Efficiency) Tính tiện dụng của phần mềm Độ tin cậy của phần mềm Hiệu năng của phần mềm Khả năng thay đổi sửa chữa phần mềm Khả năng chuyển đổi phần mềm sang chạy ở môi trường khác Chức năng yêu cầu có được đáp ứng? Hình 1.4: Mô hình đánh giá phần mềm ISO 9126 ISO 9126 là một mô hình chung để đánh giá chất lượng phần mềm, tùy từng lĩnh vực cụ thể mà người sử dụng thiết lập các mô hình phù hợp. ISO 9126 cũng đề xuất các nhân tố chất lượng có thể chia thành các tiêu chuẩn như sau: Nhân tố chất lượng Tiêu chuẩn Chức năng Tính phù hợp Tính chính xác Khả năng tương tác Đáp ứng đúng yêu cầu Tính bảo mật Độ tin cậy Độ chắc chắn Khả năng chịu lỗi Khả năng phục hồi Tính tiện dụng Tính dễ hiểu Khả năng học Tính dễ sử dụng Hiệu năng Thời gian đáp ứng Tài nguyên sử dụng Khả năng bảo trì Khả năng phân tích Khả năng thay đổi Tính ổn định Khả năng kiểm tra Tính tương thích Khả năng thích ứng Khả năng cài đặt Tính phù hợp Khả năng thay thế Bảng 1.3: Các nhân tố chất lượng và tiêu chuẩn chất lượng trong ISO 9126. Tuy nhiên các tiêu chuẩn trên được xác định thông qua các độ đo nào thì không được ISO 9126 trình bày. Các độ đo này thì tùy từng lĩnh vực cụ thể mà người sử dụng xác định tiêu chuẩn chất lượng nào được tính thông qua các độ đo nào. Sau đây là một ví dụ về mô hình đánh giá khả năng bảo trì của IEEE: Hình 1.5: Mô hình đánh giá khả năng bảo trì của IEEE Mô hình đánh giá độ tin cậy Độ tin cậy là một thuộc tính trong mô hình chất lượng ISO 9126. Quan điểm về độ tin cậy phần mềm được chấp nhận rộng rãi đó là khả năng thực thi thành công phần mềm đó, như vậy đối tượng cho phép đo độ tin cậy chỉ có thể là sản phẩm ở dạng mã máy. Đây là một trong những thuộc tính quan trọng nhất của chất lượng phần mềm. Độ tin cậy thường được đánh giá dựa trên số lỗi tìm thấy trong pha kiểm tra, hoặc là dựa trên thời gian không bị sai hỏng trong pha kiểm tra. Mô hình đánh giá độ tin cậy đơn giản nhất là độ tin cậy được tính bằng tỷ lệ lỗi của phần mềm: Tỷ lệ lỗi = số lỗi tìm thấy / kích cỡ chương trình Một cách đánh giá độ tin cậy thường dùng trong các hệ thống tin học là dựa trên thời gian giữa các sai sót, tính bằng tổng của thời gian đến sai sót (MTTF) và thời gian để sửa chữa (MTTR). MTBF = MTTF + MTTR Theo cách này, độ tin cậy phần mềm được tính qua tính sẵn sàng của nó, bằng tỷ lệ thời gian nó hoạt động không bị lỗi: Tính sẵn sàng = MTTF / (MTTF + MTTR) * 100 Độ tin cậy là một thuộc tính rất quan trọng của chất lượng phần mềm, tuy nhiên độ tin cậy thường được xác định muộn, sau khi đã có mã lệnh thực thi chương trình. Vì vậy cần có các phương pháp đánh giá độ tin cậy sớm trong quá trình phát triển phần mềm để có những cải tiến khắc phục kịp thời nhằm nâng cao chất lượng sản phẩm, giảm chi phí chữa lỗi cho dự án. Trong đề tài nghiên cứu về đánh giá phần mềm, chúng tôi đã đề xuất mô hình đánh giá độ tin cậy phần mềm dựa trên độ tin cậy các thành phần của phần mềm đó [16]. Công thức biểu diễn độ tin cậy hệ thống theo độ tin cậy các thành phần như sau: Trong đó: Rs : độ tin cậy của hệ thống Qs : độ không tin cậy của hệ thống (Qs = 1- Rs) Di : xác suất sai hỏng của thành phần i của hệ thống ji : tỷ lệ thời gian thực thi thành phần i trên tổng thời gian thực thi của hệ thống. m: số thành phần của hệ thống Ưu điểm của mô hình trên là công thức đơn giản, cho phép ước lượng sớm về độ tin cậy của hệ thống. Tuy nhiên, vấn đề còn tồn tại trong phương pháp này là cách tính độ tin cậy qua các mẫu thử chưa chính xác, chưa xét đến độ tin cậy các giao diện giữa các thành phần. Phương pháp này cần phải được nghiên cứu kỹ lưỡng hơn mới có thể áp dụng vào thực tiễn. Mô hình đánh giá hiệu năng Hiệu năng cũng là một thuộc tính trong mô hình phân cấp chất lượng (chúng ta gọi mô hình chất lượng phần mềm ISO 9126 là mô hình phân cấp chất lượng). Cũng giống như thuộc tính độ tin cậy, hiệu năng có thể đánh giá qua sự thực thi của sản phẩm phần mềm, qua tài nguyên và bộ nhớ mà nó yêu cầu. Tuy nhiên ngay cả trong trường hợp không biết cụ thể về môi trường thực thi của phần mềm, chương trình dịch được sử dụng, chúng ta vẫn có thể đánh giá hiệu quả thực thi của chương trình qua độ phức tạp tính toán của thuật toán được sử dụng. Mô hình đánh giá độ phức tạp Hình 1.6: Đánh giá độ phức tạp qua lưu đồ chương trình Một chương trình được xét dưới dạng một đồ thị với một điểm vào và một điểm ra. Dùng lý thuyết đồ thị có thể xác định được số đường đi từ điểm đầu đến điểm cuối. Độ phức tạp của chương trình được định nghĩa bởi cấu trúc điều khiển của nó và đặc trưng bằng tổng số các con đường độc lập tuyến tính đi qua chương trình. Biểu thức xác định độ phức tạp cyclomatic [13]: v(G) = e – n + 2p trong đó : e = số cạnh của đồ thị n = số đỉnh của đồ thị p = số thành phần kết nối của đồ thị Cạnh của đồ thị là một dòng lệnh chuyển điều khiển giữa các khối mã lệnh. Khối mã lệnh được coi là nút. Một chương trình con gọi là thành phần kết nối. Cách tính độ phức tạp cyclomatic này do McCabe đề xuất. Kết quả nghiên cứu của ông cũng đưa ra kết luận giá trị này nhỏ hơn 10 được coi là tốt. Những phép đo và phương pháp đánh giá được trình bày ở trên là những phép đo hướng sản phẩm, ngoài ra còn có phép đo quá trình, phép đo nguồn lực sẽ được trình bày trong phần 1.3.1 1.3 Một số vấn đề về đo phần mềm 1.3.1 Phân biệt các đối tượng đo : sản phẩm, quá trình, nguồn lực. Việc đầu tiên cần làm khi thực hiện một phép đo là phải xác định thực thể và thuộc tính cần đo. Đối với phần mềm, có ba loại thực thể là đối tượng để đo: Quá trình bao gồm các hoạt động liên quan đến sản xuất phần mềm: chúng thường kèm theo yếu tố thời gian. Sản phẩm là kết quả của quá trình, chẳng hạn như tài liệu hay chương trình bàn giao cho khách hàng. Nguồn lực là đầu vào cho quá trình: nhân lực, tài nguyên (phần cứng, phần mềm), kinh phí. Tất cả mọi đối tượng mà chúng ta muốn đo hay dự đoán về phần mềm đều thuộc một trong ba loại trên. Phép đo quá trình. Quá trình bao gồm các hoạt động sản xuất phần mềm có gắn với yếu tố thời gian, phép đo quá trình là phép đo các thuộc tính của các pha trong dự án phần mềm. Các phép đo quá trình thường có mục đích để kiểm soát, cải tiến quy trình phát triển phần mềm. Nhờ các kết quả đo có thể có những dự đoán và tiến hành những sửa đổi trong quy trình phát triển phần mềm [15]. Ví dụ như phép đo khả năng đáp ứng yêu cầu của khách hàng đúng thời hạn (timeliness). Giả sử phải bàn giao sản phẩm cho khách hàng ba lần, nếu giao hàng chậm một lần thì khả khả năng đáp ứng đúng thời hạn đạt 66%. Ngoài ra còn có nhiều phép đo khác gắn liền với quá trình sản xuất phần mềm như: công sức để tạo ra sản phẩm phần mềm (effort), hiệu quả kiểm tra (test efficiency)= số lỗi loại bỏ được qua quá trình kiểm tra / kích cỡ phần mềm. Phép đo sản phẩm Đối tượng của phép đo sản phẩm phần mềm bao gồm các thực thể là kết quả của quá trình, đó là kết quả bàn giao cho khách hàng như chương trình, tài liệu sử dụng, hoặc có thể là tài liệu được sản sinh trong vòng đời phần mềm, hoặc có thể là mã nguồn. Một số thuộc tính có thể tiến hành đo với sản phẩm là: Độ tin cậy của chương trình. Thuộc tính này phụ thuộc vào môi trường mà chương trình được thực thi (phần cứng, phần mềm). Tính dễ hiểu của tài liệu đặc tả phần mềm. Nó tùy thuộc vào người đang tìm hiểu tài liệu đó. Khả năng bảo trì của mã nguồn. Thuộc tính này phụ thuộc vào người trực tiếp tham gia bảo trì và các công cụ hỗ trợ cho công việc bảo trì. Các thuộc tính trên đây của sản phẩm phần mềm có liên quan đến môi trường mà nó được phát triển hay tồn tại, các thuộc tính này được gọi là thuộc tính ngoài, được trình bày ở phần 1.3.2. Phép đo nguồn lực Nguồn lực bao gồm các thực thể đầu vào cho quá trình sản xuất: nguồn nhân lực, công cụ (phần cứng, phần mềm), phương pháp. Một số thuộc tính nguồn lực có thể đo là: Chi phí (cost) dành cho việc đầu tư phát triển các công cụ mới. Năng suất (productivity) của nhân viên dự án. Năng suất có thể được tính như sau: Trong biểu thức trên, năng suất (productivity) được tính từ các thuộc tính sản phẩm (amount of output) và thuộc tính quá trình (effort input), trong đó sản phẩm ra có thể được tính bằng số dòng mã lệnh (LOC – lines of code), chi phí nhân lực (effort) tính bằng số lượng người tham gia dự án theo tháng (person-month). 1.3.2 Phân biệt thuộc tính trong và thuộc tính ngoài Thuộc tính trong của một sản phẩm, quá trình, nguồn lực là những thuộc tính có thể đo đạc một cách khách quan. Thuộc tính ngoài của một sản phẩm, quá trình, nguồn lực là những thuộc tính chỉ có thể đo đạc trong mối quan hệ với môi trường của sản phẩm, quá trình nguồn lực đó. Người sử dụng phần mềm và giám đốc dự án chỉ quan tâm đến các thuộc tính ngoài. Người giám đốc dự án có thể quan tâm đến các thuộc tính ngoài như năng lực sản xuất của nhân viên, hiệu quả sử dụng nguồn lực; người sử dụng muốn biết về tính tiện dụng, độ tin cậy, khả năng tương thích của sản phẩm mà họ sắp mua. Thuộc tính trong thường dùng để mô tả độ phức tạp cấu trúc như: kích thước phần mềm, độ phức tạp luồng điều khiển, độ kết dính giữa các thành phần. Chúng được định nghĩa một cách rõ ràng và có thể được đo đạc khách quan. Các thuộc tích ngoài thường có sự liên quan của con người và của môi trường như độ phức tạp, khả năng bảo trì, tính đọc hiểu .... Chỉ có các thuộc tính ngoài mới cung cấp cho chúng ta những thông tin có giá trị về hệ thống. Các thuộc tính ngoài khó có thể được định nghĩa một cách chính xác và đo đạc khách quan, hơn nữa những khái niệm như chất lượng phần mềm là một khái niệm rộng. Các thuộc tính trong có ảnh hưởng trực tiếp tới các thuộc tính ngoài, đo đạc và kiểm soát các thuộc tính trong sẽ nâng cao chất lượng của toàn hệ thống. Vì vậy chúng ta thường gián tiếp tính các thuộc tính ngoài qua các thuộc tính trong. Mô hình phân cấp chất lượng ISO 9126 hay là mô hình khác được phát triển từ mô hình FCM được đề xuất theo hướng này, nhưng chưa được áp dụng rộng rãi. Nguyên nhân chủ yếu là cách đo các thuộc tính ngoài không hoàn chỉnh, thậm chí không giống nhau. Về mặt lý thuyết, việc kiểm định mối liên hệ giữa các thuộc tính trong và các thuộc tính ngoài là hết sức khó khăn Kết luận chương 1: Trong chương này, chúng ta đã tìm hiểu những vấn đề cơ bản của lý thuyết đo phần mềm, cách tiếp cận tới lý thuyết đo phần mềm dựa trên một cơ sở vững chắc là lý thuyết đo nói chung. Chúng ta cũng đã tìm hiểu về một số mô hình đo được sử dụng rộng rãi trong công nghệ phần mềm. Tuy nhiên, việc lựa chọn phép đo phù hợp tùy vào môi trường phát triển phần mềm cụ thể cũng như mục đích tiến hành phép đo phần mềm đó. Trong đồ án này, chúng tôi tập trung nghiên cứu phép đo sản phẩm phần mềm được xây dựng trong môi trường hướng đối tượng. Chương tiếp theo sẽ tìm hiểu về các phép đo và mô hình đánh giá phần mềm phát triển trong môi trường hướng đối tượng. CHƯƠNG 2: PHÉP ĐO PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Ngày nay các hệ thống thông tin ngày càng có độ lớn, độ phức tạp, yêu cầu phải được phát triển trong một thời gian ngắn. Yêu cầu hệ thống được phát triển nhanh, có chất lượng đã thúc đẩy sự ra đời của các phương pháp phát triển phần mềm mới hiệu quả hơn. Trong số đó cách tiếp cận hướng đối tượng đã trở nên quen thuộc với giới công nghệ thông tin. Việc phát triển phần mềm hướng đối tượng có nhiều ưu điểm: tăng cường khả năng sử dụng lại mã do có tính thừa kế, rút ngắn thời gian phát triển và giảm lỗi do các lớp mới được thừa kế từ những lớp trong thư viện. Ngoài ra một vấn đề rất quan trọng trong việc cải tiến quy trình chính là khả năng đo các bước trong quy trình đó, chính vì thế đề tài nghiên cứu tìm ra các phép đo hướng đối tượng để đo phần mềm phát triển hướng đối tượng là một vấn đề đã được quan tâm nghiên cứu ngay từ năm 1988 khi phương pháp phát triển phần mềm hướng đối tượng ra đời. Từ đó đến nay đã có rất nhiều kết quả nghiên cứu về đo phần mềm hướng đối tượng đã được công bố trên thế giới. Cách tiếp cận bài toán theo quan điểm hướng đối tượng đã trở nên quen thuộc đối với chúng ta, các ngôn ngữ hướng đối tượng ngày càng được sử dụng rộng rãi. Ngày càng có nhiều các phần mềm được xây dựng theo phương pháp hướng đối tượng. Điểm nổi bật của quy trình phát triển phần mềm hướng đối tượng chính là ở bước thiết kế hướng đối tượng, hệ thống được chia thành các khối riêng gọi là đối tượng, gồm có dữ liệu và chức năng thực hiện trên các dữ liệu đó. Mô hình hướng đối tượng có những đặc điểm khác với mô hình hướng chức năng trước đây, nên cách đánh giá và đo đối với phần mềm hướng đối tượng cũng phải quan tâm đến những đặc trưng cơ bản như: đối tượng, lớp, thuộc tính, phương thức, thừa kế, thông điệp ... Các thuộc tính của đối tượng có thể đo đạc ví dụ như: số thuộc tính, số phương thức, số thông điệp gửi đến các đối tượng khác, vị trí của đối tượng trong sơ đồ cấu trúc hệ thống, số đối tượng thừa kế ... Phép đo cho phần mềm hướng đối tượng cả về mặt lý thuyết cũng như công cụ đo vẫn đang được tiếp tục nghiên cứu. Một phép đo hướng đối tượng cần giải đáp được các câu hỏi: Các bước tiến hành để đo sản phẩm phần mềm hướng đối tượng? Cần thiết kế các công cụ gì để hỗ trợ cho quá trình đo. Làm thế nào để áp dụng phép đo hướng đối tượng vào quy trình phát triển phần mềm. Có nhiều kết quả nghiên cứu về đo phần mềm hướng đối tượng đã được công bố trên thế giới. Về mặt lý thuyết, nhiều phép đo hướng đối tượng được đề xuất; về mặt thực nghiệm, các công cụ trợ giúp đo hướng đối tượng được xây dựng và có nhiều kết quả đo thực nghiệm đã được công bố. Các phép đo này tập trung vào khía cạnh hướng đối tượng, thể hiện các tính chất thừa kế, đa hình, bao bọc dữ liệu, trừu tượng hóa. Các tác giả đều đưa ra được luận điểm khẳng định phương pháp đánh giá của mình và chỉ ra lĩnh vực áp dụng của nó. Tuy nhiên nhiều phép đo còn một số tồn tại như sau: Một số phép đo không độc lập về mặt ngôn ngữ (C++, Ada . . .) Việc đánh giá các kết quả đo được nói chung là nằm trong một khoảng nào đó, dựa theo kinh nghiệm khẳng định nó là tốt hay xấu Các phép đo để đánh giá là chính chưa điều khiển được giá trị độ đo. Các phép đo hướng đối tượng đã được tổng kết trong các báo cáo [9], [11], [12]. Báo cáo [11] phân loại các phép đo hướng đối tượng theo phép đo quy trình, sản phẩm, tài nguyên (tính đến năm 1996). Báo cáo [9] tổng kết và so sánh các phép đo sản phẩm phần mềm hướng đối tượng nổi bật đã được công bố trên thế giới (tính đến năm 2000). Trong đồ án này, chúng tôi tập trung vào các phép đo CK do Chidamber, Kemerer đề xuất [3] và mô hình chất lượng đo phần mềm hướng đối tượng. Các phép đo CK có ưu điểm là gọn nhẹ, dễ tiến hành, có thể thực hiện trong các pha sớm của quá trình xây dựng phần mềm, độc lập với ngôn ngữ sử dụng. 2.1. Bộ các phép đo CK Các phép đo này do Chidamber, Kemerer đề xuất nên gọi là các phép đo CK. Các phép đo này nhấn mạnh vào pha thiết kế hướng đối tượng. Có 6 phép đo: WMC, DIT, LCOM, CBO, RFC, NOC. Các phép đo này tập trung vào khía cạnh hướng đối tượng của sản phẩm: về độ phức tạp, tính cố kết, tính kết dính và cây thừa kế. Các phép đo dựa trên các thuộc tính quan trọng, ảnh hưởng trực tiếp đến chất lượng sản phẩm, kết quả của phép đo cho phép ta dự đoán hoặc đánh giá sản phẩm. Chúng được đề xuất dựa trên cơ sở lý thuyết: cách tiếp cận hướng đối tượng của Booch và lý thuyết đo. 2.1.1 Cơ sở lý thuyết của các phép đo CK a. Cơ sở lý thuyết phát triển phần mềm hướng đối tượng Booch là một trong những người đầu tiên đề xuất phương pháp tiếp cận hướng đối tượng [2]. Ông đề xuất bốn bước trong pha thiết kế hướng đối tượng: Xác định các lớp (đối tượng): Trong bước này, xác định và định danh các lớp và đối tượng dựa trên bài toán đã được trừu tượng hóa. Xác định ý nghĩa của các lớp (đối tượng): Bước này xác định cụ thể ý nghĩa các lớp và phương thức của các lớp và đối tượng, xác định vòng đời của đối tượng từ lúc khởi tạo đến lúc hủy. Xác định mối quan hệ giữa các lớp (đối tượng): Trong bước này, tương tác giữa các lớp và đối tượng được xác định, ví dụ mối quan hệ thừa kế và mối quan hệ nhìn thấy được một phần nội dung của nhau giữa các lớp. Cụ thể hóa các lớp (đối tượng): Thiết kế chi tiết, định nghĩa các phương thức và hành vi của chúng. Dù đó là phương pháp thiết kế hướng đối tượng của Booch (gần đây là UML) hay của nhóm nghiên cứu khác, thì thiết kế các lớp đóng một vai trò trung tâm trong thiết kế hướng đối tượng. Thiết kế các lớp được dành cho mức ưu tiên cao nhất trong thiết kế hướng đối tượng, bởi vì nó giải quyết vấn đề yêu cầu chức năng của hệ thống nên thiết kế các lớp phải được thực hiện trước khi thiết kế hệ thống và thiết kế chương trình. Các phép đo CK chủ yếu để đánh giá độ phức tạp trong thiết kế lớp. Ưu điểm nổi bật của các phép do CK là có thể tiến hành chúng trong những pha sớm (thiết kế) của quá trình phát triển phần mềm, qua đó có thể có những thay đổi kịp thời để giảm tối thiểu những sai sót sau này. Ngoài ra các phép đo CK độc lập với các công cụ và ngôn ngữ được sử dụng. Tuy nhiên các phép đo CK không đánh giá được những chi tiết của việc triển khai các lớp. b. Cơ sở lý thuyết đo Một sơ đồ thiết kế hướng đối tượng có thể được đại diện bằng một hệ thống quan hệ, gồm có tập các thực thể, tập các quan hệ và tập các phép toán nhị phân: D º (A, R1...Rn, O1...Om) trong đó: A: tập các thực thể (lớp, đối tượng) R1...Rn : các quan hệ giữa các thực thể (ví dụ lớn hơn, nhỏ hơn). O1...Om : các phép toán nhị phân trên các thực thể (tổ hợp, thừa kế ...) Đánh giá độ phức tạp giúp chúng ta hiểu kỹ hơn về hệ thống quan hệ trên các thực thể. Người thiết kế thường có những quan niệm trực giác về độ phức tạp giữa các thực thể, chẳng hạn như quan niệm lớp nào có nhiều phương thức hơn thì có độ phức tạp lớn hơn. Những quan niệm trực giác như thế là phép toán nhị phân q trên tập à (tập tất cả các thiết kế có thể có). Giả sử P, P’, P” ÎÃ, các tiên đề sau đây phải được thỏa mãn: hoặc P q P’, hoặc P’ q P (đầy đủ: P phức tạp hơn P’ hoặc P’ phức tạp hơn P). P q P’, P’ q P” Þ P q P” (bắc cầu: P phức tạp hơn P’ và P’ phức tạp hơn P” dẫn đến P phức tạp hơn P”). Để có thể tiến hành đo đạc trên sơ đồ thiết kế hướng đối tượng, hệ thống quan hệ nêu trên cần được chuyển sang hệ thống quan hệ dựa trên trị số (biểu diễn thay thế). Hệ thống quan hệ dựa trên trị số F được định nghĩa: F º (C, S1...Sn, B1...Bn) trong đó: C là tập các phần tử (ví dụ là số thực) S1...Sn là các quan hệ trên C ( ví dụ >, <, =) B1...Bn là các phép toán nhị phân trên C (ví dụ +,-,*) Việc chuyển đổi như trên được thực hiện qua ánh xạ từ hệ thống quan hệ D sang hệ thống quan hệ dựa trên trị số F, ánh xạ này được gọi là phép đo m. Với mỗi thực thể aÎD, m(a)ÎF. Phép đo m phải bảo toàn tất cả các quan hệ của hệ thống quan hệ, mỗi quan hệ trong D phải có một quan hệ trong F tương ứng. c. Một số khái niệm Một đối tượng trong hệ thống được biểu diễn bởi: X = trong đó x là dấu hiệu hay tên để nhận dạng X trong hệ thống, p(x) là tập hữu hạn các thuộc tính và phương thức của đối tượng. Cố kết (cohesion) là sự liên quan, gắn bó giữa các thành phần trong cùng một lớp. Đây là một thuộc tính quan trọng. Xu hướng tốt là tăng tính cố kết giữa các phương thức trong một lớp sẽ đảm bảo sự thực hiện ẩn, tăng khả năng bảo trì. s(M1, M2) = I1 Ç I2 trong đó: s(M1, M2): mức độ liên quan giữa phương thức M1 và M2 Ii : tập các biến được sử dụng bởi Mi Ví dụ: I1 = {a, b, c, d, e} và I2 = {a, b, e} thì s(M1, M2) = {a, b, e}. Nếu một lớp có nhiều phương thức cùng tác động lên một tập các biến, ta nói lớp đó có tính cố kết cao. Kết dính (coupling) là sự liên quan gắn bó giữa các thực thể trong hệ thống (đối tượng). Một lớp được gọi là kết dính với một lớp khác nếu nó phụ thuộc vào lớp ấy, ví dụ nó truy cập vào thuộc tính hay kích hoạt phương thức của lớp khác. Các lớp có tính kết dính cao không thể coi là một thành phần độc lập của hệ thống. Khi sửa chữa các lớp này, các thành phần khác của hệ thống cũng có khả năng phải sửa chữa theo. Tính kết dính nhỏ thể hiện một thiết kế tốt, làm tăng tính độc lập giữa các modul, tăng khả năng tái sử dụng. Giả sử ta có 2 đối tượng X = , Y = p(x) = MX È IX p(y) = MY È IY trong đó Mi là tập các phương thức và Ii là tập các thuộc tính của đối tượng i. Kết dính là sự kiện MX gọi MY hay MX truy cập IY và ngược lại. Một phương thức của lớp X nếu gọi tới phương thức hay sử dụng thuộc tính của lớp Y thì X có tính kết dính với Y. Độ phức tạp của một lớp: độ phức tạp của một đoạn mã lệnh tỷ lệ với công sức cần để hiểu, viết ra nó hay sửa chữa đoạn mã lệnh đó. Tuy nhiên việc đo trực tiếp giá trị đó là không thể thực hiện được. Chúng ta dùng một cách đo tương đối bằng cách cộng độ phức tạp của các phương thức trong lớp đó ta được độ phức tạp của lớp. Độ đo này gọi là WMC (Weighted Method per Class). Độ phức tạp của một phương thức có thể đo bằng số dòng mã lệnh (LOC - lines of code) hoặc độ phức tạp cyclomatic. Độ phức tạp cyclomatic dựa vào tổng số các con đường đi độc lập qua đồ thị điều khiển của chương trình. Trường hợp đơn giản, WMC của một lớp chỉ cần tính bằng tổng số các phương thức trong lớp đó, độ phức tạp của mỗi phương thức bằng 1. Độ phức tạp của = |p(x)| (|p(x)| là lực lượng của p(x) ). Cây thừa kế : Cây thừa kế là đồ thị có hướng không có chu trình với các lớp là các nút, gốc và lá. Thừa kế là một tính chất quan trọng của lập trình hướng đối tượng. Sử dụng thừa kế rút ngắn thời gian phát triển qua việc sử dụng lại mã. Tuy nhiên sử dụng thừa kế nhiều sẽ gây khó khăn cho việc thiết kế và bảo trì. Hai độ đo tính thừa kế được giới thiệu là độ sâu và độ rộng của cây thừa kế. Độ đo chiều sâu cây thừa kế (Depth of Inheritance Tree – DIT). Độ sâu thừa kế của một lớp là chiều dài đường đi từ nút của lớp đó đến lớp là gốc của cây thừa kế. Độ sâu này càng lớn thì lớp hậu duệ càng có khả năng có nhiều thuộc tính và phương thức thừa kế, càng khó kiểm soát các hành vi của nó. Độ sâu lớn đồng nghĩa với độ phức tạp thiết kế tăng, nhưng cũng đồng thời tăng tính tái sử dụng. Độ đo số con của một lớp (Number Of Children – NOC) là số lớp được thừa kế trực tiếp từ lớp đó. Nó biểu hiện tiềm năng ảnh hưởng của một lớp lên toàn hệ thống. Một lớp có nhiều con sẽ cần được kiểm tra kỹ lưỡng vì chất lượng của nó ảnh hưởng đến các con. Độ đo này ảnh hưởng đến việc đánh giá thiết kế, kiểm tra, tái sử dụng. Thông điệp giữa các lớp: Các đối tượng tương tác qua sự trao đổi các thông điệp. Đối tượng đáp lại thông điệp bằng cách kích hoạt một phương thức có chức năng xử lý thông điệp đó. Như vậy các phương thức là sự đáp lại các thông điệp mà lớp nhận được. RFC (Responce set For a Class) = tập tất cả các phương thức có thể bị kích hoạt để đáp lại thông điệp mà lớp nhận được. RFC có thể gồm cả những phương thức bên ngoài lớp vì lớp có thể gọi các phương thức bên ngoài lớp để đáp lại các thông điệp. Tập này là hữu hạn vì số phương thức của mỗi lớp là hữu hạn và số lớp cũng là hữu hạn. Trong pha triển khai hay bảo trì, tập này có thể thay đổi khi các lớp được tạo thêm các chức năng xử lý thông điệp mới. Tổ hợp các lớp: Thiết kế lớp một quá trình lặp lại các hoạt động: tạo lớp con (tạo lớp mới dựa trên các lớp đã có), phân chia (chia nhỏ một lớp thành các lớp nhỏ hơn), tổ hợp (nhóm các lớp đã có vào trong một lớp mới). Tổ hợp của hai lớp là một lớp bao gồm các thuộc tính của cả hai lớp con hợp lại. Giả sử X = và Y = là hai lớp, thế thì X+Y được ký hiệu là Z = trong đó p(z) = p(x) È p(y). Giả sử lớp foo_a có các thuộc tính (phương thức và biến) a, b, c, d và lớp foo_b có các thuộc tính a, l, m, n thì foo_a + foo_b có các thuộc tính là a, b, c, d, l, m, n. Kết quả của sự tổ hợp là một không gian trạng thái thống nhất cho các phương thức và biến cho hai lớp cũ, loại bỏ các thông điệp giữa hai lớp thành phần trước đây. 2.1.2 Các tính chất của phép đo hướng đối tượng. Tính phân biệt: Cho lớp P và hệ đo m, luôn luôn có thể tìm được lớp Q sao cho m(P) m(Q). Tính chất này nghĩa là tất cả mọi lớp không thể có cùng độ đo, nếu không sẽ mất ý nghĩa là một phép đo. Tính không duy nhất Có thể tồn tại lớp P và lớp Q sao cho m(P) = m(Q). Điều đó nghĩa là hai lớp khác nhau có thể có chung một độ đo, ví dụ hai lớp có cùng độ phức tạp. Tính phụ thuộc vào chi tiết thiết kế Hai lớp P và Q có cùng chức năng không đảm bảo rằng m(P) = m(Q). Chi tiết của việc thiết kế lớp mới ảnh hưởng quyết định đến độ đo của lớp. Tính đơn điệu Với hai lớp P và Q, tính chất sau phải được thỏa mãn: m(P) < m(P+Q) và m(Q) < m(P+Q), trong đó P+Q là lớp tổ hợp của hai lớp P và Q. Độ đo của lớp tổ hợp không bé hơn độ đo của hai lớp thành phần. Tính khác nhau của tương tác $ P, $ Q, $ R thỏa mãn: m(P) = m(Q) nhưng m(P+R) m(Q+R). Tương tác giữa lớp P và lớp R khác với tương tác giữa lớp Q và lớp R dẫn đến độ đo khác nhau của hai lớp tổ hợp P+R và Q+R. Tương tác làm tăng độ phức tạp $ P và $ Q thỏa mãn: m(P) + m(Q) < m(P+Q) Khi hai lớp được tổ hợp, sự tương tác giữa các lớp có thể làm tăng giá trị độ đo. 2.1.3 Các phép đo trong hệ đo CK Trong phần này chúng ta trình bày nhóm các phép đo do Chidamber, Kemerer đề xuất gồm có WMC, DIT, NOC, CBO, RFC, LCOM. Để đơn giản, chúng ta bỏ qua chứng minh các độ đo này thỏa mãn 6 tính chất nêu trên. Các kết quả đo thực nghiệm được trình bày trong chương 4. 1. WMC (Weight Method per Class) Định nghĩa: Cho lớp C1, các phương thức M1, M2,..., Mn được định nghĩa trong lớp đó. Gọi c1, c2, ..., cn là độ phức tạp của các phương thức đó, ta có: Độ phức tạp của mỗi phương thức có thể được tính bằng số dòng mã lệnh (LOC) hay độ phức tạp cyclomatic. Tuy nhiên hai độ phức tạp này khó xác định ở pha thiết kế vì chưa có phần mã thực thi của phương thức. Để đơn giản quy ước độ phức tạp của mỗi phương thức là 1, thì WMC của lớp là tổng số phương thức có trong lớp đó. Ý nghĩa: WMC là độ đo đặc trưng cho độ phức tạp của một lớp, bởi vì phương thức là thuộc tính của một lớp và độ phức tạp được đặc trưng bằng lực lượng của tập thuộc tính. Quan niệm trực giác về WMC: Số phương thức và độ phức tạp của các phương thức là một chỉ số để tiên đoán về thời gian và công sức để xây dựng và bảo trì lớp đó. Càng có nhiều phương thức trong một lớp càng có nhiều khả năng gây ảnh hưởng lên các lớp con cháu vì các lớp này được thừa kế các phương thức từ lớp cha. Lớp có nhiều phương thức thì có nhiều khả năng dùng cho một ứng dụng cụ thể, càng có ít khả năng tái sử dụng. 2. DIT (Depth of Inheritance Tree) Định nghĩa: Độ sâu cây thừa kế là độ đo DIT của lớp. Trong trường hợ._.soft-fpt. Phương pháp thu thập dữ liệu của chúng tôi là xuất phát từ mã nguồn của các chương trình (sau khi dự án kết thúc), sử dụng các công cụ để phân tích mã nguồn và thu thập các độ đo. Các độ đo sau đó được đưa vào cơ sở dữ liệu. Ngưỡng cho quá trình chuẩn hóa độ đo dựa trên các kết quả đo các dự án đó. Các độ đo được sử dụng là bộ các độ đo CK: WMC, DIT, CBO, RFC, NOC, LCOM. Ngoài ra, chúng tôi cũng sử dụng mô hình QMOOD để xác định các thuộc tính chất lượng qua các độ đo. Kết quả đo sau đó được phân tích về mặt thống kê như giá trị lớn nhất, nhỏ nhất, trung bình, độ lệch. Chúng tôi cũng xem xét ma trận hệ số tương quan giữa các độ đo và các thuộc tính của dự án như: tỷ lệ lỗi (defect rate), tỷ lệ hao phí công sức sửa chữa (correction cost), tỷ lệ lỗi sau khi bàn giao sản phẩm (leakage). Hệ số tương quan cho chúng ta biết về tầm ảnh hưởng hay mối liên hệ biến thiên giữa hai biến ngẫu nhiên. Qua việc phân tích kết quả đo, chúng ta thấy được sự ảnh hưởng của các độ đo hướng đối tượng lên chất lượng của hệ thống. Chúng tôi lựa chọn 8 dự án tại trung tâm phần mềm Fsoft-fpt, các dự án này đều đã hoàn thành, chúng đều được viết bằng C++ và Java. Để thu thập các độ đo (metric), chúng tôi sử dụng công cụ Understanding C++ và Understanding Java [21] tiến hành phân tích mã nguồn của chương trình. Như vậy quá trình nghiên cứu là theo phương pháp phân tích ngược (reverse engineering). Để có thể có những so sánh đánh giá kết quả thu được, chúng tôi tiến hành đo thêm 4 thư viện phần mềm hướng đối tượng là: MFC3, JDK1.1.8, GNU, STL. Các thư viện này cũng đều được đo ở dạng mã nguồn. Mã nguồn của các thư viện MFC3, GNU, STL được download từ địa chỉ /ftp/pub/esw/mood/SPECS/C++, còn mã nguồn JDK1.1.8 được công bố rộng rãi bởi Sun Microsystem. Dự án Ngôn ngữ Số lớp Kích thước (LOC) Ghi chú 1 Faid-xml C++ 78 31541 Fsoft-fpt 2 IntraFax C++ 4 17113 Fsoft-fpt 3 Css-m1 Java 37 36165 Fsoft-fpt 4 PG-Maintain-2002-1 Java 201 48011 Fsoft-fpt* 5 CDS C++ 207 155550 Fsoft-fpt 6 CDS-MK C++ 249 208099 Fsoft-fpt* 7 Aop C++ 9 4721 Fsoft-fpt 8 BDWizard3 C++ 89 100478 Fsoft-fpt* 9 MFC3 C++ 154 74895 10 JDK1.1.8 Java 533 152231 11 GNU C++ 84 32122 12 STL C++ 43 37318 Ghi chú : * các dự án bảo trì. Bảng 4.1: Danh sách các dự án được đo Trong số các dự án tại Fsoft-fpt có 3 dự án bảo trì là: PG-Maintain-2002-1, CDS-MK và BDWizard3. Ngoài ra ta cũng chú ý thấy IntraFax và Aop là các dự án nhỏ, sử dụng cả lập trình hướng đối tượng và lập trình cấu trúc nên có số lớp ít. Ta tạm gọi nhóm 8 dự án tại Fsoft-fpt là “Fsoft”, nhóm các thư viện hướng đối tượng là “Library”. Số lớp Kích thước (LOC) Fsoft 874 601678 Library 814 296566 Bảng 4.2: Tổng cộng số lớp các dự án được đo Tổng số lớp đo được tại hai nhóm là gần bằng nhau. Trong khi đó kích thước (LOC - lines of code) của nhóm các dự án Fsoft cao hơn hẳn kích thước của nhóm thư viện Library bởi vì các dự án là thực hiện mục tiêu cụ thể còn thư viện để sử dụng lại nhiều nên chỉ cung cấp những tiện ích chung nhất. 4.1 Kết quả các phép đo CK Phần này trình bày kết quả các phép đo CK trên nhóm các dự án ở Fsoft và nhóm thư viện hướng đối tượng. Kết quả được thể hiện dưới dạng biểu đồ và bảng thống kê giá trị lớn nhất, nhỏ nhất, giá trị trung bình. Trong mỗi biểu đồ cột dưới đây, trục nằm ngang là giá trị độ đo, trục đứng là số lớp có giá trị độ đo bằng giá trị trên trục nằm ngang. 4.1.1. Kết quả độ đo LCOM Độ đo LCOM thể hiện mức độ thiếu liên quan giữa các phương thức trong cùng một lớp (cố kết). Giá trị này lớn thể hiện tính cố kết thấp, các phương thức trong cùng một lớp thiếu liên hệ là dấu hiệu của sự tách biệt chức năng, các phương thức đó nên thuộc về hai lớp khác nhau, vì thế nếu độ đo LCOM lớn, nên phân chia lớp đó thành hai lớp con. Độ đo Bé nhất Lớn nhất Trung bình Fsoft LCOM 0 100 57.9 Library LCOM 0 100 47.85 Hình 4.1: Kết quả độ đo LCOM Nhận xét: Ở cả hai nhóm có khoảng 1/3 số lớp có LCOM bằng 0 thể hiện độ cố kết giữa các phương thức trong lớp tốt. Nói chính xác hơn là các biến của lớp có xu hướng được sử dụng tại nhiều hơn một phương thức trong lớp đó. Điều này phù hợp với quan điểm các phương thức của lớp được xây dựng xoay quanh các biến (dữ liệu) trong lớp đó. Ngoài ra ta cũng nhận thấy là nhóm Library có độ đo LCOM thấp hơn độ đo LCOM của nhóm Fsoft. Độ đo LCOM thể hiện tính cố kết yếu giữa các phương thức trong một lớp, giá trị này càng bé càng tốt. Tốt nhất là LCOM = 0% tức là khi đó hai phương thức bất kỳ trong lớp đều có mối liên hệ, thể hiện tính cố kết tốt. Trên đồ thị kết quả đo LCOM ta thấy cột cao nhất có giá trị độ đo LCOM=0%, đó là các lớp có tính cố kết tốt. Cột cao thứ hai có độ đo LCOM = 100%. Đó là các lớp có tính cố kết thấp, giữa hai phương thức bất kỳ không có mối liên hệ. Các lớp chỉ khai báo giao diện lớp mà không có phần triển khai thuộc loại này. 4.1.2 Kết quả độ đo DIT Độ đo DIT thể hiện chiều sâu cây thừa kế. Độ sâu này càng lớn thể hiện tính sử dụng lại cao, tuy nhiên nếu độ đo DIT quá lớn lại làm cho các lớp con cháu có tính phức tạp cao do được thừa kế nhiều thuộc tính từ các lớp cha. Qua quá trình đo các thư viện phần mềm hướng đối tượng của các hãng nổi tiếng (nhóm Library), độ đo DIT trung bình là 2.22, như vậy độ đo DIT nằm giữa 2 và 3 có thể coi là tốt. Độ đo DIT càng lớn thì các lớp ở gốc càng phải được kiểm tra kỹ lưỡng nhằm giảm sai sót cho các lớp con cháu. Độ đo Bé nhất Lớn nhất Trung bình Fsoft DIT 0 4 1.31 Library DIT 0 6 2.22 Hình 4.2: Kết quả độ đo DIT Nhận xét: Độ đo DIT ở nhóm Library cao hơn ở nhóm Fsoft (giá trị trung bình gần gấp đôi). Có thể giải thích điều này là do các phần mềm được xây dựng ở Fsoft để phục vụ mục đích cụ thể, trong khi các thư viện được xây dựng được xây dựng với mục đích để sử dụng lại. Nhìn chung độ sâu cây thừa kế ở cả hai nhóm đều không cao, người thiết kế đã không tận dụng khả năng sử dụng lại qua việc sử dụng thừa kế nhằm làm giảm độ phức tạp của hệ thống. 4.1.3. Kết quả độ đo CBO Độ đo CBO là độ đo thể hiện tính kết dính giữa các lớp. Hai lớp gọi là có tính kết dính nếu lớp này sử dụng thuộc tính hay dữ liệu của lớp kia. CBO của một lớp tính bằng số lớp có tính kết dính với lớp đó. Giá trị độ đo này càng lớn thể hiện một thiết kế lớp tồi, khó hiểu, giảm khả năng sử dụng lại, khó bảo trì, không phù hợp với quan điểm bao bọc và đóng gói dữ liệu của lập trình hướng đối tượng. Library Độ đo Bé nhất Lớn nhất Trung bình Fsoft CBO 0 129 8.86 Library CBO 0 51 3.59 Hình 4.3: Kết quả độ đo CBO Nhận xét: Độ đo CBO của nhóm Fsoft cao hơn hẳn độ đo CBO của nhóm Library. Có thể lý giải điều này do các ứng dụng ở nhóm các dự án Fsoft được xây dựng với các chức năng cụ thể nên có nhiều thông điệp được trao đổi giữa các đối tượng hơn ở nhóm thư viện. Quan sát trên đồ thị độ đo CBO của nhóm Library, chúng ta thấy số lớp có độ đo CBO = 1 là cao nhất, đó chính là những lớp chỉ thừa kế từ một lớp cha nên chỉ có tính kết dính với lớp cha đó, không sử dụng các phương thức của các lớp khác ngoài lớp cha. 4.1.4 Kết quả độ đo NOC Độ đo NOC là số lớp con trực tiếp của một lớp, số lớp con càng lớn thì lớp đó càng có nhiều khả năng sử dụng lại, tầm quan trọng của lớp đó càng cao vì các thuộc tính của lớp cha được truyền lại cho các lớp con, yêu cầu phải được kiểm tra kỹ lưỡng. Độ đo Bé nhất Lớn nhất Trung bình Fsoft NOC 0 93 0.26 Library NOC 0 326 0.82 Hình 4.4: Kết quả độ đo NOC. Nhận xét: Độ đo NOC của các nhóm Fsoft bé hơn độ đo NOC của nhóm Library, nguyên nhân là thư viện được xây dựng để sử dụng lại nên các lớp trong thư viện có nhiều lớp con hơn. Lớp có nhiều lớp con nhất trong nhóm Library (326 con) chính là lớp java.lang.Object là lớp cha của hầu hết mọi lớp khác trong thư viện JDK. Nhìn vào biểu đồ ta cũng thấy phần lớn các lớp ở cả hai nhóm là các lớp không có lớp con nào. Như vậy, qua các độ đo DIT và NOC ta có thể thấy việc sử dụng thừa kế chưa nhiều (ít nhất là trong số các phần mềm được đo trong báo cáo này). Ta có thể giải thích nguyên nhân là do quan điểm của người thiết kế cho rằng nếu sử dụng thừa kế nhiều sẽ làm tăng độ phức tạp của hệ thống dẫn tới khó kiểm soát, hoặc là do nhóm thiết kế phần mềm có nhiều người khác nhau, trong đó người này không hiểu rõ phần thiết kế của người khác nên cũng không thể thực hiện việc thừa kế. 4.1.5 Kết quả độ đo RFC Độ đo RFC của một lớp là số phương thức mà lớp đó có thể kích hoạt (để đáp lại thông điệp mà đối tượng của lớp đó nhận được). Giá trị này càng lớn thì độ phức tạp của lớp càng cao, việc chữa lỗi và bảo trì lớp đó càng khó khăn bởi vì cần nhiều thời gian để hiểu các thông điệp và lời gọi giữa lớp đó với môi trường bên ngoài. Độ đo Bé nhất Lớn nhất Trung bình Fsoft RFC 0 407 25.1 Library RFC 1 424 54.23 Hình 4.5: Kết quả độ đo RFC Nhận xét: Độ đo RFC của hai nhóm cho thấy các lớp trong cả hai nhóm có thể kích hoạt một số lượng tương đối lớn các phương thức. Ngoài ra, ta cũng thấy của nhóm thư viện cao hơn của nhóm Fsoft. Tìm hiểu nguyên nhân, chúng tôi thấy rằng trong nhóm Fsoft, các phương thức có xu hướng gọi các phương thức khác thuộc cùng một lóp, trong khi đó ở nhóm Library, các phương thức có rất nhiều lời gọi hàm tổng thể (hàm API) và các phương thức được thừa kế từ các lớp cha. Lớp có độ đo RFC lớn nhất trong nhóm Library là CMDIFrameWnd có tới 424 lời gọi các phương thức thuộc cả trong và ngoài lớp, trong khi lớp này chỉ có 35 phương thức (chỉ tính riêng các phương thức được khai báo mới, không kể các phương thức được thừa kế). 4.1.6 Kết quả độ đo WMC Độ đo WMC của một lớp là số phương thức có trong lớp đó. Nó thể hiện độ phức tạp của một lớp. Giá trị này càng lớn thể hiện thời gian và công sức cần bỏ ra để xây dựng lớp đó càng nhiều. Độ đo WMC lớn thì lớp càng có xu hướng phục vụ mục đích cụ thể, giảm khả năng sử dụng lại. Độ đo Bé nhất Lớn nhất Trung bình Fsoft WMC 0 343 17.35 Library WMC 0 262 10.67 Hình 4.6: Kết quả độ đo WMC Nhận xét: Nhìn chung các lớp ở cả hai nhóm có số phương thức vừa phải. So sánh giá trị trung bình của hai nhóm, ta thấy trong khi độ đo RFC của nhóm Library cao hơn hẳn độ đo RFC của nhóm Fsoft thì độ đo WMC của nhóm Fsoft lại cao hơn độ đo WMC của nhóm Library (RFC bao gồm cả WMC). Chênh lệch giữa độ đo RFC và WMC (giá trị trung bình) của nhóm Fsoft không lớn (25.1-17.35), trong khi của nhóm Library lại rất lớn (54.23-10.67), điều đó một lần nữa khẳng định các phương thức trong các lớp ở nhóm Fsoft có xu hướng gọi các phương thức khác thuộc cùng lớp trong khi các phương thức ở các lớp thuộc nhóm Library có xu hướng gọi hàm API và các phương thức được thừa kế nhiều hơn. Lớp có nhiều phương thức nhất trong nhóm Library là lớp CWnd có tới 262 phương thức và tổng số 313 lời gọi các phương thức thuộc cả trong và ngoài lớp (WMC = 262 và RFC = 313). Ngoài ra, ta cũng thấy rằng trong nhóm Library, số lớp có WMC = 1 (có 177 lớp) và WMC = 2 (có 130 lớp) là nhiều nhất, đó là những lớp chỉ có phương thức tạo đối tượng (constructor) và hủy đối tượng (destructor). Trong khi đó cũng ở nhóm Library số lớp có RFC = 29 là nhiều nhất (172 lớp). Nhìn vào đồ thị kết quả đo WMC trong nhóm Library, chúng ta thấy số lớp có WMC = 1 và WMC = 2 là nhiều nhất, đó chính là những lớp chỉ có phương thức khởi tạo và phương thức hủy. 4.1.7. Tổng hợp kết quả các độ đo CK Độ đo của một phần mềm hướng đối tượng bằng trung bình các độ đo của các lớp có trong phần mềm ấy. Chúng ta có bảng kết quả các độ đo CK cho từng phần mềm như sau: LCOM DIT CBO NOC RFC WMC Faid-xml 31.58 0.88 4.86 0.12 19.9 18.06 IntraFax 81.33 1 2 0 18 18 Css-m1 75.95 1.64 5.94 0 20.59 15.4 PG-Maintain2002-1 35.79 1.84 5.42 0.46 25 11.33 Aop 71.22 0.55 3.77 0.22 21.11 15.33 Cds 63.41 1.22 4.91 0.27 26.63 18.74 Cds-mk 70.83 1.19 16.91 0.24 27.13 19.28 Bdwizard3 72.74 0.98 8.71 0.1 23.97 22.66 MFC3 75.16 2.11 3.73 0.76 133.09 20.33 JDK1.1.8 44.43 2.6 4.05 0.93 37.24 7.87 GNU 32.69 0.89 1.64 0.65 40.46 11.37 Bảng 4.3: Kết quả độ đo CK của các phần mềm Hình 4.7: Biểu đồ độ đo CK của các phần mềm Nhận xét: Độ đo LCOM có sự biến thiên không nhiều. Nhìn chung nhóm phần mềm Fsoft có độ đo LCOM cao hơn nhóm phần mềm Library. Độ đo DIT và NOC của nhóm Library (đặc biệt là MFC3 và JDK1.1.8) cao hơn hẳn độ đo DIT và NOC của nhóm phần mềm Fsoft. Xét riêng đối với từng phần mềm thì độ đo RFC và WMC của nhóm thư viện có sự chênh lệch rất lớn trong khi chênh lệch này của nhóm Fsoft nhỏ hơn. Độ đo CBO của nhóm Fsoft nhìn chung cao hơn độ đo CBO của nhóm Library, trong nhóm Fsoft thì độ đo CBO của các dự án phần mềm bảo trì như PG-Maintaint2002-1, Cds-mk, Bdwizard3 cũng lớn hơn các dự án khác. Nguyên nhân của những sự chênh lệch này đã được giải thích ở các phần trên. 4.1.8 Quan hệ ảnh hưởng giữa các độ đo CK và các thuộc tính khác. Các giá trị độ đo luôn có ảnh hưởng lên chất lượng cuối cùng của sản phẩm. Nếu các giá trị độ đo thể hiện một thiết kế tồi thì chất lượng sản phẩm cuối cùng cũng không tốt. Bên cạnh việc thu thập các giá trị độ đo, chúng tôi cũng nghiên cứu sự ảnh hưởng của các độ đo này lên các thuộc tính chất lượng phần mềm. Đối với các phần mềm ở Fsoft, chúng tôi thu thập các độ đo về một số thuộc tính: tỷ lệ chi phí công sức để chữa lỗi sản phẩm (correction cost), tỷ lệ lỗi trong quá trình test (defect rate), tỷ lệ lỗi sau khi giao sản phẩm cho khách hàng (leakage). Các độ đo này được lưu trữ trong cơ sở dữ liệu của dự án. Các độ đo công sức chữa lỗi và tỷ lệ lỗi trong pha kiểm tra là các độ đo thuộc về quá trình sản suất phần mềm, còn tỷ lệ lỗi sau bàn giao là độ đo thuộc về sản phẩm phần mềm. Dựa trên kết quả các độ đo CK ở trên và các độ đo công sức chữa lỗi, lỗi kiểm tra, lỗi sản phẩm thu thập được, chúng tôi lập ma trận hệ số tương quan giữa các độ đo. Hệ số tương quan giữa hai biến ngẫu nhiên X và Y được tính như sau: trong đó: cov (X, Y): hiệp phương sai của 2 biến ngẫu nhiên X, Y. , : giá trị trung bình của hai biến X, Y : độ lệch tiêu chuẩn của hai biến X, Y. n: số mẫu ngẫu nhiên của X và Y. Hệ số tương quan thể hiện mối liên hệ biến thiên giữa hai biến ngẫu nhiên. Hệ số tương quan nằm giữa –1 và 1, trị tuyệt đối càng lớn thể hiện mối quan hệ biến thiên càng mạnh. Hế số tương quan dương thể hiện mối quan hệ ảnh hưởng biến thiên thuận (A tăng thì B tăng), hệ số tương quan âm thể hiện mối quan hệ ảnh hưởng nghịch (A tăng thì B giảm). Hệ số tương quan không phụ thuộc vào đơn vị đo của các biến ngẫu nhiên. LCOM DIT CBO NOC RFC WMC Công sức chữa lỗi 0.38 -0.13 0.56 0.12 0.71 0.71 Lỗi kiểm tra 0.16 -0.70 -0.09 0.18 0.05 0.05 Lỗi sản phẩm 0.14 -0.16 0.05 0.01 0.17 0.42 Bảng 4.4: Hệ số tương quan giữa các độ đo CK và các chỉ số chất lượng. Trước hết chúng ta có nhận xét bảng kết quả hệ số tương quan ở trên phù hợp với lý thuyết đã nêu về các độ đo CK, chẳng hạn độ đo LCOM có ảnh hưởng thuận đến các thuộc tính chất lượng, LCOM tăng thì các thuộc tính chất lượng tăng (chú ý là LCOM là độ thiếu kết dính của một lớp, giá trị này càng bé càng tốt, trong khi đó thì các thuộc tính chất lượng ở trên gồm có chi phí sửa lỗi, tỷ lệ lỗi trong quá trình test, tỷ lệ lỗi sau khi bàn giao sản phẩm, các chỉ số này càng bé càng tốt). Tương tự với các độ đo khác như DIT có ảnh hưởng nghịch đến các thuộc tính chất lượng, chiều sâu cây thừa kế càng lớn thì sản phẩm phần mềm được tạo ra có khả năng càng tốt. Các hệ số tương quan có trị tuyệt đối nhỏ hơn 0.1 có thể thay đổi dấu nếu thử nghiệm với một tập mẫu lớn hơn nên chúng ta tạm thời không phân tích những hệ số tương quan đó. Các ô được tô đậm trong bảng trên là các ô có chứa hệ số tương quan lớn. Từ nhận xét về hệ số tương quan thể hiện mối quan hệ ảnh hưởng biến thiên giữa các biến ngẫu nhiên, chúng ta đi đến ý tưởng thiết lập mô hình để dự đoán các thuộc tính chất lượng. Khi có các độ đo chúng ta có thể có những dự đoán sớm về thuộc tính chất lượng để có những thay đổi kịp thời. Sử dụng hồi quy để thiết lập phương trình biểu diễn các thuộc tính chất lượng qua các độ đo. Phương trình có dạng y = a * x + b. Các hệ số a và b tìm được như sau: DIT RFC WMC Công sức chữa lỗi b -29.85 a 2.25 Lỗi kiểm tra b 52.81 a -31.49 Lỗi sản phẩm b -1.47 a 0.12 Bảng 4.5: Các hệ số của phương trình tuyến tính biểu diễn phụ thuộc giữa thuộc tính chất lượng và độ đo Hình 4.8: Dự đoán thuộc tính chất lượng dựa trên các độ đo CK Trong 2 đồ thị trên, đoạn thẳng biểu diễn phương trình hồi quy tìm được còn các chấm đen thể hiện độ đo của 8 dự phần mềm tại Fsoft. 4.2 Kết quả đo sử dụng mô hình QMOOD 4.2.1. Quá trình đo sử dụng mô hình QMOOD Mô hình QMOOD là mô hình đánh giá các thuộc tính ngoài qua các độ đo (xem phần 2.2). Mô hình QMOOD được dựa trên cơ sở mô hình ISO 9126 và FCM, nhưng mô hình QMOOD tập trung vào các độ đo hướng đối tượng và đánh giá các thuộc tính ngoài thể hiện tính hướng đối tượng. Mô hình QMOOD chia chất lượng phần mềm ra thành 6 thuộc tính: chức năng (functionality), hiệu năng (effectiveness), tính dễ hiểu (understandability), khả năng mở rộng (extendibility), khả năng sử dụng lại (reusability), tính mềm dẻo (flexibility). Các thuộc tính chất lượng này được xác định thông qua các độ đo theo mô hình phân cấp (hình 2.3 ). Có 11 độ đo được sử dụng trong mô hình QMOOD (không dùng độ đo tính độc lập chức năng – MFM). Chúng tôi lựa chọn 3 thuộc tính quan trọng trong mô hình QMOOD để đánh giá các phần mềm hướng đối tượng là chức năng, tính dễ hiểu và khả năng sử dụng lại. Chúng tôi tiến hành đo nhóm các dự án phần mềm tại Fsoft bằng phương pháp như ở phần 4.1. Kết quả chúng tôi thu được các độ đo của mô hình QMOOD như sau: Bé nhất Lớn nhất Trung bình Độ lệch DSC 3 249 109.12 96.69 ANA 0 0.22 0.06 0.07 DAM 0 1 0.34 0.37 DCC 2 16.91 6.56 4.59 CAM 18.66 68.41 37.14 18.72 MFA 0 0.19 0.05 0.06 CIS 9.95 22.57 14.39 4.47 NOM 11.33 22.66 17.35 3.35 Bảng 4.6: Kết quả các độ đo của mô hình QMOOD Trước khi các thuộc tính chất lượng được tính thông qua các độ đo, các độ đo cần được chuẩn hóa về giá trị nằm giữa 0 và 1. Ngưỡng cho quá trình chuẩn hóa được lựa chọn dựa trên kết quả thống kê về các độ đo trong bảng 4.6. Ngưỡng cho các dạng hàm chuẩn hóa được chọn như sau: Dạng hàm chuẩn hóa Chọn ngưỡng A Chọn ngưỡng B Đồ thị biểu diễn 1 Nhỏ nhất Trung bình – Nhỏ nhất f(a) = 0.99 ; f(a+b) = 0.5 2 Lớn nhất Lớn nhất – Trung bình f(a)=1 ; f(a+b) = f(a-b) = 0.5 Bảng 4.7: Lựa chọn ngưỡng cho các hàm chuẩn hóa các độ đo Trên cơ sở bảng 4.6 và bảng 4.7, chúng ta tính được ngưỡng của các hàm chuẩn hóa như sau: Dạng hàm chuẩn hóa Chọn ngưỡng A Chọn ngưỡng B DSC 1 3 106.12 ANA 2 0.22 0.16 DAM 2 1 0.66 DCC 1 2 4.56 CAM 2 68.41 37.21 MFA 2 0.19 0.14 CIS 1 9.95 4.44 NOM 1 11.33 4.02 Bảng 4.8: Ngưỡng cho các hàm chuẩn hóa các độ đo QMOOD. Mô hình QMOOD sử dụng 11 độ đo, nhưng trong quá trình đo các phần mềm ở Fsoft, chúng tôi chỉ thu thập được 8 độ đo nêu trên, để có thể vẫn sử dung được mô hình, đối với các độ đo chưa thu thập được là NOH, MOA, NOP chúng ta cho giá trị mặc định của chúng bằng 0.5. Chúng ta vẫn có thể nghiên cứu sự biến thiên các thuộc tính chất lượng dựa trên 8 độ đo còn lại. Sau khi chuẩn hóa các độ đo và tính các thuộc tính sử dụng lại, khả năng hiểu, chức năng qua các độ đo, ta có kết quả như sau: Tính sử dụng lại Khả năng hiểu Chức năng Faid-xml 0.45 -0.44 0.61 IntraFax 0.33 -1 0.56 Css-m1 0.80 -0.80 0.73 PG-Maintain2002-1 0.55 -0.35 0.64 Aop 0.81 -1 0.77 Cds 0.44 -0.45 0.60 Cds-mk 0.60 -0.10 0.57 Bdwizard3 0.43 -0.22 0.51 Bảng 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD Hình 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD Nhận xét: Khả năng hiểu có sự biến thiên lớn. Có thể giải thích sự biến thiên này như sau: nhân tố tính dễ hiểu (understandability) được tính thông qua 7 độ đo (metric) khác trong khi các nhân tố khác chỉ được tính thông qua 4 độ đo (bảng 2.4). Các dự án Aop và IntraFax là các dự án nhỏ (chỉ có 4 lớp và 9 lớp) nên hoàn toàn phù hợp với việc có tính dễ hiểu cao. Các dự án PG-Maintain-2002-1 và Cds-mk, Bdwizard3 là các dự án bảo trì (sửa chữa nâng cấp các sản phẩm đã có) nên có tính dễ hiểu thấp. Các nhân tố khác: chức năng, khả năng sử dụng lại không xuất hiện sự biến thiên đột ngột. 4.2.2. Quan hệ ảnh hưởng giữa các kết quả đo và các thuộc tính khác Tương tự như phần 4.1.8, chúng tôi cũng xét sự ảnh hưởng của các thuộc tính đo được lên các chỉ số chất lượng dựa trên hệ số tương quan. Tính sử dụng lại Khả năng hiểu Chức năng Công sức chữa lỗi -0.33 0.56 -0.60 Lỗi kiểm tra 0.41 -0.25 0.41 Lỗi sản phẩm -0.17 0.28 -0.36 Bảng 4.10: Hệ số tương quan giữa các thuộc tính của mô hình QMOOD với các thuộc tính chất lượng khác Các hệ số tương quan giữa ở bảng đạt mức trung bình. Căn cứ vào bảng các hệ số tương quan trên, chúng ta có thể rút ra nhận xét là khó có thể giảm đồng thời chi phí cho việc sửa lỗi (correction cost), tỷ lệ lỗi trong quá trình test (defect rate) và tỷ lệ lỗi sau khi bàn giao sản phẩm (leakage) bởi vì các hệ số tương quan trong cùng một cột không cùng dấu. Chẳng hạn nếu ta có thể tăng tính sử dụng lại (reusability) thì có khả năng correction cost và leakage giảm nhưng defect rate lại tăng. Tương tự nếu thay đổi tính dễ hiểu (understandability) và chức năng (functionality) cũng vậy. Mặc dù mong muốn của người quản lý là giảm đồng thời cả chi phí sửa lỗi, tỷ lệ lỗi khi test, tỷ lệ lỗi sau khi bàn giao nhưng nhận xét của ta ở đây lại trái với điều đó. Muốn đạt được mong muốn trên cần phải nghiên cứu thêm về các phép đo đã được tiến hành ở trên để tìm ra các mối liên hệ ảnh hưởng nhằm cải tiến các bước trong quá trình phát triển phần mềm hướng đối tượng. Đây là một nhận xét khá thú vị cần được nghiên cứu thêm. Bảng 4.11 là các hệ số tương quan giữa các độ đo và các chỉ số chất lượng phần mềm. Trên cơ sở đó, ta xây dựng bảng 4.12 thể hiện mối liên hệ ảnh hưởng giữa các độ đo và chỉ số chất lượng: dấu ‘+’ là ảnh hưởng thuận (A tăng thì B tăng), dấu ‘-‘ là ảnh hưởng nghịch (ngược lại, A tăng thì B giảm), dấu ? nghĩa là chưa xác định (-0.1 < hệ số tương quan < 0.1; có thể thay đổi nếu nghiên cứu một tập mẫu khác lớn hơn). Công sức chữa lỗi Lỗi kiểm tra Lỗi sản phẩm LCOM 0.38 0.16 0.14 DIT -0.13 -0.70 -0.16 CBO 0.56 -0.09 0.05 NOC 0.12 0.18 0.01 RFC 0.71 0.05 0.17 WMC 0.71 0.05 0.42 DSC 0.55 -0.22 -0.08 ANA 0.39 0.25 -0.28 DAM -0.05 0.33 -0.33 DCC 0.56 -0.09 0.05 CAM -0.38 -0.16 -0.14 MFA -0.18 -0.23 0.27 CIS -0.24 -0.09 0.47 NOM 0.71 0.05 0.42 Bảng 4.11: Hệ số tương quan giữa các độ đo và các chỉ số chất lượng Công sức chữa lỗi Lỗi kiểm tra Lỗi sản phẩm LCOM + + + DIT - - - CBO + ? ? NOC + + ? RFC + ? + WMC + ? + DSC + - ? ANA + + - DAM ? + - DCC + ? ? CAM - - - MFA - - + CIS - ? + NOM + ? + Bảng 4.12: Mối quan hệ ảnh hưởng giữa các độ đo và các chỉ số chất lượng Nhận xét đánh giá về các kết quả đo thực nghiệm: Trong chương này chúng ta đã thực hiện các phép đo hướng tượng trên tập mẫu một số phần mềm. Kết quả đo các phần mềm sử dụng các độ đo CK thể hiện qua bảng và biểu đồ nhằm có thể so sánh trực quan giữa hai nhóm phần mềm được đo. Với mỗi độ đo, chúng ta đều có so sánh nhận xét sự chênh lệnh giữa hai nhóm và tìm hiểu nguyên nhân sự chênh lệch đó (ví dụ như độ đo số con trực tiếp NOC và độ đo chiều sâu cây thừa kế DIT của nhóm thư viện cao hơn kết quả đo của nhóm Fsoft vì các phần mềm thư viện được xây dựng với mục đích để sử dụng lại nên sử dụng thừa kế nhiều hơn). Ngoài ra chúng ta cũng đã xét ma trận hệ số tương quan giữa kết quả đo và các chỉ số chất lượng (tỷ lệ hao phí công sức chữa lỗi, tỷ lệ lỗi trong pha kiểm tra, tỷ lệ lỗi khi bàn giao sản phẩm). Kết quả cho thấy các độ đo CK có tầm ảnh hưởng lớn lên các chỉ số chất lượng (bảng 4.4), chúng ta đã xây dựng phương trình hồi quy (bảng 4.5, hình 4.8) biểu diễn các chỉ số chất lượng qua các độ đo nhằm dự đoán chất lượng của các phần mềm khác cùng được xây dựng trong môi trường đó. Chúng ta cũng đã đánh giá tập mẫu các phần mềm theo mô hình QMOOD. Các nhân tố chất lượng được đánh giá là tính sử dụng lại, khả năng hiểu, chức năng. Kết quả đánh giá các nhân tố này cho thấy chúng có tầm ảnh hưởng không nhỏ (bảng 4.10) lên các chỉ số chất lượng của sản phẩm (tỷ lệ hao phí công sức chữa lỗi, tỷ lệ lỗi khi kiểm tra, tỷ lệ lỗi khi bàn giao sản phẩm). Dựa trên bảng hệ số tương quan, chúng ta đã có nhận xét về mục tiêu giảm đồng thời công sức chữa lỗi, lỗi kiểm tra, lỗi sản phẩm là khó có thể thực hiện được. Nhận xét này cần được nghiên cứu sâu hơn. Tóm lại, kết quả nghiên cứu thực nghiệm qua quá trình đo các dự án ở Fsoft và một số thư viện khác cho ta thấy các phần mềm hướng đối tượng đã đo ít sử dụng thừa kế, các độ đo về thừa kế, kết dính, cố kết có tầm ảnh hưởng lớn đến chất lượng phần mềm. Trong tương lai nghiên cứu thực nghiệm tiếp theo là tiến hành đo trên nhiều phần mềm hướng đối tượng hơn và tiến hành phân tích kết quả trên một mô hình phân tích cụ thể. KẾT LUẬN Sau thời gian thực tập tốt nghiệp và làm đồ án tốt nghiệp tại khoa Công nghệ thông tin trường Đại học Bách Khoa Hà Nội tôi đã đạt được một số kết quả sau: Hiểu được những khái niệm cơ bản về đo phần mềm nói chung và đo phần mềm hướng đối tượng nói riêng. Nắm bắt được xu thế phát triển của đo phần mềm trong tương lai, biết được một số công cụ để có thể xây dựng các bài toán dựa trên lý thuyết đo phần mềm. Xây dựng chương trình trợ giúp cho quá trình đánh giá phần mềm hướng đối tượng. Chương trình có một số đặc điểm như: Các mô hình đánh giá phần mềm được lưu trữ trong thư viện mô hình, người sử dụng có thể lựa chọn các mô hình, cải tiến cho phù hợp hoặc xây dựng mô hình mới. Các độ đo là đầu vào cho chương trình có thể được thu thập nhờ các công cụ hoặc có thể được nhập trực tiếp từ bàn phím. Vì thế các mô hình có thể dùng để đánh giá sản phẩm, quá trình hay nguồn lực. Xuất phát từ hai nguyên nhân trên cộng thêm với một cơ sở dữ liệu được thiết kế tốt nên có thể nói chương trình có tính mở cao, mềm dẻo khi muốn mở rộng chương trình nhằm thu thập các độ đo từ các nguồn khác nhau (sử dụng công cụ để thu thập độ đo) cũng như là xuất các kết quả ra bảng, biểu đồ hay tiến hành các phân tích kết quả đo. Áp dụng đánh giá một số phần mềm được xây dựng hướng đối tượng tại Fsoft-fpt và một số thư viện lập trình hướng đối tượng trên thế giới. Qua quá trình đánh giá cho thấy các kết quả đo phù hợp với lý thuyết các phép đo hướng đối tượng của Chidamber và Kemerer, rút ra những nhận xét về mối liên quan ảnh hưởng giữa các giá trị độ đo và chất lượng phần mềm. Trong tương lai, hướng phát triển tiếp theo của đề tài là tiếp tục hoàn thành chương trình đầy đủ tính năng hơn, cung cấp chương trình cho các trung tâm phần mềm để tiến hành đo trên các phần mềm của họ, dựa trên kết quả phản hồi có thể có những nghiên cứu đánh giá các số liệu thống kê, cải tiến chương trình để phù hợp yêu cầu người sử dụng. Do thời gian làm đồ án có hạn cũng như hạn chế về kinh nghiệm của bản thân nên chương trình còn nhiều thiếu sót. Rất mong nhận được sự thông cảm và những ý kiến đóng góp giúp đỡ của các thầy cô giáo cũng như các bạn đồng nghiệp để đề tài được hoàn thiện hơn. Qua đây một lần nữa tôi xin bày tỏ lòng biết ơn đối với tập thể các thầy cô giáo trong khoa Công nghệ thông tin, trường Đại học Bách khoa Hà Nội đã truyền thụ cho tôi những kiến thức quý báu trong thời gian qua. Tôi xin trân trọng cảm ơn thầy giáo Huỳnh Quyết Thắng, người đã tận tình hướng dẫn tôi trong suốt thời gian thực hiện đề tài này. Đồ án này cũng không thể hoàn thành nếu thiếu sự trợ giúp về tư liệu và cơ sở vật chất từ phía trung tâm xuất khẩu phần mềm Fsoft-fpt Hà Nội. TÀI LIỆU THAM KHẢO Tiếng Anh: Boehm BW. ‘Software Engineering Economics’, Prentice-Hall, New York, 1981. Booch, Grady. ‘Object-oriented Analysis and Design with Applications’, The Benjamin/Cummings Publishing Company, Inc., 1994. Chidamber, Shyam and Kemerer, Chris. ‘A Metrics Suite for Object-Oriented Design’, IEEE Transactions on Software Engineering, June, 1994, pp. 476-492. DeMarco T. ‘Controlling Software Projects’, Prentice Hall, New York 1982. Halstead MH. ‘Elements of software Science’, Elsevier N-Holland, 1975. International Function Point Users Group. ‘IT Measurement’, Addison-Wesley, 2002. John J. Marciniak (Editor-in-chief). ‘Encyclopedia of software engineering’, 1994. John M. Stroud. ‘The Fine Structure of Psychological Time’, Annals of New York Academy, 1955. M. Xenos, D. Stavrinoudis, K. Zikouli and D. Christodoulakis. ‘Object-Oriented Metrics – A Survey’, Proceedings of the FESMA 2000, Federation of European Software Measurement Associations, Madrid, Spain, 2000. Norman E. Fenton. ‘Software Metrics – A rigorous approach’, ChapMan & Hall, London, 1993. Reiner R. Dumke, Erik Foltin. ‘Metrics-based Evaluation of Object-Oriented Software Development Methods’, Preprint Nr. 10, Fakultät für Informatik, 1996. Software Productivity Consortium. ‘OO Software Product Metrics Survey’,   Technical Report SPC-97005-MC, 1998. T.J. McCabe. ‘A complexity measure’, IEEE Transactions on Software Engineering, SE-2(4):308-320, December 1976. Tao Xie, Wanghong Yuan, Hong Mei, Fuqing Yang. ‘JBOOMT: Jade BirdObject-Oriented Metrics Tool’. Submitted to Chinese Journal of Electronics (English Version), July 2000. William A. Florac, Robert E. Park, Anita D. Carleton. ‘Practical Software Measurement’, Joint Logistics Commanders & Office of the Secretary of Defense, 1997. Tiếng Việt: Huỳnh Quyết Thắng, Đặng Việt Dũng. ‘Đánh giá độ tin cậy phần mềm hướng thành phần dựa trên độ tin cậy các thành phần’. Báo cáo tại hội nghị khoa học công nghệ quốc gia ICT’RDA 2003. Học viện kỹ thuật quân sự 3/2003. Web site: Canata metric tool: QMOOD homepage: Rational Rose Suite: www.rational.com REBOOT homepage: Understanding C++, Understanding Java tools: www.scitools.com ._.