Xây dựng công cụ kiểm chứng mô hình phần mềm kiểm tra các chương trình hữu hạn, dựa trên hệ thống java path finder

Mục đích nội dung của ĐATN  Tìm hiểu về Kiểm tra mô hình, thực thi tượng trưng  Làm quen với hệ thống Java Path-Finder áp dụng kiểm tra mô hình  Đưa ra một cách tiếp cận mới để giải q

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

──────── * ────────

ĐỒ ÁN

TỐT NGHIỆP ĐẠI HỌC

NGÀNH CÔNG NGHỆ THÔNG TIN

Xây dựng công cụ kiểm chứng mô hình phần mềm kiểm tra các chương trình hữu hạn, dựa

trên hệ thống Java Path-Finder

Sinh viên thực hiện: Lê Anh Tùng

Lớp CNPM-K51

Giáo viên hướng dẫn: PGS.TS Huỳnh Quyết Thắng

Hà Nội 05-2011

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

1 Thông tin về sinh viên

 Họ và tên sinh viên: Lê Anh Tùng

 Điện thoại liên lạc: 0985170188 Email: atungbk@gmail.com

 Lớp: Công nghệ phần mềm – K51 Hệ đào tạo: Đại học chính quy

 Đồ án tốt nghiệp được thực hiện tại: Bộ môn Công nghệ phần mềm, Viện CNTT &Truyền thông – Đại học Bách Khoa Hà Nội

 Thời gian làm ĐATN: Từ ngày 15/ 01/2011 đến 25 /05/2011

2 Mục đích nội dung của ĐATN

 Tìm hiểu về Kiểm tra mô hình, thực thi tượng trưng

 Làm quen với hệ thống Java Path-Finder áp dụng kiểm tra mô hình

 Đưa ra một cách tiếp cận mới để giải quyết một số vấn đề còn tồn tại của kiểm tra

mô hình trong việc thực thi các chương trình hữu hạn

3 Các nhiệm vụ cụ thể của ĐATN

 Nghiên cứu lý thuyết cơ bản về Kiểm tra mô hình và thực thi tượng trưng và cách

áp dụng chúng vào bài toán kiểm tra các chương trình hữu hạn

 Đưa ra những vấn đề còn tồn tại của phương pháp trên và đề xuất hướng tiếp cậnmới để giải quyết những tồn tại đó

 Xây dựng công cụ từ hướng tiếp cận được đề xuất dựa trên hệ thống Java Finder kết hợp với thực thi tượng trưng để giải quyết bài toán

Path-4 Lời cam đoan của sinh viên

Tôi – Lê Anh Tùng – cam đoan ĐATN là công trình nghiên cứu của bản thân tôi, dưới sự hướng dẫn của PGS.TS Huỳnh Quyết Thắng.

Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳcông trình nào khác

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B ii

Hà Nội, ngày tháng…… năm

Tác giả ĐATN

Lê Anh Tùng

5 Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ

Hà Nội, ngày tháng…… năm

Giáo viên hướng dẫn

PGS.TS Huỳnh Quyết Thắng

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B iii

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP

Đồ án này giới thiệu một phương pháp tiếp cận cho việc kết hợp giữa thực thi tượngtrưng (Symbolic execution) và điều khiển thực thi (Program Monitoring) để kiểm thửcác chương trình Java hữu hạn có thỏa mãn các công đặc tả logic thời gian tuyến tính(Linear Temporal Logic -LTL) hay không LTL là một logic hình thức được sử dụngrộng rãi để biểu diễn các tính chất về thời gian của các hệ thống cả phần cứng cũng nhưphần mềm Để giải quyết bài toán đặt ra, nhiều phương pháp hình thức khác thườngyêu cầu rất nhiều công sức thủ công và thường không phù hợp cho việc kiểm chứngcác hệ thống thật; trong đó đặc biệt là phương pháp kiểm tra mô hình thông thường hay

sử dụng Buchi automat Tuy nhiên Buchi automat lại không được thiết kế cho việckiểm tra các dãy thực thi hữu hạn Chính vì vậy, phương pháp tiếp cận mới ở đây baogồm việc thay đổi thuật toán chuyển đổi từ các công thức LTL sang một automat hữuhạn trạng thái Sau đó dựa vào automata này, hệ thống có thể kết hợp giữa điều khiểnthực thi và thực thi tượng trưng để tự động kiểm chứng các chương trình Java hữu hạntrên tất cả các đường đi của chương trình Hướng tiếp cận này sau đó đã được cài đặtthành một phần mở rộng của hệ thống Java Pathfinder cho việc phân tích và kiểmchứng các chương trình Java

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B iv

ABSTRACT OF THESIS

This thesis represents an approach to combining symbolic execution with programmonitoring for the verification of finite Java programs against Linear Temporal Logic(LTL) specifications LTL has been widely used for expressing temporal properties ofprograms viewed as transition systems Many formal methods require significantmanual effort and not scalable for real sized system; typical model checkingenvironments use Buchi automata which are not designed to deal with finite executiontraces Hence, the approach presented here consists of modifying the standard LTL toBuchi automata conversion technique to generate finite-automata, which are used tocheck finite program traces Besides, the verification can combine with symbolicexecution to allow automatically detect counter-examples in all feasible paths of theprogram The approach has been then implemented in a tool, which is an extension ofthe Java Pathfinder framework for runtime analysis of Java programs

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B v

LỜI CẢM ƠN

Trước tiên, con muốn được gửi lời cảm ơn đến bố mẹ yêu của con Nếu không có

sự nuôi nấng, chăm lo của bố mẹ, con đã không thể có được ngày hôm nay Con sẽkhông bao giờ quên công ơn lớn lao đó của bố mẹ, và sẽ luôn cố gắng phấn đấu sống

và làm việc thật tốt, để có thể là nguồn vui của bố mẹ

Em cũng xin gửi lời cảm ơn sâu sắc đến thầy PGS.TS Huỳnh Quyết Thắng,

thầy đã tận tình giúp đỡ, trực tiếp chỉ bảo, hướng dẫn em trong suốt quá trình làm đồ ántốt nghiệp Trong thời gian làm việc với thầy và được thầy hướng dẫn đồ án, em khôngchỉ tiếp thu thêm nhiều kiến thức bổ ích mà còn học tập được tinh thần làm việc, thái

độ nghiên cứu khoa học nghiêm túc, hiệu quả, đây là những điều rất cần thiết cho

em trong quá trình học tập và công tác sau này

Bên cạnh đó, em cũng xin gửi lời cảm ơn chân thành đến các thầy cô giáo trongtrường đại học Bách Khoa Hà nội nói chung và các thầy cô giáo trong Viện Công nghệThông tin và Truyền thông, bộ môn Công nghệ phần mềm nói riêng đã tận tình giảngdạy, truyền đạt cho em những kiến thức, kinh nghiệm quý báu trong suốt thời gian qua.Ngoài ra, tôi xin được gửi lời cảm ơn sâu sắc đến Dinh Nguyen, EwgenijStarostin, viện Khoa học máy tính, Đại học Berlin, Cộng hòa liên bang Đức; FrancoRaimondi, Đại học Middlesex, Luân Đôn, Anh và nhất là cơ quan quản lý hàng không

vũ trụ Mỹ NASA đã hỗ trợ tôi rất nhiều trong quá trình nghiên cứu, tìm hiểu và pháttriển công cụ

Cuối cùng, anh xin được cám ơn em, người bạn gái mà anh luôn yêu thương.Cám ơn em đã luôn ở bên anh, giúp anh có thêm sức mạnh để vượt qua khó khăn

Hà Nội ngày 15/05/2011

Lê Anh Tùng

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B vi

MỤC LỤC

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP ii

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP iv

ABSTRACT OF THESIS v

LỜI CẢM ƠN vi

MỤC LỤC 1

DANH MỤC CÁC HÌNH MINH HỌA 3

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ 4

PHẦN MỞ ĐẦU 5

PHẦN 1:ĐẶT VẤN ĐỀ VÀ ĐỊNH HƯỚNG GIẢI PHÁP 7

CHƯƠNG I BÀI TOÁN KIỂM TRA CÁC CHƯƠNG TRÌNH JAVA HỮU HẠN8 1.1 Sơ qua về kiểm tra mô hình trong bối cảnh hiện nay 8

1.2 Bài toán kết hợp thực thi tượng trưng và điều khiển thực thi để kiểm chứng các tính chất LTL trong các chương trình Java hữu hạn 10

1.2.1 Lý do đưa ra bài toán 10

1.2.2 Mô tả bài toán và hướng giải quyết 12

1.3 Tổng kết chương I 13

CHƯƠNG II CÁC KIẾN THỨC NỀN TẢNG 14

2.1 Các tính chất về thời gian 14

2.2 Logic thời gian tuyến tính 15

2.2.1 Ngữ nghĩa chuẩn của logic thời gian tuyến tính 15

2.2.2 Ngữ nghĩa của LTL trong các dãy thực thi hữu hạn 16

2.3 Buchi automat cho các từ vô hạn 17

2.4 Automat cho các từ hữu hạn 18

2.5 Thực thi tượng trưng 18

2.6 Tổng kết chương II 20

CHƯƠNG III BÀI TOÁN KIỂM TRA MÔ HÌNH TRUYỀN THỐNG VÀ CÁC THỰC TRẠNG CỦA NÓ 21

3.1 Định nghĩa bài toán kiểm tra mô hình 21

3.2 Giải quyết bài toán kiểm tra mô hình sau khi quy về vấn đề kiểm tra tính rỗng của một Buchi 22

3.3 Những vấn đề khi áp dụng bài toán kiểm tra mô hình vào các dãy thực thi hữu hạn 25 3.4 Tổng kết chương III 26

PHẦN 2: CÁC KẾT QUẢ ĐÃ ĐẠT ĐƯỢC 27

CHƯƠNG IV KIẾN TRÚC CỦA HỆ THỐNG 28

4.1 Cấu trúc tổng quan của hệ thống được xây dựng 28

4.2 Java PathFinder (JPF) 29

4.2.1 Cấu trúc chính của JPF 29

4.2.2 Choice Generator 31

4.2.3 Property 33

4.2.4 Listener 34

4.3 Symbolic PathFinder 36

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B vii

4.4 Tổng kết chương IV 37

CHƯƠNG V XÂY DỰNG MỘT BỘ CHUYỂN ĐỔI CÁC CÔNG THỨC LTL SANG AUTOMAT HỮU HẠN TRẠNG THÁI 38

5.1 Tạo bộ phân tích cú pháp cho các công thức LTL 38

5.1.1 Các toán tử LTL được hỗ trợ 39

5.1.2 Các mệnh đề nguyên tử được hỗ trợ 39

5.1.3 Ngữ pháp của LTL 41

5.2 Cài đặt thuật toán để chuyển từ các công thức LTL sang automat hữu hạn trạng thái 43 5.3 Tổng kết chương V 48

CHƯƠNG VI KẾT HỢP THỰC THI TƯỢNG TRƯNG VÀ ĐIỀU KHIỂN THỰC THI ĐỂ KIỂM CHỨNG CÁC CHƯƠNG TRÌNH JAVA HỮU HẠN 49

6.1 Cài đặt một listener cho JPF để kiểm chứng các dãy thực thi hữu hạn 49

6.2 Kết hợp giữa thực thi tượng trưng và điều khiển thực thi trong việc kiểm tra các điều kiện chuyển trạng thái 51

6.2.1 Mệnh đề nguyên tử là một lời gọi phương thức 52

6.2.2 Mệnh đề nguyên tử là một biến logic 52

6.2.3 Mệnh đề nguyên tử là một biểu thức logic 52

6.3 Mở rộng lớp PCChoiceGenerator của Symbolic Pathfinder để rẽ nhánh chương trình khi thực thi tượng trưng 54

6.4 Tổng kết chương VI 55

CHƯƠNG VII ỨNG DỤNG CÔNG CỤ LTL VÀO CÁC BÀI TOÁN CỤ THỂ 56

7.1 Bài toán con ếch 56

7.2 Kiểm chứng lỗi Race Condition trong các chương trình đa luồng 58

7.3 Ví dụ kiểm chứng kết hợp với thực thi tượng trưng 60

7.4 Tổng kết chương VII 62

KẾT LUẬN 63

TÀI LIỆU THAM KHẢO 65

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B viii

DANH MỤC CÁC HÌNH MINH HỌA

Hình II-1: Buchi tương đương với công thức o ¬( (p⊃ ◊q) 18

Hình II-2: Cây thực thi tượng trưng với ví dụ tính trị tuyệt đối của hiệu hai số 20

Hình III-1: Thuật toán Nested Depth-First Search 24

Hình IV-1: Sơ đồ tổng quan hệ thống 28

Hình IV-2: Thiết kế chính của JPF 31

Hình IV-3: Trình tự của ChoiceGenerator khi thực thi chỉ thị get_field 33

Hình IV-4: JPF Listeners 34

Hình IV-5: Các loại Listener 36

Hình V-1: Ngữ pháp cho các công thức LTL 41

Hình V-2: Ngữ pháp cho các mệnh đề nguyên tử 42

Hình V-4: Automat sinh ra cho công thức <>(a ∨ b) viết theo cú pháp của PROMELA 48

Hình V-5: Automat được sinh ra với thuật toán bên trên cho công thức <>(a\/ b) 48

Hình VI-1: Thuật toán cho việc điều khiển thực thi 50

Hình VII-1: Bài toán con ếch 57

Hình VII-2: Ví dụ về Race condition 59

Hình VII-3: Kết quả kiểm chứng cho ví dụ Race condition 60

Hình VII-4: Ví dụ về thực thi tượng trưng 61

Hình VII-5: Máy hữu hạn trạng thái theo cú pháp PROMELA 61

Hình VII-6: Kết quả kiểm chứng cho ví dụ về thực thi tượng trưng 62

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B ix

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ ST

T

Từ viết

1 MC Model Checking Kiểm chứng mô hình

2 JPF Java Path-Finder Công cụ MC của NASA

3 SE Symbolic Execution Thực thi tượng trưng

4 SPIN Simple Promela Interpreter Công cụ kiểm chứn

5 LTL Linear Temporal Logic Logic thời gian tuyến tính

6 SPF Symbolic Path-Finder JPF thực thi tượng trưng

7 PC Path Condition Điều kiện rẽ nhánh

8 FA Finite-state Automata Automat trạng thái hữu hạn

9 DFS Depth First Search Tìm kiếm theo chiều sâu

10 JVM Java Vitual Machine Máy ảo Java

11 ANTLR ANother Tool for Language Recognition Bộ phân tích cú pháp

12 SLAM Social Location Annotation Mobile Công cụ MC của Microsoft

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B x

PHẦN MỞ ĐẦU

Tóm tắt các nhiệm vụ đề ra trong đồ án tốt nghiệp

 Nghiên cứu lý thuyết cơ bản về Kiểm tra mô hình và thực thi tượng trưng và cách

áp dụng chúng vào bài toán kiểm tra các chương trình hữu hạn

 Đưa ra những vấn đề còn tồn tại của phương pháp trên và đề xuất hướng tiếp cậnmới để giải quyết những tồn tại đó

 Xây dựng công cụ từ hướng tiếp cận được đề xuất dựa trên hệ thống Java Finder kết hợp với thực thi tượng trưng để giải quyết bài toán

Path-Môi trường thực hiện đồ án tốt nghiệp: Bộ môn Công nghệ phần mềm, Viện

CNTT & Truyền thông – Đại học Bách Khoa Hà Nội

Bố cục đồ án: Bao gồm phần mở đầu, nội dung chính và kết luận

Phần mở đầu: Giới thiệu tóm tắt nội dung, nhiệm vụ đề tài, xác định mục tiêu

o Chương 2: Các kiến thức cơ sở trong kiểm tra mô hình.

o Chương 3: Các vấn đề tồn tại của bài toán kiểm tra mô hình truyền thống

 Phần 2: các kết quả đã đạt được

o Chương 4: Kiến trúc hệ thống được xây dựng

o Chương 5: Xây dựng phương pháp, thuật toán chuyển đổi

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xi

o Chương 6: Kết hợp thực thi tượng trưng và điều khiển thực thi để kiểm chứng chương trình Java hữu hạn

o Chương 7: Ứng dụng công cụ LTL vào các bài toán cụ thể

Kết luận: Đánh giá các kết quả nghiên cứu đã đạt được, từ đó đưa ra định

hướng phát triển trong tương lai

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xii

PHẦN 1:ĐẶT VẤN ĐỀ VÀ ĐỊNH HƯỚNG GIẢI PHÁP

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xiii

CHƯƠNG I BÀI TOÁN KIỂM TRA CÁC CHƯƠNG TRÌNH JAVA HỮU HẠN

Chương này được thiết kế nhằm cung cấp những nội dung sau:

 Giới thiệu một cái nhìn tổng quan về kiểm tra mô hình

 Đặt ra bài toán cần giải quyết

 Những khó khăn của các hệ thống hiện tại

 Đưa ra giải pháp để giải quyết bài toán cũng như những khó khăn đã đề ra

I.1 Sơ qua về kiểm tra mô hình trong bối cảnh hiện nay

Kiểm chứng phần mềm là một trong những lĩnh vực nghiên cứu rất cơ bản của kỹnghệ phần mềm Mục đích chung chính là kiểm chứng xem khi nào thì một chươngtrình phần mềm được cho là chính xác, hay nói cách khác là khi nào thì cài đặt của mộtchương trình phù hợp với đặc tả của nó Bài toán kiểm tra mô hình (Model Checking)thường tập trung vào việc kiểm chứng các chương trình phản ứng hữu hạn trạng thái

Để chỉ ra các tính chất của một chương trình như vậy, chúng ta sử dụng logic thời giantuyến tính (Linear Temporal Logic - LTL)

Vậy thì thế nào là một chương trình phản ứng Mô hình thực thi của một chươngtrình thường bao gồm các bước sau: nó nhận vào một tập các giá trị đầu vào, thực hiệncác tính toán cần thiết, rồi đưa ra một giá trị đầu ra nào đó Như vậy, một chương trìnhthông thường có thể được xem xét giống như một hàm trừu tượng từ miền đầu vào đếnmiền đầu ra trong đó, quá trình thực thi là quá trình chuyển đổi từ các trạng thái banđầu tới các trạng thái kết thúc

Ngược lại, một chương trình phản ứng không hướng tới việc kết thúc Giống như têngọi của nó, các hệ thống như vậy “phản ứng” lại môi trường của chúng một cách liêntục, đáp lại một cách tương ứng với các giá trị đầu vào Một số ví dụ của các hệ thốngnhư vậy bao gồm hệ điều hành, bộ lập lịch… (thông thường, các hệ thống phản ứng làcác chương trình phân tán phức tạp, nên việc thực thi song song cần phải được tínhđến)

Để chỉ ra các tính chất của một hệ thống phản ứng, chúng ta cần một kỹ thuật để nói

về cách mà hệ thống đó thực thi, tiến triển theo những dãy tính toán vô hạn có thể xảy

ra Các logic về thời gian [1] đã trở thành một phương pháp hình thức được sử dụng rất

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xiv

rộng rãi cho mục đích này Đã có rất nhiều loại logic thời gian khác nhau được địnhnghĩa trong khoảng hai thập kỷ qua – chúng ta sẽ chỉ tập trung vào một loại đó là logicthời gian tuyến tính.

Có một mối quan hệ mật thiết giữa mô hình của các công thức LTL và ngôn ngữ củacác từ vô hạn – mô hình của một công thức LTL tạo nên một ngôn ngữ chính quy wtrên một bộ chữ cái tương ứng Và kết quả là vấn đề kiểm tra tính thỏa mãn các đặc tảđược quy về kiểm tra tính rỗng của một ngôn ngữ chính quy w Mối quan hệ này lầnđầu tiên được chỉ ra trong [2]

Sau đó, mối quan hệ này giữa LTL và các ngôn ngữ chính quy w được mở rộng rathành vấn đề kiểm tra mô hình (model checking) Không giống như vấn đề kiểm tratính thỏa mãn thông thường chỉ yêu cầu kiểm tra khi nào thì một công thức cho trước

có một mô hình, vấn đề kiểm tra mô hình yêu cầu kiểm chứng xem khi nào thì mộtchương trình hữu hạn trạng thái P thỏa mãn một đặc tả α Việc đó bao gồm kiểm trarằng tất cả các khả năng thực thi của P tạo nên mô hình α Bởi vì các chương trình phảnứng hữu hạn trạng thái có thể biểu diễn tương tự như một automat Buchi nên kiểm tra

mô hình cũng được quy về một vấn đề trong lý thuyết về automat Là đủ để chỉ ra rằngkhông có khả năng thực thi nào của P là mô hình của ¬α cũng giống như việc kiểm trarằng giao giữa ngôn ngữ được đoán nhận bởi P và ngôn ngữ được định nghĩa bởi ¬α làrỗng

Trong vài năm gần đây, các kỹ thuật đưa ra tại [3] đã dịch chuyển từ lý thuyết sangthực tiễn Trong bối cảnh này, có một vài phát hiện mới nhấn mạnh vào việc giảm độphức tạp tính toán của phương pháp sử dụng lý thuyết automat Một trong số nhữnghướng tiếp cận thành công đó là xây dựng automat tương ứng với một công thức cùnglúc với việc kiểm tra (on-the-fly) để cho thay vì phải xây dựng toàn bộ automat trướckhi kiểm tra thì nay chỉ một phần cần thiết cho kiểm tra mô hình được xây dựng màthôi Nói cách khác phương pháp này là kiểm tra tới đâu thì xây dựng automat tươngứng tới đó Bước đầu tiên trong hướng tiếp cận này là thuật toán được đề xuất tại [4]

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xv

I.2 Bài toán kết hợp thực thi tượng trưng và điều khiển thực thi để kiểm chứng các tính chất LTL trong các chương trình Java hữu hạn

I.2.1 Lý do đưa ra bài toán

a) Một số tồn tại khi áp dụng phương pháp kiểm tra mô hình vào việc kiểm chứng các chương trình hữu hạn

Trong vòng một thập kỷ trở lại đây, rất nhiều công trình nghiên cứu đã tập trung vàovấn đề kiểm tra mô hình (model checking) và coi đây là một kỹ thuật đầy hứa hẹntrong kiểm chứng phần mềm Một số ví dụ của các công trình như vậy bao gồm Blast[21] giành cho ngôn ngữ C và Bandera[22] giành cho ngôn ngữ Java Các công trìnhsau này sử dụng những công cụ kiểm tra mô hình có sẵn để thực thi việc kiểm chứng ví

dụ như SPIN [23] Một ví dụ khác là bộ công cụ SLAM [24], bộ công cụ này đã kếthợp các kỹ thuật từ phân tích chương trình, kiểm tra mô hình và suy diễn tự động đểkiểm chứng nếu như một chương trình thỏa mãn một tính chất an toàn nào đó Ngoài racòn có một số công cụ khác như jStar [25] kiểm chứng các giao thức liên lạc giữa một

số các đối tượng trong một hệ thống

Một vấn đề quan trọng trong việc kiểm chứng tự động phần mềm sử dụng các công

cụ kiểm tra mô hình đó là quá trình sinh ra mô hình từ cài đặt thực sự của phần mềm:trong một vài trường hợp, quá trình này yêu cầu sự can thiệp thủ công và không có gìđảm bảo sự tương đương giữa cài đặt thực sự và mô hình được sinh ra Việc tạo ra môhình cho việc kiểm chứng từ mã nguồn yêu cầu phải có hiểu biết chuyên sâu về cáccông cụ cũng như các ngôn ngữ mô hình hóa, và như thế nó mở ra một mức khó hơntrong quá trình kiểm chứng

Ở trong các công cụ kiểm tra mô hình truyền thống, do việc kiểm tra tất cả các khảnăng thực thi của một mô hình thỏa mãn một đặc tả tốn quá nhiều công sức và thườngkhông khả thi, nên bài toán này thường được chuyển về việc chứng minh phản chứngrằng nếu mô hình đó thỏa mãn bất kỳ một dãy thực thi vô hạn nào của phủ định củađặc tả thì nó đã vi phạm đặc tả bạn đầu Quá trình này trước tiên yêu cầu việc chuyểnphủ định của đặc tả LTL thành một Buchi automat mà đoán nhận tất cả các từ vô hạn

mà vi phạm đặc tả LTL ban đầu (Buchi automat là một automat đặc biệt trên các từ vôhạn) Sau đó ta đi tính tích của Buchi automat và của chương trình cần kiểm tra (đượcxem như một automat đặc biệt với tất cả các trạng thái của chương trình đều là trạngthái chấp nhận) Tích này sau đó được kiểm tra nếu như có tồn tại một chu trình chứa ítnhất một trạng thái chấp nhận thì tức là nó bị lỗi và việc kiểm tra mô hình dừng lại.Ngược lại, nếu như tích này mà rỗng thì tức là chương trình đã thỏa mãn công thức ban

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xvi

đầu Tuy nhiên, dễ thấy rằng automat tích này cần phải được lưu trữ cho việc kiểm traxem một trạng thái đã được thăm trước đó hay chưa Không gian trạng thái này thườngrất lớn và dễ gây ra hiện tượng bùng nổ không gian trạng thái [6].

Ngoài ra, Buchi automata chỉ được thiết kế để tính toán trên các dãy thực thi vô hạnnên nó không thể được áp dụng cho các chương trình hữu hạn Một số hệ thống kiểmtra mô hình hiện tại giải quyết việc này bằng cách thêm một vòng lặp vô hạn vào cáctrạng thái cuối cùng của các dãy thực thi hữu hạn Tuy nhiên cách giải quyết này làkhông triệt để vì nó có thể làm thay đổi ngữ nghĩa của chương trình hữu hạn (giả sửnhư nó là một phần của hệ thống lớn hơn và bắt buộc phải kết thúc) Ngoài ra, việcthêm vòng lặp vô hạn vẫn không giải quyết được vấn đề là phải lưu toàn bộ không giantrạng thái để tìm ra các chu trình

Tóm lại, việc áp dụng kiểm tra mô hình để giải quyết bài toán kiểm chứng cácchương trình hữu hạn gặp phải những khó khăn sau:

 Thường yêu cầu nhiều kiến thức chuyên gia để có thể sử dụng

 Thường không thể kiểm chứng chương trình một cách trực tiếp từ mã nguồn

mà kiểm chứng chương trình ở một mức trừu tượng hóa nào đó

 Khả năng xảy ra bùng nổ không gian trạng thái là rất lớn

 Buchi automat sử dụng trong kiểm tra mô hình không phù hợp với việc kiểmtra các chương trình hữu hạn

b) Tính ưu việt của kỹ thuật thực thi tượng trưng trong các bài toán kiểm thử

Gần đây, thực thi tượng trưng (symbolic execution) nổi lên như một kỹ thuật kiểmthử rất mới mẻ và thực sự hữu ích Nó có thể hiểu là một kỹ thuật phân tích chươngtrình bằng cách tính toán trên các giá trị tượng trưng thay vì các giá trị cụ thể được gáncho các biến trong chương trình Dựa trên kỹ thuật này, về mặt lý thuyết mà nói thìchúng ta có thể đi tất cả các nhánh của một chương trình hữu hạn Như vậy, nó có thểphát hiện ra nhiều lỗi mà các kỹ thuật kiểm thử thông thường không phát hiện đượchoặc các ca kiểm thử không được chuẩn bị kỹ lưỡng

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xvi

i

I.2.2 Mô tả bài toán và hướng giải quyết

Bài toán được đặt ra ở đây là kiểm tra trực tiếp các chương trình hữu hạn được viếttrên ngôn ngữ Java có tuân thủ theo một tính chất thời gian nào đó hay không Trong

đó, các tính chất này thường được viết dưới dạng các công thức trong logic thời giantuyến tính LTL - là một ngôn ngữ hình thức được sử dụng rất rộng rãi để miêu tả cáctính chất về thời gian trong nhiều công cụ kiểm tra mô hình ví dụ như SPIN[8]

Trước những vấn đề trên của các hệ thống kiểm tra mô hình đượng đại, ta thấy nókhông phù hợp để kiểm tra các chương trình hữu hạn hoặc đòi hỏi quá nhiều công sứchoặc làm thay đổi ngữ nghĩa của chương trình Chính vì vậy nên việc xây dựng mộtphương pháp hình thức có thể áp dụng cho nhiều ứng dụng thực tế và ít đòi hỏi côngsức thủ công hơn là vô cùng cần thiết Hướng nghiên cứu này gần đây thu hút được rấtnhiều sự chú ý [5, 7] Một trong số những cách tiếp cận mới này được biết đến với têngọi điều khiển thực thi (program monitoring) trong đó ý tưởng đằng sau phương phápnày chính là điều khiển quá trình thực thi của một chương trình nào đó theo đúng nhưđặc tả hình thức của nó Các đặc tả này thường được viết bằng các logic hình thức.Bằng cách này, việc kiểm chứng có thể áp dụng cho nhiều hệ thống hơn vì ở một thờiđiểm thì chỉ có một đường thực thi được kiểm tra, ngoài ra nó còn hữu ích ở chỗ chúng

ta có thể biểu diễn được nhiều tính chất của chương trình hơn so với các môi trườngkiểm thử truyền thống khác

Còn để giải quyết vấn đề Buchi automata không phù hợp cho việc kiểm chứng cácchương trình hữu hạn, ta thay nó bằng một automat hữu hạn trạng thái khác mà có thểdùng kết hợp với kỹ thuật điều khiển thực thi nói trên Định nghĩa chi tiết, và thuật toánxây dựng automat này sẽ được đề cập kỹ hơn ở những phần sau

Vì vậy, đồ án này cố gắng đưa ra một cách tiếp cận hiệu quả hơn bằng việc kết hợpgiữa thực thi tượng trưng và điều khiển thực thi như đã trình bày ở trên để kiểm tra cácchương trình Java hữu hạn so với các đặc tả của nó được biểu diễn bởi ngôn ngữ LTL.Giải pháp được đưa ra bao gồm những bước sau: (1) định nghĩa một ngữ pháp chínhxác cho các công thức LTL; (2) cài đặt một thuật toán [9] để chuyển một công thứcLTL sang một automat hữu hạn trạng thái (không dùng Buchi automat) để điều khiểnthực thi các chương trình hữu hạn so với các công thức LTL ban đầu Và (3) xây dựngmột công cụ dựa trên hệ thống Java Pathfinder (JPF)1, một máy ảo Java cho phép thựcthi đồng thời với việc kiểm thử chương trình Và cuối cùng là (4) kết hợp công cụ trênvới thực thi tượng trưng để kiểm tra đầy đủ các chương trình Java hữu hạn

1 http://babelfish.arc.nasa.gov/trac/jpf

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xvi

ii

I.3 Tổng kết chương I

Chương này được mở đầu với việc giới thiệu sơ qua về bối cảnh của bài toán kiểmtra mô hình hiện nay Trong đó, nó đề cập tới sự liên quan giữa tính chất về thời gian

và các công thức LTL cũng như Buchi automata được áp dụng trong bài toán kiểm tra

mô hình như thế nào Tiếp sau đó, chương này nêu ra bài toán cần phải giải quyết trongphạm vi đồ án này đó là: kiểm tra các chương trình Java hữu hạn bằng cách kết hợpgiữa thực thi tượng trưng và điều khiển thực thi Để giải quyết bài toán này, trước tiênchúng ta được giới thiệu về những hạn chế của các hệ thống kiểm tra mô hình hiện tạivào việc giải quyết bài toán đã đặt ra Sau đó, chương này kết thúc với việc đưa ra mộtgiải pháp cụ thể và một hệ thống cụ thể - JPF- để giải quyết bài toán này và vượt quanhững giới hạn của các hệ thống hiện tại như thế nào

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xix

CHƯƠNG II CÁC KIẾN THỨC NỀN TẢNG

Trước khi đi vào nội dung cụ thể của đồ án, chương này sẽ chuẩn bị cho chúng

ta những kiến thức nền tảng cần thiết có liên quan tới công trình này Chúng bao gồm những nội dung chính sau:

 Các tính chất về thời gian (Temporal Properties)

 Logic thời gian tuyến tính (Linear Temporal Logic)

 Buchi automat cho các từ vô hạn

 Automat cho các từ hữu hạn

Thực thi tượng trưng (Symbolic execution)

II.1 Các tính chất về thời gian

Để biểu diễn các tính chất thời gian, chúng ta sử dụng logic thời gian tuyến tínhLTL Một chương trình trong khi thực thi sẽ định nghĩa một dãy các trạng thái; vì thếmột dãy thực thi có thể được xem xét như là một thể hiện của LTL trong đó một tậpcác mệnh đề nguyên tử mà đúng ở một trạng thái cụ thể của chương trình được gán chomột điểm thời gian nào đó

Có hai loại tính chất cơ bản đó là tính an toàn (safety) tức là sẽ không bao giờ cóđiều gì đó xấu xảy ra trong tương lai và tính cuối cùng sẽ tốt (liveness) tức là rồi tớimột thời điểm nào đó một điều mong muốn sẽ xay ra Mọi tính chất thời gian khác cóthể được xây dựng từ hai tính chất cơ bản này Mọi công thức LTL có thể bao gồm cảhai phần safety hoặc liveness hoặc một trong hai

Ta cùng xem xét ví dụ một công thức LTL như sau: [](p ◊q) Nó biểu diễn tính⊃chất: “mọi trạng thái mà trong đó mệnh đề p đúng đều trùng với hoặc theo sau bởi mộttrạng thái mà trong đó mệnh đề q đúng” Tất cả các dãy vô hạn trạng thái mà phù hợpvới yêu cầu này sẽ thỏa mãn công thức này

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xx

II.2 Logic thời gian tuyến tính

II.2.1 Ngữ nghĩa chuẩn của logic thời gian tuyến tính

Logic thời gian tuyến tính được sử dụng để biểu diễn các tính chất của một hệ thốngcho kiểm tra mô hình Cho trước một tập các mệnh đề nguyên tử (atomic proposition)

P, một công thức LTL được định nghĩa một cách đệ quy bằng cách sử dụng các toán tửlogic chuẩn và các toán tử thời gian X (next) và U (strong until) như sau:

 Mỗi thành phần của P là một công thức

 Nếu ϕ và ψ là các công thức thì ¬ϕ, ϕ ψ, ϕ ψ, Xϕ, ϕ U ψ cũng là các công∨ ∧thức

Một thể hiện cho một công thức LTL là một từ vô hạn w = x0x1x2… trên 2P Nóicách khác, một thể hiện tương ứng với mỗi thời điểm của thời gian, tại lúc đó có mộttập các mệnh đề nguyên tử đúng Chúng ta viết w1 là phần tử đầu tiên của từ w bắt đầutại x1 Như vậy, ngữ nghĩa của LTL được định nghĩa một cách đệ quy như sau:

 w |= p khi và chỉ khi p ϵ x0, với p ϵ P

 w |= ¬ ϕ khi và chỉ khi w |= ϕ không đúng

 w |= ϕ ψ khi và chỉ khi ( w |= ϕ ) hoặc ( w |= ψ ) ∨

ϕ

Tuy nhiên, trong khuôn khổ của đồ án này thì chúng ta chỉ quan tâm tới các tính chấtnext-free hay còn gọi là LTL-X của LTL Ở đây next-free có nghĩa là chúng ta khôngchấp nhận toán tử X (next) trong công thức LTL Điều này rất phổ biến trong kiểm tra

mô hình, bởi vì LTL-X được đảm bảo cho việc không bị nhạy cảm với việc lặp cáctrạng thái [11] Tính chất này rất quan trọng bởi vì nó tránh cho việc có một trạng thái

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxi

tiếp theo tuyệt đối Thông thường ta rất khó xác định thế nào thì được coi là trạng tháitiếp theo như giả sử trong Java, ta sẽ rất khó nói là sau bao nhiêu chỉ thị thì chươngtrình sẽ chuyển sang trạng thái kế tiếp Như vậy, toán tử X sẽ bị mất đi, bởi vì người sửdụng thường giả sử có nhiều mức độ trừu tượng hóa của một chương trình nên ở cấp độnày có thể một trạng thái được coi là kế tiếp nhưng ở mức độ khác lại là không Thêmvào đó, nó không phức tạp bởi vì ý nghĩa thực sự của một công thức có toán tử X đó là

ở trạng thái cuối cùng của dãy thực thi

Trong toàn bộ phần còn lại của đồ án này, các tính chất LTL-X sẽ được coi như nóitới mỗi khi ta đề cập tới LTL Theo cách này, các tính chất LTL-X được định nghĩakhông bao gồm toán tử X theo cách sau:

Các mệnh đề nguyên tử và các toán tử logic được giữ nguyên so với định nghĩa ởtrên Tuy nhiên với các toán tử thời gian, chúng ta bỏ đi toán tử X (next) và thêm vàotoán tử V được định nghĩa như sau: φVψ = !(!φU !ψ)

II.2.2 Ngữ nghĩa của LTL trong các dãy thực thi hữu hạn

Một dãy thực thi đi qua một dãy các trạng thái của hệ thống; một dãy thực thi vô hạn

do đó có thể được coi như một thể hiện của LTL trong đó ta gán cho mỗi biến trạngthái một tập các mệnh đề nguyên tử mà đúng ở một thời điểm nhất định và một trạngthái nhất định của chương trình Kiểm tra mô hình [11] tìm ra các chu trình có chứa cáctrạng thái chấp nhận trên đồ thị của một hệ thống hữu hạn trạng thái thông qua các dãythực thi vô hạn Điều này yêu cầu lưu trữ toàn bộ không gian trạng thái của chươngtrình, kể cả gần đây chúng ta có kỹ thuật để kiểm tra cùng với việc thực thi chươngtrình (on-the-fly) cũng như xây dựng automat tích ngay khi chạy Còn điều khiển thựcthi thì không lưu toàn bộ không gian trạng thái của chương trình Thay vào đó, nó chỉlắng nghe và phản ứng lại các dãy thực thi hữu hạn, trong đó chúng ta cũng cần phảidẫn xuất các công thức LTL bằng cách gán các mệnh đề nguyên tử cho các biến trạngthái ở những thời điểm cụ thể Do có sự khác biệt này giữa các dãy thực thi hữu hạn và

vô hạn, nên ta cần sửa đổi ngữ nghĩa của các toán tử để cho phù hợp với sự khác biệtnày

Như đã thảo luận ở phần trên thì mọi công thức LTL có thể bao gồm cả phần safetyhoặc một phần liveness hoặc thậm chí cả hai Từng phần safety/liveness yêu cầu rằngmột việc xấu nào đó sẽ không bao giờ xảy ra hoặc một việc tốt nào đó cuối cùng sẽ xảy

ra trong dãy thực thi Chúng ta thay đổi ngữ nghĩa của phần safety để nó có nghĩa làtrong khoảng thực thi mà chúng ta nhận được thì không có điều gì xấu xảy ra Nếukhông thì chúng chưa được thỏa mãn tính chất về safety Tương tự như vậy với các

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxi

i

tính chất liveness, chúng được yêu cầu phải thỏa mãn trong khoảng thời gian thực thi

đã qua Liên quan đến những thay đổi về ngữ nghĩa này, chúng ta định nghĩa lại ngữnghĩa của các toán tử thời gian như sau:

Coi w=x0x1…xn là một thể hiện hữu hạn của một công thức LTL trên 2AP thì các toán

tử thời gian sẽ được định nghĩa như sau:

W |= φUψ khi và chỉ khi tồn tại 0 ≤ i ≤ n để mà wI |= ψ

Và với mọi 0 ≤ j < I, wj |= φ

II.3 Buchi automat cho các từ vô hạn

Automat trên các đầu vào vô hạn được giới thiệu bởi Buchi trong [10] Một automatBuchi là một automat hữu hạn trạng thái không đơn định và lấy các từ vô hạn làm đầuvào Một từ được đoán nhận bởi Buchi nếu như trong khi đọc từ đó, Buchi đi qua mộtvài trạng thái đặc biệt nào đó thường xuyên và vô hạn

Một cách hình thức, Buchi được định nghĩa như một tập A = (Σ,S,∆,s0 ,F), trong đó

Chúng ta định nghĩa một đường chạy σ của A trên một từ w = a1a2… như là một dãy

σ = s0, s1, …, đó là một hàm từ w sang S, ở đây (si-1 , ai, s i) ∆, với mọi i≥1 Một∈đường chạy σ = s0 ,s1 ,… được gọi là được chấp nhận nếu như có một vài trạng tháitrong F được lặp lại thường xuyên và vô hạn hay tức là có một vài trạng thái x F mà∈

ở đó có nhiều vô hạn i ω để cho s∈ i = x Từ w được đoán nhận bởi A nếu như có mộtđường chạy được chấp nhận của A trên từ w

Việc xây dựng Buchi Af từ công thức f trong trường hợp xấu nhất thì độ phức tạptính toán là hàm mũ của độ dài của công thức [12, 13] Tuy nhiên trên thực tế, hầu hếtcác công thức thường rất ngắn và trường hợp xấu nhất rất hiếm khi xảy ra

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxi

ii

Hình II-1: Buchi tương đương với công thức o ¬( (p⊃ ◊q)

Hình 1 chỉ ra một Buchi mà đoán nhận tất cả các từ vô hạn thỏa mãn công thức ¬fvới f ≡ (p ◊q), nghĩa là tất cả các dãy trạng thái trong đó bao gồm một trạng thái p⊃đúng và từ đó q không bao giờ đúng trong suốt quãng còn lại của dãy

II.4 Automat cho các từ hữu hạn

Trong bài toán kiểm tra mô hình điển hình, chúng ta dịch phủ định của đặc tả LTLsang một Buchi automat sau đó tìm ra một chu trình có chứa ít nhất một trạng thái chấpnhận trong tích của chương trình với Buchi đó Tuy nhiên, Buchi là một automat hữuhạn trạng thái nhưng thực thi trên các từ vô hạn, nên chúng ta không thể áp dụng nó đểkiểm chứng các dãy thực thi hữu hạn được Một nghiên cứu về vấn đề này đã đượcthực hiện và giới thiệu trong [9] Nó cho rằng chúng ta cần phải tạo ra một bộ chuyểnđổi mới để chuyển một công thức LTL sang một automat hữu hạn trạng thái mà đượcdùng để điều khiển các dãy thực thi hữu hạn Trong phần này, chúng ta sẽ định nghĩa

về kiểu automat hữu hạn đó và thuật toán chuyển đổi cụ thể sẽ được bàn đến ở nhữngphần sau trong đồ án này

Một automat hữu hạn trạng thái (FA) được định nghĩa như là một tổ hợp (S, A, ∆, s0,F), trong đó S là một tập hữu hạn các trạng thái, A là một tập hữu hạn các nhãn hay cònđược gọi là bộ chữ cái cho automat, ∆ ⊆S x A x là một hàm chuyển, s0 ∊ S là trạngthái ban đầu và F ⊆S là tập các trạng thái chấp nhận

Một dãy thực thi của FA là hữu hạn σ = s0 a0 s1 … an-1 sn, để mà (si ai si+1) ∊ ∆ vớimỗi 0 ≤ i ≤ n Một dãy thực thi σ của FA được coi là được chấp nhận nếu sn ∊ F Vàcuối cùng, FA chấp nhận một từ hữu hạn w = x0…xn-1 trên A, nếu như nó tồn tại mộtdãy thực thi được chấp nhận σ=s0x0s1…xn-1 sn của FA

II.5 Thực thi tượng trưng

Thực thi tượng trưng là một dạng phân tích chương trình, sử dụng các giá trị tượngtrưng thay vì dữ liệu thật làm đầu vào (input) và các biểu thức tượng trưng để biểu diễngiá trị của các biến có trong chương trình Như thế, đầu ra của chương trình có thểđược biểu diễn như một hàm của các giá trị tượng trưng đầu vào Ở một thời điểm bất

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxi

v

kỳ, trạng thái của chương trình sẽ được đặc trưng bởi ba thứ đó là giá trị của các biến(biểu thức của các giá trị tượng trưng), biểu thức điều kiện đường đi (path conditionhay PC) và con trỏ chương trình (program counter).

Path condition (PC) là một công thức logic giữa các giá trị đầu vào tượng trưng củachương trình Nó chính là ràng buộc mà các giá trị tượng trưng đó phải thỏa mãn để cóthể thực thi theo một đường nào đó Để phân biệt rõ hơn sự khác nhau giữa thực thitượng trưng (symbolic execution) và thực thi cụ thể (concrete execution) ta xem xétmột ví dụ về thực thi một hàm tính giá trị tuyệt đối của hiệu hai số sau:

Giả sử giá trị tham số đầu vào là x = 3 và y = 2 Thực thi cụ thể sẽ chỉ đi theo mộtnhánh của chương trình ứng với điều kiện if là đúng trong dòng [1] Kết quả là 1 vàkhông vi phạm điều kiện assert của chương trình

Ngược lại, thực thi tượng trưng không bắt đầu bằng giá trị thật nào cả mà bằng hai

giá trị tượng trưng là x = Sym x , y = Sym y và PC được khởi tạo là true Quá trình thực thi

tiếp theo được biểu diễn thành cây như trong hình 2 Ở mỗi điểm phân nhánh , PCđược cập nhật thêm những ràng buộc mới trên những giá trị tượng trưng để có thể đitheo một trong các nhánh đó Ví dụ như khi thực thi đến dòng số [1] thì sẽ có hai khả

năng tiếp theo của biểu thức điều kiện if, khi đó PC sẽ được cập nhật theo Nếu như PC cho kết quả là false thì có nghĩa là nhánh đó không thể đi tiếp được nữa và thực thi

tượng trưng sẽ không tiếp tục theo nhánh đó nữa

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxv

Hình II-2: Cây thực thi tượng trưng với ví dụ tính trị tuyệt đối của hiệu hai số

Ở ví dụ trên, thực thi tượng trưng đã thực thi theo bốn đường và nó đưa ra mộtđường có giá trị không thỏa mãn điều kiện assert trong chương trình

ở các chương trình vô hạn sẽ được thay đổi sao cho phù hợp sang hữu hạn rồi thì đànhchịu

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxv

i

CHƯƠNG III BÀI TOÁN KIỂM TRA MÔ HÌNH TRUYỀN THỐNG

 Định nghĩa vấn đề kiểm chứng mô hình

 Tìm hiểu một cách giải quyết kiểm chứng mô hình bằng cách quy nó vềvấn đề kiểm tra tính rỗng của một Buchi

 Những vấn đề mà kiểm chứng mô hình gặp phải khi áp dụng cho các dãythực thi hữu hạn

III.1 Định nghĩa bài toán kiểm tra mô hình

Vấn đề kiểm chứng được xem xét như sau Cho trước một chương trình song song P

và một công thức logic thời gian tuyến tính f, kiểm tra rằng tất cả các tính toán vô hạn của P thỏa mãn f Điều này được biết tới như là vấn đề kiểm tra mô hình (model

checking)

Để giải quyết vấn đề này, giả thiết duy nhất chúng ta cần làm đó là với mỗi công

thức f trong logic thời gian tuyến tính, có thể xây dựng một Buchi A f mà đoán nhận

chính xác các từ vô hạn thỏa mãn công thức thời gian f [10, 2].

Thủ tục kiểm chứng được diễn ra như sau [2, 3] Đầu tiên chúng ta xây dựng một

automat hữu hạn trên các từ vô hạn cho công thức phủ định của công thức ban đầu f.

Automat thu được A¬f đoán nhận tất cả các dãy trạng thái mà vi phạm f (Đương nhiên,

nếu A¬f được cung cấp bởi người sử dụng thì thủ tục phủ định có thể được bỏ qua) Sau

đó chúng ta tính toán automat tích AG = AP x A¬f hay chính là Buchi AG = (Σ,S,∆,s0 ,F)với

 Σ = Σ¬f,

 S = SP ×S¬f, s0 = (s0P ,s0¬f),

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxv

ii

 ( (s,w) ,a, (u,v) ) ∆ khi (s, t ,u) ∆∈ ∈ P và (w,a,v) ∆∈ ¬f (tức là mỗi hàm chuyểntrạng thái t của AP được đồng bộ với một hàm chuyển trạng thái a của A¬f),

 F = SP ×F¬f

Automat tích này đoán nhận tất cả các tính toán vô hạn của P mà được đoán nhậnbởi A¬f, nói cách khác nó đoán nhận mọi tính toán mà vi phạm f Thủ tục kiểm chứng

kết thúc bằng cách kiểm tra nếu như Buchi AG đoán nhận bất kỳ dãy nào Nếu như AG

là rỗng thì chúng ta đã chứng minh được rằng tất cả các tính toán vô hạn của P được

thỏa mãn bởi công thức f Như vậy bài toán kiểm tra mô hình được quy về bài toán

kiểm tra tính rỗng của Buchi

Cần chú ý rằng chúng ta kiểm chứng các tính chất của các tính toán vô hạn của P.Các tính chất đó được định nghĩa bằng cách coi AP như là một kiểu giới hạn của Buchitrong đó tập hợp các trạng thái chấp nhận F là toàn bộ các trạng thái trong AP Vì vậy,thủ tục kiểm chứng này không xem xét các tính toán hữu hạn của chương trình P Tuynhiên, nếu như được yêu cầu, chúng ta luôn có thể chuyển các tính toán hữu hạn sang

vô hạn bằng cách cho lặp đi lặp lại mãi mãi trạng thái kết thúc của nó

III.2 Giải quyết bài toán kiểm tra mô hình sau khi quy về vấn đề kiểm tra tính rỗng của một Buchi

Để kiểm tra nếu một Buchi AG là không rỗng, ta phải kiểm tra nếu có tồn tại mộtvòng tròn trong AG (ở đây Buchi được xem xét giống như một đồ thị) mà trong vòngtròn đó có chứa một trạng thái chấp nhận và nó có thể đi tới được tính từ trạng thái banđầu s0 Cần chú ý rằng ta không cần xem xét tất cả các vòng tròn trong AG; là đủ khi tachỉ cần kiểm tra rằng nếu như AG chứa ít nhất một thành phần liên thông mạnh mà đitới được từ trạng thái ban đầu và bao gồm một trạng thái chấp nhận từ tập F

Việc tìm kiếm thành phần liên thông mạnh trong AG có thể được thực hiện với thuậttoán Tarjan [17, 18] Thuật toán này dựa trên thuật toán tìm kiếm theo độ sâu trên đồthị AG cộng với việc tính toán thêm ở mỗi trạng thái của AG khi gặp trong khi tìm kiếm.Thuật toán này thăm tất cả n trạng thái của AG không quá một lần Độ phức tạp về thờigian vì thế chỉ là tuyến tính theo kích thước của AG Tuy nhiên, nó yêu cầu phải lưu tất

cả các trạng thái có thể đi tới trong một bộ nhớ truy cập ngẫu nhiên Ngoài ra, với mỗi

trạng thái, giá trị của một biến dfnumber dùng để đánh dấu trạng thái đi tới được theo

trình tự chúng được thăm cũng phải được lưu Thuật toán Tarjan cũng yêu cầu việc sửdụng thêm một ngăn xếp phụ

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxv

iii

Vì thuật toán này yêu cầu truy cập các thông tin trạng thái, ví dụ như giá trị của

dfnumber, để chắc chắn về tính đúng đắn của nó, nên nó không phù hợp với các kỹ

thuật mà đảm bảo sự toàn vẹn của các thông tin này Ví dụ như kỹ thuật băm trạng tháitheo bit (bit-state hashing) quy việc biểu diễn các trạng thái và các thông tin liên quantới nó thành một hoặc hai bit bộ nhớ [19] Thậm chí kỹ thuật bộ nhớ tạm còn xóa đinhững trạng thái đã thăm hoàn toàn khỏi bộ nhớ [20] Vì vậy, với một không gian bộnhớ cho trước nào đó, kích thước của vấn đề mà thuật toán Tarjan có thể phân tích làkhông thể tránh khỏi nhỏ hơn kích thước vấn đề mà hai thuật toán kể trên có thể phântích

Chính ràng buộc này đã yêu cầu phải phát triển một thuật toán để kiểm tra tính rỗngcủa Buchi [26] mà phù hợp với phương pháp băm theo bit và quy tắc bộ nhớ tạm.Trong [26], việc kiểm tra tính rỗng của một Buchi được quy về một tập các vấn đề xácđịnh khi nào có thể tới được một trạng thái nào đó Điều này đã được chứng minh bởimột thực tế rằng một Buchi là không rỗng khi và chỉ khi có một vài trạng thái x F mà∈vừa có thể đi tới được từ trạng thái ban đầu vừa có thể đi tới từ chính nó

Thuật toán được đề xuất trong [26] chính là thuật toán tìm kiếm theo chiều sâu lồngnhau (nested depth first search) bao gồm hai vòng tìm kiếm theo chiều sâu liên tiếpnhau Mục đích của vòng DFS thứ nhất là để xác định các trạng thái chấp nhận của F

mà có thể đi tới từ trạng thái ban đầu s0 Nó sắp xếp chúng theo kiểu hậu thứ tự(postorder) thành x1, … , xk, trong đó x1 là trạng thái chấp nhận đầu tiên được quay luikhi tìm kiếm trên không gian trạng thái, và xk là trạng thái cuối cùng như vậy Cáctrạng thái chấp nhận này sau đó được lưu vào một hàng đợi Mục đích của vòng DFSthứ hai là để kiểm tra nếu như có bất kỳ một trạng thái chấp nhận nào trong hàng đợi là

có thể đi tới từ chính nó Vòng DFS thứ hai bắt đầu từ x1 Nếu x1 được đi tới trong quátrình tìm kiếm, một vòng đi qua x1 được phát hiện và một lỗi (tức là một trường hợp viphạm tính chất đang được kiểm tra) sẽ được báo cáo Một vòng DFS mới sẽ được khởiđộng từ x2 và cứ như vậy cho tới khi nào tất cả k trạng thái chấp nhận đều được kiểmtra Dựa theo hậu thứ tự, ta có thể chỉ ra rằng các trạng thái đã thăm trong suốt lần tìmkiếm thứ I không thể bị thăm lại trong suốt quá trình tìm kiếm thứ j sau đó, với i < j

Hệ quả là k lần tìm kiếm có thể được thực hiện chỉ với việc sử dụng một bảng băm đểlưu các trạng thái đã được thăm Nói cách khác, tất cả các lần tìm kiếm từ x F cùng∈với nhau sẽ tương ứng với duy nhất một vòng DFS thứ hai trên AG

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxi

x

Trong trường hợp xấu nhất, thuật toán này thăm tất cả các trạng thái có thể tới đượccủa AG hai lần: mỗi lần trong mỗi pha tìm kiếm Độ phức tạp thời gian tính toán của nóvẫn là tuyến tính theo kích thước của AG Nó yêu cầu lưu tất cả các trạng thái trong một

bộ nhớ ngẫu nhiên Trong trường hợp lỗi, các trạng thái trong ngăn xếp của lần tìmkiếm thứ hai tương ứng với một vòng tròn xấu (“bad” cycle) đi qua một trạng thái chấpnhận xi Tuy nhiên, trường hợp lỗi với toàn bộ đường đi từ trạng thái ban đầu không thểđưa ra được Vì thế cần phải thực hiện một vòng tìm kiếm thứ ba để tìm ra một đường

đi từ trạng thái ban đầu tới trạng thái xi

Hình III-3: Thuật toán Nested Depth-First Search

Trong [26], một phiên bản khác của thuật toán này cũng được giới thiệu với giả mãnhư hình 4 trên đây Thuật toán này không sử dụng thêm một hàng đợi mà thay vào đó

là một ngăn xếp thứ hai và một bảng băm Ý tưởng chính đằng sau việc này là để thựchiện hai lượt DFS trên chỉ với một lượt lồng nhau thay vì hai lượt liên tiếp nhau Mỗilần một trạng thái chấp nhận được quay lui trong vòng DFS thứ nhất, pha tìm kiếm đóđược tạm ngừng và một pha tìm kiếm thứ hai bắt đầu tìm xem khi nào thì trạng tháichấp nhận đó có thể đi tới từ chính nó Nếu không tìm ra một vòng như vậy, thuật toánkhôi phục lại pha tìm kiếm thứ nhất để tìm kiếm trạng thái chấp nhận tiếp theo Phiênbản này yêu cầu không gian bộ nhớ gấp đôi so với phiên bản kể trên nhưng ưu điểmcủa nó là nếu như có một lỗi được tìm ra, một trường hợp lỗi đầy đủ đường đi kể từtrạng thái ban đầu có thể được đưa ra dựa vào hai ngăn xếp

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

i

III.3 Những vấn đề khi áp dụng bài toán kiểm tra mô hình vào các dãy thực thi hữu hạn

Theo như bài toán kiểm tra mô hình đề ra, ta có thể thấy rằng nó chỉ quan tâm tớinhững dãy thực thi vô hạn và nó giả sử rằng mọi dãy thực thi đều là vô hạn không baogiờ kết thúc Điều giả sử này tuy ở mức tổng quát là không sai vì ta có thể thêm mộtvòng lặp vô hạn vào các trạng thái cuối cùng của các dãy thực thi hữu hạn để làm cho

nó thành vô hạn Tuy nhiên, cách này chưa được hoàn toàn thuyết phục vì trong nhiềutrường hợp nó làm thay đổi ngữ nghĩa của chương trình cần kiểm tra

Lây đơn giản một ví dụ khi một chương trình là một phần của một hệ thống lớn hơn.Khi đó, nó sẽ có thể bị bắt buộc phải kết thúc khi tương tác với các phần khác trong hệthống Trong trường hợp này, ngữ nghĩa đã bị thay đổi và kết quả kiểm tra mô hình sẽkhông còn giá trị nữa

Bên cạnh đó, khi áp dụng thuật toán tìm kiếm theo độ sâu lồng nhau (Nested DepthFirst Search), hay thậm chí bất kỳ thuật toán tìm kiếm thành phần liên thông mạnh nàokhác trong đồ thị trạng thái, ta sẽ phải lưu lại toàn bộ trạng thái vào hai ngăn xếp Điềunày dẫn đến bùng nổ trạng thái rất nhanh chóng, và thường thì ta không thể kiểm tratrực tiếp từ mã nguồn mà bắt buộc người dùng phải trừu tượng hóa chương trình củamình xuống một mức độ nào đó Như thế, người dùng phải là chuyên gia với đầy đủkiến thức về phương pháp hình thức mới có thể sử dụng nổi

Ngoài ra, như ta thấy, Buchi là một automat hữu hạn trạng thái nhưng chỉ đoán nhậncác từ vô hạn Chính vì vậy mà nó không thể dùng để kiểm tra các dãy thực thi hữu hạn

vì nó có thể cho kết quả kiểm chứng sai so với những gì chúng ta mong đợi

Trước những thực trạng này, việc phát triển một công cụ để kiểm tra các chươngtrình Java hữu hạn một cách trực tiếp và đúng đắn là vô cùng hữu ích Những chươngsau đây sẽ đi vào cụ thể công cụ này được xây dựng từng bước như thế nào

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

ii

III.4 Tổng kết chương III

Chương này đã giới thiệu một cách chi tiết bài toán kiểm tra mô hình dùng để kiểmchứng các công thức LTL Đồng thời, nó cũng đưa ra những điểm chưa tốt mà kiểm tra

mô hình còn gặp phải nhất là khi kiểm tra các chương trình hữu hạn được yêu cầu phảikết thúc ở một thời điểm nào đó Từ đó, chúng ta có thể rút ra kết luận về sự cần thiếtphải phát triển một công cụ để khắc phục những khó khăn này Về chi tiết quá trìnhphát triển công cụ đó, chúng ta sẽ cùng tìm hiểu ở những chương sau

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

iii

PHẦN 2: CÁC KẾT QUẢ

ĐÃ ĐẠT ĐƯỢC

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

iv

CHƯƠNG IV KIẾN TRÚC CỦA HỆ THỐNG

Trước khi đi vào tìm hiểu cụ thể cài đặt cũng như thực nghiệm của công cụ đượcphát triển trong đồ án này, sẽ tốt hơn nếu chúng ta có một cái nhìn tổng quan về nó

Vì thế chương này được đưa ra nhằm các mục đích sau:

 Giới thiệu về cấu trúc tổng quan của hệ thống

 Cấu trúc của Java Pathfinder

 Cấu trúc của Symbolic Pathfinder

IV.1 Cấu trúc tổng quan của hệ thống được xây dựng

Hình dưới đây mô tả sơ đồ cấu trúc tổng quan của hệ thống dùng để kiểm tra mộtchương trình Java hữu hạn có thỏa mãn một tính chất LTL nào đó hay không

Hình IV-4: Sơ đồ tổng quan hệ thống

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

v

Trong sơ đồ trên, LTL properties chính là các tính chất thời gian được viết dướidạng các công thức LTL Các công thức này đầu tiên được ghi vào trong các tệp Javabằng cách sử dụng chú thích Annotation có sẵn trong ngôn ngữ Java (1) Sau khi cáctệp mã nguồn Java này được biên dịch (2), nó được đưa vào thực thi tượng trưng bởiSPF (Symbolic Pathfinder – hệ thống hỗ trợ thực thi tượng trưng của JPF và sẽ được đềcập kỹ hơn ở phần sau) Trong khi các tệp Java bytecode được nạp vào trong máy ảocủa Java Pathfinder (3.1), chúng ta sẽ lấy ra các công thức LTL từ các chú thích (3.2) ởbước trước.

Công thức LTL này sau đó sẽ được dịch sang thành một automat hữu hạn trạng tháiFSA – Finite State Automata (4) Và sau đó, automat này sẽ được dùng để điều khiểnthực thi chương trình Java dựa trên một thuật toán điều khiển sẽ được mô tả kỹ hơn ởchương sau Việc điều khiển thực thi này được cài đặt thành một phần mở rộng củaJPF (jpf-ltl) có màu đỏ ở trên hình, nó có thể tương tác với JPF trong suốt quá trìnhthực thi và thực hiện các công việc kiểm chứng

Bởi vì chúng ta chỉ quan tâm tới các chương trình hữu hạn nên khi nó kết thúc, hoặc

bị lỗi ngay trong quá trình thực thi, jpf-ltl sẽ dừng chương trình và đưa ra các thôngbáo phù hợp

Sau đây, chúng ta sẽ tìm hiểu về cấu trúc cụ thể của hệ thống JPF và những côngnghệ chúng ta sẽ sử dụng trong quá trình phát triển hệ thống kiểm chứng này Cuốicùng, một cái nhìn tổng quan về cơ chế thực thi tượng trưng của JPF cũng sẽ được xemxét

IV.2 Java PathFinder (JPF)

JPF bắt đầu như một môi trường cho việc kiểm tra mô hình các chương trình Java

ở dạng tệp Java bytecode Nó bao gồm một máy ảo mới và kết hợp thêm nhiều kỹ thuậtkhác để giảm thiểu không gian trạng thái như Partial order reduction, symmetryreduction, abstraction,… Cho tới nay, nó đã phát triển thêm rất nhiều ứng dụng và phần

mở rộng khác nhau nhưng chức năng chính của JPF vẫn là kiểm tra mô hình

IV.2.1 Cấu trúc chính của JPF

Toàn bộ framework này được thiết kế xoay quanh hai thành phần chính là máy ảoJVM và đối tượng Search

Thứ nhất là JVM Máy ảo này chạy trên nền máy ảo Java thật, nó thực hiện các chỉthị Java bytecode và đồng thời sinh ra các trạng thái (state) cùng với đó là các lớp để

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

vi

quản lý không gian trạng thái này JVM có thể kiểm tra việc trùng lặp các trạng thái(matching) xem trạng thái đó đã được thăm hay chưa, có thể lưu lại trạng thái (storing)

để sau này có thể quay lại trạng thái đó (backtracking) và thực thi theo một đườngkhác

Đối tượng Search thì ta có thể coi nó như là bộ điều khiển hoạt động của JVM Nó

có trách nhiệm hướng dẫn JVM khi nào phải tạo ra trạng thái mới hay khi nào nênquay lại một trạng thái cũ đã được sinh ra trước đó Cứ như thế cho tới khi JVM thămhết tất cả các không gian trạng thái thì thôi Nó sử dụng thuật toán tìm kiếm theo độ sâuđơn giản ngoài ra còn có các kiểu tìm kiếm kinh nghiệm khác Chúng ta hoàn toàn cóthể tự tạo ra đối tượng Search cho mình bằng cách kế thừa lớp Search này và cài đặt

phương thức search() theo các thuật toán tìm kiếm mà ta mong muốn.

JPF áp dụng rất nhiều kỹ thuật khác nhau trong cài đặt của mình mà không thể nêuhết trong phạm vi báo cáo này Do đó ta chỉ nêu ra ba kỹ thuật đã dùng trong côngtrình nghiên cứu này và có thể sẽ dùng tiếp trong thời gian tới đó là Choice Generator,Property và Listener

Sinh viên thực hiện [Lê Anh Tùng – 20063601] Khóa 51 Lớp CNPM B xxx

vii