Đo sản phầm phần mềm xây dựng trong môi trường hướng đối tượng

Tài liệu tham khảo kỹ thuật công nghệ, chuyên ngành tin học Đo sản phầm phần mềm xây dựng trong môi trường hướng đối tượng

Để 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ậpthể 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ôinhữ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ônCông nghệ Phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách khoaHà 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áucủ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ảotậ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ếnquý 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 xinchâ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.

1.1.1 Cơ bản về lý thuyết đo 10

1.1.2 Lý thuyết đo – cách tiếp cận 12

1.2 Cơ sở lý thuyết về phép đo phần mềm 14

1.2.1 Vai trò của phép đo phần mềm 14

1.2.2 Mục đích và đối tượng của phép đo phần mềm 16

1.2.3 Các yêu cầu đối với một phép đo phần mềm 18

1.2.4 Các bước của quá trình đo phần mềm 18

1.2.5 Một ví dụ về phép đo phần mềm 18

1.2.6 Một số mô hình đo phần mềm 19

Ước tính chi phí và nhân lực 20

Mô hình đánh giá chất lượng 21

Mô hình đánh giá độ tin cậy 24

Mô hình đánh giá hiệu năng 25

2.1.1 Cơ sở lý thuyết của các phép đo CK 31

a Cơ sở lý thuyết phát triển phần mềm hướng đối tượng 31

b Cơ sở lý thuyết đo 32

c Một số khái niệm 33

2.1.2 Các tính chất của phép đo hướng đối tượng 35

2.1.3 Các phép đo trong hệ đo CK 36

1 WMC (Weight Method per Class) 36

2 DIT (Depth of Inheritance Tree) 37

3 NOC (Number Of Children) 37

4 CBO (Coupling Between Object) 38

5 RFC (Responce For a Class) 38

6 LCOM (Lack of Cohesion in Methods) 39

2.1.4 Tổng kết về các phép đo CK: 39

3.1 Phân tích các yêu cầu 48

3.2 Các chức năng chính của chương trình 51

3.3 Cơ sở dữ liệu của chương trình 51

3.4 Chọn lựa công cụ thực hiện 52

3.5Xây dựng chương trình 53

a Mô tả cơ sở dữ liệu 53

b Giao diện của chương trình 55

c Xây dựng các chức năng của chương trình 55

3.6Giới thiệu chương trình: 60

Mô tả chương trình nguồn: 60

Mô tả giao diện chương trình: 62

CHƯƠNG 4: MỘT SỐ KẾT QUẢ ĐO PHẦN MỀMHƯỚNG ĐỐI TƯỢNG 68

4.1 Kết quả các phép đo CK 69

4.1.1 Kết quả độ đo LCOM 70

4.1.2 Kết quả độ đo DIT 71

4.1.3 Kết quả độ đo CBO 72

4.1.4 Kết quả độ đo NOC 73

4.1.5 Kết quả độ đo RFC 75

4.1.6 Kết quả độ đo WMC 76

4.1.7 Tổng hợp kết quả các độ đo CK 78

4.1.8 Quan hệ ảnh hưởng giữa các độ đo CK và các thuộc tính khác 79

4.2 Kết quả đo sử dụng mô hình QMOOD 82

4.2.1 Quá trình đo sử dụng mô hình QMOOD 82

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 85

Nhận xét đánh giá về các kết quả đo thực nghiệm: 86

KẾT LUẬN 88

TÀI LIỆU THAM KHẢO 90

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Ữ

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 chaAPI Application Programming

Giao diện lập trình ứng dụng

in Class Tính cố kết giữa các phương thức trong cùng một lớpCBO Coupling Between Object class Độ kết dính giữa các lớpCIS 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

GNU GNU Library General PublicLicense

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 SunMicrosystem

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)

MFA Measure of Functional Độ đo mức độ sử dụng thừa kế

Abstraction 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ỏngMTTF Mean Time To Failure Thời gian đến sai hỏngMTTR Mean Time To Repair Thời gian để sửa chữaNOC Number Of Children Số con trực tiếp của một lớpNOH 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)

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 OrientedTechnology

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ộngWMC Weight Metric per Class Độ phức tạp của một lớp

MỞ ĐẦU1 Đặ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áchoạ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 đếncá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ẩmphần mềm Tất cả các ngành công nghệ đều xác định rõ vai trò quan trọng củaphé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ểmsoát được thời gian hoàn thành sản phẩm, chất lượng sản phẩm bàn giao chokhách hàng không được đảm bảo Nếu không thể đánh giá một sản phẩm, chúngta 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 haykhông tốt Như vậy, có thể nói đo phần mềm đóng một vai trò quan trọng trongkỹ nghệ phần mềm Thực hiện đo phần mềm trong các dự án phần mềm nhằmcá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ảnphẩ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ầuphả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ểnmớ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ềmhướ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 gianphá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, đánhgiá 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ôngthể 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ữngphươ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ậptrung nghiên cứu phép đo sản phẩm phần mềm được xây dựng trong môi trườnghướ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óichung và đo phần mềm hướng đối tượng nói riêng (các phép đo CK và mô hìnhchấ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ầnmề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ếnhà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 đốitượ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ềmhướng đối tượng, đề xuất hướng nghiên cứu và phân tích các kết quả đo thựcnghiệm Ba nhiệm vụ chính của đồ án như sau:

1 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ầnmề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ứuvề đ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.

2 Đề xuất và xây dựng công cụ trợ giúp cho quá trình đo phần mềm hướng đốitượng (chương 3) Nhiệm vụ đặt ra là đề xuất một khung cho quá trình đophần mềm và xây dựng công cụ trợ giúp quy trình đó Quy trình đo phầnmềm được đề xuất gồm có 4 bước: chọn lựa mô hình, thu thập dữ liệu, tínhtoá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

3 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ả đophầ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ìnhhướ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 chothấ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ượngcủa Chidamber và Kemerer, rút ra những nhận xét về mối quan hệ ảnh hưởnggiữ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ôitrì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ínhcủ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ộtsự 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ộctính của thực thể có thể là chiều cao, chỉ số thông minh hay là độ phức tạp, độ tincậ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ácthuộ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 chongườ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ácthuộc tính mà trước đây người ta chưa thể nghĩ là có thể đo được Dựa trên kếtquả 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ôngphả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ầnmề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ụ:

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ươngtrì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ình1.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ựcthể 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ầnthông qua một thuộc tính nào khác Trong khi đó việc đo thuộc tính mật độ yêucầ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 haiphé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ộtthuộ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 đếnphé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ínhkhá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 qualạ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 đượctrình bày sau đây ban đầu chỉ liên quan đến các phép đo trực tiếp Khi chúng tacầ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ếpcậ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 đượcmô 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ầncơ 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ấtnày thường được thể hiện qua các quan hệ giữa các thực thể Ví dụ như thuộctí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ónghơ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 tabiế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ệnkhách quan nhưng các quan hệ ban đầu được thiết lập một cách chủ quan Chẳnghạn đo độ dài khi chưa có đơn vị đo thì đó là cách đánh giá chủ quan cái này dàihơ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ácchuyê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ựatrê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ậpcác thực thể là C, ta gọi hệ thống quan hệ là  = (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ậpcác sai hỏng phần mềm, ta xem xét 3 hệ thống quan hệ như sau:

1) Hệ thống quan hệ đơn giản trong đó chỉ có sự phân loại các sai hỏng phầnmềm chẳng hạn như: cú pháp, logic, đổ vỡ hệ thống Giả thiết rằng các saihỏ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ồm3 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êmtrọ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ácnhau.

2) 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 saihỏ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ỏngphần mềm là (C, R’) trong đó R’ = {R1, R2, R3, R4}.

3) 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ủacá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ỏnglogic 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êmtrọng giữa x’ và y’ trong đó x là sai hỏng đổ vỡ hệ thống, y và x’ là sai hỏngcú 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 quanhệ tương ứng trong hệ thống quan hệ dựa trên số Đó gọi là điều kiện biểu diễnthay thế cho hệ thống quan hệ Ký hiệu N là tập trị số và P là tập quan hệ giữacá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 địnhnghĩ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ốngquan 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 tatìm hệ thống quan hệ dựa trên trị số cho thuộc tính sai hỏng phần mềm.

1) Để 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ệtbấ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ácthà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 saihỏng đổ vỡ hệ thống (thuộc R3) vào số 69 Để thỏa mãn điều kiện biểu diễnthay 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à quanhệ “là 69”

2) Để 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 khigá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 Quanhệ 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ỏnglogic vào số lớn hơn sai hỏng cú pháp Như vậy có thể biểu diễn như sau: saihỏng cú pháp 1, sai hỏng logic6, sai hỏng đổ vỡ hệ thống 7.

3) Để tìm biểu diễn thay thế cho R’’, chúng ta cần bảo toàn cả quan hệ R5, nghĩalà sai khác giữa các trị số mà sai hỏng đổ vỡ hệ thống và sai hỏng logic ánhxạ 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ánvà dự đoán được các khía cạnh khác nhau về các quá trình, tài nguyên, sảnphẩ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ầnmề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ớntrong 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 saunà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ũngvậy, phép đo đóng một vai trò quan trọng Những thiếu sót mà chúng ta thườngmắc phải khi phát triển phần mềm mà không sử dụng phép đo là:

1) 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ữngthuộc tính này có ý nghĩa như thế nào xét trên khía cạnh đo đạc Như vậykhô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ờ”.2) 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ạytrong bao lâu không bị sai hỏng với một độ tin cậy nào đó, hoặc là cần baonhiêu chi phí nhân lực để chuyển sản phẩm đó sang chạy ở một môi trườngkhác.

3) 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 haycông cụ mới được phát triển sẽ nâng cao chất lượng sản phẩm mà chúng tasả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ànhkhông thường xuyên, không phù hợp và không hoàn chỉnh Phép đo phần mềmphả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ànhcho pha bảo trì” hay “cứ 1000 dòng lệnh thì có khoảng 55 lỗi” Nhưng chúng takhô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ả sosá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ôngnhiề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ươngtrình nhỏ, những thuật toán nhưng không đánh giá được những hệ thống lớnphứ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ôngxác định vai trò quan trọng của phép đo phần mềm thì cuộc khủng hoảng phầnmề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ómlạ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ếnhà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ụ sausẽ giúp chúng ta có những ý tưởng ban đầu về các phép đo phần mềm:

Nhà quảnlý

Chi phí cho các pha của dự án Kiểm soát chi phí nhằmthu được lợi nhuận

Năng suất (năng lực sản suất) của nhânviên

Trả tiền công cho nhânviê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ớivà 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ư

Thông báo cho ngườiquản lý để có nhữngquyế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

2.2.4

rt Writer

LS 2001

ch 2.0Web

SpiderNS W

ap 2CDB

1.2 PIMHNW

(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ự ánphần mềm, trục nằm ngang là các dự án, trục đứng thể hiện độ đo mức độ hoànthành đúng thời gian Ý nghĩa của độ đo này như sau: giả sử một dự án phầnmề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 đúnghạn thì được 20%, nếu dự án giao hàng chậm một lần thì dự án đạt 80% Tronghì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ấtlượng, gồm có chi phí cho việc đảm bảo quy trình (Process Cost – PCost), chiphí 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

o Đơn giản để có thể tính toán một cách dễ dàng.

o 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ấtlượng sản phẩm).

o 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).

o 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).

o Độc lập với ngôn ngữ lập trình.

o 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ấpnhữ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ếnhành đo phần mềm, chúng ta có thể tiến hành theo những bước sau [7]:

1 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ựachọn phép đo phù hợp.

2 Tiến hành đo trong môi trường phần mềm đó.3 Đá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ínhvề 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ácphép đo ban đầu được định nghĩa:

1 = số toán tử phân biệt2 = 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à=1+2 Chi phí công sức (effort) để xây dựng chương trình P được ước tínhnhư sau:

 NNE 

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 ORDERIF (N.LT.2) GO TO 40

DO 30 I=2, NM=I-1

DO 20 J=1, M

IF (A(I).GT.A(J)) GO TO 10GO TO 20

A(I) = A(J)A(J) = SAVE

 NN

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ớmchi 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ôngthức có thể ước tính trước chi phí cho các dự án sắp tiến hành Mô hìnhCOCOMO (Constructive Cost Model) đưa ra công thức cơ bản của nó như sau :

E  ( )

idiEcD 

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ẩmKLOC 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 chiathà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ầnmềm.

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ố đầura, 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ònphả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ươngphá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ữ đượcsử 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ờicá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ântố - 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âydự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ườigiá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étnhữ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 haythuộ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áctì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ấtlượ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 ứngnhữ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ácnhau

- 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

- Tương thích (Portability) : khả năng chuyển đổi môi trường giữa các nền tảngphần cứng hay phần mềm.

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ừnglĩ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:

Chức năngTính phù hợpTính chính xác

Tương thích

(Portability) Độ tin cậy(Reliability)

Tính tiện dụng(Usability)Chức năng

Bảo trì

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?

Khả năng tương tácĐáp ứng đúng yêu cầuTính bảo mật

Độ tin cậy

Độ chắc chắnKhả năng chịu lỗiKhả năng phục hồiTính tiện dụng

Tính dễ hiểuKhả năng họcTính dễ sử dụngHiệu năng Thời gian đáp ứng

Tài nguyên sử dụngKhả năng bảo trì

Khả năng phân tíchKhả năng thay đổiTính ổn địnhKhả năng kiểm traTính tương thích

Khả năng thích ứngKhả năng cài đặtTính phù hợpKhả 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 độ đonà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ểmvề độ tin cậy phần mềm được chấp nhận rộng rãi đó là khả năng thực thi thànhcông phần mềm đó, như vậy đối tượng cho phép đo độ tin cậy chỉ có thể là sảnphẩm ở dạng mã máy Đây là một trong những thuộc tính quan trọng nhất của

Bảo trì

Tính chính xác

Khả năng test

Khả năng mởrộng

Mức độ kiểm tra

Chi phínhân lựcThay đổi

Thời gian không bị lỗiThời gian sửa chữa

Tỷ lệ lỗi

Mứu độ bao phủ các câu lệnhMức độ hoàn thành kếhoạch test

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ấytrong pha kiểm tra, hoặc là dựa trên thời gian không bị sai hỏng trong pha kiểmtra 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)

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ầnnhư 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

i : 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úngta 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 thicủ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ênngay cả trong trường hợp không biết cụ thể về môi trường thực thi của phầnmề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ểncủ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ìnhbà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ầnmề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 đềuthuộ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ờigian, 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ầnmề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ìnhphá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ànhnhữ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ảibà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ầnmề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ệusử 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ìmhiể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ựctiế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ườngmà 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ínhngoà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ânlự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ựccó 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:

inputeffort

amount 

Trong biểu thức trên, năng suất (productivity) được tính từ các thuộc tính sảnphẩm (amount of output) và thuộc tính quá trình (effort input), trong đó sảnphẩ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ínhcó 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ínhchỉ có thể đo đạc trong mối quan hệ với môi trường của sản phẩm, quá trìnhnguồ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ínhngoài Người giám đốc dự án có thể quan tâm đến các thuộc tính ngoài như nănglự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ốnbiế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ắpmua Thuộc tính trong thường dùng để mô tả độ phức tạp cấu trúc như: kíchthướ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ácthuộ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 cungcấ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ữngkhá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 trongcó ả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ộctí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ántiế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ấtlượ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ếulà 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ácthuộ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 đophầ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ữngchắ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ọnphé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 trungnghiê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ầuphả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ểnnhanh, có chất lượng đã thúc đẩy sự ra đời của các phương pháp phát triển phầnmềm mới hiệu quả hơn Trong số đó cách tiếp cận hướng đối tượng đã trở nênquen thuộc với giới công nghệ thông tin Việc phát triển phần mềm hướng đốitượ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ữnglớp trong thư viện Ngoài ra một vấn đề rất quan trọng trong việc cải tiến quytrình chính là khả năng đo các bước trong quy trình đó, chính vì thế đề tài nghiêncứ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 đốitượng là một vấn đề đã được quan tâm nghiên cứu ngay từ năm 1988 khi phươngpháp phát triển phần mềm hướng đối tượng ra đời Từ đó đến nay đã có rất nhiềukế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ộngrã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ượngchính là ở bước thiết kế hướng đối tượng, hệ thống được chia thành các khốiriê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ứcnăng trước đây, nên cách đánh giá và đo đối với phần mềm hướng đối tượngcũ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 đạcví dụ như: số thuộc tính, số phương thức, số thông điệp gửi đến các đối tượngkhá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ôngcụ đ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 đốitượng? Cần thiết kế các công cụ gì để hỗ trợ cho quá trình đo Làm thế nào để ápdụ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ôngbố 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 trungvà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ọcdữ liệu, trừu tượng hóa Các tác giả đều đưa ra được luận điểm khẳng địnhphương pháp đánh giá của mình và chỉ ra lĩnh vực áp dụng của nó Tuy nhiênnhiề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 quytrì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ánhcá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ênthế 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ácphé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 phasớ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ạnhhướ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âythừ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 đếnchấ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ảnphẩm Chúng được đề xuất dựa trên cơ sở lý thuyết: cách tiếp cận hướng đốitượ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ậnhướng đối tượng [2] Ông đề xuất bốn bước trong pha thiết kế hướng đối tượng:1) 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.

2) Xác định ý nghĩa của các lớp (đối tượng): Bước này xác định cụ thể ý nghĩacá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 đốitượng từ lúc khởi tạo đến lúc hủy.

3) Xác định mối quan hệ giữa các lớp (đối tượng): Trong bước này, tương tácgiữa các lớp và đối tượng được xác định, ví dụ mối quan hệ thừa kế và mốiquan hệ nhìn thấy được một phần nội dung của nhau giữa các lớp.

4) 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ứcvà 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âmtrong thiết kế hướng đối tượng Thiết kế các lớp được dành cho mức ưu tiên caonhấ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ứcnă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ạptrong 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úngtrong 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ácphé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ácphé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ốngquan 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 đó:

- hoặc P  P’, hoặc P’  P (đầy đủ: P phức tạp hơn P’ hoặc P’ phức tạp hơn P).

- P  P’, P’  P”  P  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 quanhệ nêu trên cần được chuyển sang hệ thống quan hệ dựa trên trị số (biểu diễnthay 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ệ Dsang hệ thống quan hệ dựa trên trị số F, ánh xạ này được gọi là phép đo  Vớimỗi thực thể aD, (a)F Phép đo  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 = <x, p(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ộtlớ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ữacác phương thức trong một lớp sẽ đảm bảo sự thực hiện ẩn, tăng khả năngbảo trì

(M1, M2) = I1  I2trong đó:

(M1, M2): mức độ liên quan giữa phương thức M1 và M2Ii : 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ì (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óilớ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ủalớ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 độclậ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ốngcũ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 = <x, p(x)>, Y = <y, p(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ươngthứ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ôngsức cần để hiểu, viết ra nó hay sửa chữa đoạn mã lệnh đó Tuy nhiên việc đotrực tiếp giá trị đó là không thể thực hiện được Chúng ta dùng một cách đotươ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 perClass) Độ 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 cyclomaticdựa vào tổng số các con đường đi độc lập qua đồ thị điều khiển của chươngtrì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ácphươ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 <x, p(x)> = |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ớplà 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ạimã 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âythừa kế.

- Độ đo chiều sâu cây thừa kế (Depth of Inheritance Tree – DIT) Độ sâuthừ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ốccủ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 vicủ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 đượcthừ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ớplê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ácthô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íchhoạ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ácphươ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 phatriể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ácchứ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áclớ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ủahai 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 = <x, p(x)> và Y = <y, p(y)> là hai lớp, thế thì X+Y được ký hiệu làZ = <z, p(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ươngthứ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ầntrước đây.

2.1.2 Các tính chất của phép đo hướng đối tượng.

1 Tính phân biệt:

Cho lớp P và hệ đo , luôn luôn có thể tìm được lớp Q sao cho (P) <> (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.

2 Tính không duy nhất

Có thể tồn tại lớp P và lớp Q sao cho (P) = (Q) Điều đó nghĩa là hai lớpkhác nhau có thể có chung một độ đo, ví dụ hai lớp có cùng độ phức tạp.3 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 (P) = (Q) Chi tiếtcủa việc thiết kế lớp mới ảnh hưởng quyết định đến độ đo của lớp.

4 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: (P) < (P+Q) và (Q)< (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.

5 Tính khác nhau của tương tác  P,  Q,  R thỏa mãn:

(P) = (Q) nhưng (P+R) <> (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.

6 Tương tác làm tăng độ phức tạp P và  Q thỏa mãn:

(P) + (Q) < (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ếtquả đ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 tronglớp đó Gọi c1, c2, , cn là độ phức tạp của các phương thức đó, ta có:

ni

ướ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ươngthứ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ủatậ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 ảnhhưở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ợp có đa

thừa kế, DIT bằng chiều dài nhất đường đi từ nút đến gốc của cây.

Ý nghĩa: DIT của một lớp thể hiện số lớp cha có thể gây ảnh hưởng lên lớp đó.Quan niệm trực giác về DIT:

 Độ sâu thừa kế của một lớp càng lớn, nó càng có nhiều khả năng thừa kếnhiều phương thức, càng khó dự đoán cách xử lý tình huống của nó.

 Cây càng sâu thể hiện độ phức tạp thiết kế lớn, bởi vì càng có nhiều phươngthức và lớp.

 Một lớp ở độ sâu càng lớn, nó càng có nhiều tiềm năng sử dụng lại cácphương thức được thừa kế.

3 NOC (Number Of Children)

Định nghĩa: Độ đo NOC của một lớp được tính bằng số con trực tiếp của lớp đó.Ý nghĩa: NOC thể hiện bao nhiêu lớp sẽ được thừa kế các phương thức của lớp

Quan niệm trực giác về NOC:

 Số con của một lớp càng lớn, tính sử dụng lại của lớp đó càng cao.

 Số con của một lớp thể hiện tầm ảnh hưởng của lớp đó lên cả hệ thống Nếumột lớp càng có nhiều con thì các phương thức của lớp đó càng yêu cầu phảiđược test kỹ lưỡng.

4 CBO (Coupling Between Object)

Định nghĩa: Độ đo CBO của một lớp được tính bằng số lớp có tính kết dính với

lớp đó.

Ý nghĩa : Hai lớp được gọi là kết dính nếu phương thức của lớp này gọi tới

phương thức hay biến của lớp kia.

Quan niệm trực giác về CBO:

 Tính kết dính cao giữa các lớp làm giảm tính modul và giảm khả năng sửdụng lại Một lớp càng độc lập thì càng có nhiều khả năng được sử dụng lạitrong một ứng dụng khác.

 Để tăng tính modul và sự bao bọc dữ liệu, tính kết dính giữa các lớp nên đượcgiữ ở mức thấp Tính kết dính của một lớp cao thì một thay đổi ở lớp đó càngcó nhiều khả năng gây ra nhiều thay đổi ở các bộ phận khác trong hệ thống,gây khó khăn cho việc bảo trì.

5 RFC (Responce For a Class)

Định nghĩa: RFC = |RS| trong đó RS là tập trả lời của lớp đó

Ý nghĩa: Tập trả lời của lớp bao gồm các phương thức có thể bị kích hoạt khi đối

tượng nhận được thông điệp Nó bao gồm cả các phương thức nằm ngoài lớp đó.RS = M all i Ri

trong đó:

Ri = tập các phương thức được gọi bởi phương thức i và M = tập tất cả các phương thức của lớp đó.

Quan niệm trực giác về RFC:

 Nếu có một số lượng lớn phương thức bị kích hoạt để đáp lại một thông điệp,việc test và debug có thể khó khăn và tốn nhiều công sức hơn.

 Càng có nhiều phương thức có thể được kích hoạt bởi một lớp, độ phức tạpcủa lớp đó càng cao.

6 LCOM (Lack of Cohesion in Methods)

Định nghĩa: Giả sử lớp C1 có n phương thức M1, , Mn Gọi {Ij} = tập các biếnđược sử dụng bởi phương thức Mi Gọi P = {(Ii, Ij)| Ii Ij = } và Q = {(Ii, Ij)| IiIj <> }.

LCOM = |P| - |Q|, nếu |P| > |Q|0, ngược lại

Ý nghĩa: LCOM thể hiện sự tương tự giữa các phương thức trong cùng một lớp.

Mức độ tương tự giữa hai phương thức là:

() = I1I2, trong đó I1 và I2 là các biến do M1 và M2 sử dụng.

LCOM là hiệu số của số cặp lớp có độ tương tự là 0 trừ đi số cặp lớp có độ tươngtự khác 0 Càng có nhiều phương thức giống nhau thì lớp đó càng có tính cố kếtcao, bởi vì cố kết là mối liên hệ giữa các thành phần trong cùng một lớp

Quan niệm trực giác về LCOM:

 Nếu một lớp có tính cố kết thấp thì lớp đó nên được chia nhỏ thành các lớpcon.

 Tính cố kết thấp làm tăng độ phức tạp, tăng khả năng xảy ra lỗi trong quátrình phát triển.

 LCOM là mức độ thiếu cố kết giữa các phương thức trong một lớp, giá trịcàng bé thể hiện một thiết kế lớp càng tốt.

2.1.4 Tổng kết về các phép đo CK:

Mỗi phép đo CK liên quan đến một khía cạnh của cách tiếp cận hướng đốitượng WMC, DIT và NOC liên quan đến bước đầu tiên của quá trình thiết kếlớp, (xác định các lớp), WMC thể hiện độ phức tạp còn DIT và NOC liên quanđến vị trí của lớp trong sơ đồ thiết kế lớp WMC va RFC thể hiện tiềm năng đáplại các thông điệp từ bên ngoài của lớp LCOM thể hiện tính đóng gói và bao bọcdữ liệu, tính cố kết giữa các thành phần trong lớp WMC, RFC và LCOM liênquan đến bước thứ hai của quá trình thiết kế lớp (xác định ý nghĩa của các lớp).RFC và CBO là độ đo thể hiện mức độ trao đổi thông tin giữa các lớp qua số lớpkết dính và số phương thức được gọi tới, chúng liên quan đến bước thứ ba củaquá trình thiết kế lớp

Độ đo Xác định các lớp Xác định ý nghĩacác lớp

Mối quan hệ giữa cáclớp

Bảng 2.1: Vai trò của các độ đo CK trong các giai đoạn thiết kế lớp

Sử dụng các độ đo CK trong quá trình phát triển phần mềm hướng đối tượnggiúp cho nhà quản lý kiểm soát và có thể có các cải tiến Sử dụng WMC, DIT vàNOC giúp nhà quản lý xác định xem liệu có nhiều lớp cha quá hay liệu các lớpcha có nhiều phương thức quá hay không (các lớp có nhiều phương thức thì thíchhợp cho ứng dụng cụ thể, tính sử dụng lại thấp) Sử dụng RFC và CBO kiểm soátsự trao đổi thông điệp giữa các thành phần trong hệ thống Các độ đo này sẽ thayđổi theo quá trình phát triển phần mềm, khi bổ xung thêm lớp mới, khi bổ xungthêm thông điệp giữa các lớp Kiểm soát các độ đo này trong vòng đời phầnmềm giúp nhà quản lý kiểm soát được tiến triển của hệ thống hướng đối tượng.

2.1.5 Một ví dụ về các phép đo CK

Để minh họa cho các phép đo nêu ở trên, ta đưa ra một ví dụ minh họa sửdụng các phép đo đó Tập lồi (convex set) có 2 con là polygon và ellipse.Polygon có một phương thức tính chu vi perimeter Các con của nó đều thừa kếphương thức này.

Hình 2.1: Ví dụ minh họa về các phép đo CK- Weighted Method per Class (WMC)

Để đơn giản, quy ước WMC được tính bằng số phương thức của mỗi lớpWMC (POLYGON) = 2

- Responce for a Class (RFC)

Ta đếm số phương thức có thể bị kích hoạt đáp lại một thông điệp Với lớpTriangle có phương thức area có thể kích hoạt 3 phương thức của các lớp connên

RFC (Triangle) = 3

- Coupling Between Object (CBO)

Lớp Polygon không phụ thuộc vào lớp khác (không kể lớp thừa kế) nênCBO (Polygon) = 0

- Depth of Inheritance Tree (DIT)DIT (Polygon) = 1