Kiểm tra tự động các phép tính số học trong chương trình c và java

Hiện tại, các nghiên cứu trong lĩnh vực này đang gặp hai khó khăn lớn trong việc kiểm chứng tự động sự đúng đắn của chương trình, đó là xử lý vòng lặp và xử lý số thực.. Nếu chỉ dừng lại

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

-

THÁI ĐẮC VINH

KIỂM TRA TỰ ĐỘNG CÁC PHÉP TÍNH SỐ HỌC

TRONG CHƯƠNG TRÌNH C VÀ JAVA

Chuyên ngành: Khoa học máy tính

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 06 năm 2010

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

Cán bộ hướng dẫn khoa học: TS QUẢN THÀNH THƠ

Cán bộ chấm nhận xét 1:

Cán bộ chấm nhận xét 2:

Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày

25 tháng 08 năm 2010

Thành phần hội đồng đánh giá luận văn thạc sĩ gồm:

1 PGS.TS TRẦN VĂN LĂNG

2 TS BÙI HOÀI THẮNG

3 TS NGUYỄN HỨA PHÙNG

4 TS NGUYỄN ĐỨC CƯỜNG

5 TS QUẢN THÀNH THƠ

Xác nhận của Chủ tịch Hội đồng đánh giá LV và Bộ môn quả lý chuyên ngành sau khi luận văn đã được sửa chữa

TRƯỜNG ĐẠI HỌC BÁCH KHOA TP HCM CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

PHÒNG ĐÀO TẠO SĐH Độc lập – Tự do – Hạnh phúc

- -

Tp HCM, ngày tháng năm

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: THÁI ĐẮC VINH Phái: Nam

Ngày, tháng, năm sinh: 20/06/1983 Nơi sinh: Hòa Thành – Tây Ninh

Chuyên ngành: Khoa học máy tính MSHV: 00708217

I- TÊN ĐỀ TÀI: Kiểm tra tự động các phép tính số học trong chương trình C và Java

II- NHIỆM VỤ VÀ NỘI DUNG:

 Nhiệm vụ:

 Xây dựng hệ thống kiểm chứng bài tập lập trình C và Java cho sinh viên

 Hỗ trợ việc kiểm chứng những chương trình số thực

 Hỗ trợ việc tìm lỗi và phản ví dụ trong việc kiểm chứng những chương trình số thực

 Nội dung:

 Tìm hiểu về kiểm chứng hình thức chương trình

 Nghiên cứu những khó khăn về xử lý số thực trong kiểm chứng chương trình và đề xuất giải pháp khắc phục

 Xây dựng hệ thống kiểm chứng dựa trên web

 Xây dựng giải thuật nguyên hóa chương trình số thực và hiện thực chương trình chuyển đổi

 Tích hợp giải pháp khắc phục vào hệ thống

 Tổng hợp, nhận xét và đề ra hướng phát triển trong tương lai

III- NGÀY GIAO NHIỆM VỤ: 25/01/2010

IV- NGÀY HOÀN THÀNH NHIỆM VỤ: 02/07/2010

V- CÁN BỘ HƯỚNG DẪN: TS QUẢN THÀNH THƠ

CN BỘ MÔN

TS Quản Thành Thơ

Lời cảm ơn

Tôi xin chân thành cảm ơn sự giảng dạy, hướng dẫn và giúp đỡ tận tình của tất

cả các Thầy Cô giảng dạy sau đại học - khoa Khoa học và Kỹ thuật máy tính trường đại học Bách Khoa thành phố Hồ Chí Minh

Xin chân thành cảm ơn sự giảng dạy tận tình của Thầy TS Nguyễn Hứa Phùng, người giảng dạy trực tiếp môn học ―Nguyên lý ngôn ngữ lập trình‖ và giới

thiệu cho tôi một đề tài nghiên cứu rất thú vị là kiểm chứng hình thức chương trình

Đặc biệt tôi xin chân thành cảm ơn Thầy TS Quản Thành Thơ, giảng viên

hướng dẫn luận văn Thạc Sĩ của tôi - người giảng dạy trực tiếp môn học ―Hệ thống thông minh‖ - trưởng nhóm nghiên cứu Prove mà tôi đang tham gia, đã tận tình hướng dẫn, giúp đỡ, dẫn dắt trong những ngày đầu mới tham gia nhóm, định hướng nghiên cứu và luôn cho tôi những giải pháp để xử lý mỗi khi tôi gặp trở ngại trong quá trình nghiên cứu làm luận văn Thạc Sĩ của mình

Tôi cũng rất biết ơn các Thầy cùng với các bạn trong nhóm nghiên cứu Prove

đã cung cấp cho tôi rất nhiều kiến thức trong lĩnh vực Kiểm chứng chương trình mà tôi đang thực hiện trong đề tài luận văn này

Ngoài ra, xin cảm ơn các bạn học lớp cao học khóa 2008, các bạn bè, đồng nghiệp, những người thân trong gia đình đã giúp đỡ, trao đổi kiến thức, tin tưởng, động viên tôi rất nhiều trong suốt quá trình học và thực hiện luận văn này

Xin chân thành cảm ơn!

Tp HCM, ngày 17 tháng 06 năm 2010

Học viên Thái Đắc Vinh

Software verification is a form of using logic and reasoning to show that the program will meet (or not) the requirements after executed without running tests on the computer Currently, researchs in this area are facing two major difficulties in verifying automatically the accuracy of programs; those are loop processing and handling floating-point

Because of loop obstacles, system proving certainly has to take a long time to become a commercial product and be widely used in the field of computer science

in general However, in education we absolutely can limit the problem in a narrow range, in which the verifying of a loop-program would become feasible However, problems of proving floating-point programs are blocking the implementation of projects applied in schools If we limit exercises in level of integer data type, the exercises given to students become less diverse and the teacher forced to skip a class of highly educational problems such as: calculating the circular perimeter or area; solving quadratic equations; or examining the conditions of the triangle

In this thesis I study the difficulties in verifying floating-point-program and implement a solution of converting program source code to support the automatic verification of floating-point-program in the field of education To illustrate for my work, I implement a software verification system, which includes solutions for floating-point problems, used to verify a simple C and Java program in the range of exercises for junior students Experimental results on some samples also showed the effectiveness of innovative solutions in handling of floating-point data type problems

Tóm tắt

Kiểm chứng hình thức chương trình là một cách dùng logic và suy luận để chỉ ra rằng chương trình sẽ thỏa mãn (hoặc không) yêu cầu đề ra sau khi được thực thi mà không cần chạy kiểm nghiệm trên máy tính Hiện tại, các nghiên cứu trong lĩnh vực này đang gặp hai khó khăn lớn trong việc kiểm chứng tự động sự đúng đắn của chương trình, đó là xử lý vòng lặp và xử lý số thực

Với trở ngại về lặp, chắc chắn còn phải rất lâu nữa việc kiểm chứng tự động chương chương trình mới trở thành một sản phẩm thương mại và được sử dụng rộng rãi trong lĩnh vực khoa hoc máy tính tổng quát Tuy nhiên, trong giáo dục ta hoàn toàn có thể giới hạn bài toán vào một phạm vi hạn hẹp mà trong đó việc kiểm chứng một chương trình có lặp sẽ trở nên khả thi Tuy vậy, trở ngại về kiểm chứng số thực hiện đã và đang cản trở việc triển khai các dự án về kiểm chứng chương trình trong trường học Nếu chỉ dừng lại ở mức số nguyên, thì các bài tập đưa ra cho sinh viên trở nên kém đa dạng và người giảng viên buộc phải bỏ qua một lớp các bài toán hay, mang tính giáo dục cao như: tính chu vi, diện tích hình tròn; giải phương trình bậc hai; kiểm tra những điều kiện của tam giác …

Trong đề tài luận văn này tôi nghiên cứu về những khó khăn trong kiểm chứng chương trình số thực và hiện thực một giải pháp chuyển đổi mã nguồn giúp tự động kiểm chứng chương trình số thực trong lĩnh vực giáo dục Để minh họa cho dự án của mình, tôi hiện thực một hệ thống dùng để kiểm chứng một cách tự động các chương trình C và Java trong phạm vi các bài tập lập trình của các sinh viên năm nhất, trong đó có xử lý được các bài tập số thực Kết quả thực nghiệm trên một số bài tập mẫu cũng đã chỉ ra sự hiệu quả của các giải pháp cải tiến trong việc xử lý các vấn đề số thực

Mục lục

Lời cảm ơn i

Mục lục iv

Danh mục hình viii

Danh mục bảng x

CHƯƠNG I Giới thiệu 1

1.1 Giới thiệu về kiểm chứng hình thức chương trình 2

1.2 Giới thiệu về các vấn đề xử lý số thực trong kiểm chứng chương trình 5

1.3 Mục tiêu và động lực nghiên cứu 6

CHƯƠNG II Tổng thuật các công trình nghiên cứu về kiểm chứng chương trình và xử lý các vấn đề số thực 9

2.1 Các nghiên cứu về kiểm chứng hình thức chương trình (formal verification) 9

2.2 Giới thiệu về một số công cụ dùng trong kiểm chứng chương trình 12

2.2.1 Công cụ Caduceus 12

2.2.2 Công cụ Frama-C 14

2.2.3 Công cụ Krakatoa 16

2.2.4 Công cụ Why 17

2.2.4 Công cụ Gappa 20

2.3 Giới thiệu về một số prover 21

2.3.1 Nhóm trợ giúp chứng minh tương tác (interactive proof assistants) 21

2.3.2 Nhóm chứng minh lý thuyết tự động (automatic theorem provers) 29

2.4 Các nghiên cứu xử lý số thực trong kiểm chứng chương trình 33

2.4.1 Nghiên cứu kết hợp Coq và Gappa để xử lý số thực trong việc kiểm chứng hình thức chương trình 33

2.4.2 Nghiên cứu dùng Redlog để xử lý các phép tính số 38

2.4.3 Nghiên cứu giải quyết số thực của nhóm tác giả Frama-C 39

CHƯƠNG III Cơ sở lý thuyết 46

3.1 Cở sở lý thuyết của chứng minh và kiểm chứng chương trình 46

3.2 Cơ sở lý thuyết của việc xử lý số thực trong kiểm chứng chương trình 52

3.3 Cơ sở lý thuyết về cách biểu diễn số thực theo chuẩn IEEE 754-1985 trong các chương trình C và Java 54

3.3.1 Định dạng cơ bản 55

3.3.2 Định dạng mở rộng 56

3.3.3 Chuẩn về biểu diễn dữ liệu 56

3.3.4 Cách làm tròn 57

3.3.5 Thực hiện các phép tính và so sánh 58

3.4 Lý thuyết về ngôn ngữ lập trình 59

3.4.1 Ngữ nghĩa hình thức chương trình (Formal Semantics) 59

3.4.2 Ngôn ngữ lập trình hàm và lập trình logic 60

3.5 Lập trình sinh lexer và parser bằng ngôn ngữ lập trình Ocaml 64

3.5.1 Giới thiệu về ngôn ngữ lập trình Caml và Ocaml 64

3.5.2 Lập trình sinh lexer và parser (ocamllex, ocamlyacc) 65

3.6 Lý thuyết về model checking 71

3.6.1 Quy trình xử lý của model checking 73

3.6.2 Các đặc điểm của model checking 74

Chương IV Giải pháp đề xuất cho việc nguyên hóa chương trình 77

4.1 Định nghĩa các thuật ngữ được sử dụng trong việc nguyên hóa 77

4.1.1 Định nghĩa 1 Scale: 77

4.1.2 Định nghĩa 2 Scale degree: 78

4.1.3 Định nghĩa 3 Scale level: 78

4.1.4 Một số nhận xét: 79

4.2 Các thao tác xử lý trong việc nguyên hóa 79

4.2.1 Cách xử lý các định danh kiểu floating-point trong chương trình 79

4.2.2 Cách scale up và scale down 80

4.2.3 Xử lý các tham số và biến kiểu floating-point 80

4.2.4 Xử lý trị floating-point 81

4.2.5 Xác định scale degree 81

4.2.6 Cách nhận ra scale level 82

4.2.7 Cân bằng level 83

4.2.8 Xử lý toán tử gán 83

4.2.9 Đổi tên biến, tham số và cân bằng lại level lần thứ hai 84

4.2.10 Xử lý phép casting về số nguyên 85

4.2.11 Xử lý các hàm được sử dụng trong chương trình 85

4.2.12 Xác định scale level của giá trị trả về 85

4.2.13 Xử lý hàm chính trong chương trình và biểu thức return 87

4.2.14 Giải quyết việc trùng tên 88

4.3 Giải thuật nguyên hóa 88

4.3.1 Thể hiện trên các bước thực hiện 88

4.3.2 Thể hiện trên các giai đoạn thực hiện 92

Chương V Hiện thực: Xây dựng hệ thống tự động kiểm chứng các bài tập lập trình C và Java của sinh viên 95

5.1 Giới thiệu về hệ thống 96

5.2 Hiện thực và tích hợp thành phần chuyển đổi vào hệ thống 98

5.2.1 Chức năng tiền xử lý nhằm hỗ trợ kiểm chứng số thực 99

5.2.2 Chức năng nguyên hóa nhằm hỗ trợ tìm điểm sai và phản ví dụ 103

5.2.3 Chi tiết về hiện thực của thành phần chuyển đổi 105

Chương VI Thực nghiệm và đánh giá kết quả 107

6.1 Hệ thống kiểm chứng chương trình trên nền website 107

6.2 Đánh giá cải tiến hỗ trợ xử lý số thực 110

6.3 Đánh giá kết quả giải pháp hỗ trợ tìm điểm sai và phản ví dụ 112

Chương VII Kết luận và hướng phát triển trong tương lai 115

7.1 Kết luận 115

7.1.1 Những đóng góp của luận văn 115

7.1.2 Những giới hạn thực hiện của luận văn và hạn chế của hệ thống hiện tại 115

7.2 Hướng phát triển trong tương lai 117

Tài liệu tham khảo 120 Phụ lục A - Chú giải các thuật ngữ P1 Phụ lục B - Các bài tập thử nghiệm P3

Phụ lục C - Một số trường hợp kiểm chứng thành công nhờ cải tiến tiền sử lý trong kiểm chứng số thực P14 Phụ lục D – Minh họa một số kết quả nguyên hóa chương trình P17 Phụ lục E - Giới thiệu về các chức năng của hệ thống kiểm chứng trên web P23 Phụ lục F - Cài đặt hệ thống kiểm chứng Why và các công cụ hỗ trợ kiểm chứng P31

Danh mục hình

Hình 2.1 Platform dùng để kiểm chứng ngôn ngữ C của nhóm ProVal 10

Hình 2.2 Hệ thống được đề xuất bởi nhóm Prove 11

Hình 2.3 Kiến trúc hệ thống của Frama-C 15

Hình 3.1 Định dạng chuỗi bit cho hai loại số floating-point 56

Hình 3.2 Lược đồ của quy trình kiểm chứng hệ thống dùng model checking 73

Hình 5.1 Cấu trúc hệ thống kiểm chứng trên nền web 95

Hình 5.2 Cấu trúc bên trong thành phần Automatic verification system 97

Hình 5.3 Sơ đồ cách cài đặt thành phần chuyển đổi vào hệ thống kiểm chứng 103

Hình 5.4 Quy trình tìm điểm sai và phản ví dụ cho chương trình số thực 104

Hình 6.1 Giao diện trang chủ website kiểm chứng chương trình 107

Hình 6.2 Giao diện trang làm bài tập cho sinh viên 108

Hình 6.3 Giao diện trang kết quả kiểm chứng bài tập sinh viên 109

Hình 6.4 Một trường hợp chương trình số thực bị kiểm thất bại trong hệ thống cũ. 111

Hình 6.5 Một trường hợp chương trình số thực sau khi chuyển đổi được kiểm chứng thành công 111

Hình 6.6 Một trường hợp khắc phục lỗi kiểm chứng số thực trong hệ thống trên web 112

Hình 6.7 Kết quả nguyên hóa một chương trình trong hệ thống 114 Hình P1 Giao diện trang đăng nhập vào hệ thống P23 Hình P2 Giao diện trang chủ của người dùng sinh viên P24 Hình P3 Giao diện trang chủ của người dùng giảng viên P24 Hình P4 Giao diện trang làm bài tập của sinh viên P25 Hình P5 Giao diện trang hiển thị kết quả kiểm chứng bài tập của sinh viên P25 Hình P6 Giao diện trang xem kết quả làm bài tập của sinh viên P26 Hình P7 Giao diện trang quản lý bài tập của sinh viên P27

Hình P8 Giao diện trang kiểm chứng giải pháp mẫu của giảng viên P27 Hình P9 Giao diện trang đánh giá bài tập và xem kết quả thống kê của giảng viên.

P28

Hình P10 Giao diện trang chủ của khách viếng thăm P29 Hình P11 Giao diện trang thông tin hệ thống của khách viếng thăm P29 Hình P12 Giao diện trang ―prove for you‖ dành cho khách viếng thăm P30

Danh mục bảng

Bảng 2.1 Các prover được hỗ trợ trong platform của Why 18

Bảng 3.1 Các tiên đề cho đẳng thức phép cộng và phép nhân trong toán học 47

Bảng 3.2 Các tiên đề Hoare dùng trong kiểm chứng chương trình 49

Bảng 3.3 Các bước chứng minh một chương trình minh họa 51

Bảng 3.4 Tổng kết các tham số định dạng cho từng loại số floating-point 55

CHƯƠNG I Giới thiệu

Các thuật ngữ kiểm chứng hay chứng minh chương trình đã dần trở thành những thuật ngữ quen thuộc trong lĩnh vực khoa học và kỹ thuật máy tính Kiểm chứng chương trình là một đề tài gây được rất nhiều sự quan tâm trong lĩnh vực khoa học máy tính Trong lĩnh vực phần mềm, một chương trình được kiểm chứng đúng đắn

sẽ giúp người dùng tin tưởng tuyệt đối vào kết quả mà nó mang lại, điều này cũng giúp tiết kiệm thời gian và công sức cho việc thử nghiệm chương trình theo cách truyền thống Trong lĩnh vực phần cứng, vấn đề còn tỏ ra cần thiết hơn Một lỗi trong sản xuất ROM hay các thiết bị phần cứng có thể dẫn đến thiệt hại rất lớn Vì vậy, một cách kiểm tra đánh giá sự đúng đắn của các sản phẩm phần cứng dựa trên việc phân tích logic trước khi đưa vào công xưởng để sản xuất hàng loạt luôn được các nhà sản xuất phần cứng quan tâm Trong lĩnh vực giáo dục và học thuật, việc kiểm tra và sửa sai cho từng chương trình được viết bởi từng sinh viên thì tốn nhiều thời gian và công sức, đồng thời làm cho việc giảng dạy của giảng viên kém hiệu quả Do đó, một chương trình tự động kiểm tra bài làm của sinh viên và báo cho họ biết chương trình của họ sai ở chỗ nào sẽ giải phóng giảng viên khỏi công việc sửa lỗi nhàm chán cho từng sinh viên, mà chỉ tập trung vào việc giảng lý thuyết và ra các đề bài tập hợp lý cho từng buổi học

Từ nhu cầu thiết thực đó, trong nhiều năm qua, không ít dự án đã được triển khai nhằm kiểm tra tính đúng đắn của chương trình Dù chưa thể công bố chính thức như một sản phẩm thương mại, nhưng ít nhiều cũng mang lại kết quả bước đầu trong lĩnh vực này và gợi mở hướng phát triển cho tương lai Những dự án đang tiếp tục nghiên cứu trong lĩnh vực này như: Why, Frama-C, Alt-ergo, HOL Light, ACL2, PVS, Isabelle, Coq …

1.1 Giới thiệu về kiểm chứng hình thức chương trình

Kiểm chứng hình thức chương trình là một cách dùng logic và suy luận để chỉ ra rằng chương trình sẽ thỏa mãn (hoặc không) yêu cầu đề ra sau khi được thực thi mà không cần chạy kiểm nghiệm trên máy tính Nhu cầu về việc kiểm chứng chương trình là một nhu cầu tự nhiên, và có lẽ nó xuất phát ngay từ khi người ta nghĩ đến việc viết chương trình cho máy tính thực hiện những quy trình xử lý thay cho con người Chỉ có điều, người ta không nghĩ là có thể hiện thực được việc kiểm chứng một cách hình thức và tự động trong những buổi đầu của ngành khoa học và kỹ thuật máy tính Cho đến tận gần đây, khi mà việc sản xuất phần mềm đã trở thành một ngành công nghiệp thì nhu cầu của việc kiểm định chương trình mới thực sự được đặt ra cấp thiết như những nhu cầu kiểm định chất lượng sản phẩm trong bất

đó, nhiều loại ứng dụng lại đòi hỏi sự đảm bảo chắc chắn như các ứng dụng trong lĩnh vực năng lượng, hàng không hay điều trị bệnh … Từ nhu cầu này đã thúc đẩy nhiều dự án nghiên cứu nhằm tìm ra một phương pháp chứng minh chương trình một cách hình thức để đảm bảo sự đúng đắn tuyệt đối chứ không chỉ dừng ở mức chỉ hạn chế lỗi

Đã có nhiều dự án được triển khai và bước đầu đạt được những kết quả đáng ghi nhận trong lĩnh vực kiểm chứng chương trình Có thể kể ra như nhóm nghiên

cứu ProVal của viện nghiên cứu INRIA của Pháp, FV Group của trường đại học Oxford hay Automated Reasoning Group của trường đại học CamBridge Hầu hết cách tiếp cận của các nhóm này là chuyển đổi chương trình cần kiểm chứng thành một dạng biểu diễn luận lý rồi sau đó dùng các công cụ để chứng minh chương trình dạng luận lý đó là đúng hay sai Các công cụ này có hai dạng: dạng hỗ trợ chứng minh theo kiểu tương tác (proof assistant) như Coq, Isabelle, PVS và dạng chứng minh tự động (automatic prover) như Simplify, Alt-Ergo, Z3 Để tiện đề cập trong bài viết này tôi gọi chung hai dạng này là prover Prover thực chất là một chương trình hay một mô-đun có khả năng suy diễn logic được gắn vào trong hệ thống kiểm chứng chương trình Mỗi prover có thể dựa trên một nền tảng lý thuyết logic khác nhau, do đó, có điểm mạnh và điểm yếu khác nhau Một prover có thể làm việc tốt trên lớp bài toán này nhưng lại kém hiệu quả trong những lớp bài toán khác

Một prover khi xử lý một bài toán thường cho ra một trong ba câu trả lời: đúng (valid), sai (invalid) hay không biết (unknown) Hơn nữa, do đặc điểm là dựa trên chứng minh toán học, nên khi prover trả lời đúng (hay sai) với một bài toán thì chắc chắn bài toán đó là đúng (hay sai) Khả năng của prover chỉ giới hạn khi nó trả lời là không biết Vì đặc điểm này, ta hoàn toàn có thể kết hợp nhiều prover lại với nhau

để giải quyết cùng một bài toán Nếu một trong số các prover kết luận là đúng hay sai, bài toán của chúng ta xem như được kiểm chứng đúng hay sai tương ứng Như vậy phần công việc mà các nhóm nghiên cứu tập trung phát triển chính là tìm cách tăng cường sức mạnh cho prover và kết hợp nhiều prover khác nhau để tăng sức mạnh kiểm chứng Mỗi prover có một điểm mạnh riêng và sự kết hợp giữa chúng với nhau sẽ giúp giải quyết được các lớp bài toán rộng hơn

Hiện nay đã có một số prover được đánh giá cao trong lĩnh vực kiểm chứng chương trình cũng như vẫn đang dần phát triển bởi những người phát triển rất nhiệt tình, sẵn sàng nhận ý kiến đóng góp để nâng cấp hoàn thiện cho chúng, cũng như sẵn sàng giúp đỡ những người có quan tâm muốn sử dụng chúng Có thể liệt kê một

vài prover trong số này như: Simplify, Alt-Ergo, Z3, Coq, Isabelle, PVS … Trong phần tiếp theo, tôi sẽ giới thiệu qua một số prover tiêu biểu cũng như một số dự án đang được triển khai có sử dụng chúng

Để kiểm chứng một chương trình C hay Java (hay có thể là một ngôn ngữ khác nữa) người ta cần mô tả các thông tin về logic tiên đề cho chương trình đó Phần cơ

bản của đặc tả ngữ nghĩa tiên đề cho một chương trình là tiền điều kiện và hậu điều kiện Tiền điều kiện là yêu cầu đầu vào của chương trình, đây là những yêu cầu cần

phải có trước khi thực thi chương trình để đảm bảo kết quả được như mong muốn Hậu điều kiện là kết quả mong muốn của người dùng về giá trị trả về của chương trình Hay nói cách khác, hậu điều kiện là kỳ vọng đầu ra mà người dùng mong muốn ở chương trình sau khi nó được thực hiện Như vậy, với một chương trình đã được mô tả về tiền điều kiện và hậu điều kiện, việc kiểm chứng chương trình được hiểu đơn giản là dùng logic toán học để kiểm tra xem liệu với xuất phát ban đầu là tiền điều kiện chương trình, qua các thao tác xử lý trong phần thân chương trình sẽ dẫn đến kết quả là hậu điều kiện của chương trình hay không Một ví dụ đơn giản là

bài toán tính thương số của hai số, bài toán này nhận vào hai số x, y và trả về số r là kết quả của x chia y Thì tiền điều kiện của bài toán là y ≠ 0 và hậu điều kiện là r =

Về cách thể hiện thì các đặc tả ngữ nghĩa này thường là dạng logic vị từ first-order

logic vì tính mạnh mẽ trong việc biểu diễn ngữ nghĩa và ràng buộc của loại logic này

1.2 Giới thiệu về các vấn đề xử lý số thực trong kiểm chứng chương trình

Số thực nhìn nhận thuần túy theo toán học là một số có thể có dạng biểu diễn vô tận nên chỉ thể hiện được thông qua một công thức toán học hay trong ý niệm Vì vậy trong khoa học máy tính người ta đã dùng hình thức biểu diễn gần đúng dưới dạng

số floating-point để có thể lưu trữ và tính toán trên các số này Chuẩn floating-point được áp dụng phổ biến cho số thực hiện nay là chuẩn IEEE 754 [28, 29, 30] Những sai biệt trong cách biểu diễn trên máy tính và giá trị thực của bản thân số đó là rất nhỏ và không đáng kể trong các chương trình thông thường Tuy nhiên, trong lĩnh vực kiểm chứng và chứng minh chương trình, điều này lại phát sinh một khó khăn rất lớn Do việc kiểm chứng dựa trên chứng minh logic chương trình nên một sai khác dù rất nhỏ của giá trị mong chờ với giá trị trả về cũng có thể được trình kiểm chứng cho là thất bại, và vấn đề của việc biểu diễn số thực như đề cập trên là nguyên nhân sinh ra sự thất bại này

Ví dụ, xét việc kiểm chứng một chương trình đơn giản sau đây:

/*@ requires a != 0;

@ ensures \result == \sqrt (delta) / (2 * a) ; */

double sqrt_delta(double delta, double a){

double c = sqrt (delta) / (2 * a);

return c;

}

Trong chương trình trên, ta mong muốn kết quả trả về là delta 2/ a, nhưng giá trị trả

về chứa trong biến kiểu floating-point được biểu diễn theo dạng chuẩn IEEE 754 là

hiện trên máy tính Kết quả là, trình kiểm chứng sau khi phân tích logic sẽ trả lời chương trình sai mặc dù về logic lập trình chương trình không có sai sót nào

Phân tích về các lỗi do vấn đề số thực, người ta đã đưa ra hai lỗi cơ bản của số floating-point Thứ nhất, các thao tác tính toán trên số này sẽ trả về kết quả là một

số thực, và như trên, số thực kết quả này sẽ được làm tròn về số floating-point Kết quả là, tổng hợp các thao tác tính toán trên số floating-point không trả về chính xác

kết quả mong muốn Người ta gọi lỗi này là rounding error Thứ hai, có những

phép tính số học không thể biểu diễn bằng tổng hợp các phép tính số học cơ bản trên các số thực, như phép tổng vô hạn chẳng hạn, sẽ sinh ra một hình thức tính toán không chính xác và vì vậy kết quả trả về cũng không như mong muốn Người ta gọi

lỗi này là method error Với hai lỗi như vậy, rõ ràng một chương trình có số thực

gây ra sự phức tạp cho việc kiểm chứng tính đúng đắn và khó biết được liệu chương trình có trả về được kết quả mong muốn hay không khi kiểm tra hình thức

Ngoài việc gây ra khó khăn trong kiểm chứng chương trình, các số thực còn gây trở ngại trong việc tìm ra lỗi sai và phản ví dụ Trong hệ thống kiểm chứng của nhóm nghiên cứu Prove, nếu việc kiểm chứng chương trình thất bại thì hệ thống sẽ nhờ một thành phần thứ hai để tìm lỗi và chỉ ra phản ví dụ Thành phần thứ hai này

dùng model checker SPIN (xem mục 3.6), vốn không làm việc tốt trên các chương

trình số thực Như vậy, một chương trình số thực sẽ dễ bị kiểm chứng thất bại hơn

và khi thất bại lại khó tìm ra lỗi sai và sinh ra phản ví dụ hơn Do vậy, các nghiên cứu cải tiến trong việc kiểm chứng số thực phải bao gồm cả việc cải tiến khả năng kiểm chứng lẫn hỗ trợ cho các model checker (như SPIN) tìm phản ví dụ cho chương trình số thực

1.3 Mục tiêu và động lực nghiên cứu

Các vấn đề về số thực như trình bày ở trên đang gây cản trở cho việc kiểm chứng chương trình Hầu hết các prover hiện tại đều tránh việc xử lý trên số thực mà chỉ tập trung giải quyết các bài toán số nguyên Trong khi đó, các chương trình có số

thực cần được kiểm chứng là rất nhiều vì hầu hết những chương trình ứng dụng trong thực tế đều có dùng kiểu số thực

Hiện nay, cũng có một số giải pháp về xử lý vấn đề số thực này Tuy nhiên tất

cả các đề xuất này đều ở dạng tương tác giữa người dùng và trình chứng minh vì bản chất của vấn đề số thực là phức tạp và cần sự can thiệp của con người

Tại trường Đại Học Bách Khoa TP.HCM, nhóm nghiên cứu Prove do thầy Quản Thành Thơ chủ trì cũng đang gặp trở ngại trong việc xử lý số thực Đây là nhóm nghiên cứu về kiểm chứng hình thức chương trình và ứng dụng xây dựng một website giúp kiểm chứng bài tập lập trình của các sinh viên năm nhất Đến nay, nhóm nghiên cứu này đã phần nào đạt được những kết quả ban đầu và hệ thống đã chạy ổn định (kiểm chứng tốt) trên tập bài tập lập trình mẫu Tuy nhiên, do trở ngại trong việc xử lý số thực, hiện tại nhóm này vẫn đang áp dụng một cách hạn chế những bài tập có sử dụng số thực vốn rất hay về mặt học thuật và mang tính giáo dục cao như: tính chu vi, diện tích hình tròn; giải phương trình bậc hai; kiểm tra điều kiện của tam giác vuông …

Trong đề tài luận văn này, tôi tìm hiểu sự khó khăn của việc xử lý số thực trong kiểm chứng tự động chương trình và đề xuất một giải pháp chuyển đổi nguyên hóa chương trình để hỗ trợ giải quyết những trở ngại đó Mục tiêu của dự án

là thực hiện hai công việc sau:

Thứ nhất, tôi nghiên cứu và tìm ra một cách chuyển đổi chương trình để hỗ trợ cho việc kiểm chứng các chương trình số thực trong tập các bài tập mẫu của nhóm nghiên cứu Prove

Thứ hai, và cũng là phần công việc trong tâm trong dự án này là tôi nghiên cứu và đề xuất một giải pháp nguyên hóa chương trình số thực nhằm hỗ trợ việc tìm ra điểm sai và sinh phản ví dụ cho các chương trình số thực

Ngoài ra, để kiểm tra và minh họa cho kết quả nghiên cứu của mình, tôi xây dựng một hệ thống dựa trên web để kiểm chứng chương trình C và Java Hệ thống này mô phỏng theo hệ thống dựa trên web của nhóm nghiên cứu Prove Các bài mẫu dùng để test cũng sẽ chuyển từ các bài tập mẫu hiện tại đang dùng để test trong nhóm nghiên cứu này cộng thêm một số bài điển hình về số thực vì mong rằng kết quả xử lý số thực trong dự án của tôi có thể áp dụng ngay vào cho các bài toán có số thực mà nhóm nghiên cứu Prove đang gặp trở ngại Đồng thời, từ lớp bài toán đã giải quyết được, tôi sẽ suy rộng ra một cơ sở nền tảng để xử lý số thực cho một lớp bài toán rộng hơn và mở hướng nghiên cứu phát triển trong tương lai

CHƯƠNG II Tổng thuật các công trình nghiên cứu về kiểm chứng chương trình và xử lý các vấn đề số thực

Hiện nay, trong lĩnh vực phần mềm, có nhiều nhóm nghiên cứu về kiểm chứng chương trình và ít nhiều đều gặp trở ngại trong vấn đề xử lý số thực

2.1 Các nghiên cứu về kiểm chứng hình thức chương trình (formal verification)

Đã có nhiều công trình nghiên cứu về kiểm chứng chương trình đang tiến triển trên thế giới Điển hình như nhóm nghiên cứu ProVal của INRIA của Pháp, FV Group của trường đại học Oxford, Automated Reasoning Group của trường đại học CamBridge hay nhóm nghiên cứu Prove của Thầy Quản Thành Thơ tại trường đại học Bách Khoa TP HCM

Theo đề xuất của ProVal, họ xây dựng một platform với nhiều thành phần kết

hợp Hình 2.1 minh họa mô hình của platform kiểm chứng được đề xuất bởi nhóm

nghiên cứu này để kiểm chứng ngôn ngữ C Tầng trên cùng là một chương trình chuyển từ mã nguồn C (đã được chú thích các phát biểu điều kiện để kiểm chứng chương trình) sang ngôn ngữ trung gian Chương trình này là Caduceus dành cho C

và Kratatoa cho Java Tiếp đến hệ thống dùng một platform khác là Why để dịch ngôn ngữ trung gian này thành một dạng ngôn ngữ logic mà từ đó có thể kiểm chứng sự đúng sai bằng các prover Output của giai đoạn này người ta gọi là các điều kiện kiểm chứng (Verification conditions) Tiếp theo ta có thể kết hợp nhiều prover khác nhau để kiểm chứng sự đúng đắn của các điều kiện kiểm chứng này Nếu một prover trả lời là đúng thì mã nguồn ban đầu được đảm bảo sẽ trả về kết quả mong muốn nếu được cung cấp đúng điều kiện ban đầu, ngược lại nếu prover trả lời sai mã nguồn ban đầu đã sai logic và không thỏa mãn kết quả mong muốn ít

nhất trong một vài trường hợp nào đó Tuy vậy không phải lúc nào prover cũng trả

về kết quả là đúng hay sai Nếu logic của chương trình nguồn vượt ra ngoài khả năng của một prover, nó sẽ trả lời là không biết và chưa thể kết luận được gì từ prover này Vì thế, người ta thường kết hợp nhiều prover lại với nhau Mỗi prover được xây dựng dựa trên một nền tảng logic riêng vì thế thường có điểm mạnh và điểm yếu riêng Mỗi prover thường tỏ ra hiệu quả cho một lớp bài toán hay khả năng xử lý và vì thế hệ thống càng nhiều prover càng có nhiều khả năng nhận về kết quả đúng hay sai hơn

Nhóm Automated Reasoning Group tập trung cho việc xây dựng và áp dụng các phương pháp chứng minh lý thuyết Nhóm này chủ yếu nghiên cứu xây dựng ra

hệ thống các công cụ suy diễn logic hay các prover Trong lĩnh vực kiểm chứng

File mã nguồn C

Caduceus

Why

Các điều kiện kiểm chứng

Hình 2.1 Platform dùng để kiểm chứng ngôn ngữ C của nhóm ProVal

Công cụ trợ giúp chứng minh

(Coq, Isabelle, PVS, …)

Công cụ kiểm chứng tự động (Simplify, Alt-Ergo, Z3, …)

phần cứng, nhóm đã xây dựng được công cụ HOL HOL là hệ thống suy diễn higher-order logic mạnh mẽ và rất hứu ích trong việc việc kiểm chứng phần cứng Hiện J Harrison, một thành viên của nhóm nghiên cứu này, vẫn đang nghiên cứu sử dụng HOL cho việc kiểm chứng các xử lý số thực về phần cứng cho hãng sản xuất phần cứng máy tính Intel Nhóm này cũng đang tập trung nghiên cứu việc gắn kết HOL vào làm prover cho các chương trình kiểm chứng khác Một dự án đang tiến hành là việc tích hợp kiểm chứng hình thức vào một công cụ đưa ra ứng dụng công nghiệp CAD/CASE tool Một thành tựu khác của nhóm nghiên cứu này là việc khai sinh ra một prover nổi tiếng và mạnh mẽ trong lĩnh vực kiểm chứng hình thức chương trình là Isabelle Khác với HOL được xây dựng dành riêng cho kiểm chứng phần cứng, Isabelle được xây dựng dựa trên cơ chế suy luận tổng quát và hỗ trợ suy diễn cho nhiều lĩnh vực khác nhau Hiện Isabelle được dùng như một công cụ suy diễn toán học mạnh mẽ trong hệ thống kiểm chứng chương trình và đang được nhóm này sử dụng để kiểm chứng mức độ an toàn của các giao thức mã hóa Cả hai công cụ trên hiện đã rất nổi tiếng trên thế giới và được nhiều nhóm nghiên cứu khác

sử dụng trong hệ thống của mình

Axiom

Processing

Information Exchange Analysis Module

Counter-Example Generation

Cơ sở dữ liệu XML

Problem

Description

Correctness

Proving

Điều phối viên

Hình 2.2 Hệ thống được đề xuất bởi nhóm Prove

Sinh viên Giảng viên

Hệ thống tương tác dựa trên nền web

Nhóm nghiên cứu Prove của Thầy Quản Thành Thơ ở trường đại học Bách Khoa đề xuất một framework để kiểm chứng bài tập lập trình của các sinh viên một cách tự động (xem chi tiết trong [1]) Dự án này xuất phát từ ý tưởng giúp sinh viên học lập trình (nhất là các sinh viên năm nhất) có một môi trường rèn luyện kỹ năng lập trình hiệu quả hơn Mô hình của hệ thống trong dự án này được mô tả trong

hình 2.2 Trong đó có 3 loại người làm việc với hệ thống là giảng viên, sinh viên và

điều phối viên Đầu tiên, giảng viên sẽ đưa ra những bài tập lập trình được mô tả

trong dạng ngữ nghĩa tiên đề trong thành phần ―Problem Description‖ Sau đó,

người học có thể vào hệ thống và giải các bài tập này Bài làm gửi lên cho hệ thống

được kiểm chứng nhờ thành phần ―Correctness Proving‖ Thành phần này được

xây dựng theo mô hình tương tự như đề xuất của nhóm ProVal ở hình 2.1 trên Nếu

thành phần kiểm chứng này cho rằng chương trình sai, hệ thống sẽ chuyển nó sang

phần ―Counter-Example Generation‖ để đưa ra những ví dụ điển hình cho trường

hợp chương trình này không thỏa mãn yêu cầu dựa trên model checking Các thông tin về thống kê của hệ thống như các lỗi thường gặp hay các lần vào làm bài tập của

sinh viên sẽ được lưu giữ và phân tích trong thành phần ―Analysis Module‖ Các

thông tin này sẽ giúp cho người điều phối viên đánh giá hiệu quả của khóa học Để thuận tiện trong việc trao đổi thông tin giữa các thành phần trong hệ thống, dữ liệu trong hệ thống được lưu trữ dưới dạng XML và trao đổi thông qua thành phần

―Information Exchange‖

2.2 Giới thiệu về một số công cụ dùng trong kiểm chứng chương trình

2.2.1 Công cụ Caduceus

Caduceus [5] là công cụ dùng cho kiểm chứng chương trình ngôn ngữ C ở mức độ

mã nguồn Mã nguồn C chuyển qua Caduceus sẽ được kiểm tra trên hai mức độ:

đầu tiên, mã nguồn này được kiểm tra lỗi (như null-pointer hay out-of-bound array)

và thứ hai là được kiểm chứng chức năng xem có thỏa mãn các điều kiện mô tả trong phần chú thích của chương trình hay không Các chú thích cho chương trình bao gồm mô tả tiền điều kiện, hậu điều kiện, bất biến toàn cục, bất biến vòng lặp, v.v., theo logic nền tảng của Hoare Các chú thích có vai trò mô tả trong việc kiểm chứng chương trình được viết theo cú pháp /*@ … */ dưới dạng first-order logic

Một ví dụ điển hình về dạng chú thích cho hàm math_mod theo kiểu mẫu của

int math_mod(int x, int y) { }

Từ khóa requires chỉ định tiền điều kiện của chương trình, đây là yêu cầu mà chương trình phải được thỏa mãn trước khi thực thi Từ khóa ensures chỉ định hậu

điều kiện của chương trình, đây là kết quả mà người ta mong chờ nó sẽ trả về sau khi thực thi

Khi một chương trình C được cung cấp đầy đủ các thông tin về logic tiên đề như tiền điều kiện và hậu điều kiện, Caduceus thực hiện phân tích và chuyển vào cho Why để sinh ra các điều kiện kiểm chứng (verification conditions) Các điều kiện kiểm chứng là những phát biểu luận lý thể hiện cho mã chương trình và có lồng ghép các phát biểu logic tiên đề vào để có thể được kiểm chứng sự đúng đắn theo logic toán học Đặc điểm chính của Caduceus là tính độc lập với các prover

Nó hỗ trợ một lượng rất lớn các prover từ các prover thuộc loại trợ giúp chứng minh như Coq, PVS, Isabelle đến loại chứng minh lý thuyết tự động như Simplify, Yices, CVC Lite

Hiện tại dự án nghiên cứu Caduceus đã dừng phát triển công cụ này Thay vào

đó nhóm nghiên cứu chủ quản tập trung xây dựng một công cụ thay thế (có thể xem như phiên bản tiếp theo của Caduceus) là Frama-C Dù mới ra đời nhưng Frama-C được cho là có nhiều khả năng mạnh mẽ hơn so với Caduceus nhất là trong lĩnh vực phân tích và xử lý số thực

2.2.2 Công cụ Frama-C

Frama-C [7, 8] có thể xem như phiên bản tiếp theo của Caduceus và đang được phát triển bởi hai nhóm nghiên cứu: Software Reliability Laboratory của CEA-LIST và ProVal của INRIA-Saclay Với nền tảng và phương pháp tiếp cận được tiếp nối từ Caduceus cùng với việc bổ sung nhiều điểm mạnh khác, Frama-C có thể xem là sự thay thế hoàn hảo cho Caduceus trong tương lai Về cách biểu diễn các điều kiện kiểm chứng, Frama-C sử dụng ngôn ngữ ACSL (ANSI C Specification Language) được cho là mạnh mẽ hơn và là một cải tiến hơn so với phiên bản cũ Caduceus Dựa trên ACSL, Frama-C có thể đặc tả tốt hơn về xử lý số thực trong khi kiểm chứng chương trình và vì thế khi kết hợp với một số prover mạnh mẽ như ergo, Frama-C

đã có thể giải quyết khá tốt số thực

Dù mới ra đời và tỏ ra chưa thật ổn định, nhưng bù lại Frama-C lại cung cấp nhiều đặc tính mạnh mẽ hướng tới việc giải quyết số thực và nhiều đặc điểm kiểm chứng chương trình khác như khai báo tiên đề, contract code …

Hơn nữa, Frama-C còn là một dự án đang phát triển Các tác giả rất nhiệt thành sẵn sàng nhận ý kiến phản hồi và khắc phục yếu điểm liên tục thông qua các phiên bản cập nhật Hiện Frama-C vừa tung ra phiên bản Frama-C Boron 20100401 với hy vọng tiến thêm một bước trong kiểm chứng chương trình và xử lý số thực

Tuy nhiên qua kiểm tra, phiên bản này vẫn chưa ổn định nên trong hệ thống của mình tôi vẫn sử dụng phiên bản cũ ổn định hơn là Frama-C Beryllium 20090902

Frama-C được gắn vào Why thông qua plug-in Jessie Như vậy, chương trình

C được đặc tả các điều kiện kiểm chứng bằng ACSL sẽ được chuyển qua ngôn ngữ trung gian jessie Sau đó, nhờ một plug-in Jessie2Why để chuyển thành ngôn ngữ

Why như trong hình 2.3 Từ đây, cũng giống như trong Caduceus, Why sẽ sinh ra

các điều kiện kiểm chứng và nhờ các prover kiểm chứng tính đúng đắn của chương trình

Đặc điểm đáng chú ý khác của Frama-C là nhóm phát triển dự án cho phép người sử dụng có thể tự tạo plug-in và gắn vào Frama-C Đây cũng có thể được xem

là một hướng tiếp cận trong vấn đề xử lý số thực mà những người nghiên cứu về kiểm chứng chương trình đang phải đối mặt

Hình 2.3 Kiến trúc hệ thống của Frama-C

2.2.3 Công cụ Krakatoa

Giống như Caduceus và Frama-C ở ngôn ngữ C, Krakatoa [6] là công cụ kiểm chứng chương trình Java Chú thích trong chương trình được viết dưới dạng JML (Java Modeling Language) Sau khi được phân tích bởi Krakatoa, kết quả xuất ra của mã nguồn Java sẽ được Why xử lý và sinh ra các các điều kiện kiểm chứng (Verification Conditions)

Cách thức dùng chú thích để đặc tả logic tiên đề cho chương trình cũng gần như tương tự với cú pháp của Caduceus sử dụng cho ngôn ngữ C Phần chú thích có

ý nghĩa đặc biệt này được đặt trong /*@ … */ Thử xem qua một ví dụ kiểm chứng

thủ tục tìm max trong chương trình Java có chú thích đặc biệt sau đây:

public class Lesson1 {

/*@ ensures \result >= x && \result >= y &&

@ \forall integer z; z >= x && z >= y ==> z >= \result; @ */

public static int max(int x, int y) {

if (x>y) return x; else return x;

}

}

Theo ví dụ trên, mệnh đề ensures chỉ định hậu điều kiện, \result chỉ định giá

trị mà phương thức sẽ trả về, và như vậy phần đặc tả trong chú thích trên có ba

nghĩa sau đây: thứ nhất, kết quả trả về luôn lớn hơn hoặc bằng x; thứ hai, kết quả trả

về luôn lớn hơn hoặc bằng y; và cuối cùng, kết quả trả về là giá trị nhỏ nhất trong tất cả các giá trị lớn hơn hoặc bằng cả x lẫn y

Đoạn mã Java trên khi đưa vào Krakatoa sẽ được công cụ này kiểm tra cú pháp và sau đó sinh ra các điều kiện kiểm chứng của công cụ này Đến đây thì cũng giống như Caduceus với ngôn ngữ C, phần việc còn lại sẽ được chuyển cho Why và cuối cùng là nhờ đến các prover để kiểm chứng sự đúng sai của chương trình

2.2.4 Công cụ Why

Được đề xuất và chịu trách nhiệm xây dựng bởi J.C Filliâtre ở LRI, tên Why của công cụ này là ngụ ý của tác giả nhằm làm cho chương trình máy tính không chỉ hướng dẫn cách (how) máy tính thực hiện để chuyển từ input thành output mà còn cho máy tính biết tại sao (why) chương trình xử lý như vậy là đúng với yêu cầu

Về cơ bản, công cụ Why [2] nhận vào chương trình được chú thích và được viết bằng một dạng ngôn ngữ riêng biệt Những chương trình được viết bằng ngôn ngữ lập trình khác nhau có thể nhờ một số công cụ chuyển về ngôn ngữ này Các công cụ chuyển đổi thường dùng như Caduceus và Frama-C với ngôn ngữ C hay Krakatoa với ngôn ngữ Java Tiếp đến Why sẽ sinh ra các điều kiện kiểm chứng và gửi chúng cho các prover (nhóm proof assistant như Coq, PVS, v.v hay nhóm automatic theorem prover như Simplify, CVC Lite, v.v) Các prover được hỗ trợ bởi

Why được mô tả trong bảng 2.1

Why có những đặc điểm và điểm mạnh chính sau đây:

Nó là một công cụ sinh ra điều kiện kiểm chứng (verification condition generator viết tắt là VCG) cho một ngôn ngữ được thiết kế đặc biệt dành riêng Trong ngôn ngữ này có bao hàm các cấu trúc cơ bản của một mô hình ngôn ngữ lập trình và các chú thích luận lý tiên đề (như tiền điều kiện, hậu điều kiện, bất biến vòng lặp, xác nhận trung gian v.v)

Công cụ này cho phép khai báo những mô hình luận lý (kiểu, hàm, vị từ, tiên đề) có thể được sử dụng trong chương trình và chú thích kiểm chứng chương trình Vì thế, đây là một VCG mạnh mẽ Chẳng hạn, một người muốn mô hình một sự tính toán số học có độ chính xác giới hạn, người này đơn giản chỉ cần khai báo một kiểu mới và các toán tử tương ứng

Why hỗ trợ một số lượng lớn các prover Vì vậy các điều kiện kiểm chứng

có thể được giải quyết bởi nhiều prover một cách độc lập Thực tế Why được

sử dụng như điểm trước (front-end) của các prover này và cơ chế sinh điều kiện kiểm chứng cũng không phụ thuộc vào bất kì prover nào Verification condition của Why là một dạng cú pháp first-order logic chung cho các prover này

Bảng 2.1 Các prover được hỗ trợ trong platform của Why

Hãy xem qua một ví dụ đơn giản của Why

logic min: int, int -> int

parameter r: int ref

let f (n:int) = r := min !r n { r <= r@ }

Đoạn mã này khai báo một hàm min Trong Why thì bất kỳ hàm nào cũng phải

được khai báo mới có thể được sử dụng trong các phần sau Dòng tiếp theo khai báo một tham số, đây là giá trị được giả định là có tồn tại trong môi trường của hàm mà

nó được khai báo Ở đây tham số được khai báo là r và có kiểu là tham chiếu

integer Dòng thứ ba khai báo hàm f nhận một đối số n integer (một kiểu phải được cung cấp nếu Why không thể suy diễn kiểu) và gán cho r là min !r n Hàm f không

có đặc tả tiền điều kiện mà chỉ có một hậu điều kiện thể hiện rằng giá trị cuối cùng

của r nhỏ hơn hoặc bằng giá trị ban đầu r@ Như vậy đoạn mã trên của Why là cách định nghĩa hàm min hai đối số bằng cách nhận vào từng đối số một

Giả sử rằng đoạn mã trên được lưu vào file test.why Ta có thể kiểm chứng

chương trình trên với Coq bằng dòng lệnh sau:

why coq test.why

Một file test_why.v sẽ được sinh ra sau khi thực hiện dòng lệnh trên và có nội dung

why simplify test.why

Tuy nhiên với chương trình trên Simplify không thể chứng minh thành công vì

không biết ý nghĩa của hàm min

Simplify test_why.sx

1: Invalid

Người dùng có thể bổ sung thêm định nghĩa tiên đề cho hàm min trong đoạn mã trên như sau:

logic min: int, int -> int

axiom min_ax: forall x,y:int min(x,y) <= x

parameter r: int ref

let f (n:int) = {} r := min !r n { r <= r@ }

Và với chương trình này Simplify có thể chứng minh thành công

why simplify test.why

Công cụ này thao tác trên các công thức luận lý trong đó các biểu thức được bao trong một khoảng Ví dụ chứng minh hình thức cho tính chất

c [-0.3, -0.1] (2a [3,4]  b + c [1,2]) a – c [1.9, 2.05]  b +1 [2,3.5]

sẽ được sinh ra nhờ vào kịch bản Gappa sau đây:

{

Về lĩnh vực kiểm chứng chương trình, Gappa chưa thể được xem là một prover vì chưa có khả năng kiểm chứng và đánh giá đúng sai một chương trình Tuy nhiên với khả năng xử lý số thực rất mạnh của mình Gappa có thể là một tactic đắc lực cho Coq trong việc xử lý số thực

2.3 Giới thiệu về một số prover

2.3.1 Nhóm trợ giúp chứng minh tương tác (interactive proof assistants)

2.3.1.1 PVS

PVS [9] là viết tắt của cụm từ ―Prototype Verication System‖ và như mô tả qua tên,

nó là một môi trường mẫu cho việc đặc tả và chứng thực Mục đích của PVS là cung cấp một sự hỗ trợ hình thức cho việc ý niệm hóa và debug lỗi trong giai đoạn đầu của quy trình thiết kết hệ thống phần cứng và phần mềm Trong giai đoạn này, các yêu cầu và thiết kế được thể hiện ở mức trừu tượng và không nhất thiết khả thực thi Vì thế PVS được xây dựng nhằm mục đích phân tích những đặc tả trừu tượng này và chứng minh được sự thỏa yêu cầu đề ra

Điểm nổi bậc của PVS là các cấu trúc chứng minh có tính dễ đọc vì thế nó hỗ trợ tốt cho việc truyền thông trao đổi với con người Nhằm giúp việc xây dựng

chứng minh dễ dàng hơn, PVS cung cấp một tập lệnh chứng minh mạnh mẽ để xử

lý các mệnh đề, đẳng thức và suy diễn toán học sử dụng các định nghĩa và bổ đề Nhiều lệnh chứng minh có thể kết hợp lại với nhau để tạo thành một chiến lược chứng minh

PVS là một phương tiện hỗ trợ chứng minh định lý hiệu quả

họ

Trong lĩnh vực kiểm chứng chương trình, HOL Light đóng vai trò là công cụ thể hiện hoàn chỉnh cho những bài toán có logic phức tạp không thể thể hiện đầy đủ trong first-order logic Đồng thời với hệ thống định lý nền vững chắc, HOL Light

hỗ trợ tốt cho việc chứng minh hoàn chỉnh sự đúng đắn của chương trình

được dùng để mã hóa các đối tượng logic dưới dạng First-order logic (FOL), Higher-order logic (HOL) hay ZFC (xem chi tiết trong [7])

Phương thức chứng minh chính của Isabelle là dùng một phiên bản order logic của resolution, dựa trên higher-order unification Dựa trên sự tương tác, Isabelle thể hiện là một công cụ suy luận cũng như hỗ trợ nhiều thủ tục quyết định mạnh mẽ Hiện tại, Isabelle đang được dùng để hình thức hóa nhiều bài toán chứng minh toán học và tham gia vào việc kiểm chứng các chương trình máy tính

higher-2.3.1.4 ACL2

ACL2 [12] là một ngôn ngữ lập trình hàm (dựa trên ngôn nghữ Lisp), một order logic, và là trình chứng minh lý thuyết toán học Nó được dùng để chứng minh các định lý theo logic và theo các hàm được định nghĩa trước trong ngôn ngữ lập trình ACL2 viết tắt của cụm từ A Computational Logic for Applicative Common Lisp

first-ACL2 còn được xem là một phiên bản công nghiệp mạnh mẽ của hệ thống Boyer-Moore được giới thiệu bởi Kaufmann và Moore dựa trên bản thiết kế đầu tiên của Boyer ACL2 là công cụ chứng minh lý thuyết, tính tương tác được thể hiện ở khía cạnh là người dùng phải lập ra chiến lược chứng minh nhưng nó cũng tự động ở khía cạnh là khi bắt đầu một vấn đề nó sẽ xử lý mà không cần sự giúp đỡ của con người

ACL2 đã được sử dụng trong nhiều dự án công nghiệp và thương mại quan trọng như: kiểm chứng sự đúng đắn trong thiết kế các phép toán xử lý số học của các vi xử lý AMD, IBM Power v.v; kiểm chứng kiến trúc vi mô của các bản rom cho một số hệ thống phần cứng Motorola digital signal processor (DSP), Rockwell

Collins AAMP7; kiểm chứng chức năng sinh bytecode bằng javac của JVM; kiểm chứng sự đúng đắn của chương trình LISP; và nhiều ứng dụng khác

Một ví dụ đơn giản về ACL2 được mô tả qua việc định nghĩa một hàm sum để tính tổng các số nguyên từ n đến 0 như sau:

(defun sum (n)

(if (zp n)

0 (+ n (sum (- n 1)))))

Như vậy, sum (6) sẽ là 6 + 5 + 4 + 3 + 2 +1 + 0 và kết quả là 21

ACL2 có thể chứng minh rằng (sum n) bằng với (n x (n + 1) / 2) khi n là số tự nhiên Trong ACL2, định lý này được viết như sau:

ACL2 hiện đang được sử dụng như một giải pháp cho bài toán xử lý số thực trong lĩnh vực kiểm chứng chương trình

2.3.1.5 Coq

Coq [3] là trình trợ giúp chứng minh cho phép xây dựng những chứng minh hình thức trên các bài toán logic được đặc tả theo định dạng đặc biệt theo kiểu tương tác người dùng và chương trình Sự tương tác diễn ra theo kiểu sau: với một bài toán logic cần được chứng minh và đã được viết đúng đặc tả của Coq, trình thông dịch sẽ đọc từng dòng lệnh, với mỗi dòng lệnh trình thông dịch sẽ hiển thị cho người dùng xem hoàn cảnh chứng minh hiện tại (như Coq đã nhận thấy những giả thuyết gì, điều gì đã đúng cho tới thời điểm này, danh sách các mục tiêu phụ) và hỏi người dùng cách để giải quyết mục tiêu phụ đầu tiên trong hoàn cảnh hiện tại Điều này cứ tiếp diễn cho tới khi đi đến đích cần chứng minh hay nhận ra một điểm không thể vượt qua được Nếu quá trình này đi được đến đích thì tập hợp những câu trả lời của người dùng trong quá trình tương tác chính là phần chứng minh cho bài toán ban đầu Xem qua một ví dụ minh họa sau đây, trong đó chúng ta muốn chứng minh một hằng đúng ( ( A -> ( B -> C ) ) -> ( A -> B ) -> ( A -> C ) Ta sẽ nhập vào Coq với từ khóa Goal theo sau là điều ta cần kiểm chứng:

intro tactic intro tactic dùng cho các phán quyết mà có liên quan đến mục tiêu bằng cách lấy mệnh đề bên trái đưa và danh sách các giả thuyết cục bộ:

intros tactic có thể thay thế nhiều intro trong cùng một bước:

Coq < intros H’ HA

Giờ chúng ta đang có hai mục tiêu phụ cần được giải quyết Với Coq thì nó chỉ thể hiện đầy đủ giả thuyết cục bộ của mục tiêu đầu tiên còn các mục tiêu tiếp theo thì nó chỉ liệt kê tên Tuy vậy những giả thuyết cục bộ tương ứng cho từng mục tiêu vẫn được lưu giữ và sẽ hiển thị đầy đủ khi mục tiêu đó trở thành mục tiêu hiện thời

Để giải quyết mục tiêu hiện thời, chúng ta lưu ý rằng mục tiêu này (là A) sẽ có nếu

ta xác minh giả thuyết HA là đúng Vì thế ta dùng tactic exact:

Coq < exact HA

Coq < assumption

Proof completed