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

R = (MetricID, ChildID, ModelID, Weight). 3.4 Chọn lựa công cụ thực hiện Công cụ được lựa chọn để xây dựng chương trình là Visual C++. Bởi vì VC++ có nhiều ưu điểm: C++ là một ngôn ngữ mạnh mẽ, mã máy được biên dịch tốt hơn các công cụ khác về mặt tối ưu mã, có nhiều ưu điểm về mặt sử dụng bộ nhớ và tốc độ thực thi. Visual C++ cung cấp thư viện MFC làm rút ngắn thời gian phát triển phần mềm. Đó là ngôn ngữ của hệ điều hành nên tận dụng được các dịch vụ hệ thống, có thể sử dụng thuận tiện các hàm API. Có thể nâng cấp ứng dụng lên chạy trên dotNet một cách dễ dàng. Đây là ngôn ngữ hướng đối tượng, trong khi chúng ta đang xây dựng chương trình đánh giá phần mềm hướng đối tượng nên sử dụng VC++ là phù hợp. Hệ quản trị CSDL được chọn là Access vì các lý do sau: Chương trình của ta không yêu cầu sử dụng CSDL phân tán và có kích thước lớn, hệ quản trị CSDL Access phù hợp với những ứng dụng CSDL nhỏ gọn. Đây là ứng dụng mang tính chất nghiên cứu thử nghiệm nên chưa đòi hỏi tính bảo mật cao. Hệ quản trị CSDL Access được bộ công cụ Visual Studio (VC++) hỗ trợ tốt qua các dịch vụ ODBC, DAO, OLEDB. Có thể nâng cấp CSDL từ Access lên SQL Server. Xây dựng chương trình a. Mô tả cơ sở dữ liệu Để công cụ có tính mở hỗ trợ nhiều mô hình khác nhau, toàn bộ dữ liệu của chương trình được lưu trữ trong CSDL. Các quan hệ trong cơ sở dữ liệu gồm có: MetricType = (MetricID, MetricName, Scope, Description, NormType, ParamA, ParamB, Help) MetricModel = (MetricID, ChildID, ModelID, Weight) MetricResult = (ProjectID, MetricID, ModelID, Measure, Compute) ProjectTable = (ProjectID, ProjectName, ProjectType, Description) ModelName = (ModelID, ModelName) Để có thể lưu trữ các mô hình trong cơ sở dữ liệu, chúng ta dựa vào đặc điểm các mô hình có cấu trúc cây. Chúng ta lưu trữ cấu trúc cây trong CSDL bằng quan hệ MetricModel = (MetricID, ChildID, ModelID, Weight), trong đó MetricID là khóa chính của một độ đo, ChidID trỏ đến nút con kế tiếp. Mỗi bản ghi trong bảng MetricModel là một quan hệ cha con giữa các nút trên cây. Trường Weight là trọng số thể hiện mối liên hệ giữa nút cha và nút con trong mô hình. Các kiểu độ đo được lưu trữ trong bảng MetricType. Tùy theo kết quả đo là thuộc tính, nhân tố, tiêu chuẩn hay độ đo mà trường Scope nhận giá trị là 0, 1, 2, 3. Các loại độ đo được chuẩn hóa theo một trong ba dạng hàm chuẩn hóa: hàm tuyến tính, hàm giới hạn trên và hàm giá trị tối ưu. Vì thế trường NormType nhận một trong ba giá trị là 0, 1, 2. Các trường ParamA và ParamB là ngưỡng cho các hàm chuẩn hóa này. Các giá trị của ParamA và ParamB được xác định từ kết quả đo thực nghiệm. Kết quả đo được lưu trữ trong bảng MetricResult. Kết quả được lưu theo từng độ đo (MetricID) tương ứng với mỗi phần mềm (ProjectID), mỗi mô hình (ModelID). Kết quả một độ đo của một phần mềm ứng với các mô hình khác nhau có thể khác nhau. Ví dụ cùng là nhân tố khả năng sử dụng lại trong mô hình REBOOT cho ta kết quả khác và trong mô hình QMOOD cho ta kết quả khác. Truy cập CSDL Toàn bộ các bảng được lưu trữ trong file “Metrics97.mdb”. Để truy cập CSDL chúng ta sử dụng dịch vụ OLEDB. Để sử dụng được OLEDB trong Visual C, cần thêm các dòng sau vào file ‘stdafx.h’: #import "C:\program files\common files\system\ado\msado15.dll" no_namespace \ rename( "EOF", "adoEOF" ) Khi ứng dụng được khởi tạo, chúng ta tạo kết nối với CSDL bằng đối tượng _ConnectionPtr: hr = m_pConnection.CreateInstance( __uuidof( Connection ) ); if (SUCCEEDED(hr)) { hr = m_pConnection->Open(_bstr_t(L"Provider=Microsoft.Jet.OLEDB.3.51; Data Source=Metrics97.mdb;"), _bstr_t(L""),_bstr_t(L""), adModeUnknown); if (SUCCEEDED(hr)) { m_IsConnectionOpen = TRUE; } } Để thực hiện các truy vấn (câu lệnh SQL) trong Visual C, chúng ta gán câu lệnh SQL vào một biến CString, rồi sử dụng phương thức Execute của đối tượng _ConnectionPtr để chạy câu truy vấn đó. Ví dụ như sau: _bstr_t bstrQuery("SELECT * FROM MetricModel WHERE ModelID=1"); try { pRecordSet = pDoc->m_pConnection->Execute(bstrQuery, &vRecsAffected, adOptionUnspecified); while (!pRecordSet->GetadoEOF()) { ....... pRecordSet->MoveNext () ; } catch (...) {} b. Giao diện của chương trình Giao diện của chương trình cần có tính thân thiện với người sử dụng, tính toán và hiển thị trên các mô hình một cách trực quan. Bởi vì các mô hình phân cấp chất lượng có cấu trúc cây nên chúng ta chọn lớp CTreeCtrl làm cơ sở để hiển thị các mô hình. Các chương trình xây dựng bằng Visual C++ thường dùng kiến trúc tài liệu-quan sát (document-view architecture) với mục đích tạo sự độc lập giữa dữ liệu và hiển thị. Chính vì thế, chúng ta sử dụng lớp quan sát CTreeView được gắn liền với lớp CTreeCtrl để hiển thị các mô hình theo cấu trúc cây. Để người sử dụng có thể nhập dữ liệu về các độ đo vào cơ sở dữ liệu, xem thông tin về cơ sở dữ liệu, chúng ta sử dụng lớp CMSFlexGrid được cung cấp bởi thư viện MFC. Lớp CMSFlexGrid cho phép liên kết trực tiếp với một bảng trong CSDL (thuộc tính bound), tuy nhiên để tạo tính mềm dẻo khi nhập dữ liệu cũng như hiển thị chúng ta cần thực hiện các truy cập CSDL riêng rồi mới xuất kết quả ra CMSFlexGrid. c. Xây dựng các chức năng của chương trình Chức năng quản lý mô hình Các mô hình được lưu trữ trong CSDL. Mỗi mô hình được xác định từ các bảng MetricModel, MetricType. Để có thể lấy mô hình từ thư viện, chúng ta làm theo các bước như sau: Mỗi mô hình có một khóa là ModelID, vì vậy muốn lấy mô hình nào trước hết cần xác định cụ thể ModelID của mô hình đó (từ tên của mô hình, trong bảng ModelName) . Chọn tất cả các bản ghi trong bản MetricModel có ModelID như trên. Tìm bản ghi lưu trữ nút gốc của mô hình (nút gốc của mô hình được quy ước đặc biệt, ví dụ MetricID = 0). Với mỗi nút trong mô hình tìm tất cả các nút con của nó bằng cách tìm các bản ghi (MetricID, ChildID, ModelID, Weight) trong bảng MetricModel có cùng giá trị MetricID với nút đó. Các nút con được thêm vào mô hình và lại tiếp tục tìm kiếm các nút con của chúng. Quá trình tìm kiếm sẽ nhanh chóng kết thúc vì mỗi mô hình chỉ có 4 hoặc 3 mức. Mô hình được gắn liền với điều khiển CTreeCtrl, mỗi nút trên mô hình tương ứng với một nút trên cây. Việc hiển thị, sửa chữa, thêm bớt các độ đo trên mô hình đều được thực hiện qua việc hiển thị, sửa chữa, thêm bớt các nút tương ứng trên điều khiển cây CTreeCtrl. Mỗi độ đo của mô hình đều có các thông tin kèm theo, để có thể lưu trữ các thông tin này trên điều khiển cây CTreeCtrl, chúng ta dùng một cấu trúc lưu trữ tất cả các thông số kèm theo một độ đo trên mô hình: struct node_data { int MetricID ; float Weight, Measure, Compute, temp ; short NormType ; float ParamA, ParamB; int Scope ; }; Mỗi nút trên điều khiển cây được gắn kèm theo một cấu trúc như trên để lưu thông tin về độ đo tương ứng: node_data *node = new node_data(); CTreeCtrl& pCtrl = (CTreeCtrl&) GetTreeCtrl(); HTREEITEM hPA = pCtrl.InsertItem (...); pCtrl.SetItemData(hPA, (DWORD)node); Chức năng nhập dữ liệu Kết quả đo được nhập vào chương trình qua hai cách: trực tiếp từ bàn phím hoặc nhập từ file kết quả đo của các công cụ khác. Nhập trực tiếp từ bàn phím: Cách làm này có tính mở cao, bởi vì các kết quả đo khi không thể thu thập tự động được thì phải tiến hành thủ công, chẳng hạn như khi cần thu thập các độ đo về thiết kế mà các sơ đồ thiết kế chỉ được vẽ trên giấy, hoặc không được nhập vào máy theo một định dạng dữ liệu có thể dễ dàng thu thập được. Nhược điểm là cách nhập này là tốn nhiều công sức và thời gian. Dữ liệu được nhập vào CSDL qua giao diện là một bảng các độ đo (CMSFlexGrid). Bởi vì điều khiển lưới CMSFlexGrid chỉ cho phép hiển thị thông tin ra màn hình chứ không cho phép nhập trực tiếp dữ liệu vào nên chúng ta phải viết đoạn chương trình để xử lý các thông tin nhập từ bàn phím. Có thể tóm tắt cách làm này như sau: Khi người sử dụng lựa chọn một độ đo nào đó và nhấn phím Enter để nhập dữ liệu thì ta đưa một điều khiển soạn thảo (edit box) vào vị trí ô được chọn trên lưới, khi kết thúc điều khiển soạn thảo lại được ẩn đi. Trong tương lai, các phiên bản sau của chương trình có thể cho phép nhập các độ đo trực tiếp trên mô hình. Nhập từ kết quả đo của các công cụ khác: Như trên đã nói, hiện nay có rất nhiều công cụ trợ giúp cho ta thu thập các độ đo, vì thế chúng ta có thể xuất các kết quả đo từ công cụ đo ra một dạng file phù hợp rồi dùng chương trình của ta để nhập kết quả đo từ dạng file đó. Ưu điểm của cách làm này là nhanh, tiến hành tự động. Nhược điểm là khi sử dụng một công cụ thu thập kết quả đo mới, chúng ta phải tiếp tục mở rộng chương trình của ta để có thể hiểu được định dạng file mới, mặt khác không phải công cụ thu thập độ đo nào cũng cho phép ta xuất kết quả đo ra. Trước mắt, nhằm tiến hành các phép đo thực nghiệm trên các phần mềm hướng đối tượng được xây dựng C++ và Java, chúng tôi lựa chọn phương pháp phân tích ngược (reverse engineering). Chúng tôi cần tiến hành đo các phần mềm hướng đối tượng đã hoàn thành (được viết bằng các ngôn ngữ C++, Java), chúng tôi sử dụng công cụ để phân tích mã nguồn của chương trình, từ đó xây dựng lại sơ đồ thiết kế và thu thập các kết quả đo từ sơ đồ thiết kế đó. Công cụ được sử dụng là Understanding C++ và Understanding Java [21], các công cụ này có khả năng phân tích mã nguồn của các chương trình viết bằng C++ và Java, cung cấp tới 200 kết quả đo các loại. Công cụ Understanding cho phép xuất kết quả đo ra các dạng file .html, .xls, .txt, để đơn giản chúng tôi lựa chọn sử dụng dạng file văn bản .txt. Sau khi phân tích mã nguồn, các kết quả đo được tính toán cho các phương thức, các lớp, cả chương trình. Các kết quả đo sau khi xuất ra file .txt được nhập vào chương trình của chúng ta để xử lý. Chương trình này không phụ thuộc vào một môi trường phát triển phần mềm cụ thể cũng như các công cụ lập trình được sử dụng trong môi trường đó, bởi vì nó thu thập kết quả đo bằng các công cụ đo phần mềm được xây dựng riêng cho môi trường đó. Chức năng tính toán trên mô hình Mỗi mô hình được tính toán theo chiều từ dưới lên (xem hình 3.6). Bắt đầu là các độ đo được chuẩn hóa theo một trong ba dạng hàm chuẩn hóa trong bảng 3.2. Các tham số x và y của các hàm chuẩn hóa được tìm từ các ngưỡng a và b, các ngưỡng a và b được xác định từ các kết quả đo thực nghiệm (cách tính ngưỡng này do chúng tôi đề xuất, xem phần 4.2). Với từng dạng hàm để chuẩn hóa độ đo, chúng ta tính toán các tham số x và y như sau: Hàm tuyến tính Hàm giới hạn trên Hàm giá trị tối ưu f(a) = 1 ; f(b) = 0 f(a) = 0.99 ; f(a+b) = 0.5 f(a)=1 ; f(a+b) = f(a-b) = 0.5 Bảng 3.2: Công thức tính tham số cho các dạng hàm chuẩn hóa Mỗi độ đo được chuẩn hóa qua hàm chuẩn hóa như sau: void CaculateLeafMetric (node_data *node) { float x,y, temp ; try { switch (node->NormType) { case 1 : y = (float) node->ParamA + node->ParamB ; x = - log(1/0.99-1) / node->ParamB ; temp = 1/(1+exp(x*(node->Measure - y))) ; break ; case 2: x = log(2) / (node->ParamB * node->ParamB) ; y = (float)node->Measure - node->ParamA ; temp = (float)exp (-x*(y*y)) ; break ; case 3 : temp=(float) (node->ParamA +node->ParamB - node->Measure )/node->ParamB; break ; } } catch (_com_error &e) { } node->Compute = temp; } Sau khi tính toán các độ đo, các tiêu chuẩn, nhân tố và thuộc tính lần lượt được tính dựa trên kết quả các độ đo đó và công thức biểu diễn mối liên hệ giữa chúng. void CProjectView::CaculateRecursiveNode(HTREEITEM hItem) { CTreeCtrl& pCtrl = (CTreeCtrl&) GetTreeCtrl() ; HTREEITEM hChild; if(pCtrl.ItemHasChildren(hItem)) { node_data *node = (node_data *)pCtrl.GetItemData(hItem); node->Compute = 0 ; hChild = pCtrl.GetChildItem (hItem) ; while(hChild){ CaculateRecursiveNode (hChild) ; hChild = pCtrl.GetNextItem(hChild, TVGN_NEXT); } } else { ComputeLeafNode (pCtrl, hItem) ; } } Chức năng hiển thị mô hình Các mô hình được hiển thị trên điều khiển cây CTreeCtrl. Mỗi độ đo trên mô hình tương ứng với một nút trên điều khiển cây và có lưu trữ các kết quả đo (trong cấu trúc dữ liệu node_data). Sau khi tính toán, ta cần gán nhãn mỗi nút của cây chứa các thông tin về tên độ đo, hệ số với nút cha, giá trị đo được. Thông tin chi tiết về các độ đo được hiển thị trong một quan sát khác (view), để làm được điều đó, chúng ta gắn việc xử lý sự kiện người sử dụng chọn một độ đo với quan sát khác đó. Chức năng phân tích kết quả đo Các kết quả đo có thể được phân tích về mặt thống kê (giá trị lớn nhất, bé nhất, trung bình, độ lệch chuẩn), về mặt ảnh hưởng của giá trị độ đo đến chất lượng phần mềm, về mặt so sánh kết quả đo giữa các sản phẩm phần mềm với nhau. Vì toàn bộ kết quả đo được lưu trữ trong bảng MetricResult (CSDL Access) nên việc chuyển kết quả đo đó sang các ứng dụng khác có khả năng phân tích số liệu thống kê là điều có thể thực hiện được. Hiện tại chức năng phân tích số liệu mới chỉ dựa trên kết quả đo được (chưa dựa trên một mô hình phân tích kết quả đo nào); chương trình có thể phân tích các kết quả đo được về mặt thống kê, về hệ số tương quan. Giới thiệu chương trình: Mô tả chương trình nguồn: Toàn bộ chương trình MetricOO được xây dựng trong một project của Visual C++. Chương trình có các lớp quan trọng như sau: Lớp CMetricOODoc chứa các dữ liệu chung cho chương trình. Khi ứng dụng bắt đầu chạy, đối tượng của lớp CMetricOODoc sẽ tạo kết nối với CSDL qua phương thức OnNewDocument() BOOL CMetricOODoc::OnNewDocument() { HRESULT hr; try { hr = m_pConnection.CreateInstance( __uuidof( Connection ) ); if (SUCCEEDED(hr)) hr = m_pConnection->Open(_bstr_t(L"Provider=Microsoft.Jet.OLEDB.3.51;Data Source=Metrics97.mdb;"), _bstr_t(L""),_bstr_t(L""),adModeUnknown); } catch( _com_error &e ) { } if (!CDocument::OnNewDocument()) return FALSE; return TRUE; } Lớp CProjectView: thực hiện chức năng tính toán và hiển thị mô hình. Lớp CProjectView được thừa kế từ lớp CTreeView nên nó được gắn liền với điều khiển cây CTreeCtrl. Khi một ứng dụng dựa trên MFC được khởi tạo, nó sẽ lần lượt tạo đối tượng tài liệu, đối tượng của sổ chính, đối tượng quan sát, sau đó thiết lập mối quan hệ giữa tài liệu và quan sát. Sau khi gọi phương thức CDocument::OnNewDocument(), chương trình sẽ gọi tới CView::OnInitialUpdate(). Chính vì thế việc nạp mô hình từ thư viện được gọi từ trong phương thức OnInitialUpdate(). Việc tìm các độ đo trên mô hình trong CSDL được gọi đệ quy, các nút cha trỏ đến lớp con qua quan hệ MetricModel. void CProjectView::FindChildNode(int NodeID, const HTREEITEM myNodeID) { // Lan theo node con cua mot node de add vao tree CTreeCtrl& pCtrl = (CTreeCtrl&) GetTreeCtrl(); _RecordsetPtr pRecordSet; _variant_t vRecsAffected(0L); char buf[10] ; sprintf (buf,"%d",NodeID) ; _bstr_t bstrQuery("SELECT * FROM MetricModel WHERE (MetricID="); bstrQuery += LPCTSTR(buf) ; bstrQuery += ") AND (ModelID = " ; sprintf (buf,"%d",m_ActiveModel) ; bstrQuery += LPCTSTR(buf) ; bstrQuery += ") "; CString itemp ; try { pRecordSet = pDoc->m_pConnection->Execute(bstrQuery, &vRecsAffected, adOptionUnspecified); while (!pRecordSet->GetadoEOF()) { HTREEITEM hPA=pCtrl.InsertItem(TVIF_TEXT, _T((_bstr_t) m_pRecordSet->GetCollect ("MetricName")), 0, 0, 0, 0, 0, myNodeID, NULL); FindChildNode (i,hPA) ; pRecordSet->MoveNext () ; } pRecordSet->Close(); } catch(...) { } } Việc tính toán trên mô hình cũng được thực hiện qua lời gọi đệ quy hàm tính toán độ đo từ nút gốc. Nếu độ đo là ở mức thấp nhất thì ta gọi hàm chuẩn hóa (CaculateLeafMetric), còn chưa phải là ở mức thấp nhất thì ta gọi hàm đệ quy (CaculateRecursiveNode). Lớp CNodeView cung cấp quan sát cho từng độ đo. Khi người sử dụng chọn một độ đo trên điều khiển cây thì các thông tin trong quan sát CNodeView về kết quả đo, về tham số chuẩn hóa cũng thay đổi tương ứng với độ đo đó. Bởi vì các quan sát trong một chương trình đều được gắn với một tài liệu chung nên quan sát CProjectView có thể kích hoạt quan sát CNodeView thông qua đối tượng tài liệu chung. void CProjectView::OnSelchanged(...) { CTreeCtrl& pCtrl = (CTreeCtrl&) GetTreeCtrl() ; HTREEITEM hItem = pCtrl.GetSelectedItem ( ) ; if (hItem == NULL ) return ; node_data *node = (node_data *)pCtrl.GetItemData(hItem); pDoc ->m_currentMetricID = node->MetricID ; pDoc->m_MetricCurrentNode = node ; pDoc->UpdateAllViews (NULL); } Lớp CInputMetric: Lớp này thực hiện chức năng nhập dữ liệu. Như phần trên đã nói, có hai khả năng là nhập từ bàn phím hoặc nhập từ kết quả đo của các công cụ khác. Trong trường hợp nhập từ bàn phím, ta sử dụng điều khiển lưới CMSFlexGrid nhưng điều khiển này chỉ cho phép hiển thị thông tin ra chứ không cho phép nhập thông tin vào nên phải kết hợp với một điều khiển soạn thảo để nhập thông tin vào Trong trường hợp nhập từ kết quả đo của một công cụ đo khác, chúng ta phải xác định một định dạng file dữ liệu chung giữa chương trình của chúng ta và công cụ đo đó, vì thế có khả năng khi sử dụng một công cụ đo mới, chúng ta phải mở rộng phần nhập dữ liệu này cho phù hợp. Tạm thời, nhằm phục vụ cho những mục đích đo trong chương 4, chúng tôi sử dụng công cụ Understanding nên cần xây dựng cho chương trình của chúng ta đọc được địng dạng file kết quả của công cụ đó. Lớp CModelView: Cho phép sửa chữa mô hình và tạo mô hình mới. Việc nạp mô hình từ CSDL và hiển thị cũng tương tự như lớp CProjectView. Quá trình sửa chữa thay đổi mô hình được tiến hành trên điều khiển cây CTreeCtrl. Khi sửa chữa hoặc thay đổi xong thì thông tin về mô hình mới được lưu vào CSDL Lớp CDataGridView: thực hiện mở CSDL để xem hoặc sửa các bản ghi trong đó. Có thể nhập dữ liệu, thay đổi các ngưỡng chuẩn hóa, xây dựng các mô hình bằng cách nhập trực tiếp vào CSDL. Điều khiển CMSFlexGrid trong lớp này được gắn kết với các bảng trong CSDL (bằng cách đặt thuộc tính bound). Mô tả giao diện chương trình: Nhập dữ liệu: Dữ liệu về các độ đo có thể nhập trực tiếp từ bàn phím hoặc nhập từ kết quả phân tích của các công cụ khác (Understanding C++, Understanding Java ...) Hình 3.5: Chức năng nhập dữ liệu của chương trình Hình 3.5 là giao diện chức năng nhập các kết quả đo. Sau khi tạo một ứng dụng đo cho một phần mềm cụ thể, ta tiến hành nhập kết quả đo cho ứng dụng đó. Hình 3.5 là một ví dụ giao diện nhập các độ đo từ bàn phím. Ngoài ra, người sử dụng có thể nhập trực tiếp trên mô hình bằng cách click chuột vào nút chứa độ đo, hoặc có thể nhập kết quả đo từ file kết quả của công cụ đo (Understanding C++, Java) Tính toán và hiển thị mô hình: Tính toán các thuộc tính ngoài qua các thuộc tính trong (độ đo) và hiển thị mô hình theo dạng cây. Hình 3.6: Chức năng tính toán và hiển thị độ đo trên mô hình Hình 3.6 thể hiện kết quả đo theo mô hình QMOOD. Phần mềm được đo ở đây là Faid-xml (Fsoft-fpt). Tạo mới và sửa chữa mô hình: cho phép tạo mới, thay đổi thểm bớt các độ đo hay thuộc tính trong các mô hình đã có. Hình 3.7: Chức năng tạo mới và sửa đổi mô hình Hình 3.7 minh họa chức năng tạo mới mô hình. Mô hình ‘new model’ đang được tạo dựng; cửa sổ con cho phép chọn các độ đo để thêm vào mô hình. Mở cơ sở dữ liệu: cho phép người sử dụng mở trực tiếp CSDL để xem và sửa đổi thông tin về kết quả đo, về các kiểu độ đo. Hình 3.8: Chức năng mở CSDL Phân tích kết quả đo: Hiện tại chương trình có thể phân tích các số liệu đo được về mặt thống kê, về hệ số tương quan. Hiện tại chương trình chưa phân tích kết quả đo được theo một mô hình phân tích nào. (a). Thống kê kết quả đo (b). Hệ số tương quan Hình 3.9: Chức năng phân tích kết quả đo. Hình 3.9 minh họa việc phân tích số liệu thống kê các kết quả đo về giá trị lớn nhất, bé nhất, trung bình, hệ số tương quan. CHƯƠNG 4: MỘT SỐ KẾT QUẢ ĐO PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Trong chương này chúng tôi trình bày những kết quả đo một số chương trình phần mềm hướng đối tượng và các phân tích đánh giá của chúng tôi trên các kết quả đó. Đối tượng đo là kết quả một số dự án đã hoàn thành ở trung tâm xuất khẩu phần mềm Fsoft-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