Kiểm tra và đo lường dịch vụ web

Depth of Inheritance Tree FCM Nhân tố – Tiêu chuẩn – Độ đo Factors/Criteria/Metrics GQM Mục tiêu – Câu hỏi – Độ đo Goal/Question/Metric LCFG Đồ thị luồng điều khiển được gán nhãn Labeled

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

LUẬN ÁN TIẾN SĨ CÔNG NGHỆ THÔNG TIN

Hướng dẫn khoa học: PGS.TS Huỳnh Quyết Thắng

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi Các kết quả được viết chung với các tác giả khác đều được sự chấp thuận của đồng tác giả trước khi đưa vào luận án.Các số liệu, kết quả nêu trong luận án là trung thực và chưa từng được

ai công bố trong bất cứ một công trình nào khác

Tác giả luận án

Ph ạm Thị Quỳnh

MỤC LỤC

DANH MỤC KÝ HIỆU VÀ CHỮ VIẾT TẮT v

DANH MỤC HÌNH VẼ vii

DANH MỤC BẢNG ix

GIỚI THIỆU - 1 -

Bối cảnh thực hiện luận án - 1 -

Phương pháp tiếp cận và giải quyết vấn đề - 3 -

Các đóng góp chính của luận án - 5 -

Bố cục luận án - 6 -

CHƯƠNG 1: KIẾN THỨC CƠ BẢN THỰC HIỆN LUẬN ÁN - 8 -

1.1 Đo lường phần mềm - 8 -

1.1.1.Các khái niệm liên quan đến đo lường phần mềm - 8 -

1.1.2 Phân loại độ đo phần mềm - 9 -

1.1.3 Quy trình xây dựng độ đo phần mềm - 10 -

1.1.4 Các mô hình chất lượng - 12 -

1.2 Kiểm tra mô hình phần mềm - 13 -

1.3 Tổng quan về hệ thống hướng dịch vụ - 16 -

1.3.1 Định nghĩa dịch vụ Web - 17 -

1.3.2 Điều phối dịch vụ Web - 18 -

Kết luận chương 1 - 20 -

CHƯƠNG 2: KIẾN THỨC LIÊN QUAN ĐẾN ĐO LƯỜNG PHẦN MỀM VÀ KIỂM TRA TIẾN TRÌNH BPEL - 22 -

2.1 Xây dựng tập độ đo các thuộc tính chất lượng của phần mềm - 22 -

2.2 Kiểm tra tiến trình BPEL - 27 -

Kết luận chương 2 - 28 -

CHƯƠNG 3: ĐỘ ĐO CÁC THUỘC TÍNH CHẤT LƯỢNG CỦA DỊCH VỤ WEB - 29 - 3.1 Quy trình xây dựng độ đo - 29 -

3.2 Tập độ đo độ phức tạp dựa trên cấu trúc của dịch vụ Web - 32 -

3.2.1 Định nghĩa về độ phức tạp của phần mềm - 32 -

3.2.2 Các hướng tiếp cận đo lường độ phức tạp phần mềm trước đây - 32 -

3.2.3 Xây dựng tập độ đo độ phức tạp dựa trên cấu trúc của dịch vụ Web - 34 -

3.2.4 Kiểm tra tính hợp lệ của độ đo - 37 -

3.3 Tập độ đo tính kết nối của dịch vụ Web theo khía cạnh tĩnh và động - 40 -

3.3.1 Định nghĩa về tính kết nối - 40 -

3.3.2 Các độ đo tính kết nối trước đây - 40 -

3.3.3 Xây dựng tập độ đo tính kết nối của dịch vụ Web - 42 -

3.3.4 Đánh giá tập độ đo tính kết nối đã đề xuất - 51 -

3.4 Độ đo tính gắn kết của dịch vụ Web - 56 -

3.4.1 Khái niệm về tính gắn kết (cohesion) - 56 -

3.4.2 Ý tưởng về độ đo tính gắn kết từ trước tới nay - 57 -

3.4.3 Định nghĩa độ đo tính gắn kết cho dịch vụ Web - 58 -

3.4.4 Đánh giá độ đo tính gắn kết của dịch vụ Web - 61 -

3.5 Độ đo khả năng tái sử dụng của dịch vụ Web - 63 -

3.5.1 Khái niệm liên quan đến độ đo khả năng tái sử dụng - 63 -

3.5.2 Phương pháp xây dựng độ đo khả năng tái sử dụng của dịch vụ Web - 65 -

3.5.3 Thử nghiệm và đánh giá - 67 -

3.6 Mô hình tham chiếu các thuộc tính chất lượng của dịch vụ Web - 72 -

3.7 Ví dụ minh họa quy trình sử dụng tập độ đo đã đề xuất - 78 -

Kết luận chương 3 - 83 -

CHƯƠNG 4: ĐO LƯỜNG VÀ KIỂM TRA TIẾN TRÌNH BPEL - 84 -

4.1 Xây dựng độ đo độ phức tạp về mặt cấu trúc của tiến trình BPEL - 84 -

4.1.1 Các nghiên cứu liên quan đến đo lường quy trình nghiệp vụ - 85 -

4.1.2 Xây dựng Framework đánh giá tiến trình BPEL - 86 -

4.1.3 Chuyển đổi BPEL sang dạng biểu diễn đồ thị - 88 -

4.1.4 Đánh giá độ phức tạp của tiến trình BPEL - 91 -

4.2 Kiểm tra tiến trình BPEL - 97 -

4.2.1 Phương pháp kiểm tra tiến trình BPEL sử dụng SPIN - 98 -

4.2.2 Phương pháp kiểm tra bộ bắt lỗi của tiến trình BPEL sử dụng SPIN - 104 -

4.2.3 Đánh giá phương pháp kiểm tra tiến trình BPEL sử dụng SPIN - 110 -

Kết luận chương 4 - 112 -

KẾT LUẬN - 113 -

TÀI LIỆU THAM KHẢO - 116 -

DANH MỤC CÁC CÔNG TRÌNH KHOA HỌC ĐÃ CÔNG BỐ CỦA LUẬN ÁN - 123 - PHỤ LỤC 1

Phụ lục 1: Cây cấu trúc dữ liệu của service AmazonWebServices 1

Phụ lục 2: Ví dụ mô tả cách tính độ đo tính kết nối của dịch vụ GoogleSearch 2

Phục lục 3: Ví dụ về quá trình tính độ đo ChM 3

Phụ lục 4 : Bảng tổng kết giá trị các phép đo 4

Phụ lục 5: Tệp WSDL trong hệ thống thẻ 20

Phụ lục 6: Bảng tổng kết, so sánh kết quả đo của SCB và CC trên ba tập mẫu 43

Phụ lục 7 : Kiểm tra tiến trình LoanApproval 45

Phụ lục 8: Kiểm tra tiến trình Acme Travel có xét đến ngoại lệ 53

DANH MỤCKÝ HIỆU VÀ CHỮ VIẾT TẮT

Ký hiệu và chữ

coh i,j Hệ số gắn kết giữa hai phương thức i và j

coh i Hệ số gắn kết giữa phương thức i với các phương thức khác

COM k Độ phức tạp của thông điệp thứ k

d(u,v) Là chiều dài đường đi ngắn nhất từ đỉnh u đến đỉnh v trong

đồ thị được tạo bởi liên kết giữa các dịch vụ Web

length i Chiều sâu của cây cấu trúc dữ liệu thứ i

N(A, B) Số liên kết động của dịch vụ WebA đến dịch vụ WebB

M Tập phương thức trong dịch vụ Web

Msg Tập phương thức có trong dịch vụ Web

nmessage Số lượng thông điệp có trong dịch vụ Web

nmethod Số lượng phương thức có trong dịch vụ Web

nservice Số lượng dịch vụ Web có trong hệ thống

ntype Số lượng kiểu dữ liệu có trong dịch vụ Web

OP Tên phương thức trong dịch vụ Web

BPEL Ngôn ngữ thực thi tiến trình nghiệp vụ

Business Process Execution Language CBS Kết nối giữa các dịch vụ

Coupling Between Services

CC Độ phức tạp chu trình

Cyclomatic Complexity ChM Độ đo tính gắn kết

Cohesion Metric CpM Độ đo tính kết nối

Coupling Metric DC2S Mức độ kết nối giữa 2 dịch vụ Web

Degree of Coupling between 2 Web Services DCM Độ đo tính kết nối dữ liệu

Data Coupling Metric DCSS Mức độ kết nối trong một tập dịch vụ Web cho trước

Degree of Coupling within a given Set of Web Services

Ký hiệu và chữ

DIT Chiều sâu của cây thừa kế

Depth of Inheritance Tree FCM Nhân tố – Tiêu chuẩn – Độ đo

Factors/Criteria/Metrics GQM Mục tiêu – Câu hỏi – Độ đo

Goal/Question/Metric LCFG Đồ thị luồng điều khiển được gán nhãn

Labeled Control Flow Graph

Lines Of Code MBC Độ phức tạp dựa trên thông điệp

Message Based Complexity OBC Độ phức tạp dựa trên phương thức

Operation Based Complexity OASIS

Tổ chức của các tiêu chuẩn thông tin có cấu trúc tiên tiến Organization for the Advancement of Structured Information Standards

SCB Độ phức tạp về mặt cấu trúc của BPEL

Structural Complexity for BPEL SCCp Khả năng tự hoàn thiện của tham số của thành phần

Self-Completeness of Component’sParameter SCM Độ đo tính kết nối dấu hiệu

Stamp Coupling Metric SOA Kiến trúc hướng dịch vụ

Service-Oriented Architecture SOAD Phân tích và thiết kế hướng dịch vụ

Service-Oriented Analysis and Design SOAP Giao thức truy nhập đối tượng đơn giản

Simple Object Access Protocol SPIN Bộ biên dịch ngôn ngữ Promela đơn giản

Simple Promela Interpreter SRM Độ đo khả năng tái sử dụng của dịch vụ

Service’s Reusability Metric TBC Độ phức tạp dựa trên kiểu dữ liệu

Type Based Complexity UDDI Mô tả, phát hiện và tích hợp chung

Universal Description, Discovery and Integration WSDL Ngôn ngữ đặc tả dịch vụ Web

Web Service Description Language WSRF Dịch vụ Web thỏa mãn chức năng

DANH MỤC HÌNH VẼ

Hình 0.1: Mô hình đo lường và kiểm tra theo tầng trong SOA - 4 -

Hình 1.1: Kỹ thuật GQM - 12 -

Hình 1.2: Mô hình FCM - 12 -

Hình 1.3 Quan hệ giữa các thành phần trong mô hình chất lượng ISO-9126 - 13 -

Hình 1.4: Quy trình kiểm tra mô hình - 14 -

Hình 1.5: Bộ kiểm tra mô hình SPIN - 15 -

Hình 1.6: Mô hình cộng tác giữa các thành phần chính trong SOA [70] - 17 -

Hình 1.7: Quan hệ giữa các chuẩn trong dịch vụ Web [70] - 17 -

Hình 1.8: Quy trình xây dựng và thực thi tiến trình BPEL - 19 -

Hình 3.1: Quy trình xây dựng độ đo - 30 -

Hình 3.2: Tám nguyên tắc thiết kế của Thomas Erl - 31 -

Hình 3.3: Ví dụ về xây dựng đồ thị, trong đó A, B, C, D là các dịch vụ - 47 -

Hình 3.4: Đồ thị và ma trận ban đầu - 48 -

Hình 3.5: Đồ thị và ma trận đường đi chuyển đổi với K=4 - 48 -

Hình 3.6: Hai hệ thống WS có cùng số nút và liên kết nhưng DCSS khác nhau - 49 - Hình 3.7: Quy trình gửi/nhận thông điệp SOAP [64] - 50 -

Hình 3.8: Ma trận trọng số - 59 -

Hình 3.9: Phương pháp xác định độ đo tái sử dụng của dịch vụ Web - 67 -

Hình 3.10: Mô hình đánh giá khả năng tái sử dụng của dịch vụ Web - 67 -

Hình 3.11: Quy trình tính toán độ đo - 68 -

Hình 3.12: Biểu đồ phân bố giá trị của độ đo SCM - 70 -

Hình 3.13: Biểu đồ phân bố giá trị của độ đo ChM - 71 -

Hình 3.14: Biểu đồ phân bố giá trị của độ đo SRM - 71 -

Hình 3.15: Mô hình tham chiếu các thuộc tính chất lượng của dịch vụ Web - 77 -

Hình 3.16: Sơ đồ kết nối của hệ thống thẻ - 78 -

Hình 3.17: Đồ thị tương tác giữa các dịch vụ Web trong hệ thống thẻ hiện tại - 80 -

Hình 3.18: Đồ thị tương tác giữa các dịch vụ Web trong hệ thống thẻ mới - 82 -

Hình 4.1: Mô hình tổng quát của Framework - 86 -

Hình 4.2: Cấu trúc của thành phần Core - 87 -

Hình 4.3: Chuyển đổi BPEL từ định dạng XML sang đồ thị - 88 -

Hình 4.4: DOT mô tả đồ thị có hướng - 89 -

Hình 4.5: Biểu diễn nút trong BPEL-G - 89 -

Hình 4.6: Một ví dụ tính độ phức tạp của một hoạt động có cấu trúc - 92 -

Hình 4.7: Lưu đồ thực hiện của quá trình đo BPEL - 94 -

Hình 4.8: Đồ thị so sánh độ đo SCB và CC - 95 -

Hình 4.9: Tiến trình BPEL Rút tiền trên hệ thống cũ và mới - 96 -

Hình 4.10: Quy trình kiểm tra tiến trình BPEL sử dụng SPIN - 98 -

Hình 4.11: Các thành phần trong LCFG - 98 -

Hình 4.12: Nút biểu diễn các hoạt động invoke, receive và reply - 99 -

Hình 4.13:Nút biểu diễn hoạt động gán - 99 -

Hình 4.14:Nút biểu diễn hoạt động tuần tự - 100 -

Hình 4.15:Nút biểu diễn hoạt động rẽ nhánh - 100 -

Hình 4.16:Nút biểu diễn hoạt động lặp - 100 -

Hình 4.17:Nút biểu diễn hoạt động song song - 101 -

Hình 4.18: Cấu trúc của Bộ quản lý ngoại lệ - 106 -

Hình 4.19: Ứng xử của bộ quản lý ngoại lệ - 109 -

DANH MỤC BẢNG

Bảng 1.1: Các hoạt động cơ bản trong BPEL - 20 -

Bảng 2.1: Tập độ đo C&K - 23 -

Bảng 2.2 : Tập độ đo khả năng tái sử dụng của thành phần của Washizaki - 25 -

Bảng 3.1: Thống kê các độ đo độ phức tạp đã đề xuất - 32 -

Bảng 3.2: Kết quả đo trên 7 dịch vụ Web thực hiện chức năng xác thực email - 39 -

Bảng 3.3: Thống kê các độ đo tính kết nối đã đề xuất - 41 -

Bảng 3.4: Thống kê các độ đo tính gắn kết đã đề xuất - 57 -

Bảng 3.5: Thuộc tính ảnh hưởng đến khả năng tái sử dụng của phần mềm - 64 -

Bảng 3.6: Một số kết quả thử ngiệm - 69 -

Bảng 3.7 : Tổng kết tập hợp các độ đo đã đề xuất - 74 -

Bảng 3.8 : Kết quả đo trên hệ thống thẻ hiện tại - 79 -

Bảng 3.9 : Kết quả đo của DC2S - 80 -

Bảng 3.10 : Kết quả đo của CBS - 80 -

Bảng 3.11: So sánh độ đo độ phức tạp - 82 -

Bảng 3.12: So sánh độ đo tính gắn kết - 82 -

Bảng 4.1: Một số phương pháp đo độ phức tạp của tiến trình nghiệp vụ - 85 -

Bảng 4.2: Giải thuật duyệt tệp BPEL - 88 -

Bảng 4.3: Minh họa phương pháp biểu diễn các hoạt động có cấu trúc - 90 -

Bảng 4.4: Độ phức tạp của các hoạt động có cấu trúc - 92 -

Bảng 4.5: Giải thuật đánh giá độ phức tạp của một tiến trình BPEL - 93 -

Bảng 4.6: Biểu diễn trên ngôn ngữ PROMELA - 102 -

Bảng 4.7: Giải thuật chuyển đổi sang ngôn ngữ PROMELA - 104 -

Bảng 4.8: Cài đặt Bộ quản lý ngoại lệ trong PROMELA - 108 -

Bảng 4.9: Sử dụng biến làm điều kiện canh trong cấu trúc unless - 111 -

Bảng 4.10: Bắt nhiều ngoại lệ - 112 -

Bối cảnh thực hiện luận án

Trong những năm gần đây, kỹ thuật hướng dịch vụ [71]đã mang lại những hiệu quả to lớn trong việc phát triển và tổ chức lại hệ thống Chúng ta có thể quan sát hệ thống hướng dịch vụ từ nhiều góc độ khác nhau để thấy được đặc trưngtiêu biểu của chúng

 Từ góc độ kỹ thuật, hệ thống hướng dịch vụ bao gồm: các dịch vụ cơ bản

đã được định nghĩa sẵn; các dịch vụ hợp thành và một môi trường thống nhất giúp phát hiện, phối hợp và triệu gọicác dịch vụ

 Từ góc độ nghiệp vụ, hệ thống hướng dịch vụ cho phép cài đặt mô hình quy trình nghiệp vụ mới bằng cách sử dụng các dịch vụ cơ bản sẵn có (hoặc dịch vụ do bên thứ ba cung cấp) Phương pháp này giúp giảm thời gian và rủi ro trong quá trình phát triển hệ thống

 Kỹ thuật hướng dịch vụ được coi là cầu nối giữa các mô hình nghiệp vụ

và các giải pháp kỹ thuật khác nhau

Dịch vụ Web(Web Service) [61]là công nghệ phổ biến nhất hiện nay được sử dụng để xây dựng các hệ thống hướng dịch vụ OASIS đã cung cấp một số chuẩn như WSDL - giúp định nghĩa một dịch vụ Web, UDDI - phát hiện dịch vụ Web, SOAP - định dạng thông điệp trao đổi giữa các dịch vụ Web, BPEL - phối hợp các dịch vụ Web theo một tiến trình nghiệp vụ cụ thể,

Trong quá trình xây dựng hệ thống hướng dịch vụ,tái sử dụng các dịch vụ Web

là một nhiệm vụthen chốt Điều này đặt ra một ngữ cảnh khá phổ biến: Người phát

triển hệ thống thường xuyên phải lựa chọn một dịch vụ Webthích hợp nhất với yêu cầu của họ Vì cùng một yêu cầu chức năng, sẽ có rất nhiều dịch vụ Webđáp ứng Vào lúc này, người phát triển hệ thống có thể lựa chọn tùy thuộc vào tiêu chí mà họ đưa ra như: tiếng tăm của nhà cung cấp, sự tin tưởng vào dịch vụ mà họ đã từng sử dụng qua Hầu hết các tiêu chí này đều mang tính cảm tính và dựa trên kinh nghiệm Do đó, người phát triển các hệ thống hướng dịch vụ cần có những đánh giá chính xác, có thể lượng hóa được về chất lượng của dịch vụ Web

Đo lường phần mềm là một giải pháp hữu hiệu giúp đưa ra các quyết định đánh giá về chất lượng phần mềm Ngay khi các chương trình máy tính có cấu trúc đơn giản xuất hiện, người ta đã đánh giá độ phức tạp của chúng bằng cách đếm số dòng lệnh hay số điểm chức năng [13] Đối với phần mềm hướng đối tượng, nhiều tác giả đã đề xuất những tập độ đo và khung đo hoàn chỉnh [16], [29], [30], [31] nhằm đánh giá hầu hết các thuộc tính chất lượng của phần mềm theo mô hình ISO

9126 [11] Sau đó, sự ra đời của phần mềm dựa thành phần cũng tạo nên một xu hướng xây dựng các độ đo thành phần và tương tác giữa các thành phần trong hệ thống [17], [33], [34] Vì vậy, việc đánh giá chất lượng của dịch vụ Web hoàn toàn

có thể được thực hiện bằng cách sử dụng các độ đo phù hợp với các đặc trưng tiêu biểu của nó

Hiện nay, một số độ đo liên quan đến các hệ thống hướng dịch vụ cũng đã được đề xuất Tuy nhiên, những độ đo này thường được xây dựng riêng lẻ và chỉ phản ánh một thuộc tính cụ thể của phần mềm hướng dịch vụ [35], [36], [37] hoặc

sử dụng các thông số kỹ thuật khi thực thi hệ thống [21] – điều này không có tác dụng trong việc dự đoán chất lượng của dịch vụ Do đó, quy trình xây dựng phần mềm hướng dịch vụ cần có mô hình đánh giá chất lượng một cách thống nhất và sớm được thực hiện trong giai đoạn đầu của dự án

Bên cạnh đó, tích hợp các dịch vụ cơ bản theo một tiến trình nghiệp vụ cụ thể

là một nhiệm vụ quan trọng trong quá trình phát triển các hệ thống hướng dịch vụ Khi thực hiện nhiệm vụ này, người phát triển phần mềm cần biếtmức độ phức tạp, khả năng xảy ra các bất thường của quy trình nghiệp vụ hoặc điều kiện cụ thể mà

quy trình đó cần thỏa mãn Để thực hiện yêu cầu này, chúng ta cần phải đánh giá độ phức tạp và kiểm tra các thuộc tính về độ an toàn, tính chính xác, khả năng có thể kết thúc, của quy trình nghiệp vụ

Những lý giảitrên đã làm rõ hai nhiệm vụ chính cần thực hiện trong luận án:

1 Đối với dịch vụ cơ bản, xây dựng tập độ đo các thuộc tính chất lượng tiêu biểu dựa trên các thành phần cấu tạo nên chúng Tập độ đo này sẽ giúp người phát triển phần mềm lựa chọn được dịch vụ Web cơ bản, thích hợp nhất theo tiêu chí của họ

2 Đối vớidịch vụ hợp thành, tiến hành đo lường độ phức tạp và kiểm tra tính đúng đắncủa quy trình nghiệp vụ Công cụ này sẽ cung cấp thông tin về các tính chất cần kiểm tra của một quy trình nghiệp vụ sau khi thiết kế

Phương pháp tiếp cận và giải quyết vấn đề

Luận án tiến hành xây dựng công cụ đo lường các thuộc tính chất lượng củadịch vụ Web Cấu trúc của mỗi dịch vụ Web được công bố công khai thông qua tệp đặc tả WSDL Do luận án chỉ đảm bảo nguyên tắc đo hộp đen [3] - tức là coi hệ thống là một hộp đen và không có thông tin gì về cấu trúc bên trong của nó;nên luận

án chỉ sử dụng thông tin từ tệp WSDL

Thông thường, độ đo phần mềm được xây dựng dựa trên các thành phần cấu tạo nên chúng Ví dụ, độ đo phần mềm hướng đối tượng dựa trên các khái niệm về lớp, thuộc tính, phương thức và cây kế thừa [16], [30] Độ đo phần mềm dựa thành phần sử dụng thông tin về giao diện của của thành phần [17] hoặc coi thành phần là tập hợp các lớp [34] Cho nên, khi sử dụng tệp WSDL như dữ liệu đầu vào của các

độ đo thì các thành phần chính trong tệp WSDL như kiểu dữ liệu, kiểu thông điệp

và phương thức sẽ được coi là dữ liệu đầu vào chính của tập độ đo sẽ được đề xuất trong luận án

Trong nguyên tắc thiết kế dịch vụ Web[63], một số thuộc tính chất lượng quan trọng của dịch vụ cần được đảm bảo Các thuộc tính này có mối quan hệ tác

chất lượng tiêu biểu của một dịch vụ Web bao gồm: độ phức tạp (complexity), tính kết nối (coupling), tính gắn kết (cohesion) và khả năng tái sử dụng (reusability) Ngoài ra, chất lượng của một hệ thống hướng dịch vụ không chỉ phụ thuộc vào từng dịch vụ cụ thể của nó, mà còn phụ thuộc vào việc tích hợp các dịch vụ để thực hiện yêu cầu nghiệp vụ Người ta thường sử dụng ngôn ngữ BPEL để mô tả sự phối hợp và cộng tác giữa các dịch vụ Web Việc kiểm tra tính đúng đắn của tiến trình BPEL đã được rất nhiều tác giả quan tâm [89], [90], [91], [92] Tuy nhiên, cách tiếp cận của các phương pháp đã đề xuất thường tập trung vào lý thuyết kiểm tra mô hình và không giải quyết được hết các khái niệm phức tạp trong tiến trình BPEL Luận án đề xuất khung đánh giá tiến trình BPEL một cách tổng quát thông qua việc đo lường độ phức tạp và kiểm tra tính đúng đắn của tiến trình BPEL Tiến trình BPEL sẽ được chuyển đổi sang các dạng đồ thị trung gian và chỉ lưu trữ thông tin cần thiết phục vụ cho mục tiêu cụ thể cần giải quyết

Nếu quan sát hệ thống hướng dịch vụ từ góc độ phân tầng [66] thì việc kiểm tra và đo lường trong luận án này được thực hiện chủ yếu trên hai tầng: tầng dịch vụ

và tầng tiến trình nghiệp vụ Trên tầng dịch vụ, tập độ đo liên quan đến các thuộc tính chất lượng của dịch vụ Web sẽ được sử dụng Trên tầng tiến trình nghiệp vụ, các công cụ kiểm tra và đo lường tiến trình BPEL sẽ được sử dụng

Giao diện

Tầng tiến trình nghiệp vụ

Tầng dịch vụ

Tập độ đo thuộc tính chất lượng

Độ đo độ phức tạp của tiến trình BPEL

Kiểm tra tiến trình BPEL

Hình 0.1: Mô hình đo lường và kiểm tra theo tầng trong SOA

Hình 0.1 mô tả mô hình đo lường và kiểm tra theo các tầng trong kiến trúc hướng dịch vụ Mô hình này coi một hệ thống hướng dịch vụ bao gồm một tập hợp các dịch vụ Web cơ bản và dịch vụ Web hợp thành Luận án định nghĩa một số khái niệm sau:

 Ký hiệu hệ thống hướng dịch vụ Sys = (S, P); trong đó S đại diện cho tập

các dịch vụ Webcơ bản và P đại diện cho tập các tiến trình BPEL Như

vậy, việc đo lường và kiểm tra hệ thống Sys sẽ được chuyển thành đo lường và kiểm tra trên các phần tử của tập S và P

 Mỗi dịch vụ Webcơ bản được tạo bởi một tập kiểu dữ liệu, thông điệp và

phương thức Ký hiệu dịch vụ Web cơ bảns = (T, Msg, M) với s∈S; trong

đó T là tập kiểu dữ liệu, Msg là tập các thông điệp và M là tập các phương thức của dịch vụ Web Việc đo lường và kiểm tra dịch vụ Web cơ bảns sẽ

được thực hiện trên ba tập con cấu tạo nên nó

 Mỗi tiến trình BPEL bao gồm một tập các dịch vụ Webcơ bản và quan hệ

giữa chúng Ký hiệu tiến trình BPEL p= (S ’ , ∑) với p∈P, S ’⊆S và ∑ là

quan hệ giữa các dịch vụ Web cơ bản Trong tiến trình BPEL, tập ∑ được coi là tập các hoạt động và thứ tự thực hiện chúng

Các đóng góp chính của luận án

Bằng cách tiếp cận và giải quyết vấn đề đã đặt ra theo phương pháp trên, luận

án đã đạt được một số kết quả sau:

 Đề xuất phương pháp đánh giá chất lượng của hệ thống hướng dịch vụ ở hai mức: dịch vụ Web cơ bản và dịch vụ Web hợp thành

 Xây dựng tập độ đo các thuộc tính chất lượng của dịch vụ Web theo cách tiếp cận tĩnh như: độ phức tạp, tính kết nối, tính gắn kết và tái sử dụng Tập độ đo này đã được chứng minh tính hợp lệ thông qua thực nghiệm và các tính chất cần thỏa mãn Các kết quả thu được giúp người phát triển hệ thống có thể lựa chọn một dịch vụ Web phù hợp nhất với tiêu chí của họ

 Đề xuất mô hình tham chiếu các thuộc tính chất lượng của dịch vụ Web,

 Xây dựng môi trường đo lường và kiểm tra tiến trình nghiệp vụ BPEL Môi trường này đánh giá độ phức tạp của tiến trình BPEL và kiểm tra một số thuộc tính như tính đúng đắn, tính dừng dựa trên bộ kiểm tra mô hình SPIN Trong quá trình kiểm tra tiến trình BPEL, luận án giải quyết vấn đề liên quan đến mô hình bắt ngoại lệ được gắn kèm với các tiến trình BPEL

 Chương 2: Nghiên cứu liên quan đến đo lường phần mềm và kiểm tra tiến trình BPEL Chương này trình bày các kết quả nghiên cứu đã được công

bố mà luận án sử dụng làm cơ sở khoa học để kế thừa và phát triển

 Chương 3: Độ đo các thuộc tính chất lượng của dịch vụ Web Luận án xây dựng tập độ đo các thuộc tính chất lượng của dịch vụ Web Bốn thuộc tính quan trọng nhất của dịch vụ Web được lựa chọn, bao gồm: độ phức tạp, tính kết nối, tính gắn kết và khả năng tái sử dụng

Bố cục trình bày bốn tập độ đo này tương đối giống nhau Bắt đầu từ các nghiên cứu đã có, định nghĩa độ đo và chứng minh tính hợp lệ Cuối cùng, luận án xây dựng một mô hình tham chiếu giúp phản ánh chất lượng của dịch vụ Web thông qua các độ đo

 Chương 4: Đo lường và kiểm tra tiến trình BPEL Tiến trình BPEL là phương pháp phối hợp các dịch vụ Web hoạt động theo một yêu cầu

nghiệp vụ cụ thể Chương này gồm hai nội dung rõ rệt là: đo lường độ phức tạp của tiến trình BPEL và kiểm tra tiến trình BPEL dựa trên bộ kiểm tra mô hình SPIN Ngoài ra, luận án còn thực hiện một số ví dụ điển hình để minh họa cho phương pháp đề xuất Chi tiết về các ví dụ điển hình này được trình bày trong phần phụ lục

CHƯƠNG 1: KIẾN THỨC CƠ BẢN

1.1.1 Các khái niệm liên quan đến đo lường phần mềm

Đo lường phần mềm là một lĩnh vực quan trọng trong công nghệ phần mềm

Từ trước tới nay, đã có rất nhiều các nghiên cứu liên quan đến lĩnh vực này Các kết quả nghiên cứu đã mang lại những đóng góp to lớn cho sự phát triển của ngành công nghệ phần mềm nói riêng và công nghệ thông tin nói chung

Khái niệm về đo lường và độ đo đã được các tác giả định nghĩa và phát biểu theo nhiều quan điểm khác nhau [1], [2], [3], [4], [5], [6] Tuy nhiên, định nghĩa của Fenton [3] là phù hợp nhất với phương pháp nghiên cứu trong luận án:“Một cách

hình thức, có thể định nghĩa độ đo là một ánh xạ từ thế giới thực sang miền trị, có sắp thứ tự Do đó, giá trị đo là một con số hoặc một ký hiệu được gán cho một thực thể theo cách ánh xạ này để mô tả thuộc tính của thực thể đó.”

Khái niệm vềđộđo phần mềm lầnđầu tiên cũngđượcFenton đề xuất : “Độ đo

phần mềm là thuật ngữ được sử dụng để mô tả các hoạt động từ việc xác định một giá trị để mô tả các thuộc tính mã nguồn cho đến việc tạo ra các mô hình nhằm dự đoán yêu cầu tài nguyên và chất lượng phần mềm.” [5]

Tuy nhiên, độ đo phần mềm sẽ chỉ phát huy tác dụng nếu nó thoả mãn các tính chất sau [3], [5], [9]:

• Độ đo hợp lệ nếu nó mô tả chính thuộc tính cần đo

• Độ đo đáng tin cậy nếu kết quả đánh giá từđộđo gần đúng với kết quả đánh giáthật

• Độ đo có thể thực hiện được nếu nó dễ sử dụng và yêu cầu chi phí đo là chấp nhận được Độ đo có thể thực hiện được nếu không yêu cầu chi phí

đo quá lớn hoặc dữ liệu đo có thể lấy được tại thời điểm đo

• Độ đo mang tính chủ quan và tính khách quan Độ đo khách quan không phụ thuộc vào người đo và kết quả đo là như nhau Các độ đo như dòng lệnh, đo độ điểm chức năng, … có thể được đo một cách khách quan sau khi cài đặt; nhưng có nhiều độ đo quan trọng khác như độ đo kỹ năng và động lực của đội dự án lại phụ thuộc vào sự đánh giá của người ước lượng

1.1 2 Phân loại độ đo phần mềm

Cùng với sự phát triển của lĩnh vực công nghệ phần mềm, rất nhiều độ đo phần mềm đã được đề xuất và sử dụng rộng rãi Tuỳ thuộc vào tiêu chí phân loại, một độ

đo phần mềm có thể được phân bố vào nhiều loại khác nhau

1.1.2.1 Độ đo sản phẩm và độ đo quy trình

Độ đo sản phẩm đo các sản phẩm có liên quan đến dự án phần mềm Nó tập trung vào sản phẩm được tạo ra chứ không phải cách tạo ra sản phẩm Chúng có thể được sử dụng để đánh giá các thuộc tính chất lượng của sản phẩm như: khả năng bảo trì, tính mềm dẻo, khả năng sử dụng và tính đúng đắn của sản phẩm Các thuộc tính này có mối quan hệ mật thiết với nhau

Độ đo quy trình đo các thuộc tính liên quan đến quy trình phát triển một hệ thống phần mềm Các thuộc tính của độ đo quy trình có thể là số lượng và khoảng thời gian xảy ra các hành động được thực hiện trong quy trình, mức độ rủi ro, chi phí, …

1.1 2.2 Độ đo bên trong và bên ngoài

Độ đo bên ngoài là độ đo được sử dụng để đo các thuộc tính ngoài của sản phẩm Thuộc tính ngoài là những thuộc tính phụ thuộc vào ứng xử của sản phẩm và các yếu tố môi trường bên ngoài cũng có thể ảnh hưởng đến độ đo Một số thuộc tính ngoài như khả năng tái sử dụng, mức độ linh động, khả năng thao tác, khả năng tích hợp, …

Độ đo bên trong là độ đo được sử dụng để đo các thuộc tính trong của sản phẩm Ví dụ: kích thước chương trình, số lượng hàm, số lượng lỗi, … Tuy nhiên, do

tính chất đóng gói và che giấu thông tin nên việc đo các thuộc tính bên trong của một số phần mềm có thể không thực hiện được

1.1.2.3 Độ đo động và độ đo tĩnh

Phần mềm có hai trạng thái rõ rệt đó là trạng thái tĩnh – không hoạt động và trạng thái động – đang thực thi Trong trạng thái tĩnh, các đặc tính và cấu trúc của phần mềm được thể hiện như trong thiết kế Chúng không chịu tác động của các yếu

tố bên ngoài như môi trường, hệ điều hành, các ứng dụng khác Tương tác giữa các thành phần đượcmô tả trong lúc thiết kế chương trình, và không chịu ảnh hưởng của các tương tác khác, cũng như các yếu tố khác Các phép đo được đề xuất để đo các thuộc tính của phần mềm trong trạng thái tĩnh được gọi là các phép đo tĩnh

Nếu chỉ xét phần mềm trong trạng thái tĩnh thì không đủ Trong trạng thái tĩnh, các thành phần, các quan hệ tuân theo đúng thiết kế và không chịu tác động từ các yếu tố bên ngoài Khi thực thi, phần mềm ở trong một môi trường bao gồm phần cứng, hệ điều hành, bộ nhớ, môi trường mạng, các vấn đề bảo mật Ngoài ra, các liên kết cũng là các liên kết động và chúng còn chịu ảnh hưởng của các liên kết khác Vì vậy, đo phần mềm trong trạng thái động sẽ phản ánh đầy đủ các đặc tính của phần mềm

Tuy nhiên, không phải mọi thuộc tính đều có thể đo được khi phần mềm ở trạng thái động hoặc không cần thiết đo ở trạng thái động Sự kết hợp giữa các phép

đo động và phép đo tĩnh sẽ giúp hoàn thiện tập độ đo cho phần mềm

1.1.3 Q uy trình xây dựng độ đo phần mềm

Vai trò của độ đo phần mềm trong quá trình phát triển dự án đã được khẳng định Để xây dựng được một độ đo phần mềm, người ta cần phải thực hiện một quy trình tương đối nghiêm ngặt Quy trình này thông thường bắt đầu từ việc xác định đối tượng sử dụng, thuộc tính cần đo, đo như thế nào, cho đến việc chứng minhtính hợp lệ của phép đo đã đề xuất Phần này sẽ trình bày một số khái niệm được sử dụng trong quy trình xây dựng độ đo phần mềm

Hàm đo định nghĩa cách tính ra giá trị đo [6] Một số độ đo có thể được tính

trực tiếp và hàm đo của nó thường chỉ chứa một biến đơn Những độ đo này gọi là

độ đo cơ bản Các độ đo phức tạp hơn được gọi là độ đo dẫn xuất Chúng được xây dựng dựa trên các độ đo cơ sở và các độ đo dẫn xuất khác

Sau khi đã xác định cần đo cái gì và đo như thế nào, ta sẽ phải quyết định làm

gì với kết quả đo được? cần phải hiểu kết quả đo như thế nào? Thông thường, kết

quả đo là giá trị số hoặc ký hiệu Chúng ta phải xác định các tiêu chuẩn đo hay giá

trị ngưỡng để xác định mức đánh giá hoặc dự đoán thuộc tính cần đo Ví dụ, độ đo

khả năng tái sử dụng của một dịch vụ trả về kết quả là 0,5 Vậy giá trị 0,5 cho biết khả năng tái sử dụng của dịch vụ đó là cao, thấp hay trung bình Trong trường hợp này, người xây dựng độ đo cần phái xác định giá trị ngưỡng để ánh xạ từ giá trị đo thành các đánh giá thích hợp

Độ đo hợp lệ khi nó phản ánh chính xác thuộc tính cần đo Do đó, việc chứng

minh tính hợp lệ của độ đo là quy trình đảm bảo rằng độ đo được đề xuất mô tả chính xác thuộc tính cần đo thông qua các giá trị số hoặc ký hiệu [3] Hiện nay, để chứng minh tính hợp lệ của một độ đo mới được đề xuất, người ta thường sử dụng một số phương pháp sau:

 Chỉ ra mối quan hệ giữa độ đo mới với các độ đo nổi tiếng đã tồn tại

 Sử dụng các mệnh đề hoặc định lý để chứng minh Ví dụ: Chuẩn IEEE Std 1061-1998 [8] thường được sử dụng để kiểm tra các thuộc tính chất lượng của phần mềm, phương pháp đánh giá các độ đo độ phức tạp dựa trên 9 thuộc tính do Weyuker đề xuất [23], phương pháp đánh giá DESMET của Barbara Kitchenham [9]

 Phương pháp thực nghiệm được tiến hành khi áp dụng độ đo trên nhiều tập mẫu và lưu lại kết quả thống kê Kết quả này sẽ được so sánh với các đánh giá thực tế sau khi thực hiện độ đo Nếu trùng lặp với xác suất lớn thì tức là độ đo đã được chứng minh tính hợp lệ

P hương pháp GQM (Goal/Question/Metric) [7] minh họa cách sử dụng các độ đo

trong thực tế.Trước hết, người sử dụng phải xác định mục tiêu cần đo Mục tiêu này biến đổi tuỳ thuộc vào từng cấp độ Ví dụ, ở cấp tổ chức, mục tiêu đặt ra thường là giảm chi phí, thoả mãn tối đa yêu cầu khách hàng Ở cấp dự án, thường tập trung vào

việc điều khiển và giải quyết vấn đề nhằm đảm bảo sự thành công của dự án Ngoài ra, còn có các mục tiêu cho từng nhiệm vụ cụ thể.Tiếp theo là xác định các câu hỏi cần trả lời nhằm đạt được mục tiêu Ví dụ, nếu mục tiêu là chuyển giao một phần mềm không

có lỗi, thì các câu hỏi cần đặt ra có thể là: phần mềm đã được kiểm tra chưa? Các lỗi phát hiện ra đã được sửa chưa?Cuối cùng, lựa chọn độ đo thích hợp để trả lời cho các câu hỏi vừa nêu ra Một độ đo có thể trả lời cho nhiều câu hỏi

Dễ dịch chuyển Khả năng tái sử dụng Khả năng hợp tác

Tính chính xác

Độ tin cậy Hiệu quả Khả năng sử dụng được

Khả năng tích hợp

Khả năng bảo trì Tính linh động Khả năng kiểm thử

Đánh giá sản phẩm

Chuyển giao sản phẩm

Vận hành sản phẩm

Hình 1.2: Mô hình FCM

Mô hình chất lượng FCM (Factors Criteria Metrics) do McCall đề xuất vào năm 1977 [10] đã đưa ra một số nhân tố chất lượng từ khung nhìn của người sử dụng và người phát triển phần mềm Hình 1.2 mô tả mô hình FCM từba khía cạnh chính bao gồm: đánh giá sản phẩm, vận hành sản phẩm và chuyển giao sản phẩm

Từ những góc độ này, mô hình FCM chỉ rõ cần đánh giá thuộc tính nào

Sau đó, chuẩn ISO 9126 [11] đượcđề xuất dựa trên sự cải tiến của mô hình FCM Trong chuẩn ISO-9126, chất lượng được định nghĩa là một tập các thuộc tính của sản phẩm đảm bảo khả năng thỏa mãn các yêu cầu đã đề ra

Để thuận tiện hơn cho việc ước lượng và đánh giá cũng như làm tăng khả năng

dễ hiểu cho các thuộc tính chất lượng, các thuộc tính chất lượng được chia thành các thuộc tính con Các thuộc tính con lại được chia nhỏ, và quá trình này được thực hiện cho đến khi ở bước cuối cùng là các thuộc tính có thể tính toán được thông qua các độ đo cụ thể

Hình 1.3 Quan hệ giữa các thành phần trong mô hình chất lượng ISO-9126

1.2 Kiểm tra mô hình phần mềm

Các phương pháp chính được sử dụng để kiểm chứng phần mềm bao gồm kiểm thử (testing), mô phỏng (simulation), kiểm chứng suy diễn (deductive verification) và kiểm tra mô hình (model checking) [87]

Phương pháp kiểm thử và mô phỏng gửi dữ liệu cần kiểm tra tại các điểm đầu vào và kiểm tra dữ liệu tại các điểm đầu ra Đối với các hệ thống phức tạp và không đồng bộ, chi phí để thực hiện hai phương pháp này rất cao Hơn nữa, chúng chỉ thực hiện trên một tập con các trường hợp có thể xảy ra của hệ thống

Phương pháp kiểm chứng suy diễn sử dụng các mệnh đề và các quy luật để chứng minh tính chính xác của các hệ thống có không gian trạng thái vô hạn Nhược điểm của phương pháp này là khá tốn thời gian và phải do các chuyên gia thực hiện Kiểm tra mô hình là một phương pháp thẩm tra hệ thống có không gian trạng thái hữu hạn một cách tự động

Hình thức hóa

Yêu cầu

Đặc tả thuộc tính

Phản ví

dụ Mô phỏng Vị trí lỗi

Hình 1.4: Quy trình kiểm tra mô hình

Kiểm tra mô hình [87] là thuật ngữ chung đề cập tới các phương pháp hình thức và kỹ thuật nhằm xác định ứng xử của hệ thống có phù hợp với đặc tả hay không Bộ kiểm tra mô hình phát hiện tất cả các ngữ cảnh có thể có của hệ thống và chỉ ra rằng hệ thống có thỏa mãn một thuộc tính nào đó hay không Hình 1.4 mô tả các bước chính trong quá trình kiểm tra mô hình

Mô hình hóa hệ thống và thuộc tính cần kiểm tra Mô hình hệ thống mô tả ứng

xử của hệ thống một cách rõ ràng, chính xác Chúng thường được mô tả bằng các automat hữu hạn Mỗi automat hữu hạn chứa một tập hữu hạn trạng thái và luồng dịch chuyển Các trạng thái lưu thông tin về giá trị hiện tại của các biến, câu lệnh được thực hiện trước đó, … Luồng dịch chuyển trạng thái mô tả cách hệ thống tiến triển từ trạng thái này sang trạng thái khác

Thuộc tính kiểm tra cũng cần được hình thức hóa (đặc tả hình thức) Người ta

thường sử dụng các biểu thức Temporal Logic để mô tả những thuộc tính này Temporal Logic là sự kết hợp của logic mệnh đề cổ điển và các toán tử đề cập tới ứng xử của hệ thống theo thời gian Nó cho phép đặc tả các thuộc tính như: tính đúng đắn về mặt chức năng (hệ thống có thực hiện đúng chức năng theo yêu cầu không?), reachability (hệ thống có thể thoát khỏi trạng thái deadlock không?),

safety (lỗi sẽ không bao giờ xảy ra trong hệ thống), liveness (kết quả trông đợi cuối cùng rồi cũng xảy ra), fairness (một sự kiện có bị lặp lại trong điều kiện hiện tại) và các thuộc tính thời gian thực (hệ thống có đang hoạt động đúng giờ?)

Bộ kiểm tra mô hình sẽ được kích hoạt để kiểm tra các thuộc tính trên có thỏa

mãn trong mọi trạng thái của mô hình hệ thống hay không Kết quả trả về có thể xảy ra ba trường hợp:

• Thuộc tính được thỏa mãn

• Thuộc tính không thỏa mãn: đưa ra một số phản ví dụ

SPIN tập trung vào việc chứng minh tính đúng đắn của các tương tác giữa các tiến trình mà không quá chú trọng tới việc tính toán bên trong từng tiến trình Tương tác giữa các tiến trình được thực hiện thông qua các kênh thông điệp Tương tác này có thể là đồng bộ hoặc không đồng bộ

Với vai trò của một công cụ kiểm thử, SPIN cung cấp:

• Ngôn ngữ PROMELA [88]dùng để đặc tả mô hình hệ thống

• Ký pháp để biểu diễn các yêu cầu kiểm tra như biểu thức LTL

• Phương pháp thiết lập sự nhất quán về mặt logic của mô hình hệ thống (mô hình PROMELA) và các yêu cầu cần kiểm tra được viết bằng biểu thức LTL

model.trail

Hình 1.5: Bộ kiểm tra mô hình SPIN

Như vậy, SPIN được sử dụng theo hai mô hình cơ bản:

• Mô phỏng các chương trình PROMELA

• Kiểm tra các thuộc tính được định nghĩa trong chương trình PROMELA

1.3 Tổng quan về hệ thống hướng dịch vụ

Ngày nay, các nhà phát triển phần mềm đang phải đối mặt với một số vấn đề

cơ bản Làm thế nào để giảm chi phí xây dựng hệ thống phần mềm? Làm thế nào đểnâng cao chất lượng hệ thốngnhư: đáp ứng tốt hơn với sự thay đổi của các yêu cầu nghiệp vụ, thời gian chuyển giao nhanh, thoả mãn yêu cầu khách hàng? Làm thế nàođểcác hệ thống và ứng dụng khác nhau giao tiếp với nhau một cách dễ dàng?

Kiến trúc hướng dịch vụ (Service Oriented Architecture - SOA) ra đời là một giải pháp giúp trả lời những câu hỏi này

SOAđưa ra một phương pháp xây dựng các hệ thống phân tán,trong đó cung

cấp các chức năng ứng dụng dưới dạng các dịch vụ Dịch vụ được thiết kế và phát triển theo những đặc điểm sau [61], [70]:

• Mỗi dịch vụ định nghĩa một chức năng thương mại cụ thể và có thể tương ứng với một hoạt động trong thế giới thực

• Mỗi dịch vụ có nhiều phương thức hoạt động khác nhau

• Tương tác giữadịch vụ với các dịch vụ khác là kết nối lỏng

• Giao diện của dịch vụ đượcđịnh nghĩa một cách rõ ràng và có thể được sử dụng bởi các dịch vụ khác

Với SOA, thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ Điều này giúp giảm thời gian, chi phí trong quá trình xây dựng và bảo trì hệ thống

Ý tưởng về hướng dịch vụ là không hoàn toàn mới, DCOM và CORBA cũng

có kiến trúc tương tự Tuy nhiên, trong những kiến trúc này, các thành phần ràng buộc với nhau quá chặt Ví dụ, các ứng dụng phân tán DCOM muốn làm việc với nhau phải đạt được thỏa thuận về chi tiết tập hàm API, một thay đổi mã lệnh trong

thành phần COM sẽ yêu cầu những thay đổi tương ứng đối với mã lệnh truy cập thành phần COM này

Dịch vụ Web[61]là công nghệ phổ biến nhất hiện nay để cài đặt kiến trúc hướng dịch vụ Hình 1.7 mô tả những chuẩn chính được sử dụng trong dịch vụ Web

Hình 1.7: Quan hệ giữa các chuẩn trong dịch vụ Web[70]

1.3.1 Định nghĩadịch vụ Web

Dịch vụ Web được định nghĩa thông qua ngôn ngữ WSDL[70] Mỗi dịch vụ Web có một tệp WSDL được công bố công khai.Tệp WSDL này mô tả những phương thức mà dịch vụ Web hỗ trợ, thông điệp mà nó trao đổi và kiểu dữ liệu mà

nó sử dụng

WSDL thực chất là dạng tài liệu XML[61], [70]; do đó, nó phải tuân theo các quy tắc định nghĩa của ngôn ngữ XML Tài liệu WSDL bắt đầu với việc định nghĩa không gian tên lược đồ hay còn gọi là thành phần gốc <definitions>

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/">

Thành phần <definitions> sẽ bao đóng toàn bộ nội dung của tài liệu WSDL Tất cả các thành phần được biểu diễn kế tiếp đều là con của thành phần gốc

<definitions> WSDL chứa 7 thành phần chính và chia làm hai loại:

• Mô tả trừu tượng: là các thành phần tư liệu hóa giao diện của dịch vụ Web, bao gồm các phương thức mà nó hỗ trợ, các tham số đầu vào và kiểu trả về

• Cài đặt cụ thể: là các thành phần XML mô tả cho người sử dụng biết cách ràng buộc vật lý với dịch vụ Web và sử dụng các phương thức của nó như thế nào

Tuy nhiên, trong phạm vi xây dựng độ đo các thuộc tính của dịch vụ Webluận

án sẽ chỉ dựa vào các định nghĩa trừu tượng của dịch vụ Web Vì vậy, luận án sẽ chỉ tập trung vào ba thành phần chính trong tài liệu WSDL là: <types>, <messages> và

1.3 2 Điều phối dịch vụ Web

Để thực hiện yêu cầu nghiệp vụ, các dịch vụ Web cần phải phối hợp với nhau theo một trình tự nhất định Orchestration và Choreography là hai cách sắp xếp trình

tự hoạt động của dịch vụ Web[61]

Trong Orchestration luôn tồn tại một thành phần trung tâm nhận quyền điểu khiển các dịch vụ Web có liên quan với nhau và xác định quá trình thực thi các hoạt động khác nhau trên các dịch vụ Web đó Thành phần trung tâm ở đây được xem như người “nhạc trưởng” của Orchestration, mỗi dịch vụ Web là một thành phần

trong dàn nhạc Các dịch vụ Web chỉ hoạt động theo sự điều khiển mà không cần biết nó đang thuộc quá trình nào

Ngược lại, Choreography yêu cầu mỗi dịch vụ Web phải biết chính xác thời

điểm thi hành của nó và nó cần tương tác với đối tượng nào Xét trên khía cạnh điều phối dịch vụ Web, để thực thi một tiến trình nghiệp vụ thì Orchestration là một cách tiếp cận thích hợp hơn Choreography

Để hỗ trợ phương pháp điều phối Orchestration, OASIS đã đề xuất ra ngôn

ngữ BPEL [74] BPEL là ngôn ngữ dựa trên nền tảng XML và được sử dụng để định nghĩa các tiến trình nghiệp vụ trong các hệ thống hướng dịch vụ

BPEL giúp định nghĩa mô hình và các quy tắc ngữ pháp mô tả tiến trình nghiệp vụ dựa trên tương tác giữa tiến trình đó với các đối tác của nó Một tiến trình BPEL chứa nhiều hoạt động có liên quan lẫn nhau Ngoài ra, BPEL còn cung cấp các kỹ thuật dùng để bắt sự kiện, bắt lỗi và khả năng khôi phục

Thiết kế

BPEL Designer

Thực thi BPEL Engine

BPEL File

Hình 1.8: Quy trình xây dựng và thực thi tiến trình BPEL

Quy trình xây dựng và thực thi một tiến trình BPEL gồm ba bước sau:

• Sử dụng công cụ BPEL Designer để xây dựng luồng tiến trình nghiệp vụ BPEL Desgner có giao diện đồ họa, cho phép các chuyên gia về nghiệp

vụ định nghĩa các tiến trình nghiệp vụ mà không cần quan tâm tới vấn đề

quản lý giao tác và bảo mật BPEL Engine được được tích hợp trong Application Server Hiện nay, có một số BPEL Engine phổ biến như: ActiveBPEL[78], Oracle BPEL Process Manager [79], Parasoft BPEL Maestro [80]

Tiến trình BPEL chứa một tập hợp các hoạt động Hoạt động được chia thành hai loại: hoạt động cơ bản và hoạt động có cấu trúc Hoạt động cơ bản tương ứng với một hoạt động đơn lẻ Hoạt động có cấu trúc nhấn mạnh vào ràng buộc ứng xử hoặc thực thi trên một tập hợp các hoạt động con Các hoạt động có cấu trúc có thể lồng nhau hoặc kết hợp theo một thứ tự bất kỳ, và điều đó cho phép biểu diễn các cấu trúc phức tạp

Bảng 1.1: Các hoạt động cơ bản trong BPEL

Invoke Triệu gọi một phương thức của dịch vụ

Receive Đợi thông điệp từ đối tác bên ngoài

Reply Trả lời cho đối tác bên ngoài

Wait Dừng hoạt động trong một khoảng thời gian cụ thể

Assign Sao chép dữ liệu từ chỗ này sang chỗ khác

Throw Trả ra lỗi trong quá trình thực thi tiến trình

Compensate Khôi phục lại các ảnh hưởng từ các hoạt động đã hoàn thành Exit Dừng một hoạt động hoặc một tiến trính

Empty Không làm gì

Kết luận chương 1

Chương 1 giới thiệu và thống nhất các khái niệm cơ bản liên quan đến toàn bộ quá trình nghiên cứu Từ những thông tin thu thập được, luận án đã nhất quán các khái niệm cơ bản về hoạt động đo lường và độ đo phần mềm Bên cạnh đó, luận án còn tổng hợp và đề xuất một quy trình xây dựng độ đo phần mềm Quy trình này sẽ được sử dụng để đưa ra tập độ đo các thuộc tính chất lượng của dịch vụ Web

Ngoài ra, một số mô hình đánh giá chất lượng phần mềm như FCM và ISO9126 cũng được nhắc tới Đây là những mô hình quan trọng cho thấy vai trò của

độ đo và cách sử dụng độ đo trong từng ngữ cảnh cụ thể

Kiểm tra mô hình phần mềm là một khía cạnh quan trọng của luận án Chương này đã mô tả ngắn gọn về quy trình kiểm tra mô hình phần mềm và giới thiệu bộ kiểm tra mô hình SPIN Chương 4 của luận án sẽ sử dụng bộ kiểm tra mô hình SPIN Cuối cùng, dịch vụ Weblà đối tượng cần đánh giá chất lượng Vì vậy, luận án đã giới thiệu về hệ thống phần mềm hướng dịch vụ và công nghệ Web Service Chuẩn WSDL – đặc tả cấu trúc của dịch vụ Web và ngôn ngữ BPEL – định nghĩa tiến trình nghiệp vụ đã được trình bày chi tiết trong phần này Đây chính là hai thông tin đầu vào quan trọng cho các nội dung sẽ được trình bày trongchương 3 và chương 4

CHƯƠNG 2: KIẾN THỨC LIÊN QUAN ĐẾN ĐO LƯỜNG PHẦN MỀM VÀ KIỂM TRA TIẾN TRÌNH BPEL

Chương 2 đề cập tới các kiến thức có liên quan tới hai vấn đề cần giải quyết trong luận án Đây là nền tảng cơ bản và cơ sở khoa học giúp xác định phương pháp thực hiện nhiệm vụ đã đề ra

2.1 Xây dựng tập độ đo các thuộc tính chất lượng của phần mềm

Mô hình ISO9126 [11] đã định nghĩa sáu thuộc tính chất lượng quan trọng của phần mềm và cấu trúc phân cấp của chúng Nhiều tập độ đo đã được đề xuất tương ứng với từng thuộc tính này và được xây dựng dựa trên những đặc trưng tiêu biểu của từng mô hình phần mềm khác nhau

Phần này trình bày một số độ đo tiêu biểu cho phần mềm hướng đối tượng và phần mềm dựa thành phần Những độ đo này cũng là cơ sở để nhiều tác giả khác sử dụng để đề xuất những độ đo mới

2.1.1 Tập độ đo các thuộc tính chất lượng của phần mềm hướng đối tượng

Đối với phần mềm hướng đối tượng, người ta thường xây dựng độ đo độ phức tạp của lớp và dựa trên các kỹ thuật hướng đối tượng như kế thừa, dẫn xuất Những

ưu điểm to lớn do phần mềm hướng đối tượng mang lại khiến cho sự tập trung nghiên cứu về loại phần mềm này rất phong phú

Tập độ đo của C&K [16] và Framework do Briand [29], [30], [31] là hai hướng nghiên cứu quan trọng trong việc đo lường các thuộc tính chất lượng của phần mềm hướng đối tượng Chúng còn tiếp tục được thừa kế và phát triển trong các mô hình phần mềm khác

2.1.1.1 Tập độ đo C&K

Tậpđo C&K [16] được xây dựng dựa trên các thành phần cấu tạo nên lớp và

mối quan hệ giữa các lớp Phương thức của lớp và kỹ thuật kế thừa là hai yếu tố

quan trọng được tác giả sử dụng trong quá trình xây dựng độ đo Bảng 2.1 mô tả tập

độ đo C&K và vai trò của chúng trong việc đánh giá chất lượng của lớp

Bảng 2.1: Tập độ đo C&K

WMC WMC (Weighted Methods Per

Class) bằng tổng độ phức tạp

của các phương thức trong lớp

- Số lượng phương thức và độ phức tạp của phương thức là thông số để dự đoán thời gian và chi phí cần thiết để xây dựng lớp

- Lớp có nhiều phương thức thì sẽ

có khả năng ảnh hưởng lớn tới các lớp con kế thừa nó

DIT DIT (Depth of Inheritance Tree)

đo chiều sâu của cây thừa kế

- Cây thừa kế càng sâu thì số lượng lớp kế thừa càng lớn

- Phương thức của lớp được tái sử dụng ở nhiều mức Điều đó làm tăng thêm độ phức tạp

NOC NOC (Number Of Children)

đếm số lớp con kế thừa trực tiếp

từ lớp đang xét

- Càng nhiều lớp dẫn xuất thì khả năng tái sử dụng càng cao

- Càng nhiều lớp dẫn xuất cho thấy khả năng trừu tượng hóa của lớp càng cao

CBO CBO (Coupling Between Object

Classes) đếm số lượng lớp kết

nối đến lớp đang xét

Hai lớp được gọi là kết nối với

nhau nếu phương thức của một

lớp sử dụng phương thức hoặc

biến thành phần của lớp kia

- Một lớp ít có kết nối tới các lớp khác – tức là mức độ độc lập của lớp là cao, thì khả năng tái

sử dụng lớp ở nhiều ứng dụng khác nhau càng cao

- Tính kết nối cao thì khó thay đổi cấu trúc thiết kế và khó bảo trì

RFC RFC (Response For a Class) đo

kích thước của tập đáp ứng RS

Tập đáp ứng RS là tập các

phương thức có thể đáp ứng

một thông điệp được gửi tới

một đối tượng của lớp

- Nếu số lượng các phương thức được viện dẫn khi có một thông điệp đến là lớn thì việc kiểm thử

và gỡ lỗi sẽ rất khó khăn

LCOM LCOM (Lack Cohesion of

Methods) là số các tập rời rạc

được tạo bởi phép giao của n

tập các biến được sử dụng bởi n

phương thức trong lớp

- Số lượng các phương thức sử dụng chung biến càng lớn thì tính gắn kết của lớp càng cao

- Tính gắn kết cao đảm bảo khả năng bao đóng của lớp

2.1.1.2 Framework của Briand

Briand et.al [29], [30], [31] xây dựng một Framework nhằm định nghĩa các khái niệm liên quan đến đo lường phần mềm hướng đối tượng một cách thống nhất như: độ phức tạp, tính kết nối, tính gắn kết, … Tác giả đã thực hiện các bước sau để xây dựng Framework:

• Giới thiệu một số định nghĩa cơ bản về: hệ thống hướng đối tượng, mô-đun

của hệ thống S, tập các quan hệ vào/ra của mô-đun InputR và OutputR

• Định nghĩa độ đo các thuộc tính chất lượng như: kích thước, độ phức tạp, tính kết nối, tính gắn kết là một hàm phải thỏa mãn các tính chất: không

âm, giá trị null, đơn trị và kết hợp

Tác giả đánh giá hệ thống dựa trên lớp, phương thức của lớp, quan hệ giữa các lớp và tương tác giữa các lớp hoặc thành phần của lớp Kiểu tương tác bao gồm: tương tác lớp-thuộc tính, tương tác lớp-phương thức và tương tác phương thức-phương thức Quan hệ giữa các lớp chính là các kỹ thuật được sử dụng trong lập trình hướng đối tượng như: quan hệ bạn, quan hệ kế thừa, quan hệ hợp thành

Trong các nghiên cứu sau đó, Briand et.al tiếp tục đưa ra các khái niệm liên quan đến hướng kết nối [31] Dựa trên quan hệ khách-chủ giữa các lớp, tác giả đã phân biệt hai loại: kết nối đến và kết nối đi

Bên cạnh đó, Yacoup et al [32] phát triển các độ đo của Briand và đề xuất tập

độ đo liên quan đến tính kết nối động giữa các đối tượng

2.1.2 Tập độ đo các thuộc tính chất lượng của phần mềm dựa thành phần

Khi kiến trúc phần mềm hướng thành phần ra đời, cũng có nhiều độ đo được

đề xuất phù hợp với loại hình phần mềm này Thông thường, các tác giả coi một thành phần là một tập hợp các lớp Vì vậy, đo lường thành phần dựa trên hai hướng chính gồm đánh giá cấu trúc của tập hợp các lớp cấu tạo nên thành phần đó và tương tác giữa các thành phần

H Washizaki [17] xây dựng tập độ đo tái sử dụng cho các thành phần JavaBeans Tác giả thực hiện phương pháp đo hộp đen nên chỉ dựa trên các thông tin tĩnh được công bố công khai của thành phần JavaBean mà không sử dụng mã nguồn Bảng 2.2 thống kê tập độ đo khả năng tái sử dụng của thành phần JavaBeans

do H Washizaki [17] đề xuất

Bảng 2.2 : Tập độ đo khả năng tái sử dụng của thành phần của Washizaki

EMI EMI (Existence of Meta Information)

kiểm tra lớp BeanInfo cóồn tại không

Nếu EMI bằng 1 thì dễ sử dụng thành phần hơn

RCO RCO (Rate of Component Observability)

là tỷ lệ các thuộc tính có thể đọc được

trong số các trường được cài đặt trong lớp

Facade của thành phần

Khả năng hiểu rõ một thành phần khi quan sát nó từ bên ngoài

RCC RCC (Rate of Component Customizability)

là tỷ lệ các thuộc tính có thể ghi được

trong số các trường được cài đặt trong lớp

Facade của thành phần

RCC chỉ ra mức độ thay đổi thành phần từ phía người sử dụng

SCCr SCCr (Self-Completeness of Component’s

Return Value) là tỷ lệ các phương thức

không có giá trị trả về được cài đặt trong

thành phần

Giá trị của SCCr càng nhỏ thì khả năng thành phần có phụ thuộc ngoài càng thấp

SCCp SCCr (Self-Completeness of Component’s

Parameter) là tỷ lệ các phương thức không

có tham số được cài đặt trong thành phần

Giá trị của SCCr càng nhỏ thì khả năng thành phần có phụ thuộc ngoài càng thấp Tác giả tiếp tục đề xuất mô hình tái sử dụng thành phần hộp đen dựa trên các nhân tố chất lượng của mô hình ISO 9126 [11] Từ mô hình này, vai trò của tập độ

đo đã định nghĩa được thể hiện rõ nét Độ đo EMI và RCO được sử dụng để đánh giá khả năng hiểu được, độ đo RCC đánh giá khả năng tích hợp, độ đo SCCr và SCCp đánh giá tính khả chuyển của thành phần

Xuất phát từ ý tưởng các tương tác đến và đi của các thành phần, Narasimhan

đã đề xuất các phép đo để đo tần suất các tương tác đến và đi của mỗi thành phần [33] Tác giả đưa ra hai phép đo:

• IIDC(comp) (Interaction Ingoing Density of a Component) –Tần suất

tương tác đến của thành phần comp: được đo bằng tỷ số giữa các tương tác đến của thành phần comp được các thành phần khác sử dụng thực sự

và tổng số các tương tác đến mà nó cung cấp

• IODC(comp) (Interaction Outgoing Density of a Component) –Tần suất

tương tác đi của thành phần comp: được đo bằng tỷ số giữa các tương tác

ra mà thành phần comp sử dụng để giao tiếp thực sự với các thành phần khác và tổng số các tương tác ra có sẵn trên thành phần comp

2.1.3 Tập độ đo độ phức tạp của tiến trình nghiệp vụ

Hầu hết các độ đo đánh giá độ phức tạp đều dựa trên cấu trúc đồ thị của mô hình tiến trình nghiệp vụ và sử dụng lại một số phép đo thông dụng để áp dụng trên các khái niệm của tiến trình nghiệp vụ [50], [51]

Từ độ đo LOC (Lines Of Code), J Cardoso đề xuất độ đo NOA – đếm số lượng các hoạt động của một tiến trình, độ đo NOAC – đếm số lượng các hoạt động

và các thành phần luồng điều khiển của một tiến trình và độ đo NOAJS – đếm số lượng các hoạt động và các thành phần tách, hợp trong tiến trình [50]

Từ độ đo MCC (McCabe’s Cyclomatic complexity), tác giả xây dựng độ đo CFC (Control-flow Complexity) [51] Trước hết, tác giả xây dựng đồ thị luồng điều khiển

Đồ thị này có thể được sử dụng để mô tả cấu trúc logic của một tiến trình Một tiến trình bao gồm các hoạt động và luồng dịch chuyển Trong đồ thị, mỗi hoạt động trở thành nút và mỗi luồng dịch chuyển trở thành cung Luồng dịch chuyển biểu diễn sự phụ thuộc giữa các hoạt động Một hoạt động có nhiều cung đi ra có thể được phân loại thành AND-split, OR-split và XOR-split Độ đo CFC được xây dựng dựa trên việc đánh giá các thành phần điều khiển XOR-splits, OR-splits, và AND-splits

=

) ( )

( )

(

)()

()

()

(

P AND k

AND P

OR j

OR P

XOR i

CFC P

2.2 Kiểm tra tiến trình BPEL

Trong quá trình xây dựng hệ thống hướng dịch vụ, một yêu cầu cần thiết được đặt ra là đảm bảo các tiến trình BPEL hoạt động một cách chính xác Nhiều công cụ

và kỹ thuật đã được xây dựng để thực hiện nhiệm vụ này Hầu hết, các tác giả đều

sử dụng phương pháp ánh xạ tiến trình BPEL sang dạng trung gian; sau đó, sử dụng các bộ kiểm tra mô hình để thực hiện quá trình kiểm tra Các nghiên cứu này thường dựa trên một số hướng chính sau:

Sử dụng mạng Petri net: Mạng Petri net là một đồ thị có hướng, liên thông và

hai phía Trong đó, mỗi nút của đồ thị là một vị trí hoặc dịch chuyển Các thẻ token được đặt vào các vị trí Bất kỳ sự dịch chuyển hợp lệ nào đều có thể di chuyển thẻ token từ mọi vị trí đầu vào và gửi đến vị trí đầu ra Các quy tắc chuyển đổi từ BPEL sang Petri net đã được Stahl [89] đề xuất

Máy trạng thái trừu tượng (Abstract state machine - ASM): cũng được sử

dụng đề mô hình hóa các tiến trình BPEL Một ASM cơ bản chứa một tập hữu hạn các quy tắc chuyển đổi Mỗi quy tắc chuyển đổi chứa hai phần: biểu thức logic và một tập hữu hạn các phép gán Một dịch chuyển sẽ đưa ASM từ trạng thái này sang trạng thái khác SFU Group [90] đã mô hình hóa tất cả các khía cạnh của BPEL như các hoạt động, bộ bắt lỗi, bộ bắt sự kiện, dựa trên ASM

Bộ kiểm tra mô hình SPIN là một công cụ để kiểm tra các hệ thống phần mềm

Ngôn ngữ đầu vào của nó là PROMELA và các thuộc tính cần kiểm tra được đặc tả

dưới các biểu thức LTL SPIN có thể kiểm tra một chương trình PROMELA có thỏa mãn một thuộc tính LTL nào đó hay không [88]

Nhiệm vụ đầu tiên khi sử dụng SPIN để kiểm tra tiến trình BPEL là phải chuyển đổi từ tiến trình BPEL sang ngôn ngữ PROMELA Đã có một số tác giả đề xuất nguyên tắc chuyển đổi toàn bộ hoặc một phần BPEL sang PROMELA theo các phương pháp khác nhau

• Fu [91] đã đưa ra một Framework WSAT (Web Service Analysis Tool) để kiểm tra các thuộc tính của tiến trình BPEL Mỗi tiến trình BPEL được chuyển đổi thànhautomata có điều kiện Sau đó, automata này được ánh xạ sang ngôn ngữ PROMELA Ngoài ra, các tác giả còn thay thế các giao tiếp không đồng bộ bằng các giao tiếp đồng bộ mà không làm thay đổi ngữ nghĩa của chúng

• Phương pháp chuyển đổi các hoạt động BPEL sang PROMELA do Nakajima [92] đề xuất được chia thành hai giai đoạn Thứ nhất, hoạt động BPEL được ánh xạ sang automata hữu hạn mở rộng Automata này cung cấp một mô hình hình thức cho các hoạt động BPEL Thứ hai, automata sẽ được biểu diễn bằng ngôn ngữ PROMELA

sử dụng của H Washizaki được xây dựng dựa trên các thông tin tĩnh của thành phần và Narasimhan xây dựng độ đo dựa trên tương tác giữa các thành phần Bên cạnh đó, luận

án cũng liệt kê một số độ đo đánh giá độ phức tạp của tiến trình nghiệp vụ

Sau khi nghiên cứu một số phương pháp được sử dụng để kiểm tra tiến trình BPEL

Bộ kiểm tra mô hình SPIN được lựa chọn để áp dụng trong chương 4 của luận án

CHƯƠNG 3: ĐỘ ĐO CÁC THUỘC TÍNH CHẤT LƯỢNG CỦA DỊCH VỤ WEB

Chương này trình bày tập độ đo liên quan đến các thuộc tính chất lượng của

dịch vụ Web cơ bảnthông qua tệpWSDL Đây là tài liệuđược cung cấp công khai để

mô tả cấu trúc của một dịch vụ Web

Để đánh giá chất lượng của dịch vụ Web, người ta có thể sử dụng nhiều thuộc tính khác nhau Tuy nhiên, các thuộc tính liên quan đến độ phức tạp, tính kết nối, tính gắn kết và khả năng tái sử dụng là quan trọng nhất và có ảnh hưởng tới các thuộc tính chất lượng khác Vì vậy, luận án tập trung xây dựng tập độ đo liên quan đến các thuộc tính này

Phương pháp xây dựng tập độ đo được thực hiện một cách nhất quán Đầu tiên, luận án định nghĩa tập độ đo phản ánh đúng bản chất của thuộc tính cần đo Sau đó, tiến hành việc chứng minh tính hợp lệ của độ đo

Trong phần cuối cùng của chương, luận án đề xuất một mô hình nhằm minh họa vai trò và cách áp dụng các độ đo đã đề xuất Đây được coi là mô hình tham chiếu chất lượng của dịch vụ Web

3.1 Quy trình xây dựng độđo

Khi sử dụng một dịch vụ Webcơ bản, người xây dựng phần mềm không thể biết được mã lệnh cài đặt hay cấu trúc chi tiết bên trong của nó; mà chỉ biết các mô

tả chung thông qua tệp WSDL Do đó, để xây dựng tập độ đo các thuộc tính chất lượng của dịch vụ Web theo phương pháp hộp đen, luận án chỉ sử dụng những thông tin được cung cấp bởi tệpWSDL làm cơ sở đầu vào cho các phép đo

Dựa trên các nghiên cứu về phương pháp luận xây dựng độ đo [3], [4], luận ántổng hợp mộtquy trình xây dựng độ đo gồmnăm bước như sau:

1 Xác định thuộc tính cần đo và bản chất của nó