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

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

PHẠM THỊ QUỲNH

KIỂM TRA VÀ ĐO LƯỜNG
DỊCH VỤ WEB

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

HÀ NỘI - 2012


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

PHẠM THỊ QUỲNH

KIỂM TRA VÀ ĐO LƯỜNG
DỊCH VỤ WEB

Chuyên ngành : Công nghệ phần mềm
Mã số

: 62.48.10.01

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

PGS.TS. Nguyễn Thị Tĩnh

HÀ NỘI - 2012


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

i


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 -

ii


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 -

iii


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

iv


DANH MỤCKÝ HIỆU VÀ CHỮ VIẾT TẮT
Ký hiệu và chữ
viết tắt
cohi,j
cohi
COMk
d(u,v)
lengthi
N(A, B)
M
Msg
nmessage
nmethod

nservice
ntype
OP
OPnone complex
OPnone input
P
Par
S
s
ε
BPEL
CBS
CC
ChM
CpM
DC2S
DCM
DCSS

message

Giải nghĩa
Hệ số gắn kết giữa hai phương thức i và j
Hệ số gắn kết giữa phương thức i với các phương thức khác
Độ phức tạp của thông điệp thứ k
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.
Chiều sâu của cây cấu trúc dữ liệu thứ i
Số liên kết động của dịch vụ WebA đến dịch vụ WebB
Tập phương thức trong dịch vụ Web

Tập phương thức có trong dịch vụ Web
Số lượng thông điệp có trong dịch vụ Web
Số lượng phương thức có trong dịch vụ Web
Số lượng dịch vụ Web có trong hệ thống
Số lượng kiểu dữ liệu có trong dịch vụ Web
Tên phương thức trong dịch vụ Web.
Phương thức không có tham số kiểu phức
Phương thức không có tham số input
Tập các tiến trình BPEL
Tập tham số của các phương thức
Tên phần mềm hướng dịch vụ
Tên dịch vụ Web
Tham số tính độ phức tạp của hoạt động lặp trong tiến trình
BPEL. (ε > 1)
Ngôn ngữ thực thi tiến trình nghiệp vụ.
Business Process Execution Language
Kết nối giữa các dịch vụ
Coupling Between Services
Độ phức tạp chu trình
Cyclomatic Complexity
Độ đo tính gắn kết
Cohesion Metric
Độ đo tính kết nối
Coupling Metric
Mức độ kết nối giữa 2 dịch vụ Web
Degree of Coupling between 2 Web Services
Độ đo tính kết nối dữ liệu
Data Coupling Metric
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

v


Ký hiệu và chữ
viết tắt
DIT
FCM
GQM
LCFG
LOC
MBC
OBC
OASIS
SCB
SCCp
SCM
SOA
SOAD
SOAP
SPIN
SRM
TBC
UDDI
WSDL
WSRF

Giải nghĩa
Chiều sâu của cây thừa kế.
Depth of Inheritance Tree
Nhân tố – Tiêu chuẩn – Độ đo

Factors/Criteria/Metrics
Mục tiêu – Câu hỏi – Độ đo
Goal/Question/Metric
Đồ thị luồng điều khiển được gán nhãn
Labeled Control Flow Graph
Số dòng lệnh
Lines Of Code
Độ phức tạp dựa trên thông điệp
Message Based Complexity
Độ phức tạp dựa trên phương thức
Operation Based Complexity
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
Độ phức tạp về mặt cấu trúc của BPEL
Structural Complexity for BPEL
Khả năng tự hoàn thiện của tham số của thành phần
Self-Completeness of Component’sParameter
Độ đo tính kết nối dấu hiệu
Stamp Coupling Metric
Kiến trúc hướng dịch vụ
Service-Oriented Architecture
Phân tích và thiết kế hướng dịch vụ
Service-Oriented Analysis and Design
Giao thức truy nhập đối tượng đơn giản
Simple Object Access Protocol
Bộ biên dịch ngôn ngữ Promela đơn giản
Simple Promela Interpreter
Độ đo khả năng tái sử dụng của dịch vụ
Service’s Reusability Metric

Độ phức tạp dựa trên kiểu dữ liệu
Type Based Complexity
Mô tả, phát hiện và tích hợp chung
Universal Description, Discovery and Integration
Ngôn ngữ đặc tả dịch vụ Web
Web Service Description Language
Dịch vụ Web thỏa mãn chức năng
Web Service Relevancy Funtion
vi


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 -

vii


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 -

viii


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 -

ix


GIỚI THIỆU
Quy trình phát triển hệ thống hướng dịch vụ cần có những công cụ hữu hiệu

giúp đánh giá chất lượng của từng dịch vụ cơ bản và các dịch vụ hợp thành. Luận
án này đề xuất một mô hình thống nhất giúp đo lường và kiểm tra dịch vụ
Web(Web Service) – công nghệ phổ biến được sử dụng để xây dựng các hệ thống
hướng dịch vụ.

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
-1-


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à

-2-


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
động qua lại lẫn nhau. Dựa trên mối quan hệ này, luận án lựa chọn bốn thuộc tính
-3-


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
Độ đo độ
phức tạp
của tiến
trình BPEL

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

Kiểm tra
tiến trình
BPEL

Tầng dịch vụ
Tập độ đo
thuộc tính
chất lượng

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

-4-


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,
kế thừa từ mô hình ISO 9126.
-5-




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.

Bố cục luận án
Bố cục của luận án bao gồm 4 chương. Chương 1 trình bày các kiến thức nền
tảng liên quan đến nội dung luận án. Chương 2trình bày các nghiên cứu liên quan
mà luận án sử dụng và kế thừa. Chương 3và chương 4 là phần nội dung chính của
luận án liên quan đến đo lường và kiểm tra dịch vụ Web.


Chương 1: Kiến thức cơ bản thực hiện luận án. Chương này đề cập tới

các vấn đề cơ bản về đo lường và kiểm tra phần mềm. Bên cạnh đó, do
luận án tập trung giải quyết trên phần mềm hướng dịch vụ nên cũng cần
nhắc tới một số vấn đề liên quan đến kiến trúc hướng dịch vụ và các công
nghệ được sử dụng.



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
-6-


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.

-7-


CHƯƠNG 1: KIẾN THỨC CƠ BẢN
THỰC HIỆN LUẬN ÁN
Chương này trình bày các khái niệm cơ bản liên quan đến đo lường, kiểm tra
phần mềm và kiến trúc hướng dịch vụ. Đây là những kiến thức nền tảng cần thiết
mà luận án sử dụng để thực hiện các nghiên cứu sau này.

1.1. Đo lường phần mềm
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.
-8-


•

Độ đ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

-9-


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. Quy 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à

- 10 -


độ đ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ệ.

Phươ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

- 11 -


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.
Mục tiêu

Câu hỏi
Độ đo

Hình 1.1: Kỹ thuật GQM

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

Người ta không thể đánh giá hay đo lường chất lượng phần mềm một cách
chung chung, mà chỉ có thể đánh giá các thuộc tính cụ thể của phần mềm để đưa ra
một nhận xét tổng quát. Do đó, khái niệm mô hình chất lượng là một nền tảng quan
trọng giúp xác định các thuộc tính chất lượng của phần mềm.
Khả năng bảo trì
Tính linh động
Khả năng kiểm thử

Đánh giá
sản phẩm

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

Chuyển giao
sản phẩm

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

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

Hình 1.2: Mô hình FCM

- 12 -


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.
- 13 -


Yêu cầu

Hệ thống

Hình thức
hóa

Mô hình hóa

Đặc tả
thuộc
tính

Mô hình
hệ thống

Kiểm tra
mô hình

Thỏa
mãn

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?),

- 14 -