Phương pháp tạo giả định tối thiểu áp dụng để kiểm chứng phần mềm hướng thành phẩm

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN VĂN HIẾU PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN LUẬN VĂN THẠC SĨ Hà Nội – 2009... Đ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HIẾU

PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU

ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN

LUẬN VĂN THẠC SĨ

Hà Nội – 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HIẾU

PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU

ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN

Ngành: Công nghệ phần mềm

Mã số : 6020611

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Lê Anh Cường

Hà Nội – 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HIẾU

PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU

ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN

LUẬN VĂN THẠC SĨ

Hà Nội – 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HIẾU

PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU

ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN

Ngành: Công nghệ phần mềm

Mã số : 6020611

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Lê Anh Cường

Hà Nội – 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HIẾU

PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU

ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN

LUẬN VĂN THẠC SĨ

Hà Nội – 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN HIẾU

PHƯƠNG PHÁP TẠO GIẢ ĐỊNH TỐI THIỂU

ÁP DỤNG ĐỂ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN

Ngành: Công nghệ phần mềm

Mã số : 6020611

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Lê Anh Cường

Hà Nội – 2009

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC HÌNH VẼ 2

DANH MỤC CÁC CHỮ VIẾT TẮT 3

MỞ ĐẦU 4

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM CHỨNG PHẦN MỀM HƯỚNG THÀNH PHẦN 6

1.1 Giới thiệu 6

1.2 Các khái niệm cơ bản 9

1.2.1 Labeled Transition System(LTS) 9

1.2.2 Dẫn xuất(Traces) 10

1.2.3 Ghép nối song song(Parallel Composition) 11

1.2.3 Safety LTSs, Safety Property, error LTS 13

1.2.4 Sự thoả mãn(satisfying) 14

1.2.5 Ôtomat đơn định hữu hạn trạng thái (Deterministic Finite State Automata) 14 1.3 Về vần đề đảm bảo giả định 15

CHƯƠNG 2: TẠO GIẢ ĐỊNH SỬ DỤNG THUẬT TOÁN HỌC L* 18

2.1 Thuật toán học L* 18

2.2 Tạo giả định sử dụng thuật toán học L* 21

CHƯƠNG 3: GIẢI THUẬT TẠO GIẢ ĐỊNH TỐI THIỂU 25

3.1 Giới thiệu 25

3.2 Định nghĩa giả định tối thiểu 25

3.3 Giải thuật tạo giả định tối thiểu 27

3.3.1 Tư tưởng của giải thuật 27

3.3.2 Chi tiết giải thuật tạo giả định tối thiểu 28

3.3 Tính dừng và đúng đắn của giải thuật tạo giả định tối thiểu 31

3.3.1 Đặc điểm không gian tìm kiếm 31

3.3.2 Tính dừng và tính đúng đắn của giải thuật 32

3.4 Ví dụ tạo giả định tối thiểu 33

CHƯƠNG 4: THỰC NGHIỆM 43

KẾT LUẬN 53

TÀI LIỆU THAM KHẢO 55

PHỤ LỤC 58

Phụ lục A 58

Phụ lục B 61

DANH MỤC CÁC HÌNH VẼ

Hình 1.1: Ví dụ về LTS 10

Hình 1.2: Minh hoạ phép ghép nối song song 13

Hình 1.3: Phép ghép nối CLIENT || SERVER 13

Hình 1.4: Minh hoạ tạo LTS an toàn từ một DFA 15

Hình 1.5: Bài toán và tư tưởng chính của cách tiếp cận xác minh đảm bảo giả định 16

Hình 2.1: Minh hoạ mối quan hệ giữa Teacher và L* learner 19

Hình 2.2: Giải thuật L* 20

Hình 2.3: Một sơ đồ khối để tạo giả định sử dụng giải thuật L* [4, 8] 22

Hình 3.1: Các thành phần của hệ thống trong ví dụ được xét 26

Hình 3.2: Giả định được tạo ra sau khi sử dụng giải thuật L* 26

Hình 3.3: Giả định được tạo ra bởi giải thuật tạo giả định tối thiểu 26

Hình 3.4: Thủ tục để tìm giả định tối thiểu 30

Hình 3.5: Bảng quan sát ban đầu 34

Hình 3.6: Hệ thống ghép nối Input || Ordererr 34

Hình 3.7: Mô hình cây tìm kiếm của các bảng quan sát 36

Hình 3.8: Hệ thống ghép nối A1.2.1 || Input|| Ordererr 38

Hình 3.9: Hệ thống ghép nối Output || A1.2.1err 39

Hình 3.10: Cây tìm kiếm sau khi duyệt đến bảng quan sát 1.2.1 40

Hình 3.11: Giả định kết quả 42

Bảng 4.1 Kết quả thực nghiệm 43

Hình 4.1: FSPs và LTSs của hệ thống minh hoạ trong LTSA 49

Hình 4.2: FSP và LTS của giả định tạo bởi giải thuật trong [1] và kết quả kiểm tra giả định bởi LTSA 50

Hình 4.3: FSP và LTS của giả định tạo bởi giải thuật tạo giả định tối thiểu và kết quả kiểm tra giả định bởi LTSA 51

DANH MỤC CÁC CHỮ VIẾT TẮT

CBSD Component-Based Software Development CBS Component-Based Software

FSP Finite State Proces

LTSA Labelled Transition Systems Analyzed

MỞ ĐẦU

Phát triển phần mềm hướng thành phần (Component-Based Software Development - CBSD) là một trong những công nghệ quan trọng nhất trong kỹ nghệ phần mềm Hệ thống phần mềm hướng thành phần được xây dựng dựa trên quá trình lựa chọn và ghép nối các thành phần riêng biệt thành một hệ thống hoàn chỉnh Với cách tiếp cận này, phát triển phần mềm hướng thành phần đã góp phần rút ngắn thời gian thực hiện dự án, nâng cao chất lượng và độ tin cậy của sản phầm Vì những ưu điểm này mà công nghệ này đã được áp dụng rộng rãi trong quá trình phát triển các dự

án phần mềm hiện nay Tuy nhiên, một trong những hạn chế của CBSD là vấn đề đảm bảo tính đúng đắn của hệ thống khi ghép nối các thành phần với nhau vì các thành phần có thể được phát triển một cách độc lập hoặc được đặt mua từ các công ty thứ 3 (third parties) Hiện tại, các công nghệ hỗ trợ phát triển phần mềm hướng thành phần như CORBA (OMG), COM/DCOM or NET (Microsoft), Java and JavaBeans (Sun),

… vv chỉ hỗ trợ việc ghép nối các thành phần (component plugging) Chúng không có

cơ chế kiểm tra liệu các thành phần có thể bị lỗi khi cộng tác với nhau hay không

Điều này có nghĩa là cơ chế “plug-and-play” không được đảm bảo

Một trong những giải pháp phổ biến để giải quyết vấn đề nêu trên là sử dụng các phương pháp kiểm chứng mô hình (Model checking) Tuy nhiên, một trong những hạn chế lớn nhất của kiểm chứng mô hình là vấn đề bùng nổ không gian trạng thái khi kiểm chứng các phần mềm có kích thước lớn Một trong những cách tiếp cận tiềm năng để giải quyết vấn đề này là áp dụng kiểm chứng từng phần (modular verification

- MV) Thay vì tiến hành kiểm chứng trên toàn bộ hệ thống gồm các thành phần được ghép nối với nhau, cách tiếp cận này tiến hành kiểm chứng trên từng thành phần riêng biệt Với cách tiếp cận này, vấn đề bùng nổ không gian trạng thái hứa hẹn sẽ được giải quyết Một trong những phương pháp kiểm chứng hỗ trợ ý tưởng này là phương pháp kiểm chứng đảm bảo giả định (Assume-Guarantee Verification - AGV) Sử dụng tư

tưởng của chiến lược “chia để trị”, AGV phân chia bài toán kiểm chứng thành các bài

toán con cùng dạng nhưng kích thước nhỏ hơn sao cho chúng ta có thể kiểm chứng các bài toán con một cách riêng biệt AVG được đánh giá là một phương pháp hứa hẹn để kiểm chứng phần mềm hướng thành phần thông qua phương pháp kiểm chứng mô hình AVG không những thích hợp cho phần mềm hướng thành phần mà còn có khả

năng giải quyết vấn đề bùng nổ không gian trạng thái trong kiểm chứng mô hình Trong phương pháp này, các giả định (assumptions) (có vai trò như là môi trường của các thành phần) sẽ được tạo lập Việc tạo lập các giả định chính là bài toán quan trọng nhất trong phương pháp này Kích thước của các giả định này (số lượng trạng thái) nên được cực tiểu hóa bởi vì chi phí cho quá trình kiểm chứng mô hình của phương pháp này phụ thuộc chính vào thông số này Đây chính là mục tiêu nghiên cứu của luận văn này Với mục tiêu này, chúng tôi đề xuất một phương pháp tạo giả định tối thiểu (có kích thước nhỏ nhất) như là một cải tiến của phương pháp kiểm chứng đảm bảo giả định như đã trình bày ở trên Ý tưởng chính của phương pháp đề xuất là tìm kiếm giả định tối thiểu trên toàn bộ không gian tìm kiếm của các ứng cử viên giả định (candidate assumptions) Giả định tối thiểu sau khi tạo lập bằng phương pháp đề xuất

sẽ được sử dụng để kiểm chứng lại hệ thống với chi phí thấp hơn Một số ví dụ minh họa và kết quả thực nghiệm cũng được trình bày trong luận văn này

Bố cục của luận văn được trình bày như sau:

Chương 1: Giới thiệu tổng quan phần mềm hướng thành phần, các khái niệm cơ bản, cách tiếp cận để kiểm chứng phần mềm hướng thành phần

Chương 2: Trình bày chi tiết thuật toán học L*

, giải thuật tạo giả định sử dụng thuật toán học L*

Chương 3: Chương này trình bày giải thuật tạo giả định tối thiểu Trong chương này chúng tôi sẽ đưa ra một phản ví dụ để minh hoạ rằng: giả định được tạo ra bởi giải thuật sử dụng thuật toán học L* chưa phải là giả định tối thiểu Chúng tôi cũng sẽ trình bày một ví dụ cụ thể để minh hoạ cho thuật toán tạo giả định tối thiểu

Chương 4: Thực nghiệm Chúng tôi sử dụng bộ công cụ LTSA để xác minh một

số hệ thống đơn giản nhằm so sánh về thời gian cũng như bộ nhớ sử dụng của giải pháp cũ và giải pháp được đưa ra trong luận văn

Phần kết luận của luận văn tổng kết các kết quả đã đạt được, kết luận và đưa ra một số hướng nghiên cứu tiếp theo

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM CHỨNG PHẦN MỀM

HƯỚNG THÀNH PHẦN

1.1 Giới thiệu

Quá trình phát triển phần mềm hướng thành phần được biết đến là sự phát triển phần mềm bằng cách ghép nối các phần độc lập Đây là một trong những kỹ thuật quan trọng nhất trong kỹ nghệ phần mềm Cách tiếp cận này vẫn đang thu hút sự chú ý trong cộng đồng kỹ nghệ phần mềm và được xem là một cách tiếp cận mở, hiệu quả, giảm thời gian và chi phí phát triển đồng thời tăng chất lượng của phần mềm Đã có rất nhiều khái niệm, kỹ thuật đề xuất nhằm phát triển cho ý tưởng này

Tuy nhiên, một trong những hạn chế của phát triển phần mềm hướng thành phần là vấn đề đảm bảo tính đúng đắn của hệ thống khi ghép nối các thành phần với nhau vì các thành phần có thể được phát triển một cách độc lập hoặc được đặt mua từ các công ty thứ 3 (third parties) Hiện tại, các công nghệ hỗ trợ phát triển phần mềm hướng thành phần như CORBA (OMG), COM/DCOM or NET (Microsoft), Java and JavaBeans (Sun), … vv chỉ hỗ trợ việc ghép nối các thành phần (component plugging) Chúng không có cơ chế kiểm tra liệu các thành phần có thể bị lỗi khi cộng tác với

nhau hay không Điều này có nghĩa là cơ chế “plug-and-play” không được đảm bảo

Một giải pháp phổ biến hiện nay để giải quyết cho vấn đề trên là áp dụng kiểm chứng

mô hình (model checking - MC) [5] Kiểm chứng mô hình là một cách tiếp cận quan trọng để giải quyết bài toán chứng minh độ tin cậy của phần mềm Nó cũng tạo ra một không gian trạng thái chi tiết có thể bao phủ được các hệ thống đang được kiểm tra đồng thời đạt được hiệu quả đặc biệt trong quá trình dò các lỗi tổng hợp khá phức tạp

mà nguyên nhân chủ yếu do quá trình ghép nối các thành phần gây nên Tuy nhiên,

một trong những hạn chế lớn nhất của kiểm chứng mô hình là “vấn đề bùng nổ không gian trạng thái” khi kiểm chứng các phần mềm có kích thước lớn Một trong những

cách tiếp cận tiềm năng để giải quyết vấn đề này là áp dụng kiểm chứng từng phần (modular model checking - MMC) [10, 11] Thay vì tiến hành kiểm chứng trên toàn bộ

hệ thống gồm các thành phần được ghép nối với nhau, cách tiếp cận này tiến hành kiểm chứng trên từng thành phần riêng biệt Với cách tiếp cận này, vấn đề bùng nổ không gian trạng thái hứa hẹn sẽ được giải quyết Một trong những phương pháp kiểm chứng hỗ trợ ý tưởng này là phương pháp kiểm chứng đảm bảo giả định (Assume-

Guarantee Verification - AGV) [2, 4, 7, 8] Sử dụng tư tưởng của chiến lược “chia để trị”, AGV phân chia bài toán kiểm chứng thành các bài toán con cùng dạng nhưng

kích thước nhỏ hơn sao cho chúng ta có thể kiểm chứng các bài toán con một cách riêng biệt AVG được đánh giá là một phương pháp hứa hẹn để kiểm chứng phần mềm hướng thành phần thông qua phương pháp kiểm chứng mô hình AVG không những thích hợp cho phần mềm hướng thành phần mà còn có khả năng giải quyết vấn đề bùng nổ không gian trạng thái trong kiểm chứng mô hình Trong phương pháp này, các giả định (assumptions) (có vai trò như là môi trường của các thành phần) sẽ được tạo lập Việc tạo lập các giả định chính là bài toán quan trọng nhất trong phương pháp này Mục tiêu chính của cách tiếp cận này là nhằm kết hợp tốt nhất giữa lợi thế của hai phần: kiểm chứng mô hình và phát triển hướng thành phần

Hiện nay, đã có nhiều nghiên cứu về kiểm chứng mô hình từng phần cho phần mềm hướng thành phần (modular verification of component based software) [2, 4, 7,

8, 10, 11, 22] Mỗi khi thêm một thành phần nào đó vào hệ thống, thì toàn bộ hệ thống gồm các thành phần đang tồn tại và thành phần mới phải được kiểm chứng lại Vì thế, đối với những phần mềm phức tạp, vấn đề “bùng nổ không gian trạng thái” có thể xảy

ra khi ấp dụng các phương pháp trong các nghiên cứu này Cách tiếp cận trong [2, 4, 7, 8] đề xuất phương pháp kiểm chứng đảm bảo giả định như đã trình bày ở trên Xét một hệ thống đơn giản gồm hai phần M1 và M2 Mục đích của cách tiếp cận này là kiểm chứng hệ thống này thoả mãn một thuộc tính p mà không cần đến việc ghép nối giữa các thành phần với nhau Dựa trên tư tưởng này, AGV tìm ra một giả định A sao cho nó đủ mạnh cho M1 thoả mãn p và đủ yếu để nó được thỏa mãn bởi M2 Nếu tìm được một giả định A thỏa mãn các điều kiện trên thì hệ thống khi ghép nối M1||M2 sẽ thoả mãn thuộc tính p Tuy nhiên, cách tiếp cận này không đề cập đến việc kiếm chứng

hệ thống trong ngữ cảnh của tiến hóa thành phần phền mềm Nếu một thành phần bị tiến hóa sau khi thực hiện một vài thay đổi, khi đó giải pháp này sẽ phải thực hiện kiểm chứng hệ thống như một hệ thống mới Trong khi đó việc thay đổi chỉ xảy ra ở một vài thành phần nên việc chạy lại trên toàn bộ hệ thống là không cần thiết Để giải quyết hạn chế này, giải pháp trong [25] đã đề xuất một cách tiếp nhằm tạo lại giả định nhanh hơn trong ngữ cảnh các thành phần bị tiến hóa (thay đổi) Giả sử tồn tại một thành phần M1 có trước (thành phần này không được phép thay đổi) và một phần mở rộng M2 (thành phần này được phép thay đổi) Phần mở rộng M2 được ghép nối với

thành phần M1 bởi một vài cơ chế nào đó Đầu tiên, chúng ta giả thiết rằng hệ thống chứa M1 và M2 thoả mãn thuộc tính p (tức là, M1||M2╞ p) Tiếp theo, phần M2 được biến đổi thành một thành phần mới M’2 bằng cách thêm các hành vi (behavior) mới vào thành phần M2 Hệ thống mới chứa M1 và thành phần mới M’2 sẽ phải được kiểm chứng lại xem liệu nó có tiếp tục thoả mãn thuộc tính p hay không (tức là, M1||M’2╞ p?) Với tư tưởng này, kỹ thuật được đề xuất chỉ cần kiểm tra liệu M’2 có thỏa mãn giả đinh hiện tại A(p) hay không, trong đó A(p) là một giả định giữa hai thành phần; M1

và M2 sao cho nó đủ mạnh để cho M1 thoả mãn điều kiện p nhưng đủ yếu để nó được thỏa mãn bởi M2 Giả định A(p) được tạo ra bằng việc sử dụng một giải thuật học có tên là L* [1, 24] Trong kỹ thuật này, các thành phần (M1, M2, và M’2), thuộc tính p, và các giả định đều được biểu diễn bởi LTS Nếu M’2 thỏa mãn A(p) thì khi đó hệ thống mới M1||M’2 vẫn thỏa mãn thuộc tính p Ngược lại, một phản ví dụ để minh chứng cho kết quả này Trong trường hợp này, phương pháp này sẽ thực hiện phân tích để xác định xem có phải thuộc tính p bị vi phạm trong hệ thống mới hay là giả định A(p) quá mạnh để M’2 thoả mãn Nếu giả định A(p) là quá mạnh, khi đó một giả định mới

Anew(p) sẽ được tạo lại giữa M1 và thành phần mới M’2 Việc tạo lại giả định này không cần phải chạy lại toàn bộ các phần từ ban đầu, mà sử dụng lại kết quả của quá trình kiểm chứng trước đó (sử dụng lai A(p)) nhằm giảm bớt độ phức tạp cho quá trình tạo lại giả định Chi tiết của giải thuật tham khảo trong [25] Cách tiếp cận này là giải pháp tiềm năng cho việc kiểm chứng hệ thống hướng thành phần trong ngữ cảnh của tiến hóa phần mềm

Như chúng ta đã biết, vấn đề quan trọng và cũng hết sức khó khăn của cách tiếp cận đảm bảo giả định là làm sao để xác định được giả định A Bên cạnh đó, kích thước của giả định cũng đóng vai trò quyết định đến chi phí cho quá trình kiểm chứng hệ thống hướng thành phần Hiện tại có hai giải pháp đã được đề xuất để tạo giả định A thoả mãn các yêu cầu của AGR (Assume-Guarantee Reasoning) Giải pháp thứ nhất, nhằm tìm ra giả định yếu nhất Aw (kích thước lớn nhất) [7] Giải pháp này sẽ gặp khó khăn nếu hệ thống phức tạp với không gian trạng thái quá lớn, quá trình chạy có thể dẫn đến hết không gian bộ nhớ và không thu lại kết quả như mong muốn Như vậy, chúng ta cần phải giảm kích thước của giả định, bên cạnh đó, AGR chỉ có ý nghĩa khi thời gian tính toán của A||M1 << M1||M2 Cách tiếp cần thứ hai [4] tạo ra một giả định

có kích thước nhỏ hơn so với cách thứ nhất bằng cách sử dụng thuật toán học có tên là

L* Thuật toán này gồm nhiều bước lặp, bắt đầu từ giả định rỗng để đạt được giả định thoả mãn yêu cầu của AGR Tại mỗi bước lặp, thuật toán sẽ sinh ra một ứng cử viên cho giả định Sau đó, giải thuật sẽ kiểm tra xem ứng cử viên đó có thoả mãn các yêu cầu của AGR hay không? Nếu thoả mãn, thuật toán sẽ dừng và ứng cử viên đó chính là giả định cần tìm Nếu yêu cầu của AGR không được thoả mãn, quá trình kiểm tra sẽ đưa ra một phản ví dụ giúp cho thuật toán sẽ xác định các ứng cử viên tiếp theo tốt hơn Quá trình trên sẽ được lặp đi lặp lại cho đến khi tìm được giả định hoặc chỉ ra một phản ví dụ chứng tỏ hệ thống không thỏa mãn thuộc tính p Tuy nhiên, giả định (nếu có) được đưa ra bởi cách tiếp cận này chưa phải là giả định tối thiểu, minh chứng cho điều này sẽ được trình bày chi tiết qua một phản ví dụ trong chương 3 Trong phương pháp này, các giả định (assumptions) (có vai trò như là môi trường của các thành phần) sẽ được tạo lập Việc tạo lập các giả định chính là bài toán quan trọng nhất trong phương pháp này Kích thước của các giả định này (số lượng trạng thái) nên được cực tiểu hóa bởi vì chi phí cho quá trình kiểm chứng mô hình của phương pháp này phụ thuộc chính vào thông số này Đây chính là mục tiêu nghiên cứu của luận văn này

1.2 Các khái niệm cơ bản

1.2.1 Labeled Transition System(LTS)

Bộ ứng dụng LTSA sử dụng LTSs [9] để mô hình hoá các đặc tính giao tiếp giữa các thành phần trong một hệ thống Trong luận văn chúng tôi cũng sử dụng LTS

để thể hiện các đặc tính của các thành phần của hệ thống và thuộc tính Một LTS được xem như là một đồ thị định hướng với các cạnh được gán nhãn Thêm vào đó, tập trạng thái, các phép biến đổi và tập các nhãn được kết hợp với nhau tạo nên một hệ thống Đặt Act là tập các hành động có thể kiểm soát được, và τ là một hành động cục

bộ nào đó khó kiểm soát trong môi trường của thành phần Chúng ta sử dụng π để ký hiệu một trạng thái lỗi cụ thể, để thể hiện sự vi phạm trong hệ thống ghép nối

Một LTS M là mộ bộ bốn

0 , , ,

QM  q , trong đó:

 Q là một tập các trạng thái không rỗng

αM  Act là tập các hành động có thể kiểm soát được gọi là bảng chữ cái của M

 q 0 Q là trạng thái ban đầu

   Q M  Q là hàm chuyển

Chúng ta sử dụng  để ký hiệu cho LTS { },Act, , p Æp Một LTS

M=

0 , , ,

QM  q đƣợc gọi là LTS không đơn định nếu nó có phép biến đổi τ hoặc tồn tại (q, a, q’

), (q, a, q’’)  δ trong đó q’ ≠ q’’ Ngƣợc lại M đƣợc gọi là đơn định (deterministic)

Giả sử có hai LTS:

0 , , ,

M  Q M  q và ' ' ' ' '

0

M  Q M  q Chúng ta nói LTS M biến đổi thành M’ qua hành động a, ký hiệu a '

M M nếu và chỉ nếu (q0, a,

q’0)  δ và αM = αM’ và δ = δ’ Hình 2.1 biểu diễn đồ thị cho hai LTS CLIENT và SERVER

Hình 1.1: Ví dụ về LTS 1.2.2 Dẫn xuất(Traces)

Một dẫn xuất [2, 4] t của một LTS M là một chuỗi các hành động có thể kiểm soát đƣợc, hay nói một cách khác nó là chuỗi các hành động để thu đƣợc M xuất phát

từ một trạng thái ban đầu Giả sử Σ  Act, ký hiệu t↑Σ ký hiệu một dẫn xuất thu đƣợc bằng cách loại bỏ khỏi t tất cả các hành động a mà a  Σ Tập tất cả các dẫn xuất của

M đƣợc gọi là ngôn ngữ đoán nhận M, ký hiệu L(M)

Hình 1.1 đưa ra biểu diễn đồ hoạ của hai LTS: CLIENT và SERVER Trạng thái ban đầu của LTS CLIENT trong ví dụ là trạng thái 0, còn của LTS SERVER là trạng thái a LTS CLIENT thực hiện một yêu cầu cần xử lý khi hành động request xảy

ra, khi đó nó sẽ thực hiện yêu cầu LTS SERVER để thực hiện yêu cầu bằng hành động Call Sau khi yêu cầu được gửi lên LTS SERVER, server sẽ xử lý và đưa ra ra kết quả bằng việc sử dụng hành động Service, sau đó thực hiện trả lại kết quả và kết thúc bởi hành động reply Tại thời điểm này, cả hai LTS cùng trả lại trạng thái ban đầu của nó,

và một tiến trình mới lại có thể được lặp lại Trong minh hoạ này, <call>, <call, service>, <call, service, reply> là các dẫn xuất của LTS SERVER

1.2.3 Ghép nối song song(Parallel Composition)

Ghép nối song song || [9] là thao tác thực hiện hai hành động thay thế và kết hợp trong đó, việc kết hợp các đặc tính của hai thành phần bằng cách đồng bộ hoá các hành động chung tương ứng với bảng chữ cái, và chèn thêm các hành động còn lại

call: do call  Input, và call  Output, nên ta có ((0,a), call ,(1, b))

Kết hợp các hành động và các cặp trạng thái, ta thu đƣợc kết quả nhƣ sau:

Hình 1.2: Minh hoạ phép ghép nối song song

Bằng việc loại bỏ tất cả các trạng thái không thể tới khi xuất phát từ trạng thái ban đầu (0, a) và tất cả các biến đổi đến các trạng thái này, ta sẽ thu đƣợc kết quả của phép ghép nối song song CLIENT || SERVER:

Hình 1.3: Phép ghép nối CLIENT || SERVER

1.2.3 Safety LTSs, Safety Property, error LTS

Một Safety LTS là một LTS hữu hạn không chứa bất kỳ một trạng thái lỗi π nào Một thuộc tính an toàn(Safety Property) đƣợc xác định nhƣ là một LTS an toàn p trong đó ngôn ngữ L(p) xác định tập tất cả các thuộc tính chấp nhận đƣợc Một error LTS, ký hiệu perr phát sinh trong quá trình kiểm thử LTS M thoả mãn thuộc tính p Về

cơ bản, error LTS của một thuộc tính p Q, p, ,q0 là   '

err , err, , 0

p  Q  p  q , trong đó αperr = αp và '  

vi phạm thuộc tính p Ngược lại, M thoả mãn thuộc tính p

1.2.5 Ôtomat đơn định hữu hạn trạng thái (Deterministic Finite State Automata)

Cách tiếp cận trong luận văn này sử dụng thuật toán học L* [1, 24] để tạo giả định từ hai thành phần Toàn bộ quá trình tạo giả định sẽ được trình bày trong chương

3 Trong quá trình này, tại bước lặp thứ i, bộ huấn luyện đưa ra một Deterministic Finite State Automata (DFA) Mi là tối thiểu và duy nhất và L(Mi) = L(AW), trong đó

AW là giả định yếu nhất khi F thoả mãn thuộc tính p [7] DFA Mi sau đó sẽ được biến đổi thành giả định ứng cử viên Ai, trong đó Ai được thể hiện như là một LTS an toàn Deterministic Finite State Automata được định nghĩa như sau:

Otomat hữu hạn có thể xem như “máy trừu tượng” để đoán nhận ngôn ngữ Otomat hữu hạn là bộ M = <Q, αM, δ, qo, F>, trong đó:

 Q, αM, δ, qo được định nghĩa như trong định nghĩa của các LTS hữu hạn

 F  Q là tập các trạng thái kết thúc

Cho một DFA M và một chuỗi σ, ký hiệu δ(q, σ) là trạng thái kết quả sau khi M đọc chuỗi σ bắt đầu tại trạng thái q Ta nói DFA M đoán nhận chuỗi σ hay chuỗi σ

được đoán nhận bởi Otomat hữu hạn M nếu δ(q0, σ)  F Tập L(M) = {σ | δ(q0, σ) 

F} được gọi là ngôn ngữ được đoán nhận bởi Otomat M

Cho một DFA M, chúng ta cũng dễ dàng thu được một LTS an toàn A từ M bằng cách loại bỏ tất cả các trạng thái không phải là trạng thái kết thúc và các biến đổi liên quan đến trạng thái này bên trong M Hình 1.4 mô tả một ví dụ để biến đổi một DFA thành một LTS an toàn:

Hình 1.4: Minh hoạ tạo LTS an toàn từ một DFA

1.3 Về vần đề đảm bảo giả định

Xác minh đảm bảo giả định các phần mềm hướng thành phần là một cách tiếp cận được đưa ra bởi D.Giannakopoulou [2, 4, 7, 8] Cách tiếp cận này dựa trên tư tưởng của kiểm chứng mô hình giả định Nó đưa ra một cách tiếp cận đầy hứa hẹn để giải quyết vấn đề xác minh đối với những hệ thống lớn Cách tiếp cận này dựa trên tư tưởng của chiến lược “Chia để trị”, thuộc tính của hệ thống được biến đổi thành các thuộc tính của các thành phần sau đó thay vì kiểm tra trên toàn hệ thống chúng ta sẽ chỉ cần kiểm tra độc lập trên từng thành phần

Xét một hệ thống đơn giản gồm hai thành phần độc lập M1 và M2 Bài toán quan trọng, cũng là xuyên suốt quá trình nghiên cứu của chúng ta là cần xác minh xem, một hệ thống M1||M2 có thoả mãn một thuộc tính p nào đó hay không? Nếu chúng ta xác minh trên toàn bộ hệ thống M1 || M2, giải pháp này sẽ dẫn tới vấn đề

“bùng nổ không gian trạng thái” Đảm bảo giả định nhằm đưa ra giải pháp nhằm kiểm tra hệ thống M1 || M2 có thoả thuộc tính p hay không mà không cần thực hiện phép ghép nối song song giữa M1 và M2

Đảm bảo giả định sử dụng tư tưởng của chiến lược “Chia để trị”, phân chia bài toán kiểm chứng thành các bài toán con cùng dạng nhưng kích thước nhỏ hơn Nếu M1 thoả mãn p với một điều kiện nào đó, và M2 cũng thoả mãn điều kiện đó, khi đó hệ thống M gồm M1 và M2 cũng thoả mãn điều kiện p Điều kiện ở đây được thể hiện bởi các giả định (Assumption) Như vậy để kiểm chứng hệ thống sử dụng phương pháp này, đòi hỏi chúng ta phải xác định được giả định, bài toán này chúng ta sẽ xem xét sau Ở đây chúng ta giả thiết có một giả định A đã được xác định và thuật toán trên của chúng ta đã được chứng minh là đúng đắn Giả định A được đưa ra, yêu cầu phải

trừu tượng hơn M2 nhưng vẫn thể hiện được các đặc tính của M2 Hơn nữa, giả định phải đủ mạnh để M1 thoả mãn p (Hình 1.5 minh hoạ tổng quan về mục tiêu và giải pháp cho cách tiếp cận xác minh đảm bảo giả định) Như vậy, bài toán kiểm chứng hệ thống M = M1|| M2 có thoả mãn thuộc tính p hay không? Ta đã đưa được về việc giải quyết hai bài toán con:

 A M P1

 true M2 A

Để kiểm chứng công thức A M P1 ta thực hiện phép ghép nối song song A||M1||perr Trong đó, A, M1, p, perr được biểu diễn bởi các LTS Nếu không có dẫn xuất để trạng thái lỗi xảy ra trong A||M1||perr thì công thức A M P1 thỏa mãn Hay nói cách khác là A||M1 thỏa p Ngược lại, A||M1 không thỏa p

Với công thức true M2 A , kiểm tra xem M2 có thoả mãn thuộc tính A hay không với bất kỳ điều kiện gì của môi trường Để kiểm chứng công thức này ta chỉ cần thực hiện phép ghép nối M2||A, nếu LTS kết quả không tồn tại một dẫn xuất nào dẫn tới trạng thái lỗi khi đó M2 thoả A, ngược lại M2 không thoả A

Hình 1.5: Bài toán và tư tưởng chính của cách tiếp cận xác minh đảm bảo giả

định

Từ giải pháp trên, vấn đề chính trong cách tiếp cận này là làm thế nào để tìm ra giả định A Hiện tại, có hai phương pháp tạo giả định A một cách tự động như sau:

1 Phương pháp thứ nhất được đưa ra [7] Cho trước thành phần M1, thuộc tính

p và phần giao diện của M1 với môi trường của nó, tạo giả định môi trường yếu nhất

AW sao cho M1 ╞ p Giả định yếu nhất AW tức là nó ràng buộc môi trường không nhiều hơn cũng không ít hơn những gì nó cần, cụ thể như sau: với mọi môi trường E khi đó E || M1 ╞ p khi và chỉ khi E ╞ AW Giả định yếu nhất AW chứa tất cả các dẫn xuất trên bảng chữ cái (M1p)M2 không chứa trạng thái lỗi trong hệ thống

M1||p Trong trường hợp này, M2 là không biết và được xem như là môi trường của

M1

2 Phương pháp thứ hai được đưa ra trong [2, 4, 8] Kỹ thuật này sử dụng thuật toán học L* để thực hiện tạo giả định A đảm bảo rằng A là đủ yếu để được thoả mãn bởi M2 và đủ mạnh để để M1 thoả mãn thuộc tính p Giả định A được tạo ra bởi phương pháp này là mạnh hơn so với giả định yếu nhất AW

CHƯƠNG 2: TẠO GIẢ ĐỊNH SỬ DỤNG THUẬT TOÁN HỌC

L*

Chương 1 đã trình bày một cách tổng quan cách tiếp cận đưa ra nhằm xác minh phần mềm hướng thành phần Một bài toán quan trọng trong kỹ thuật này là làm thế nào để tạo ra được một giả định Chương này sẽ giới thiệu một cách để tạo ra một giả định giữa hai thành phần M1 và M2 Thông tin chi tiết về thuật toán học L* cũng được trình bày trong chương này

2.1 Thuật toán học L *

Giả sử có một tập ký tự ∑ cho trước Với mỗi ngôn ngữ chính quy U có bảng chữ cái là tập con của ∑* Chúng ta cần tìm một Otomat đơn định tối thiểu hữu hạn trạng thái(DFA- Deterministic Finite state Automata) M đoán nhận ngôn ngữ U, tức là L(M) = U

Tư tưởng chính của giải thuật này dựa trên định lý: “Myhill – Nerode Theorem”[13]: Giả sử có một tập ký tự ∑ Với mỗi ngôn ngữ chính quy U, có bảng chữ cái là tập con của ∑* cho trước, khi đó tồn tại duy nhất một DFA đoán nhận nó

Giải thuật học L* được phát triển bởi [1] và sau đó được cải tiến bởi Rivest và Schapire [24] Trong luận văn này, chúng tôi sẽ trình bày giải thuật đã được cải tiến với cùng tên L* Dựa trên tư tưởng học, giải thuật L* sẽ thực hiện xây dựng dần dần từng bước nghiệm của bài toán Để huấn luyện U, L* cần thiết phải kết hợp với Minimally Adequate Teacher, từ bây giờ chúng ta sẽ gọi là Teacher (người huấn luyện) Teacher sẽ phải trả lời chính xác hai loại câu hỏi từ L*:

 Kiểm tra thành viên(Membership query), với một chuỗi *, câu trả lời là true nếu U và false nếu ngược lại

 Loại câu hỏi thứ hai: kiểm tra sự phỏng đoán Với mỗi ứng cử viên DFA

M, khi đó, ngôn ngữ của nó có đồng nhất với U hay không? Tức là L(M) = U? Câu trả lời là true nếu L(M) = U, ngược lại, Teacher sẽ đưa ra một phản ví dụ

để minh chứng cho sự khác nhau giữa L(M) và U

Mối liên hệ giữa bộ huấn luyện L* và nhà huấn luyện Teacher được minh hoạ như hình sau:

Hình 2.1: Minh hoạ mối quan hệ giữa Teacher và L* learner

Chi tiết hơn, L* sử dụng một bảng T để ghi lại kết quả kiểm tra một chuỗi

*

s có thuộc vào U hay không? Bảng quan sát T được cập nhật mỗi khi có sự thay đổi bởi các thao tác kiểm tra thành viên Ôtomat hữu hạn Mi được xây dựng dựa trên bảng T, và khi đó với mỗi Mi, các nhà huấn luyện sẽ quyết định xem sự phỏng đoán đó

có đúng hay không? Nếu phỏng đoán là chính xác, thuật toán sẽ dừng ở đây, ngược lại,

L* sử dụng phản ví dụ mà nhà huấn luyện trả lại để cập nhật lại bảng T

Giải thuật L* xây dựng một bảng quan sát (S, E, T), trong đó:

S  là tập tiền tố Nó thể hiện các lớp tương đương hay các trạng thái

E  là tập hậu tố Nó thể hiện sự khác nhau giữa U và L(Mi)

 T:S S.   true false, , trong đó toán tử “.” thực hiện ghép nối hai xâu được định nghĩa như sau: P Q pq p| P q, Q Như vậy, bảng T được

sử dụng để kiểm tra xem với mỗi chuỗi *

s , s có thuộc vào tập U hay không Tức là, T(s) = true nếu s U , ngược T(s) = false nếu s U

Bảng quan sát (S, E, T) được gọi là đóng nếu:

" Î " Î S $ Î " Î = Trong trường hợp này, s’ là trạng thái tiếp theo từ trạng thái s sau khi đi qua a Bảng quan sát (S, E, T) là đóng, khi đó mỗi hàng sa trong S.∑ sẽ tương ứng với một hàng s’ trong S

Giải thuật L*

được trình bày chi tiết từng bước như trong hình 2.2:

Hình 2.2: Giải thuật L*

Đầu tiên, giải thuật L* khởi gán các tập S và E là chuỗi rỗng {λ}(dòng 1) Tiếp theo, giải thuật thực hiện cập nhật bảng quan sát (S, E, T) bằng cách thực hiện các thao tác kiểm tra thành viên để có sự liên kết giữa các chuỗi trong tập S S. .E(dòng 2) Giải thuật sẽ kiểm tra xem bảng quan sát có đóng hay không Nếu bảng quan sát là không đóng, khi đó sa đƣợc thêm vào tập S, trong đó s  S và a  ∑ là các hàng mà không tồn tại s’  S sao cho T(sae) = T(s’e)(dòng 3) Vì sa đƣợc thêm vào tập S, khi

đó bảng T phải đƣợc cập nhật lại sử dụng các hành động kiểm tra thành viên(dòng 4) Dòng 3 và dòng 4 đƣợc lặp đi lặp lại cho đến khi bảng quan sát (S, E, T) là bảng đóng

Khi bảng quan sát (S, E, T) là bảng đóng, L*

xác định một DFA M = <Q, αM,

δ, q0, F> (dòng 5), trong đó:

 Q = S,

 αM = ∑, trong đó ∑ là bảng chữ cái của ngôn ngữ U,

 Biến đổi δ đƣợc định nghĩa nhƣ sau: δ(s, a) = s’ và " e  E: T(sae) = T(s’e),

 Trạng thái ban đầu q0 = λ,

 F = {s  S | T(s) = true}

Một ứng cử viên DFA M đƣợc đƣa ra cho nhà huấn luyện (dòng 6) Nếu Teacher trả lại kết quả true (tức là, L(M) = U), L* trả lại M là chính xác (dòng 7),

ngược lại nó sẽ nhận được một phản ví dụ c  ∑* Phản ví dụ c được phân tích để tìm

ra một hậu tố e của c để minh chứng cho sự khác nhau giữa L(M) và U Sau đó, e phải được thêm vào tập E (dòng 8) Sau khi e được thêm E, giải thuật L* sẽ lặp lại toàn bộ quá trình bằng cách quay lại dòng 2

Mỗi ứng cử viên DFA Mi được đưa ra bởi giải thuật L* là nhỏ nhất Nó có nghĩa là, với mỗi DFA bước i +1 tiếp theo luôn có số trạng thái luôn nhiều hơn hoặc ít nhất cũng bằng với số trạng thái của Mi Giả sử M1, M2, ., Mn là các ứng cử viên được đưa ra bởi giải thuật L* theo từng bước, dễ dàng kiểm tra được rằng |M1| ≤ |M2|

≤ ≤ |Mn|, trong đó |Mi| kí hiệu cho số trạng thái của DFA Mi Giả sử M là giả định cuối cùng sau khi kết thúc giải thuật Giải thuật L* tạo ra các ứng cử viên DFA có kích thước tăng dần, mỗi DFA ở bước này luôn nhỏ hơn DFA ở bước tiếp theo, và tất cả các DFA không chính xác luôn có kích thước nhỏ hơn M Vì vậy, nếu M có n trạng thái, khi đó sẽ có nhiều nhất n -1 DFA không chính xác Do đó, số lần thực hiện kiểm tra thành viên được thực hiện bởi L* là O(kn2 + nlogm), trong đó k là kích thước của bảng chữ cái của U, n là số trạng thái của DFA tối thiểu đoán nhận ngôn ngữ U, m là chiều dài của phản ví dụ dài nhất

2.2 Tạo giả định sử dụng thuật toán học L *

Xét hệ thống gồm 2 thành phần C1, C2, và một thuộc tính p Nhiệm vụ của chúng ta cần phải xác định công thức sau: C1 || C2 ╞ p có được thoả mãn hay không

mà không cần thực hiện phép ghép nối C1 || C2 Để thực hiện được điều này, giải thuật đưa ra yêu cầu tạo một giả định A(p) đủ mạnh để C1 thoả mãn p nhưng đủ yếu để vẫn được đảm bảo bởi C2 Tức là cả hai biểu thức sau được thoả mãn:

 A p C p( ) 1 ,

 true C2 A p( )

Hiện tại có hai giải pháp để giải quyết bài toán này:

 Thứ nhất, thuật toán (non-incremental): Nhằm tìm ra một giả định yếu nhất Aw với bảng chữ cái  C1 pC2 Khi đó ta luôn có ' '

 Như vậy chúng ta sẽ tìm một giả định mạnh hơn giải định Aw

 Thứ hai, tạo giả định sử dụng giải thuật L* Cách tiếp cận incremental,

dựa trên các phản ví dụ và quá trình huấn luyện Thay vì đi tìm Aw, ta sử dụng

L* để huấn luyện Aw

Trong luận văn này chúng tôi sẽ trình bày giải pháp thứ hai Để thu được các giả định thích hợp, giải thuật áp dụng luật lệ ghép nối vào một thuật toán lặp được minh hoạ trong hình 2.3

Hình 2.3: Một sơ đồ khối để tạo giả định sử dụng giải thuật L* [4, 8]

Tại mỗi vòng lặp, mỗi giả định được kiểm tra Ai sẽ được xử lý dựa trên những thông tin về môi trường và kết quả của bước lặp trước Đầu tiên chúng ta sẽ tìm hiểu giải thuật học L* xác định Ai như thế nào? Giải thuật tạo giả định sử dụng tư tưởng của thuật toán học L*, huấn luyện giả định yếu nhất AW Điều này cũng có nghĩa là, L* huấn luyện ngôn ngữ chính quy U = L(AW) có bảng chữ cái  C pC

1 || C2

Real Error? p violated

Counterexample – weaken assumption

False cexL(Ai)

Ai

Y

N

Cex || C1 |≠ p?

Để đưa ra mỗi ứng cử viên giả định Ai, đầu tiên giải thuật L* xác định một DFA Midựa trên bảng quan sát (S, E, T), sau đó dựa vào định nghĩa 2.4 biến đổi DFA Mi thành một LTS an toàn Ai Để huấn luyện được AW, giải thuật L* sử dụng một người huấn luyện Teacher để trả lời hai câu hỏi:

Đầu tiên, xác nhận thành viên, với một chuỗi *, câu trả lời là true nếu

an toàn Ai Khi đó, LTS Ai được xem như một ứng cử viên đầu vào cho giải thuật trong hình 2.3 Nhiệm vụ tiếp theo của giải thuật cần phải xác định xem, Ai có phải là giả định cần tìm hay không? Tức là cần phải kiểm tra xem Ai có thoả mãn các điều kiện của AGR hay không? Teacher sẽ phải thực hiện hai bước: luật ghép nối và phân tích phản ví dụ để trả lời câu hỏi trên như sau:

 Bước 1: Kiểm tra công thức sau A C p i 1 bằng cách xây dựng hệ thống ghép nối Ai || C1 || perr Nếu trạng thái lỗi π xuất hiện trong hệ thống ghép nối, khi đó biểu thức trên là sai, tức là giả định Ai là quá yếu để C1 thoả mãn p Vì vậy, giả định Ai sẽ phải được làm mạnh hơn (loại bỏ một vài đặc tính của Ai) cùng với đó giải thuật sẽ trả lại một phản ví dụ cex (CounterExample) Dựa trên phản ví dụ này giúp chúng ta đưa ra giả định Ai+1 tại bước tiếp theo tốt hơn Nếu kết quả là true, tức là giả định Ai đủ mạnh để C1 thoả mãn p Giải thuật sẽ chuyển sang bước 2

 Bước 2: Kiểm tra công thức: true C2 A i : Nếu kết quả là true, khi đó C1

|| C2 ╞ p  giải thuật kết thúc Nếu kết quả là false, Teacher sẽ đưa ra một phản ví dụ cex Tuy nhiên, đến thời điểm này, chúng ta chưa thể khẳng định hệ thống C1 || C2 không thoả mãn thuộc tính, vì có thể giả định Ai quá mạnh để C2thoả mãn Như vậy, Teacher phải phân tích để xác định xem có phải hệ thống

C1 || C2 không thoả mãn thuộc tính p hay là giả định Ai quá mạnh để C2 thoả mãn

 Phân tích phản ví dụ: Để thực hiện nhiệm vụ này, Teacher sẽ sử dụng phản ví dụ cex được trả lại tại bước 2 Khi đó, nó sẽ phải kiểm tra xem

W

ex (A )

c L ? Đầu tiên, Teacher xây dựng một LTS an toàn A cextừ phản ví dụ cex Sau đó, Teacher kiểm tra biểu thức A cex C p1 bằng cách xây dựng hệ thống ghép nối A cex|| C1 || perr Nếu trạng thái lỗi π xuất hiện trong hệ thống ghép nối, tức là hệ thống A cex|| C1 không thoả mãn thuộc tính p, nó cũng có nghĩa là hệ thống C1 || C2 cũng ko thoả mãn thuộc tính p Ngược lại, trạng thái lỗi π không xuất hiện trong hệ thống ghép nối, tức là biểu thức trên là đúng, khi

đó ta khẳng định giả định Ai là quá mạnh để C1 thoả mãn trong ngữ cảnh của cex Và sau đó, giả định Ai sẽ được làm yếu bớt đi

CHƯƠNG 3: GIẢI THUẬT TẠO GIẢ ĐỊNH TỐI THIỂU

3.1 Giới thiệu

Xét một hệ thống đơn giản gồm hai thành phần độc lập M1 và M2 Bài toán của chúng ta là cần xác minh xem hệ thống ghép nối song song M1||M2 có thoả mãn thuộc tính p cho trước hay không? Nếu chúng ta giải quyết bài toán toàn bộ hệ thống M1 ||

M2, giải pháp này sẽ dẫn tới vấn đề “bùng nổ không gian trạng thái” Đảm bảo giả định nhằm đưa ra giải pháp để kiểm tra hệ thống M1 || M2 có thoả thuộc tính p hay không mà không cần thực hiện phép ghép nối song song giữa M1 và M2 Tuy nhiên, để xác minh hệ thống sử dụng phương pháp đảm bảo giả định, đòi hỏi chúng ta phải xác định được giả định A Mặt khác, không phải giả định nào cũng có thể chấp nhận được Chúng ta cần phải xác định được giả định tối thiểu, vì kích thước của giả định A là rất quan trọng:

 Kiểm chứng hệ thống được thực hiện bởi kiểm tra mô hình thông qua các thao tác ghép nối các thành phần trong đó giả định được xem như một thành phần của hệ thống Chi phí của quá trình ghép nối bị ảnh hưởng bởi kích thước của giả định Vì vậy, chi phí cho việc xác minh sẽ giảm đi nếu có một giả định nhỏ hơn

 Khi một thành phần của hệ thống được phát triển sau một khi thực hiện một vài biến đổi trong ngữ cảnh tiến hoá phần mềm, khi đó toàn bộ phần mềm gồm cả những thành phần cũ và các thành phần mới cần được kiểm tra lại[26] Trong trường hợp này, chúng ta cần phải giảm chi phí kiểm tra lại hệ thống mới bằng cách sử dụng một giả định có kích thước nhỏ hơn

 Một giả định có kích thước nhỏ hơn khi đó độ phức tạp về mối quan hệ giữa các thuộc tính là ít đi do đó sẽ giúp chúng ta dễ dàng hơn để hiểu, tránh nhầm lẫn

3.2 Định nghĩa giả định tối thiểu

Cho hai mô hình thành phần M1, M2 và một thuộc tính p, A(p) là một giả định nếu và chỉ nếu A(p) thoả các luật ghép nối Một giả định A(p) được biểu diễn bởi một LTS là cực tiểu nếu và chỉ nếu số lượng các trạng thái của A(p) là nhỏ hơn hoặc bằng với số lượng trạng thái của bất kỳ giả định nào khác

Xác minh đảm bảo giả định được đưa ra trong [Rivest&Schapire’1993] là một phương pháp hiệu quả cho việc xác minh phần mềm hướng thành phần, được thực hiện bằng cách tách nhiệm vụ xác minh một phần mềm hướng thành phần thành các công việc nhỏ hơn trên các thành phần độc lập Trong phương pháp này, giả định được xem như là môi trường của các thành phần Tuy nhiên, giải thuật này chưa đưa ra cho chúng ta một giả định tối thiểu Chúng ta sẽ xét một ví dụ cụ thể để minh chứng cho điều này Xét hệ thống gồm các thành phần sau:

Hình 3.1: Các thành phần của hệ thống trong ví dụ được xét

Áp dụng giải thuật L* tại chương 4 ta sẽ thu được giả định A như sau:

Hình 3.2: Giả định được tạo ra sau khi sử dụng giải thuật L*

Tuy nhiên, tồn tại một giả định A’ như sau:

Hình 3.3: Giả định được tạo ra bởi giải thuật tạo giả định tối thiểu

Dễ dàng kiểm tra được các biểu thức sau là đúng:

 <A’> Input <Order>

 <true> Output <A’>

Mặt khác, ta có |A’| = 2 < 4 = |A| Như vậy, giả định được tạo ra bởi giải thuật L* chưa phải là giả định tối thiểu Theo lý thuyết của nhóm NASA, giải thuật L* thực hiện huấn luyện và sẽ đưa ra Otomat tối thiểu Vậy, nguyên nhân nào làm cho giải thuật L* không cho chúng ta giả định tối thiểu

Giải thuật L* sử dụng một phương pháp thực hiện học ngôn ngữ của giả định yếu nhất AW với bảng chữ cái  (M1p)M2 và đưa ra một DFA chấp nhận

nó Để học được ngôn ngữ này, giải thuật L* xây dựng một bảng quan sát (S, E, T) trong đó S và E tương ứng là tập tiền tố và hậu tố T là một hàm thực hiện ánh xạ tập (S S ).E sang tập {true, false}, trong đó toán tử “.” được định nghĩa như sau: Cho hai tập các chuỗi hành động P và Q, khi đó P Q {pq| pP q, Q}, trong đó pq thể hiện sự ghép nối của hai chuỗi hành động p và q Kỹ thuật này thực hiện trả lời câu hỏi kiểm tra thành viên như sau: với mỗi chuỗi s  (S S ).E, T(s) = true nếu s L(AW)

và bằng false nếu ngược lại.Trong phản ví dụ trên, ta nhận thấy nếu s L(AW) nhưng s

L(A(p)), khi đó T(s) được gán giá trị true (trong trường hợp này, T(s) nên là giá trị false) Vì lý do này, giả định A(p) được tạo ra bởi giải thuật đưa ra trong [1] chứa một

số chuỗi/dẫn xuất mà không thuộc vào ngôn ngữ của giả định được huấn luyện Do đó, A(p) không phải là giả định tối thiểu

Trong chương này, chúng tôi đã đề xuất phương pháp tạo giả định tối thiểu cho việc xác minh đảm bảo giả định của các phần mềm hướng thành phần Chúng tôi cũng định nghĩa một kỹ thuật mới để trả lời câu hỏi kiểm tra thành viên nhằm khắc phục vấn đề gặp phải của giải thuật tạo giả định sử dụng thuật toán học L* Giả định tối thiểu được tạo ra bằng cách kết hợp giải thuật học L* và tư tưởng tìm kiếm trên cây tìm kiếm theo chiều rộng

3.3 Giải thuật tạo giả định tối thiểu

3.3.1 Tư tưởng của giải thuật

Xuất phát từ tư tưởng của giải thuật L* được đưa ra trong[1], thực hiện huấn luyện dần dần tập trạng thái của giả định cần tìm Tuy nhiên, chúng ta sẽ cải tiến cách

trả lời câu hỏi kiểm tra thành viên đã được đưa ra trong giải thuật đó Như đã đề cập ở trên, để học ngôn ngữ của giả định, giải thuật học L* sử dụng trong [1] đã xây dựng một bảng quan sát (S, E, T) trong đó T là một hàm thực hiện ánh xạ tập (S S ).E

sang tập {true, false} Với mỗi chuỗi s  (S S ).E, T(s) = true nếu s L(AW) và bằng false nếu ngược lại Trong trường hợp s L(AW), chúng ta không chắc chắn được rằng s có nằm trong giả định được huấn luyện hay không (tức là, s L(A(p))?) Nếu s

L(A(p)) khi đó T(s) phải nhận giá trị false Tuy nhiên, giải thuật trong [1] đặt T(s) là true trong trường hợp này Vì lý do này, giả định được tạo ra của giải thuật trong [1] không phải là giả định tối thiểu Để giải quyết được hạn chế này, chúng tôi sử dụng một giá trị mới gọi là “?” để gán cho giá trị của T(s) trong trường hợp trên Chúng tôi định nghĩa một kỹ thuật cải tiến để trả lời câu hỏi kiểm tra thành viên như sau Để tạo một giả định tối thiểu, giải thuật học L* cải tiến sẽ xây dựng một bảng quan sát (S, E, T), trong đó S và E tương ứng là tập tiền tố và hậu tố T là một hàm thực hiện ánh xạ tập (S S ).E sang tập {true, false, “?”}, trong đó “?” có thể được xem như là một giá trị “chưa xác định rõ” Giá trị “chưa xác định rõ” có nghĩa là với mỗi chuỗi

s  S S E, thậm chí s L(AW), chúng ta không biết s có nằm trong giả định được huấn luyện hay không Chúng có thể nhận giá trị true hoặc false Nếu nhận giá trị là true, tức là nó sẽ thuộc vào L(A(p)) còn nhận giá trị là false, tức là nó không thuộc vào L(A(p)) Câu trả lời cho câu hỏi kiểm tra thành viên được cải tiến như sau:

 Một chuỗi s = a1, a2, , an  (S S ).E

 Nếu s = λ (chuỗi rỗng), khi đó T(s) = true

 Nếu s  L(AW), thì T(s) = false

 Ngược lại, T(s) = “?”

3.3.2 Chi tiết giải thuật tạo giả định tối thiểu

Dựa trên tư tưởng của giải thuật, ta có thể xem quá trình tìm kiếm một giả định

có kích thước nhỏ nhất thoả mãn luật ghép nối như là một bài toán tìm kiếm trong một không gian của các bảng quan sát Chúng ta sử dụng chiến lược duyệt theo chiều rộng bởi vì chiến lược này đảm bảo chắc chắn rằng giả định được tạo ra là giả định tối thiểu (mục 3.4) Chi tiết của giải thuật tạo giả định tối thiểu được minh hoạ dưới dạng giả

mã trong hình (Hình 3.4) Trong thủ tục này chúng tôi sử dụng một cấu trúc dữ liệu hàng đợi để chứa các bảng quan sát được tạo ra Những bảng quan sát này được sử