Chúng ta sẽ xây dựng bảng quan sát (S, E, T). Đầu tiên, L* đặt tập S và E là {λ}, khi đó ta có bảng quan sát như sau:
Bảng 4.1: Bảng quan sát ban đầu E E T λ S λ S.∑ ack out send
Tiếp theo, chúng ta phải cập nhật bảng quan sát ban đầu bằng cách trả lời các câu hỏi sau:
λ L(AW)? <ack> L(AW)? <out> L(AW)? <send> L(AW)?
Để trả lời các câu hỏi trên, chúng ta sẽ thực hiện minh hoạ các chuỗi đó trên hệ thống ghép nối Input || Ordererr.
Dễ dàng ta có các kết quả như bảng 4.2: Bảng 4.2: Bảng sau khi cập nhật T1 E T λ S λ true S.∑ ack ? out false send ?
Dấu ? ở đây có nghĩa là, chúng ta chưa xác định được các chuỗi <ack>, <send> có thuộc vào giả thiết tối thiểu Am mình cần tìm hay không. Nó có thể nhận giá trị là true hoặc false. Như vậy, từ bảng T1 ta có thể nhận được 4 bảng khác nhau được thể hiện làn lượt như các bảng T1.1, T1.2, T1.3, T1.4.
Bảng 4.3: Bảng T1.1 S T λ λ true S.∑ ack true out false send true Bảng 4.4: Bảng T1.1 S T λ λ true S.∑ ack true out false send false Bảng 4.5: Bảng T1.2 S T λ λ true S.∑ ack false out false send true Bảng 4.6: Bảng T1.3 T λ S λ true S.∑ ack false out false send false
Giải thuật thực hiện đưa lần lượt các bảng T1.1, T1.2, T1.3, T1.4 vào ngăn xếp s. Như vậy, sau bước này ngăn xếp chứa các phần tử T1.1, T1.2, T1.3, T1.4, với cận dưới giả thiết là A0 gồm một chuỗi rỗng.
Dễ nhận thấy, quan hệ giữa bảng T1 và các bảng T1.1, T1.2, T1.3, T1.4 thể hiện như quan hệ cha con trong mô hình dữ liệu cây tìm kiếm như hình 4.7.
Hình 4.6: Mô hình cây tìm kiếm của các bảng quan sát.
Giải thuật thực hiện duyệt cây tìm kiếm theo chiều sâu lặp, đầu tiên xuất phát từ đỉnh cha bảng T1, tiếp đến duyệt đến các nút con. Tại mỗi nút, nếu bảng quan sát không phải nghiệm của bài toán, giải thuật L* thực hiện cập nhật lại nó và đưa ra các bảng quan sát con, tương ứng sẽ là nút con của nút hiện tại. Quá trình duyệt sẽ kết thúc khi tìm được giả thiết kết quả hoặc duyệt qua tất cả các nút mà không tìm được giả thiết nào thoả mãn.
Trong ví dụ trên, giải thuật duyệt theo các nút con Bảng T1.1, Bảng T1.3, Bảng T1.4 sẽ không cho chúng ta kết quả mong muốn. Giải thuật thực hiện duyệt tại nút con Bảng T1.2:
Trong bảng T1.2 có hàng out, send S.∑ không có hàng nào trong S thoả mãn T(sae) = T(s’e). Như vậy, bảng quan sát T1.2 chưa phải là bảng đóng. Vì vậy ta phải thêm out vào tập S để bảng quan sát T1.2 đóng. Khi đó bảng T1.2 được cập nhật lại thành bảng T1.2.1 như sau: Bảng 4.7: Bảng T1.2.1 E T λ S λ true out false S.∑ ack true out false Bảng T1 Bảng T1.1 Bảng T1.2 Bảng T1.3 Bảng T1.4
out, ack false
out, out false
out, send false
Dễ nhận thấy bảng quan sát T1.2.1 là bảng đóng. DFA M được xây dựng như sau: Q = S = {λ, out}
αM = ∑ = {send, out, ack},
δ(λ, ack) = λ, δ(λ, out) = out, δ(λ, send) = out
δ(out, ack) = out, δ(out, out) = out, δ(out, send) = out. Giả thiết A1.2.1 được tạo ra Hình 4.7.
Hình 4.7: Giả thiết A1.2.1
Bây giờ, Teacher sử dụng LTS A1.2.1 như là một ứng cử viên cho luật ghép nối. Bước 1. Kiểm tra biểu thức <A1.2.1> Input <Order>. Để kiểm tra biểu thức này ta thực hiện xây dựng ghép nối A1.2.1 || Input || Ordererr.
Dễ thấy, trạng thái lỗi π đã xuất hiện trong hệ thống ghép nối A1.2.1 || Input|| Ordererr. Như vậy, biểu thức trên là sai, Teacher sẽ đưa ra một phản ví dụ cex↑∑ = <send>. Từ phản ví dụ cex↑∑ = <send> được đưa ra từ bước này, bộ phân tích L* sẽ xác định một hậu tố e của cex để minh chứng cho sự khác nhau giữa L(A1.2.1) và U = L(Aw). Trong trường hợp này L* phân tích và gán e = send. Thêm send vào trong tập E, và cập nhật lại bảng quan sát (S, E, T) sử dụng thao tác kiểm tra thành viên ta được bảng quan sát như bảng 4.8.
Thay dấu ? trong bảng quan sát 1.2.1 bằng các giá trị true hoặc false ta sẽ được các bảng quan sát tương ứng. Như vậy, từ bảng quan sát T1.2.1 ta có thể thu được 8 bảng quan sát: T1.2.1.1, T1.2.1.3, T1.2.1.3, T1.2.1.4, T1.2.1.5, T1.2.1.6, T1.2.1.7, T1.2.1.8 (Chi tiết các bảng này được trình bày trong phục lục A).
Cây tìm kiếm của chúng ta sẽ được thể hiện như hình 4.10.
Giải thuật tiếp tục duyệt qua tất cả các bảng con của bảng quan sát T1.2.1. Trong ví dụ của chúng ta, nút con khả thi nhất là nút chứa bảng quan sát T1.2.1.1.
Bảng 4.8: Bảng T1.2.1 sau khi cập nhật
Hình 4.8: Cây tìm kiếm sau khi duyệt đến bảng quan sát T1.2.1
Dễ nhận thấy bảng quan sát T1.2.1.1 chưa phải là bảng đóng. Thêm hàng send trong S.∑ vào trong tập S để bảng T1.2.1.1 trở thành bảng đóng. Khi đó, ta có bảng quan sát như Bảng 4.9.
E
T λ send
S
λ true ?
out false false
S.∑
ack true ?
out false false
send false ?
out, ack false false
out, out false false
out, send false false
T 1.2.1.1 T1 T 1.2 T 1.2.1 T 1.1 …….. T 1.3 T 1.4 …….. T 1.2.1.2 T 1.2.1.3 T 1.2.1.4 T 1.2.1.5 T 1.2.1.6 T 1.2.1.7 T 1.2.1.8
Bảng 4.9: Bảng quan sát T1.2.1.1 sau khi thêm send vào S
S
T λ send
λ true true
out false false
send false true
S.∑
ack true true
out false false
send false true
out, ack false false
out, out false false
out, send false false
send, ack false false
send, out ? ?
send, send ? ?
Thay các dấu “?” trong bảng 1.2.1.1 bởi các giá trị true hoặc false ta được 16 bảng con, trong đó bảng quan sát T1.2.1.1.1 là bảng khả thi nhất:
Bảng 4.10: Bảng quan sát T1.2.1.1.1 E E
T λ send
S
λ true true
out false false
send false true
S.∑
ack true true
out false false
send false true
out, ack false false
out, out false false
out, send false false
send, ack false false
send, out true true
Dễ nhận thấy bảng quan sát trên là bảng đóng. Giả thiết A1.2.1.1.1 được tạo ra từ bảng quan sát như sau:
Hình 4.9: Giả thiết kết quả.
Giải thuật L* sử dụng A1.2.1.1.1 như là một ứng cử viên đầu vào cho luật ghép nối.
Bước 1 được áp dụng để kiểm tra biểu thức <A1.2.1.1.1> Input <p> bằng cách tính toán hệ thống ghép nối A1.2.1.1.1 || Input || perr. Dễ dàng kiểm tra được trạng thái lỗi
không xuất hiện trong hệ thống ghép nối này nên Teacher trả ra giá trị true. Điều này có nghĩa là biểu thức <A1.2.1.1.1> Input <p>. Teacher chuyển A1.2.1.1.1 sang bước 2.
Bước 2 được áp dụng bằng cách kiểm tra công thức true Output A1.2.1.1.1. Để
kiểm tra công thức này, Teacher tính toán hệ thống ghép nối Output || A1.2.1.1.1err. Trạng thái lỗi không đạt tới trong hệ thống này, nên Teacher tra ra kết quả true. Điều này có nghĩa CBS Input || Output thỏa mãn thuộc tính p (Input || Output ╞ p). Giải thuật
học L* kết thúc và trả ra giả thiết Am(p) = A1.2.1.1.1.
0 1
ack send
send out
CHƯƠNG 5. THỰC NGHIỆM 5.1. Mô tả công cụ 5.1. Mô tả công cụ
Nhằm đánh giá tính hiệu quả của phương pháp cải tiến, chúng tôi bổ sung thêm công cụ (gọi là công cụ IMAG) vào bộ công cụ AGTool. Trong bộ công cụ này đã cài đặt phương pháp sinh giả thiết đề xuất trong [4] (gọi là công cụ AG) và phương pháp sinh giả thiết tối thiểu trong [9, 10] (gọi là công cụ MAG) bằng ngôn ngữ lập trình hàm Objective Caml (OCaml) [20]. Chi tiết về lập trình hàm và ngôn ngữ lập trình OCaml có thể tìm thấy trong [18,19].
Hình 5.1 thể hiện kiến trúc của công cụ IMAG và một ví dụ minh họa cách sử dụng công cụ này. Dữ liệu đầu vào của công cụ này là hai mô hình M1 và M2, thuộc tính yêu cầu p với M1, M2, p được thể hiện bằng LTSs. Công cụ này trả ra một giả thiết tối thiểu Am thỏa mãn luật ghép nối nếu CBS M1||M2 thỏa mãn p, một phản ví dụ cex nếu M1||M2 không thỏa mãn p, ngược lại trả ra giá trị “Không tìm thấy”. Ví dụ, cung cấp 2 mô hình M1 là LTS Input và M2 là LTS Output, một thuộc tính là LTS p. Công cụ IMAG trả ra một giả thiết tối thiểu là LTS Am như chỉ ra trong hình 5.1
Hình 5.1 Công cụ IMAG và một ví dụ
Để chứng minh tính đúng đắn của công cụ được xây dựng xem giả thiết được sinh ra bởi công cụ này có là giả thiết thực sự bằng cách kiểm tra xem giả thiết A này có thỏa mãn luật ghép nối (tức là kiểm tra xem A M1 p và true M2 A cùng đúng). Để thực hiện công việc này chúng tôi sử dụng công cụ cho việc kiểm chứng các chương trình tương tranh được gọi là LTSA [14] để kiểm tra tính chính xác của giả thiết sinh ra A bằng cách kiểm tra hệ thống ghép nối A||M1||Perr và M2||Aerr trong công cụ LTSA. Nếu các công thức này đúng, chứng tỏ giả thiết sinh ra bởi công cụ chúng
tôi xây dựng là chính xác. Hình 5.2 thể hiện một ví dụ kiểm tra tính chính xác của giả thiết A được sinh bởi công cụ IMAG trên công cụ LTSA.
Hình 5.2 Một ví dụ kiểm tra tính đúng đắn của công cụ IMAG trên LTSA 5.2. Kết quả thực nghiệm 5.2. Kết quả thực nghiệm
Chúng tôi tiến hành thực nghiệm để so sánh kết quả của phương pháp sinh giả thiết tối cải tiến với phương pháp sinh giả thiết tối thiểu đề xuất trong [9, 10] và phương pháp sinh giả thiết trong [4]. Thực nghiệm được tiến hành trên ba hệ thống tương tranh là hệ thống điều khiển bếp ga [21] (gồm 5 phiên bản), hệ thống điều khiển ôtô [14], và hệ thống vào ra [4] (gồm 3 phiên bản). Trong thực nghiệm này, kích thước của giả thiết (|A|), số hàm chuyển trạng thái (|A|), và thời gian của việc sinh giả thiết được đánh giá. Chúng tôi không đánh giá chi phí sử dụng bộ nhớ trong thực nghiệm này bởi vì độ phức tạp bộ nhớ của tìm kiếm theo chiều sâu lặp là thấp hơn rất nhiều so với tìm kiếm theo chiều rộng (được sử dụng trong phương pháp sinh giả thiết tối thiểu). Bảng 1 chỉ ra kết quả thực nghiệm chúng tôi thu được. Trong kết quả này, kích thước của hệ thống là tích kích thước của các thành phần phần mềm và kích thước của LTS lỗi (ký hiệu perr) của thuộc tính yêu cầu cho mỗi hệ thống được kiểm tra với |perr| = |p| + 1 (tức là kích thước của hệ thống bằng |M1| x |M2| x |perr|). Ký hiệu “-” dùng cho trường hợp vượt quá thời gian cho phép sinh giả thiết (hơn một giờ cho việc sinh giả thiết) hoặc là thiếu bộ nhớ cho việc sinh giả thiết.
Kết quả thực nghiệm thu được cho chúng ta thấy rằng phương pháp tìm giả thiết tối thiểu cải tiến cho giả thiết có kích thước như phương pháp tìm giả thiết tối
nữa phương pháp cải tiến còn sinh ra giả thiết tối thiểu với thời gian thấp hơn phương pháp tìm giả thiết tối thiểu trong [9, 10]. Đặc biệt trong một số trường hợp (GOCS ver. 2, GOCS ver. 4, và I/O ver. 3) phương pháp cải thiến sinh ra giả thiết tối thiểu trong khi phương pháp sinh giả thiết tối thiểu là “vượt quá thời gian sinh giả thiết” hoặc “thiếu bộ nhớ cho việc sinh giả thiết”. Điều này cho thấy phương pháp cải tiến có
Bảng 5.1: Kết quả thực nghiệm
Hệ thống KTHT |M1| |M2| |p|
Phương pháp AG Phương pháp MAG Phương pháp IMAG
|A| |A| Thời gian
sinh (ms) |A| |A| Thời gian
sinh (ms) |A| |A| Thời gian sinh (ms) GOCS ver. 1 180 15 4 2 11 63 80 4 16 1330 4 16 21 GOCS ver. 2 180 10 6 2 14 110 128 - - - 6 26 31 GOCS ver. 3 126 21 2 2 1 4 14 1 4 21 1 4 10 GOCS ver. 4 180 10 6 2 - - - 6 14 20 GOCS ver. 5 136 14 3 2 1 6 6 1 6 12 1 6 11 ACCS 360 30 3 3 1 6 21 1 6 40 1 6 30 I/O ver. 1 27 3 3 2 2 4 14 2 3 20 2 3 12 I/O ver. 2 27 3 3 2 4 9 11 2 4 19 2 4 15 I/O ver. 3 100 5 5 3 6 26 25 - - - 5 7 28
CHƯƠNG 6. KẾT LUẬN
Chúng tôi đã đưa ra một phương pháp cải tiến để tạo ra giả thiết tối thiểu phục vụ quá trình xác minh phần mềm đảm bảo giả thiết đối với các phần mềm dựa thành phần nhằm mục tiêu giảm độ phức tạp của phương pháp sinh giả thiết tối thiểu trong [9, 10]. Tư tưởng chính của phương pháp này thực hiện tìm kiếm một giả thiết tối thiểu trên một cây con của cây tìm kiếm bao gồm tất cả các giả thiết ứng cử viên với kích thước nhỏ hơn hoặc bằng kích thước của của thành phần M2. Với cách tiếp cận này, phương pháp cải tiến có thể sinh ra giả thiết với chi phí thấp hơn phương pháp sinh giả thiết tối thiểu. Những giả thiết đó là đủ mạnh để một số thành phần của phần mềm dựa trên thành phần thoả mãn các thuộc tính cho trước và đủ yếu để được các thành phần còn lại thoả mãn. Trong phương pháp cải tiến này, chúng tôi đã sử dụng chiến lược tìm kiếm theo chiều sâu lặp thay cho chiến lược tìm kiếm theo chiều rộng trong phương pháp sinh giả thiết tối thiểu và chiến lược này đảm bảo rằng nếu tìm thấy giả thiết thì giả thiết đó là tối thiểu (xem định lý 2).
Chúng tôi cũng cài đặt thêm công cụ IMAG bổ sung vào bộ công cụ AGTool đã có các công cụ cài đặt phương pháp sinh giả thiết trong [4] và phương pháp sinh giả thiết tối thiểu trong [9, 10]. Các công cụ này đã được sử dụng để kiểm tra một số phần mềm dựa trên thành phần tiêu biểu nhằm chỉ ra tính hiệu quả của phương pháp cải tiến sinh giả thiết tối thiểu. Kết quả cho thấy trong một số trường hợp phương pháp cải tiến sinh giả thiết khá nhanh trong khi phương pháp tối thiếu không sinh ra được giả thiết trong thời gian cho phép.
Hướng nghiên cứu tiếp theo của chúng tôi là ứng dụng phương pháp đã đưa ra cho những CBS có kích lớn hơn những hệ thống đã được sử dụng trong thực nghiệm để chỉ ra khả năng ứng dụng thực tế của phương pháp cải tiến. Một hạn chế của phương pháp cải tiến sử dụng tìm kiếm theo chiều sâu lặp là các bảng quan sát trên cây con tìm kiếm từ gốc cho tới bảng quan sát cho ta giả thiết tối thiểu sẽ được tạo ra và duyệt nhiều lần. Như vậy công việc tiếp theo, chúng tôi tìm cách cải tiến sự hạn chế của chiến lược tìm kiếm theo chiều sâu lặp, giảm việc duyệt di duyệt lại nhiều lần các bảng quan sát từ gốc tới giả thiết được tìm thấy. Thay vì việc khởi tạo bảng quan sát OT0 là bảng rỗng trong giải thuật DLS mỗi lần gọi tới nó ở bước lặp thứ i+1 bằng bảng quan sát OTi ở bước lặp thứ i. Việc này sẽ giúp chúng ta giảm bớt chi phí tạo và duyệt bảng quan sát trước vị trí tìm được giả thiết tối nhiều nhiều lần.
DANH MỤC CÔNG TRÌNH KHOA HỌC ĐÃ CÔNG BỐ
1. Phạm Ngọc Hùng, Nguyễn Trọng Khánh, Đào Anh Hiển và Nguyễn Việt Hà,
"Phương pháp hiệu quả cho việc kiểm chứng lại phần mềm dựa trên thành phần trong
TÀI LIỆU THAM KHẢO
[1] D. Angluin: “Learning regular sets from queries and counterexamples”, Information and Computation, 75(2): 87-106, Nov. 1987.
[2] C.Blundell, D.Griannakaopoulou, C.Pasareanu: “Assume-Guanrantee Testing”, Microsoft Research – Specification and Verification of Component-Based Systems (SAVCBS2005) Worshop: 7-14
[3] Sagar Chaki and Ofer Strichman. “Three optimizations for assume-guarantee reasoning with L*”. Form. Methods Syst. Des., 32: 267–284, June 2008.
[4] J.Cobleigh, D.Giannakopoulou, C.Pasareanu : “Leanring Assumption for Compositional Verification”, TACAS 2003 : 331-346.
[5] E.M. Clarke, O. Grumberg, D.Peled : “Model Checking”, MIT Press, (1999). [6] D. Giannakopoulou, C. Pasareanu, H. Barringer: “Assumption Generation for
Software Component Verification”, ASE 2002: 3-12.
[7] D. Giannakopoulou, C. Pasareanu, J. Cobleigh: “Assume-Guarantee Verification of Source Code with Design-Level Assumptions”, ICSE 2004: 211-220.
[8] P. N. Hung and T. Katayama: “Modular Conformance Testing and Assume- Guarantee Verification for Evolving Component-Based Software”. In: 15th Asia- Pacific Softw. Eng. Conf. (APSEC), IEEE Computer Society, pp. 479-486 (2008).