Các nguyên lý và kỹ thuật kiểm chứng chất lượng phần mềm

Trong luận văn, đã áp dụng các lý thuyết của kiến trúc phần mềm, đặc tả yêu cầu và kiểm chứng mô hình của phương pháp hình thức để kiểm chứng mô hình cho phần mềm Reading Practise.. CHƯƠ

BÌA LUẬN VĂN

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

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

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn "Các nguyên lý và kỹ thuật kiểm chứng chất lượng phần mềm" do bản thân thực hiện dưới sự hướng dẫn của PGS.TS Huỳnh

Quyết Thắng - Viện CNTT&TT - Trường Đại học Bách khoa Hà Nội, là không sao chép nguyên văn của bất kỳ một luận văn nào đã được công bố Nội dung luận văn

có tham khảo và sử dụng các tài liệu, thông tin được đăng tải trên các tác phẩm, tạp chí và các trang web theo danh mục tài liệu tham khảo của luận văn Các kết quả chạy thử nghiệm là số liệu trung thực

Tác giả luận văn

Trần Việt Hưng

MỤC LỤC

TRANG PHỤ BÌA i

LỜI CAM ĐOAN ii

MỤC LỤC iii

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ vii

MỞ ĐẦU 1

1 Lý do chọn đề tài: 1

2 Lịch sử nghiên cứu 1

3 Mục đích, đối tượng và phạm vi nghiên cứu 2

3.1Mục đích 2

3.2 Đối tượng 2

3.3 Phạm vi nghiên cứu 2

4 Các luận điểm cơ bản và đóng góp mới của tác giả 3

5 Phương pháp nghiên cứu 3

CHƯƠNG I: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 4

1.1Kiểm thử phần mềm 4

1.2Các phương pháp kiểm thử phần mềm 5

1.3Các chiến lược kiểm thử phần mềm 6

1.4Các giai đoạn kiểm thử phần mềm 7

1.4.1Kiểm thử đơn vị 7

1.4.2Kiểm thử tích hợp 7

1.4.3Kiểm thử hợp thức hoá 8

1.4.4Kiểm thử chấp nhận 8

1.4.5Kiểm thử hồi quy 8

1.5Các vấn đề của kiểm thử phần mềm 9

1.5.1Các hạn chế của kiểm thử 9

1.5.2Các nguyên tắc kiểm thử 10

1.5.3Phân loại một số công cụ kiểm thử tự động 10

1.6Kiểm chứng phần mềm 12

1.6.1Phương pháp Giả lập và kiểm thử (Simulation and Testing) 12

1.6.2Phương pháp Kiểm chứng suy dẫn thường (Deductive Verification) 13

1.6.3Phương pháp Kiểm chứng mô hình (Model Checking) 13

1.6.4Sự khác nhau giữa Kiểm chứng mô hình phần mềm và kiểm thử phần mềm 14

1.7Các phương pháp đặc tả và thiết kế phần mềm 15

1.7.1Phương pháp hình thức (formal method) 15

1.7.2Phương pháp bán hình thức (semi-formal method) 16

1.8Kết luận 16

CHƯƠNG II: KIỂM CHỨNG MÔ HÌNH 17

2.1Tổng quan về kiểm chứng mô hình 17

2.2Quy trình kiểm chứng mô hình 17

2.2.1Mô hình hoá hệ thống (System Modeling) 18

2.2.2Đặc tả các đặc tính (Properties Specification) 18

2.2.3Kiểm chứng (Verification) 19

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

2.3.1Đồ thị trạng thái 19

2.3.2Phân đoạn đường đi 20

2.3.3Phân đoạn đường đi cực đại và phân đoạn đường đi khởi tạo 20

2.3.4Đường đi 21

2.3.5Dấu vết và phân đoạn dấu vết 22

2.3.6Tính chất thời gian tuyến tính 24

2.4Tính bất biến, tính an toàn và tính sống còn 26

2.4.1Tính bất biến 26

2.4.2Tính an toàn 27

2.4.3Tính sống còn 32

2.5Logic thời gian tuyến tính (LTL) 34

2.5.1Cú pháp của LTL 34

2.5.2Ngữ nghĩa 36

2.5.2.1Ngữ nghĩa của LTL (diễn tả thông qua Words) 36

2.5.2.2Ngữ nghĩa của các đường đi và trạng thái 36

2.5.3Chỉ ra các thuộc tính 38

2.5.3.1Ví dụ loại trừ lẫn nhau dựa trên tín hiệu 38

2.5.3.2Modulo 4 counter 39

2.5.4Tính tương đương của công thức LTL 40

2.6Ngôn ngữ lập trình phương trình Maude 40

2.6.1Tổng quan về Maude 40

2.6.2Tại sao lại chọn Maude làm công cụ hình thức? 42

2.6.3Cơ bản về Maude 43

2.6.3.1Ví dụ 43

2.6.3.2Tái sử dụng thành phần 46

2.6.3.3Tính kết hợp và tính giao hoán 47

2.6.3.4Cài đặt và sử dụng Maude 48

2.6.4Sử dụng Maude để kiểm chứng mô hình 49

2.6.4.1Kiểm chứng mô hình LTL dựa ô-tô-mát 49

2.6.4.2Kiểm chứng mô hình LTL trong Maude 50

2.6.4.3Kiểm chứng mô hình LTL 54

2.6.4.4Sự trừu tượng của phương trình 57

2.7Kết luận 65

CHƯƠNG III: ÁP DỤNG MAUDE CHECKER KIỂM CHỨNG MÔ HÌNH MÔ PHỎNG READING PRACTISE 66

3.1Phát biểu bài toán 66

3.2Phương pháp giải quyết bài toán 67

3.3Đề xuất quy trình kiểm chứng mô hình sử dụng MaudeChecker 67

3.4Kiểm chứng mô hình phần mềm Reading Practise 68

3.4.1Đặc tả thuộc tính cần kiểm chứng 69

3.4.2Thiết kế Hệ thống 69

3.4.3Mô hình hóa Hệ thống bằng ngôn ngữ Maude 69

3.4.3.1Tính sống còn 71

3.4.3.2Tính an toàn 72

3.4.3.3Tính bất biến 72

3.5Kết luận 73

CHƯƠNG IV: KẾT QUẢ VÀ BÀN LUẬN 75

4.1Kết quả và các đóng góp của luận văn 75

4.2Bàn luận 75

KẾT LUẬN 77

TÀI LIỆU THAM KHẢO 78

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 2.1 Quy trình kiểm chứng mô hình 18

Hình 2.2 Đồ thị trạng thái của hệ thống máy bán đồ uống 21

Hình 2.4 Hai đèn giao thông đồng bộ hoàn toàn (trái và giữa) 24

và thành phần song song của chúng (phải) 24

Hình 2.5 Đặc tả các thuộc tính thời gian tuyến tính 26

Hình 2.6 Mô tả bằng hình ảnh 1 số phép toán LTL 35

Hình 2.7 Mô tả Hệ thống chuyển dịch thái với các mệnh đề a,b 37

Hình 2.8 Mô tả Hệ thống chuyển dịch thái với duy nhất mệnh đề a 38

Hình 2.9 Ví dụ mô tả loại trừ nhau dựa trên tín hiệu 38

Hình 2.10 Mô tả biểu đồ và hệ thống chuyển dịch 39

Hình 2.11 Giao diện màn hình làm việc của Maude 48

Hình 2.12 Quy trình kiểm chứng mô hình LTL dựa ô-tô-mát 50

Hình 2.13 Đồ thị nhập của các mô đun kiểm chứng mô hình 56

Hình 3.1 Biểu đồ mô tả trạng thái của Hệ thống 69

Hình 3.2.Kết quả kiểm tra Thuộc tính sống còn 72

Hệ thống có thể đạt đến trạng thái kết thúc 72

Hình 3.3 Kết quả kiểm tra Thuộc tính sống còn 72

Hệ thống đảm bảo không luôn ở trạng thái đợi 72

Hình 3.4 Kết quả kiểm tra Thuộc tính an toàn 72

Hệ thống đảm bảo không tồn tại hai trạng thái kết thúc .72

Hình 3.5 Kết quả kiểm tra tính bất biến 73

Số từ mà người dùng đọc đúng luôn nhỏ hơn 100 73

Hình 3.6 Kết quả kiểm tra tính bất biến 73

Số từ mà người dùng không đọc liên tiếp luôn nhỏ hơn 100 .73

Hình 3.7 Kết quả kiểm tra tính bất biến 73

Số lần mà người dùng đọc sai liên tiếp phải nhỏ hơn hoặc bằng 5 73

MỞ ĐẦU

1 Lý do chọn đề tài:

Ngày nay, công nghệ thông tin ngày càng phát triển và được ứng dụng vào hầu hết các lĩnh vực của cuộc sống, tạo ra một diện mạo mới cho xã hội Công nghệ phần mềm là một phần không thể tách rời trong công nghệ thông tin Phần mềm được coi là sản phẩm chính của công nghệ phần mềm Quá trình phát triển phần mềm gồm nhiều giai đoạn: thu thập yêu cầu, phân tích, thiết kế, xây dựng, kiểm chứng, triển khai và bảo trì Trong đó việc kiểm chứng phần mềm là hết sức quan trọng để đảm bảo chất lượng một phần mềm Trong công nghệ phần mềm, kiểm chứng phần mềm luôn thu hút được mối quan tâm của rất nhiều các nhà nghiên cứu Vấn đề đặt ra ở đây là làm thế nào để phát triển, ứng dụng các phương pháp nhằm tăng độ tin cậy trong việc thiết kế và xây dựng phần mềm và hơn nữa các phương pháp này cần phải được tiến hành một cách tự động Các phương pháp này sẽ cải thiện chất lượng và hạ giá thành cho việc phát triển hệ thống Các phương pháp kiểm chứng cơ sở cho các hệ thống phức tạp bao gồm: Giả lập, kiểm thử, kiểm chứng suy dẫn và kiểm chứng mô hình Trong tất cả các phương pháp kể trên, kiểm chứng mô hình (Model Checking)[3] là phương pháp cung cấp một cách tiếp cận toàn diện và hữu hiệu nhất để phân tích hệ thống Với yêu cầu tìm hiểu, đề xuất, tổng hợp các nguyên lý, kỹ thuật kiểm chứng chất lượng phần mềm trong xây dựng phần mềm đạt chất lượng cao, tác giả đã chọn đề tài cho luận văn là: “Các nguyên

lý và kỹ thuật kiểm chứng chất lượng phần mềm”

2 Lịch sử nghiên cứu

Với sự phát triển như vũ bão của công nghệ thông tin nói chung và phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công cụ tiên tiến Tuy nhiên, với yêu cầu ngày càng cao về chất lượng và cũng vì độ phức tạp của phần mềm và những giới hạn về thời gian, chi phí, nên việc phát triển phần mềm vẫn gặp phải những khó khăn trong các khâu như là đặc tả yêu cầu phần mềm

và các kỹ thuật đánh giá chất lượng phần mềm Ngôn ngữ Maude ra đời đã phần

nào giải quyết được những khó khăn kể trên; Maude cũng đã có những ứng dụng to lớn vào việc phát triển các hệ thống phần mềm chất lượng cao trong nhiều lĩnh vực

Lần đầu tiên các tài liệu về Maude đã được nhóm tác giả Manuel Clavel và José Meseguer công bố vào năm 1996

Đến năm 2000, tác giả Olveczky đã công bố tài liệu đầu tiên về đặc tả và phân tích hệ thống thời gian thực

Và đến năm 2002, tác giả Eker và José Meseguer đã công bố tài liệu đầu tiên

về logic thời gian tuyến tính với Maude Tiếp thu thành tựu của các nhà khoa học đi trước, được PGS.TS Huỳnh Quyết Thắng hướng dẫn, tác giả đã cố gắng thực hiện

đề tài: "Các nguyên lý và kỹ thuật kiểm chứng chất lượng phần mềm"

3 Mục đích, đối tượng và phạm vi nghiên cứu

3.1 Mục đích

Tìm hiểu, đề xuất, tổng hợp các nguyên lý, kỹ thuật kiểm chứng phần mềm trong xây dựng phần mềm đạt chất lượng cao Trong luận văn, đã áp dụng các lý thuyết của kiến trúc phần mềm, đặc tả yêu cầu và kiểm chứng mô hình của phương

pháp hình thức để kiểm chứng mô hình cho phần mềm Reading Practise Nghiên

cứu và đề xuất các hướng mở rộng phát triển của lý thuyết đã tìm hiểu

3.2 Đối tượng

Luận văn tìm hiểu các lý thuyết liên quan đến đánh giá chất lượng phần mềm, kiểm chứng phần mềm, kiểm chứng mô hình; công nghệ, giải pháp, công cụ của Maude[5] vào kiểm chứng mô hình cho ứng dụng phần mềm cụ thể Do giới hạn

nên luận văn chỉ mới ứng dụng kiểm chứng mô hình cho phần mềm Reading

Practise

3.3 Phạm vi nghiên cứu

Cơ sở lý thuyết về các nguyên lý và kỹ thuật kiểm chứng chất lượng phần mềm vào việc phát triển phần mềm nói chung Với ngôn ngữ lập trình Maude, tập

trung vào tìm hiểu cơ bản về ngôn ngữ lập trình Maude, cách thức kiểm chứng mô hình trong Maude Cuối cùng là đề xuất quy trình đặc tả và kiểm chứng mô hình sử

dụng MaudeChecker kiểm chứng cho phần mềm Reading Practise

4 Các luận điểm cơ bản và đóng góp mới của tác giả

- Các luận điểm cơ bản:

+ Tổng quan các nguyên lý và kỹ thuật kiểm chứng chất lượng phần mềm

+ Tổng quan ngôn ngữ lập trình Maude

+ Chi tiết kỹ thuật kiểm chứng mô hình, logic thời gian tuyến tính và ngôn ngữ lập trình Maude

+ Cụ thể hóa việc kiểm chứng chất lượng phần mềm sử dụng kỹ thuật kiểm chứng mô hình và công cụng MaudeChecker với phần mềm Reading Practise và đưa ra kết quả của chương trình

- Đóng góp mới của tác giả:

+ Đã xây dựng thành công mô hình kiểm chứng (viết bằng ngôn ngữ

Maude, sử dụng công cụ MaudeChecker)

+ Đề xuất các hướng nghiên cứu tiếp theo

5 Phương pháp nghiên cứu

- Tìm hiểu lý thuyết và kỹ thuật về kiểm chứng chất lượng phần mềm thông qua các nguồn tài liệu

- Tìm hiểu, thực hành chạy thử các đối tượng với ngôn ngữ Maude

CHƯƠNG I: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 Kiểm thử phần mềm

Ngày nay, với sự phát triển mạnh mẽ của lĩnh vực công nghệ thông tin, phần mềm đã thực sự trở thành một bộ phận quan trọng không thể thiếu trong hầu hết các lĩnh vực Và càng ngày càng có nhiều hệ thống được điều khiển bởi phần mềm Do

đó, việc xây dựng, bảo trì và đặc biệt là kiểm định chất lượng hệ thống phần mềm là yêu cầu cần thiết đối với nền kinh toàn cầu và của từng quốc gia

Song song với sự phát triển mạnh mẽ của các hệ thống phần cứng và phần mềm, khả năng xảy ra nhiều lỗi, đặc biệt là các lỗi phức tạp là rất cao Trong bối cảnh hầu hết các ngành kinh tế quan trọng đều đang sử dụng rộng rãi các hệ thống phần mềm thì có thể thấy, những lỗi phần mềm có thể gây ra những hậu quả nghiêm trọng về tiền bạc, thời gian, thậm chí sinh mạng của con người Nhìn chung, một lỗi càng sớm được phát hiện sẽ càng mất ít công sức để sửa lỗi đó Chất lượng phần mềm là một trong những mục tiêu chung mà mọi đối tượng liên quan trong việc sử dụng (người dùng), quản lý và phát triển (người xây dựng, lập trình) đều đặt lên vị trí hàng đầu khi đưa ra một vấn đề phát triển phần mềm Trong các mô hình phát triển dù với quy mô bé hay lớn, đơn giản hay phức tạp vấn đề kiểm thử phần mềm luôn được đặt lên hàng đầu, có tầm quan trọng không kém so với các vị trí phân tích

và phát triển, và được thực hiện song song, xuyên suốt quá trình phát triển một hệ thống phần mềm

Kiểm thử phần mềm có nhiều cách định nghĩa khác nhau Tuy nhiên, chúng cùng bao trùm hai nội dung cơ bản là phát hiện lỗi và đánh giá chất lượng của phần mềm Định nghĩa sau đây của Myers là đơn giản và có tính thực tế: “Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi” Theo định nghĩa của Myers, kiểm thử mà không phát hiện được lỗi được coi là không thành công

Mục đích của việc kiểm thử phần mềm[2]:

Theo Deutch: “Phát triển hệ thống phần mềm gồm rất nhiều hoạt động sản

xuất, và nguy cơ có lỗi là rất lớn Lỗi có thể xảy ra ngay lúc khởi đầu của tiến trình, hay trong các giai đoạn thiết kế và phát triển sau này, ”

Kiểm thử phần mềm nhằm đảm bảo chất lượng phần mềm

Theo Glen Myers: Kiểm thử là tiến trình thực thi chương trình để tìm ra lỗi

- Một trường hợp kiểm thử là trường hợp có xác suất cao để tìm ra lỗi chưa biểu hiện

- Kiểm thử thành công khi phát hiện lỗi

Những mục đích trên ngược với quan điểm thông thường là “kiểm thử thành công là kiểm thử không tìm ra lỗi nào” Nếu kiểm thử không phát hiện ra lỗi thì ta

sẽ nghĩ rằng cấu hình kiểm thử này chưa đúng và lỗi vẫn còn tiềm ẩn trong phần mềm Nếu những lỗi này được phát hiện bởi người dùng thì chi phí cho việc bảo trì, xác định lỗi có thể gấp rất nhiều lần chi phí tìm lỗi trong quá trình phát triển Vậy kiểm thử thành công là kiểm thử tìm ra lỗi

Chúng ta cần phải nhớ rằng: “Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể chứng minh rằng khiếm khuyết phần mềm hiện hữu.”

1.2 Các phương pháp kiểm thử phần mềm

Có 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động

Kiểm thử tĩnh – Static testing

Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc

tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chương trình Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một mình

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch

mà xác nhận tính hợp lệ về cú pháp của chương trình

Kiểm thử động – Dynamic testing

Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình

để điều tra trạng thái tác động của chương trình Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử động thực

sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests

1.3 Các chiến lược kiểm thử phần mềm

Một chiến lược kiểm thử là một kế hoạch định nghĩa mục tiêu các giai đoạn kiểm thử cũng như các kỹ thuật kiểm thử sử dụng Chiến lược kiểm thử thường được quyết định dựa vào tiêu chuẩn về độ tin cậy của phần mềm và chi phí cho việc phát triển phần mềm Ngoài ra, một chiến lược kiểm thử sẽ phụ thuộc kích thước của đối tượng được kiểm thử cũng như quan điểm về đối tượng được kiểm thử Nếu chúng ta muốn kiểm thử một cách độc lập các thành phần/đơn vị cấu tạo nên phần mềm, chúng ta gọi là kiểm thử đơn vị Nếu chúng ta muốn kiểm thử sự kết hợp các thành phần cấu tạo nên phần mềm, chúng ta gọi là kiểm thử tích hợp Nếu chúng ta muốn bảo đảm rằng một phần mềm đang được phát triển một cách đúng đắn và các thành phần cấu tạo nên phần mềm cũng được phát triển một cách đúng đắn, chúng ta gọi là xác minh Tuy nhiên, một phần mềm không chỉ đơn thuần là đáp ứng yêu cầu của nhà sản xuất, mà nó chỉ trở nên hữu ích nếu đáp ứng được nhu cầu của người sử dụng cuối cùng Việc bảo đảm một phần mềm đáp ứng nhu cầu của người sử dụng được gọi là hợp thức hoá

1.4 Các giai đoạn kiểm thử phần mềm

Kiểm thử phần mềm gồm có giai đoạn: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hợp thức hóa, Kiểm thử chấp nhận sản phẩm và Kiểm thử hồi quy

1.4.1 Kiểm thử đơn vị

Phần lớn các phương pháp thiết kế phần mềm đều dẫn đến chia phần mềm thành những mô-đun hay chương trình nhỏ có các dữ liệu vào và kết quả riêng Chúng ta gọi các mô-đun hay chương trình đó là các đơn vị phần mềm Trên các đơn vị này chúng ta sẽ tiến hành kiểm thử đơn vị

Một khi đơn vị phần mềm đã được mã hoá, nghĩa là lập trình và hồ sơ kiểm thử đơn vị tương ứng đã được hoàn thành thì kiểm thử đơn vị có thể được tiến hành Kiểm thử đơn vị chủ yếu là thực hiện các trường hợp kiểm thử đã được mô tả trong hồ sơ kiểm thử đơn vị và điền các thông tin cần thiết vào các phiếu báo cáo kiểm thử Nếu một lỗi hay sự không tương thích được phát hiện, cần phải chỉnh sửa lại đơn vị phần mềm Sau đó, kiểm thử đơn vị được thực hiện lại Kiểm thử đơn vị

sẽ kết thúc khi mà tất cả các trường hợp kiểm thử được mô tả trong hồ sơ kiểm thử đơn vị đã được thực hiện thành công và kết quả được lưu lại trong hồ sơ

1.4.2 Kiểm thử tích hợp

Kiểm thử tích hợp được tiến hành một khi kiểm thử đơn vị các thành phần cần thiết cho kiểm thử tích hợp kết thúc và hồ sơ kiểm thử tích hợp đã được chuẩn bị sẵn sàng Trong giai đoạn kiểm thử tích hợp, ý tưởng là các thành phần đã được kiểm thử đơn vị sẽ được tích hợp lại dần dần cho đến khi có được toàn bộ phần mềm Phần mềm càng phức tạp thì đòi hỏi giai đoạn kiểm thử tích hợp phải trải qua các giai đoạn trung gian, là các giai đoạn mà các nhóm các thành phần sẽ được kiểm thử

Mục tiêu của giai đoạn kiểm thử tích hợp là kiểm tra sự giao tiếp và trao đổi

dữ liệu giữa các thành phần phần mềm Trong giai đoạn tích hợp, có thể có khả năng phải sử dụng các thành phần không được phát triển trong dự án phần mềm, mà

là những thành phần được cung cấp sẵn bởi các thư viện hay thậm chí là các thành phần được cung cấp bởi hệ điều hành

Khi tích hợp các thành phần tạo thành tập hợp, chúng ta có thể tiến hành theo các chiến lược:

- Tích hợp từ trên xuống bằng cách kiểm thử tích hợp các thành phần chính trước, sau đó thêm vào các thành phần được gọi trực tiếp bởi các thành phần vừa kiểm thử

- Tích hợp từ dưới lên bằng cách kiểm thử các thành phần không gọi các thành phần khác, sau đó thêm vào các thành phần gọi các thành phần vừa kiểm thử

1.4.3 Kiểm thử hợp thức hoá

Kiểm thử hợp thức hoá có thể bắt đầu ngay sau khi kiểm thử tích hợp kết thúc

và hồ sơ kiểm thử hợp thức hoá đã sẵn sàng Mục tiêu của kiểm thử hợp thức hoá là cần chỉ ra rằng phần mềm thực hiện đúng những gì mà người sử dụng mong đợi Vì thế, ở giai đoạn này, kiểm thử được thực hiện dưới góc nhìn của người sử dụng, chứ không phải dưới góc nhìn của người phát triển như các giai đoạn kiểm thử đơn vị hay kiểm thử tích hợp

Vì kiểm thử được thực hiện dưới góc nhìn của người sử dụng nên giai đoạn này chỉ sử dụng các kỹ thuật kiểm thử chức năng, tức là các kỹ thuật kiểm thử hộp đen Các bộ dữ liệu thử sẽ được tạo ra dựa trên các tài liệu đặc tả Thông thường các tài liệu đặc tả sẽ được phân tích để xác định các yêu cầu chứa đựng các hành vi mong đợi của phần mềm

1.4.4 Kiểm thử chấp nhận

Được thực hiện khi tất cả các giai đoạn kiểm thử được hoàn tất nhằm để chứng minh phần mềm đã đủ sẵn sàng xuất xưởng Các thủ tục kiểm thử hoặc chạy thử phải được người đặt hàng chấp nhận trước khi thực hiện để nghiệm thu

1.4.5 Kiểm thử hồi quy

Phần mềm là một trong những loại sản phẩm thay đổi rất nhanh Người sử dụng luôn có yêu cầu cải tiến phần mềm và các chức năng mới Vì vậy, sự chỉnh

sửa phần mềm sau khi đưa vào sử dụng là cần thiết Mặt khác, bất kỳ sự sửa đổi nào cùng có thể dẫn đến các lỗi mới Phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn kiểm thử này gọi là kiểm thử hồi quy

Giai đoạn kiểm thử hồi quy thường tái sử dụng các bộ dữ liệu thử đã sử dụng trong các giai đoạn trước nhằm kiểm tra rằng không có các lỗi mới được đưa vào Vấn đề đặt ra ở đây là trong giai đoạn này, các bộ dữ liệu thử nào được tái sử dụng: kiểm thử đơn vị, kiểm thử tích hợp hay kiểm thử hệ thống?

1.5 Các vấn đề của kiểm thử phần mềm

1.5.1 Các hạn chế của kiểm thử

Do kiểm thử là chạy thử chương trình với tập dữ liệu giả nên không thể khẳng định tính đúng của chương trình do bản chất quy nạp không hoàn toàn của nó Trong nhiều trường hợp, việc kiểm thử thường được thực hiện từ những giai đoạn đầu của quá trình cài đặt sản phẩm

Một chương trình được cho tuyệt đối đúng phải được thực hiện thông qua: tính đúng đắn của thuật toán và tính tương đương của chương trình với thuật toán (được thể hiện ở chứng minh thông qua văn bản chương trình)

Việc kiểm thử chương trình chỉ là nhìn sự kiện đưa ra kết luận do vậy không thể khẳng định một chương trình tuyệt đối đúng bằng kiểm thử Tuy vậy, bộ dữ liệu kiểm thử phải phủ kín mọi trường hợp cần đánh giá

Thêm vào đó, trong quá trình kiểm thử, ta thường mắc phải các đặc trưng của nguyên lý chủ quan như sau:

- Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng phần mềm

- Chỉ kiểm thử các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và các sự cố

- Cài đặt chức năng nào thì chỉ kiểm thử riêng chức năng đó, không kiểm thử tổng hợp chức năng vừa cài đặt với các chức năng đã cài đặt trước đó

- Người kiểm thử đồng thời là người xây dựng phần mềm

1.5.2 Các nguyên tắc kiểm thử

Các nguyên tắc luôn đóng vai trò quan trọng trong lĩnh vực công nghệ phần mềm Các nguyên tắc trong công nghệ phần mềm là các luật hay quy tắc hướng dẫn làm thế nào để xây dựng (thiết kế, phát triển, kiểm thử và bảo trì) phần mềm Kiểm thử là một trong những lĩnh vực của công nghệ phần mềm, kiểm thử cũng có các nguyên tắc riêng dành cho các kiểm thử viên Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau:

- Kiểm thử là tiến trình thực thi phần mềm và sử dụng các trường hợp kiểm thử để phát hiện lỗi

- Với mục đích của kiểm thử nhằm phát hiện lỗi, một ca kiểm thử tốt là ca kiểm thử có khả năng cao phát hiện những lỗi chưa được tìm thấy

- Một ca kiểm thử phải định nghĩa kết quả mong muốn

- Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm phát triển

- Kết quả kiểm thử nên được kiểm tra một cách cẩn thận

- Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào hợp lệ và không hợp lệ

- Các ca kiểm thử phải được tái sử dụng

- Xác suất tồn tại của các lỗi hơn nữa trong một đơn vị phần mềm tỷ lệ với số các lỗi đã được phát hiện trong đơn vị phần mềm đó

- Kiểm thử nên phải được lập kế hoạch

- Các hoạt động kiểm thử nên phải được tích hợp vào tiến trình phát triển phần mềm

- Kiểm thử là một công việc đầy sáng tạo và thách thức

1.5.3 Phân loại một số công cụ kiểm thử tự động

Vì kiểm thử phần mềm thường chiếm tới 40% tất cả các nỗ lực dành cho một

dự án xây dựng phần mềm, nên công cụ có thể làm giảm thời gian kiểm thử sẽ rất

có giá trị Thừa nhận lợi ích tiềm năng này, các nhà nghiên cứu và người thực hành

đã phát triển một số thế hệ các công cụ kiểm thử tự động:

Bộ phân tích tĩnh: Các hệ thống phân tích chương trình này hỗ trợ cho việc

chứng minh các lý lẽ tĩnh - những mệnh đề yếu kém về cấu trúc và định dạng của chương trình

Bộ thanh tra mã nguồn: Những bộ lọc chuyên dụng này được dùng để kiểm

tra chất lượng của phần mềm để đảm bảo rằng nó đáp ứng các chuẩn mã hoá tối thiểu

Bộ xử lý khẳng định: Những hệ thống tiền xử lý/hậu xử lý này được sử dụng

để cho biết liệu những phát biểu do người lập trình nêu, được gọi là các khẳng định,

về hành vi của chương trình có thực sự được đáp ứng trong việc thực hiện chương trình thực hay không

Bộ sinh trường hợp kiểm thử: Những bộ xử lý này sinh ra, và điền các giá trị

đã xác định vào các trường hợp kiểm thử cho chương trình đang được kiểm thử

Bộ sinh dữ liệu kiểm thử: Những hệ thống phân tích tự động này hỗ trợ cho

người dùng trong việc chọn dữ liệu kiểm thử làm cho chương trình hành xử theo một cách đặc biệt

Bộ kiểm chứng kiểm thử: Những công cụ này đo mức bao quát kiểm thử bên

trong, thường được diễn tả dưới dạng có liên quan tới cấu trúc điều khiển của sự vật kiểm thử, và báo cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng

Dụng cụ kiểm thử: Lớp các công cụ này hỗ trợ cho việc xử lý các phép kiểm

thử

Bộ so sánh kết quả đầu ra: Công cụ này làm cho người ta có thể so sánh một

tập kết quả đầu ra từ một chương trình này với một tập kết quả khác (đã được lưu giữ trước) để xác định sự khác biệt giữa chúng

Hệ thống thực hiện ký hiệu (symbolic execution system): Công cụ này thực

hiện việc kiểm thử chương trình bằng cách dùng “dữ liệu vào” đại số, thay vì giá trị

dữ liệu số Phần mềm được kiểm thử xuất hiện để kiểm thử các lớp dữ liệu, thay vì chỉ là một trường hợp kiểm thử đặc biệt “Dữ liệu ra” là đại số và có thể được so sánh với kết quả trông đợi cũng được xác định dưới dạng đại số

Bộ mô phỏng môi trường: Công cụ này là một hệ thống dựa trên máy tính

giúp người kiểm thử mô hình hoá môi trường bên ngoài của phần mềm thời gian thực và rồi mô phỏng các điều kiện vận hành thực tại một cách động

Bộ phân tích luồng dữ liệu: Công cụ này theo dõi dấu vết luồng dữ liệu đi

qua hệ thống và cố gắng tìm ra những tham khảo dữ liệu không xác định, đặt chỉ số sai và các lỗi khác có liên quan tới dữ liệu

1.6 Kiểm chứng phần mềm

Để phát hiện ra các lỗi phần mềm thì các phần mềm cần phải được thẩm định (Validation) và kiểm chứng (Verification)[4]

- Thẩm định: nhằm chỉ ra toàn hệ thống đã phát triển xong phù hợp với tài liệu

mô tả yêu cầu

- Kiểm chứng: nhằm xác định đầu ra của một công đoạn trong việc phát triển phần mềm phù hợp với công đoạn trước đó

So sánh giữa thẩm định và kiểm chứng

- Thẩm định: thẩm định quan tâm đến sản phẩm cuối cùng không còn lỗi

- Kiểm chứng: kiểm chứng quan tâm đến việc ngăn chặn lỗi giữa các công đoạn

Về cơ bản các phương pháp kiểm chứng cơ sở cho các hệ thống phức tạp bao gồm: Giả lập-kiểm thử, kiểm chứng suy dẫn và kiểm chứng mô hình[3]

1.6.1 Phương pháp Giả lập và kiểm thử (Simulation and Testing)

Cần phải tiến hành thử nghiệm trước khi triển khai hệ thống ra thực tế Các phương pháp này thường nhận đầu vào cho hệ thống để thử nghiệm rồi quan sát đầu

ra tương ứng, từ đó đưa ra kết luận hệ thống có đáp ứng được yêu cầu đặt ra hay không

Khó khăn:

- Các phương pháp này có thể tìm ra nhiều lỗi tuy nhiên chúng không thể tìm

ra tất cả các lỗi tiềm tàng, nhất là với những phần mềm tương tranh đa luồng, phần mềm nhúng, phần mềm thời gian thực, phần mềm hướng đối tượng

- Các phương pháp này thường không tự động hoặc chỉ đưa ra kết quả từng phần

1.6.2 Phương pháp Kiểm chứng suy dẫn thường (Deductive Verification)

Dựa vào các tiên đề và các luật suy diễn để chứng minh tính đúng đắn của hệ thống Khi mới ra đời và phát triển, phương pháp này thường được thực hiện bằng tay và cần có sự trợ giúp của các chuyên gia suy diễn logic có kinh nghiệm Sau này, phương pháp kiểm chứng suy diễn được thực hiện trên các công cụ phần mềm

Khó khăn: các công cụ này lập luận trên hệ thống vô hạn trạng thái1 và tốn rất nhiều tài nguyên và thời gian Chính vì thế, kiểm chứng suy diễn được sử dụng rất ít

và hiện nay phương pháp này thường được áp dụng chủ yếu cho các hệ có độ nhạy cảm cao như các giao thức bảo mật

1.6.3 Phương pháp Kiểm chứng mô hình (Model Checking)

Là một kỹ thuật kiểm chứng phần mềm tự động trên các hệ hữu hạn trạng thái2 Phương pháp này cho phép tìm kiếm vét cạn trên không gian trạng thái của hệ thống để xác định yêu cầu của hệ thống (các đặc tính - property) có được thỏa mãn hay không, nếu không thỏa mãn thì đưa ra phản ví dụ minh họa

Ưu điểm và lợi thế của phương pháp Kiểm chứng mô hình:

- Mặc dù kiểm chứng mô hình giới hạn trên các hệ hữu hạn trạng thái nhưng phương pháp này lại tỏ ra rất hữu hiệu trong nhiều loại bài toán quan trọng Trong một vài trường hợp, hệ thống cần kiểm tra không phải là hệ hữu hạn trạng thái thì chúng ta vẫn có thể sử dụng kiểm chứng mô hình bằng cách kết hợp với nhiều quy tắc quy nạp và trừu tượng khác nhau Thực tế đã chứng minh rằng nhiều trường hợp lỗi phần mềm có thể được phát hiện bằng cách giới hạn như thế

- Bên cạnh đó, kiểm chứng mô hình có thể tiến hành hoàn toàn tự động và không cần phải có sự giám sát hay chuyên gia về toán học để suy diễn hay

1 infinite state system

2 finite state system

chứng minh các định định lý, logic Bất kỳ ai có thể chạy giả lập của hệ thống đều có thể sử dụng phương pháp này để kiểm chứng cho hệ thống đó

- Khi hệ thống không thỏa mãn đặc tính cần kiểm chứng, kết quả xử lý của kiểm chứng mô hình luôn đưa ra ít nhất một phản ví dụ minh họa cho hành vi của hệ thống không thỏa mãn đặc tính này Nó sẽ giúp người phát triển định

vị và sửa lỗi một cách hiệu quả

Như vậy, kiểm chứng mô hình có rất nhiều ưu điểm và lợi thế so với các phương pháp kiểm chứng khác trong việc phát hiện và sửa lỗi phần mềm nhằm giảm thời gian và chi phí phát triển phần mềm và đưa ra các phần mềm có chất lượng tốt hơn

1.6.4 Sự khác nhau giữa Kiểm chứng mô hình phần mềm và kiểm thử phần mềm

Cả kiểm chứng mô hình và kiểm thử phần mềm đều thực hiện vai trò đảm bảo chất lượng phần mềm bằng việc tìm ra các lỗi nếu có của phần mềm

Tuy nhiên giữa kiểm chứng mô hình và kiểm thử phần mềm có một số điểm khác nhau quan trọng sau:

- Kiểm thử phần mềm đòi hỏi phải có chương trình để thực hiện, còn kiểm chứng mô hình thì ngoài kiểm thử trên mã nguồn còn có thể dùng để kiểm chứng bản thiết kế, nghĩa là khi chương trình vẫn còn trên giấy

- Kiểm thử phần mềm chỉ có thể khẳng định được chương trình không gặp lỗi đối với các trường hợp kiểm thử đã kiểm tra tức không tìm thấy lỗi chứ không khẳng định được là chương trình hoàn toàn không còn lỗi Ngược lại, kiểm chứng phần mềm cho phép ta kết luận được chương trình hoàn toàn không còn lỗi

- Tuy nhiên, kiểm thử phần mềm có ưu điểm rất lớn là dễ thực hiện Một người bình thường cũng có thể thực hiện được Trong khi đó, kiểm chứng mô hình đòi hỏi phải mô hình hóa và đặc tả, công việc này rất khó và đòi hỏi người thực hiện có trình độ kinh nghiệm và kiến thức nhất định

1.7 Các phương pháp đặc tả và thiết kế phần mềm

1.7.1 Phương pháp hình thức (formal method)

Các phương pháp hình thức là các kỹ thuật toán học phục vụ cho việc đặc tả, phát triển và kiểm định các hệ thống phần mềm và phần cứng Cách tiếp cận này đặc biệt quan trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống điều khiển lò phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò quan trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống

sẽ không có lỗi Các phương pháp hình thức đặc biệt hiệu quả tại giai đoạn đầu của quá trình phát triển (tại các mức yêu cầu và đặc tả hệ thống), nhưng cũng có thể sử dụng cho một quá trình phát triển hoàn chỉnh của một hệ thống

Các phương pháp hình thức có thể được sử dụng để mô tả về hệ thống cần phát triển, tại bất kỳ mức độ chi tiết nào và bất cứ pha nào trong vòng đời phát triển phần mềm Khi một đặc tả hình thức đã được phát triển xong, đặc tả đó có thể được

sử dụng làm một hướng dẫn trong quá trình hệ thống thực được phát triển (nghĩa là được hiện thực hóa trong phần mềm hoặc phần cứng) Sau đó đặc tả này có thể được dùng làm cơ sở cho việc chứng minh các tính chất của hệ thống Các đặc tả hình thức mô tả ở mức độ chính xác logic cao Nó loại trừ những nhầm lẫn mập mờ không tránh khỏi trong các đặc tả phi hình thức Tính chính xác này giúp cho người diễn tả và người đọc có tiếng nói chung, đạt được sự nhất quán, giúp cho phát triển

hệ thống ổn định an toàn

Định nghĩa đặc tả hình thức: là một mô tả chính xác các hành vi và thuộc tính của hệ thống được viết trên một số ngôn ngữ có cơ sở toán học, nó mô tả một cách ngắn gọn và chặt chẽ các yêu cầu mà một hệ thống được giả định là sẽ thực hiện Vì vậy có thể loại trừ những chi tiết mập mờ và mô tả được những thay đổi tổng quát cộng với những thay đổi của hệ thống trong tương lai

Có khá nhiều phương pháp hình thức được áp dụng cho đặc tả, phát triển và kiểm định các hệ thống phần mềm Tùy vào yêu cầu và đặc trưng của từng loại hệ thống phần mềm người ta còn có thể kết hợp các phương pháp hình thức với nhau

hoặc với các phương pháp bán hình thức để mô tả đầy đủ và chính xác về hệ thống cần xây dựng

1.7.2 Phương pháp bán hình thức (semi-formal method)

Các phương pháp bán hình thức là các kỹ thuật đặc tả, phát triển và kiểm định các hệ thống phần mềm và phần cứng theo cấu trúc sử dụng các thành phần đồ họa

và được ứng dụng rộng rãi trong phân tích thiết kế phần mềm Cách tiếp cận này giúp cho người phát triển mô hình hóa hệ thống một cách trực quan dễ hiểu và các

bộ phận tham gia phát triển hệ thống có thể hiểu và đóng góp được nhằm xác định đúng hệ thống cần xây dựng Các phương pháp này được áp dụng tại tất cả các pha trong vòng đời phát triển phần mềm

1.8 Kết luận

Chương này trình bày về tổng quan kiểm thử phần mềm:

- Khái niệm kiểm thử phần mềm, các phương pháp kiểm thử phần mềm, các chiến lược và các giai đoạn kiểm thử phần mềm và một số vấn đề trong kiểm thử phần mềm

- Khái niệm phương pháp kiểm chứng mô hình phần mềm, so sánh sự giống và khác nhau giữa kiểm chứng mô hình phần mềm và kiểm thử phần mềm

- Bên cạnh đó, chương này cũng trình bày về phương pháp đặc tả và thiết kế phần mềm đó là các phương pháp hình thức và bán hình thức

CHƯƠNG II: KIỂM CHỨNG MÔ HÌNH 2.1 Tổng quan về kiểm chứng mô hình

Kiểm chứng mô hình[3] là một kỹ thuật tự động để kiểm chứng các hệ thống tương tranh hữu hạn trạng thái được phát triển độc lập bởi Clarke và Emerson tại

Mỹ và Queille và Sifakis tại Pháp vào những năm 1980 Kiểm chứng mô hình được chia làm 2 loại: Kiểm chứng mô hình phần cứng và kiểm chứng mô hình phần mềm Trong khuôn khổ của luận văn, chúng ta sẽ chỉ xét đến kiểm chứng mô hình phần mềm

Mặc dù kiểm chứng mô hình giới hạn trên các hệ hữu hạn trạng thái nhưng phương pháp này lại tỏ ra rất hữu hiệu trong nhiều loại bài toán quan trọng Bên cạnh đó, kiểm chứng mô hình có thể tiến hành hoàn toàn tự động và không cần phải

có sự giám sát hay chuyên gia về toán học để suy diễn hay chứng minh các định lý, logic

Khi hệ thống không thỏa mãn đặc tính cần kiểm chứng, kết quả xử lý của kiểm chứng mô hình luôn đưa ra ít nhất một phản ví dụ minh họa cho hành vi của hệ thống không thỏa mãn đặc tính này Như thế, vết của lỗi xảy ra sẽ giúp người phát triển có thể biết được nguyên nhân thực sự của lỗi để tìm ra cách giải quyết vấn đề

2.2 Quy trình kiểm chứng mô hình

Phương pháp kiểm chứng mô hình bao gồm ba công việc chính Đầu tiên hệ thống được mô hình hóa thành một mô hình hình thức nào đó được các công cụ

kiểm chứng mô hình (model checking tool hoặc model checker) chấp nhận Trước

khi tiến hành kiểm chứng, các yêu cầu của hệ thống (các đặc tính hệ thống cần thỏa

mãn-property) được biểu diễn bằng một đặc tả logic hình thức nào đó, thông thường

là logic thời gian (temporal logic) Cuối cùng, công cụ kiểm chứng mô hình sẽ tìm

kiếm vét cạn trên không gian trạng thái của mô hình hình thức đã xây dựng để xác định xem mô hình đó có thỏa mãn các yêu cầu của hệ thống đã được đặc tả hay không, nếu không thỏa mãn thì đưa ra phản ví dụ Như vậy, công việc kiểm chứng được tiến hành tự động trên các công cụ kiểm chứng đã cài đặt các thuật toán kiểm

chứng Các công việc trong kiểm chứng mô hình được minh họa trong hình bên dưới

Hình 2.1 Quy trình kiểm chứng mô hình

2.2.1 Mô hình hoá hệ thống (System Modeling)

Đầu tiên hệ thống được mô hình hóa thành một mô hình hình thức nào đó được các công cụ kiểm chứng mô hình chấp nhận Trong nhiều trường hợp, công việc này chỉ đơn thuần là việc biên dịch Trong một số trường hợp khác, khi có những giới hạn về mặt thời gian và bộ nhớ thì việc mô hình hóa cần sử dụng

phương pháp trừu tượng hóa (abstraction) để loại bỏ các chi tiết không liên quan

hoặc các chi tiết không quan trọng

Thông thường, mô hình hình thức được sử dụng là máy hữu hạn trạng thái

(Finite State Machine - FSM) được mô tả bởi đồ thị chuyển dịch trạng thái có gán nhãn được gọi là cấu trúc Kripke hay ô-tô-mát

2.2.2 Đặc tả các đặc tính (Properties Specification)

Trước khi tiến hành kiểm chứng, các đặc tính hệ thống cần thỏa mãn được biểu diễn bằng một logic hình thức nào đó Thông thường, người ta hay sử dụng

logic thời gian (temporal logic) để biểu diễn các hành vi của hệ thống tiến triển như

thế nào theo thứ tự thời gian

Công cụ kiểm chứng

mô hình (Model Checker)

Mô hình

(Model)

Đặc tả (Specification)

Kết quả:

“ Đúng ”: Hệ thống thỏa mãn các tính chất

“ Sai ”: Hệ thống không thỏa mãn

→ đưa ra phản ví

dụ

Logic thời gian được sử dụng để đặc tả các đặc tính của các trạng thái và các đặc tính hệ thống cần thỏa mãn Cú pháp phổ biến nhất của logic thời gian chính là

CTL* (Computation Tree Logic*) LTL(Linear Temporal Logic) và CTL

(Computation Tree Logic) là hai logic thời gian được sử dụng rộng rãi nhất trên các công cụ kiểm chứng LTL là một phần của CTL* được sử dụng để mô tả các đặc tính trên một đường tuyến tính còn CTL lại được sử dụng để mô tả các đặc tính trên

Về mặt ý tưởng, công việc kiểm chứng hoàn toàn có thể thực hiện tự động Tuy nhiên, trong thực tế, công việc này thường cần có sự trợ giúp của con người, ví

dụ như việc phân tích kết quả kiểm chứng

Trong trường hợp hệ thống không thỏa mãn, người dùng sẽ được cung cấp một phản ví dụ dưới dạng một vết lỗi Vết lỗi này sẽ giúp người phát triển hệ thống

có thể theo vết mà lỗi đã xảy ra để chỉnh sửa hệ thống Sau khi chỉnh sửa hệ thống,

ta cần áp dụng lại thuật toán kiểm chứng để kiểm tra lại kết quả chỉnh sửa

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

2.3.1 Đồ thị trạng thái

Đồ thị trạng thái của TS, ký hiệu là G(TS), là một cặp (V,E) với đỉnh V = S và

cạnh E={( , ')s s ∈ ×S S s| '∈P t sos ( )}

Đồ thị trạng thái của Hệ thống chuyển đổi có đỉnh là các trạng thái trong Hệ

thống chuyển đổi và một cạnh giữa các đỉnh s và s’, với s’ là một kế nhiệm trực tiếp của s trong Hệ thống chuyển đổi cho một vài hành động α (s’ trước s)

Ký hiệu Pre*( )s và Pre ( )∗ C có ý nghĩa tương tự Tập các trạng thái có khả

năng đạt được từ một vài trạng thái khởi tạo được kí hiệu là Reach(TS), bằng

Post ( )∗ I

2.3.2 Phân đoạn đường đi

Một phân đoạn đường đi hữu hạn π của TS là một chuỗi trạng thái hữu hạn

s 0 …s n mà s i∈Post s( i− ∀ < ≤ 1) 0 i n , khi n ≥ 0 Một phân đoạn đường đi vô hạn π là

một chuỗi trạng thái vô hạn s 0 s 1 s 2 … mà s i∈Post s( i− 1) ∀ >i 0

Chúng ta áp dụng các ký hiệu quy ước cho phân đoạn đường đi vô hạn

0 1

s s

π = như sau:

- Trạng thái khởi tạo của π được biểu diễn bởi first( ) sπ = 0

- Với j≥0, đặt π[ ]j =sjbiểu diễn trạng thái thứ j của π và π[ ] j biểu diễn

2.3.3 Phân đoạn đường đi cực đại và phân đoạn đường đi khởi tạo

Một phân đoạn đường đi cực đại là một phân đoạn đường đi hữu hạn mà điểm cuối là một trạng thái kết thúc, hoặc một phân đoạn đường đi vô hạn

Một phân đoạn đường đi được gọi là khởi tạo nếu nó bắt đầu tại một trạng thái khởi tạo, ví dụ nếu s0∈ I

Một phân đoạn đường đi cực đại là một phân đoạn đường đi mà không thể nối thêm dài được nữa: hoặc là nó là vô hạn, hoặc nó hữu hạn nhưng kết thúc tại một trạng thái mà không có sự chuyển đổi nào đi ra từ nó Đặt Paths s( )biểu thị tập các phân đoạn đường đi cực đại π với first( )π =s, và Paths fin( )s biểu thị tập tất cả các phân đoạn đường đi xác định π với first( ) sπ =

2.3.4 Đường đi

Một đường đi của TS là một phân đoạn đường đi khởi tạo, cực đại

ĐặtPaths TS( ) biểu thị tập tất cả các đường đi trong TS, và Paths fin(TS)là tập

tất cả các phân đoạn đường đi khởi tạo, có giới hạn của TS

Ví dụ: máy bán đồ uống, máy có thể cung cấp beer hoặc soda Các trạng thái

được biểu diễn bằng hình oval và được chuyển đổi bằng các cạnh Tên trạng thái được miêu tả bên trong hình oval Trạng thái khởi tạo được chỉ ra bởi một mũi tên không có gốc

Hình 2.2 Đồ thị trạng thái của hệ thống máy bán đồ uống

Nhãn trạng thái là đơn giản L s( ) { }= s với mỗi trạng thái s, tên của trạng thái có

thể được sử dụng trong đường đi Ví dụ phân đoạn đường đi của Hệ thống chuyển đổi này là

1 pay seclect soda pay select soda

Ở trên, π1 là một đường đi Phân đoạn đường đi vô hạn π2 là phân đoạn đường

đi cực đại, nhưng không là phân đoạn đường khởi tạo π là phân đoạn đường đi khởi đầu nhưng không là phân đoạn đường đi cực đại vì nó có giới hạn khi kết thúc

ở một trạng thái có sự chuyển đổi đi ra

2.3.5 Dấu vết và phân đoạn dấu vết

Đặt TS=(S Act, , , → I AP L, , )là một Hệ thống chuyển đổi không có các trạng thái cuối Dấu vết của phân đoạn đường đi vô hạn π = s s0 1…được định nghĩa là

( ) ( ) ( )0 1

trace π =L s L s Dấu vết của phân đoạn đường đi hữu hạn π = s s0 1… s n

được định nghĩa trace( )π =L s L s( ) ( )0 1 …L s( )n

Dấu vết của một phân đoạn đường đi hữu hạn hoặc vô hạn nằm trong tập 2AP Tập hợp các dấu vết của một tập Π của các đường đi được định nghĩa theo cách thông thường:

( ) { | ( ) }

Một dấu vết của trạng thái s là dấu vết của một phân đoạn đường đi vô hạn π

với first( )π =s Theo đó, một dấu vết hữu hạn của s là dấu vết của một phân đoạn đường đi hữu hạn mà bắt đầu ở s

Gọi Traces s( ) biểu diễn tập các dấu vết của s, và Traces TS( )là tập các dấu vết của trạng thái khởi tạo của Hệ thống chuyển đổi TS

Traces s =trace Paths s Traces TS = U ∈trace s

Một cách tương tự, dấu vết hữu hạn của một trạng thái và của một Hệ thống chuyển đổi được định nghĩa:

Ví dụ: Semaphore-Based Mutual Exclusion (loại trừ lẫn nhau dựa trên tín hiệu)

Xem xét một Hệ thống chuyển đổi TS Semnhư được mô tả trong hình 2.3 Giả

thiết có sẵn các mệnh đề nguyên tử là crit 1 và crit 2, ví dụ AP= {crit crit1, 2} crit 1 giữ bất cứ trạng thái nào của Hệ thống chuyển đổi TS Semnơi mà quá trình đầu tiên (gọi là

P 1 ) vào đoạn tới hạn crit 2 có ý nghĩa tương tự cho quá trình thứ hai (ví dụ P 2)

Xem xét sự thực thi trong đó các quá trình P 1 và P 2 nhập đoạn tới hạn của chúng trong một kiểu cách xen kẽ Bên cạnh đó, chúng chỉ yêu cầu nhập vào đoạn tới hạn khi quá trình khác không còn trong đoạn tới hạn nữa

Hình 2.3 Hệ thống chuyển đổi TS Sem

Đường đi π trong đồ thị trạng thái của TS Sem nơi quá trình P 1 được nhập vào đầu tiên trong đoạn tới hạn của nó có dạng:

, , 1 , , 1 , , 0 , , 1 , , 1 , , 0

Dấu vết của phân đoạn đường đi hữu hạn:

, , 1 , , 1 , , 1 , , 0 , , 1 , , 0

π =< = >→< = >→< = >→

< = >→< = >→< = >

Là trace( )π =Ø Ø Ø crit Ø crit { 2} { 1}

2.3.6 Tính chất thời gian tuyến tính

Một tính chất thời gian tuyến tính trong tập hợp tất cả các AP (atomic

propostions) là một tập con của (2 )AP ω

Ở đây, (2 )AP ω biểu thị tập hợp các tiền tố xuất hiện từ những xâu chuỗi vô hạn của các tiền tố trong bảng chữ cái 2AP Một tính chất LT là một tập hợp của các tiền

tố vô hạn trong bảng chữ cái 2AP Việc thực hiện của một tính chất LT bởi một Hệ

thống chuyển đổi được định nghĩa như sau:

Định nghĩa 2.1 Mối quan hệ thỏa mãn cho các tính chất LT: Đặt P là một

tính chất LT trên AP và TS=(S Act, , , → I AP L, , ) là một Hệ thống chuyển đổi không có các trạng thái cuối TS=(S Act, , , → I AP L, , ) thỏa mãn P, ký hiệu

TS P ¨ bnếu và chỉ nếu Traces TS( )⊆P Trạng thái s∈S thỏa mãn P, ký hiệu s P ¨ b

Hình 2.4 Hai đèn giao thông đồng bộ hoàn toàn (trái và giữa)

và thành phần song song của chúng (phải) Chúng ta xem xét hai tính chất LT của những chiếc đèn giao thông này và đưa

ra vài tiền tố ví dụ rằng chúng được chứa đựng bởi các tính chất Đầu tiên, xem xét

Red 1

Green 1

tính chất P mà trạng thái: “The first traffic lights is infinitely often green” (đèn giao

thông thứ nhất vô hạn lần xanh)

Tính chất LT này tương ứng với tập các tiền tố vô hạn của form A A A0 1 2 trên

2AP, mà green1∈A i giữ cho vô hạn i Ví dụ, P chứa đựng các tiền tố vô hạn

{red green1, 2}{green red1, 2}{red green1, 2}{green red1, 2}…,

{red green1, 1}{red green1, 1}{red green1, 1}{red green1, 1}…và

{green green1, 2}{green green1, 2}{green green1, 2}{green green1, 2}…

Tiền tố vô hạn {red green red green1, 1}{ 1, 1}∅∅∅∅ .không thuộc P green1chỉ xuất hiện ở A0 và A1

Tại tính chất LT thứ hai, xem xét P’: “The traffic lights are never both green

simultaneously” (các đèn giao thông không bao giờ cùng đồng thời màu xanh)

Tính chất này được hình thức hóa bởi tập hợp các tiền tố vô hạn của form

0 1 2

A A A mà green1∉A i or green2∉A i, i 0 ∀ ≥ Ví dụ, các tiền tố vô hạn sau thuộc P’

{red green1, 2}{green red1, 2}{red green1, 2}{green red1, 2}…,

{red green1, 1}{red green1, 1}{red green1, 1}{red green1, 1}…,

Bất cứ khi nào tiền tố vô hạn {red green1, 2}{red green1, 2} không thuộc P’ Thông thường, một tính chất LT không đề cập đến tất cả các mệnh đề nguyên

tử xảy ra trong một Hệ thống chuyển đổi mà chỉ đề cập tới một tập con tương đối

nhỏ của nó Với mỗi tính chất P trên một tập các mệnh đề AP’⊆AP, chỉ các nhãn

trong AP’ là thích hợp Đặt π là phân đoạn đường đi hữu hạn của TS Chúng ta viết

' ( )

AP

Trace π nhằm biểu thị dấu vết hữu hạn của π nơi chỉ mệnh đề nguyên tử trong

AP’ được xem xét Theo đó, trace AP'( )π biểu thị dấu vết của phân đoạn đường đi vô

hạn π bằng việc tập trung vào mệnh đề trong AP’ Do đó, với π =s s s0 1 2 ., chúng ta

có

Đặt Trace AP'( )π biểu thị tập hợp các dấu vết Trace AP’(Paths TS( ))

Ví dụ: tính chất loại trừ lẫn nhau: Để xác định tính chất loại trừ lẫn nhau, ta

chỉ cần xem xét mệnh đề nguyên tử crit 1 và crit 2 Mệnh đề nguyên tử khác không thích hợp cho tính chất này Hình thức của tính chất loại trừ lẫn nhau được cho bởi

mệnh đề nguyên tử cho trước

Hình 2.5 Đặc tả các thuộc tính thời gian tuyến tính

2.4.1 Tính bất biến

Định nghĩa 2.2: Một thuộc tính LT P inv trên AP là bất biến nếu có một mệnh

đề logic Φ trên AP mà

0 1 2{ (2 ) | AP 0.| }

( )

iff L s ¨ Φb với mọi trạng thái s Reach TS∈ ( )

Do đó, ký hiệu “invariant” có thể được giải thích như sau: điều kiện Φ phải

được thực hiện bởi tất cả các trạng thái khởi tạo và sự thỏa mãn của Φ là bất biến dưới tất cả sự chuyển đổi trong phân đoạn có thể có của một Hệ thống chuyển đổi Một điều cần nói nữa rằng nếu Φ giữ trạng thái nguồn s của sự chuyển đổi s→α s',

thì Φ cũng giữ trạng thái đích s’

Chúng ta hãy đến với ví dụ về loại bỏ lẫn nhau và deadlock freedom (sự bế tắc

tự do) cho bữa ăn tối của các nhà triết học Ví dụ được mô tả như sau: Năm nhà triết học ngồi quanh một cái bàn tròn với một bát cơm ở giữa Đối với các nhà Triết học (mang một chút ngây thơ), sống bao gồm nghĩ và ăn (và chờ đợi, như chúng ta thấy) Để lấy một ít cơm ra khỏi bát, một nhà triết học cần hai chiếc đũa Tuy nhiên,

ở giữa hai nhà triết học cạnh nhau chỉ có một chiếc đũa Do đó, tại bất kỳ thời điểm nào chỉ có một trong hai nhà triết học đó có thể ăn Dĩ nhiên, việc sử dụng đôi đũa

là độc quyền và việc ăn với hai bàn tay là bị cấm

Tính chất loại trừ lẫn nhau có thể được mô tả bằng một bất biến sử dụng công thức mệnh đề logic

crit crit

Với deadlock freedom (bế tắc độc lập) của bữa ăn tối của các nhà triết học, bất

biến bảo đảm rằng ít nhất một trong các nhà triết học không phải chờ đợi để lấy chiếc đũa lên Điều này có thể được thiết lập sử dụng công thức

wait wait wait wait wait

Ở đây, mệnh đề wait i biểu thị trạng thái của nhà triết học i trong khi ông ấy

chờ đợi một chiếc đũa

2.4.2 Tính an toàn

Như chúng ta đã thấy ở trên, các bất biến có thể được xem như các thuộc tính trạng thái và có thể được kiểm tra bằng việc xem xét các trạng thái có thể đạt đến được Tuy nhiên, một số thuộc tính an toàn có thể áp đặt các yêu cầu về phân đoạn đường đi hữu hạn, và không thể được xác minh bằng cách chỉ xem xét các trạng thái

có thể đạt đến Để hiểu rõ điều này, xem xét ví dụ của một máy rút tiền, cũng được

biết đến như là một máy rút tiền tự động (ATM: Automated Teller Machine) Một

yêu cầu tự nhiên là số tiền đó chỉ có thể được rút khỏi máy rút tiền mỗi khi xác thực

được người sỡ hữu (PIN) được cung cấp Thuộc tính này là không bất biến, vì nó

không phải là một thuộc tính trạng thái Tuy nhiên, xem xét đó là một thuộc tính an toàn, như bất kỳ hành vi vi phạm vô hạn nào yêu cầu có một tiền tố hữu hạn là

“bad”, ví dụ, trong đó tiền được rút ra mà trước đó không cần phải cấp mã PIN

Về mặt hình thức, thuộc tính an toàn P là được xác định như một tính chất LT trên AP mà bất kỳ tiền tố vô hạn σ nơi P không nắm giữ chứa đựng một tiền tố tồi

(bad prefix) Tiếp sau là tiền tố hữu hạn σ nơi mà các điều tồi đã xảy ra, và do đó không có tiền tố vô hạn mà bắt đầu với σ đáp ứng P

Định nghĩa 2.3.: Safety Properties, bad Prefixes (Thuộc tính an toàn, tiền tố

P I σ ∈ ω σ là một tiền tố hữu hạn của σ’ }= ∅

Bất kỳ tiền tố hữu hạn σ nào được gọi là một tiền tố tồi - bad prefix với P safe Một tiền tố tồi tối thiểu với P safe biểu thị một tiền tố tồi σ cho P safe mà không có tiền tố thích hợp của σ là một tiền tố tồi cho P safe Nói cách khác, tiền tố tồi tối thiểu là các tiền tố tồi mà chiều dài tối thiểu Tập tất cả các tiền tố tồi cho P safe

được biểu thị qua BadPref P( )safe , tập các tiền tố tồi tối thiểu được biểu thị qua

( safe)

Đầu tiên chúng ta hãy quan sát một bất biến bất kỳ nào cũng là một thuộc tính

an toàn Với các mệnh đề công thức Φ trên AP và bất biến P inv của nó, mọi tiền tố hữu hạn của form 0 1 ( )2AP

n

A A A… ∈ ϖ với A ¨0 Φ … , ,b A n−1 và A ¨ n Φ tạo thành tiền tố

tồi tối thiểu cho P inv Hai ví dụ sau đây minh họa rằng có các thuộc tính an toàn mà không bất biến

Ví dụ: A Safety Property for a Traffic Light (Một thuộc tính an toàn cho đèn

giao thông)

Chúng ta giả sử một đặc tả của một đèn giao thông với ba giai đoạn thông

thường là “red”, “green”, và “yellow” Yêu cầu rằng mỗi giai đoạn red sẽ được đặt trước bởi một giai đoạn yellow là thuộc tính an toàn nhưng không bất biến Điều

này được thể hiện ở sau

Đặt red, yellow và green là các mệnh đề nguyên tử Bằng trực giác, chúng phục vụ cho việc đánh dấu các trạng thái mô tả giai đoạn red (yellow hay green)

Thuộc tính “luôn luôn có ít nhất một đèn sáng” được mô tả bởi:

0 1 {σ = A A |A j ⊆AP A∧ j ≠ ∅ }.

Các tiền tố tồi là các tiền tố hữu hạn mà chứa đựng Ø Một tiền tố tồi tối thiểu kết thúc với Ø

Thuộc tính “không bao giờ có trường hợp mà hai đèn được bật lên cùng lúc” được mô tả bởi:

0 1 {σ = A A A j ⊆AP∧ A j ≤ 1}.

Tiền tố tồi cho thuộc tính là các tiền tố chứa đựng các tập như

{red green red green, },{ , }, Tiền tố tồi tối thiểu kết thúc với bộ như vậy

Giờ chúng ta đặt AP' {= red yellow, } Thuộc tính “giai đoạn red phải được đứng ngay trước bởi giai đoạn yellow” được mô tả bằng tập các tiền tố vô hạn

0 1

A A

σ = với A i∈ {red yellow i } ∀ ≥ 0, ta có:

1 kéo theo i>0 và yellow

Tiền tố tồi là các tiền tố hữu hạn mà vi phạm điều kiện này Một ví dụ của tiền

tố tồi mà là tối thiểu là: ØØ{ }red v à Ø{ }red

Các tiền tố tồi sau đây không phải là tối thiểu:

{yellow yellow red red}{ }{ }{ } cũng là tiền tố tồi

Thuộc tính an toàn yêu cầu cho dấu vết hữu hạn được chính thức phát biểu trong Bổ đề sau:

Bổ đề 2.1: Satisfaction Relation for Safety Properties (Mối quan hệ thỏa mãn

cho thuộc tính an toàn)

Với Hệ thống chuyển đổi TS không có các trạng thái cuối và thuộc tính an

toàn P safe

safe

TS P ¨ bnếu và chỉ nếu Traces fin( )TS IBadPref P( )safe =Ø

Chứng minh:

“if”: chứng minh dựa theo sự mâu thuẫn Đặt Trace fin( )TS IBadPref P( )safe =Ø

và giả thiết rằng TS¨ P safe b Do TS¨ P safe b , thì trace( )π ∉P safe với một số đường đi π

trong TS Như vậy, traces( )π bắt đầu với một tiền tố tồi σ cho P safe Nhưng,

và do đó TS¨ P safe b Mâu thuẫn

Ta kết luận phần này với một đặc tính thay thế của thuộc tính an toàn bằng bao đóng của chúng

Định nghĩa 2.4 Prefix and Closure (Tiền tố và bao đóng)

Với dấu vết ( )2AP ω

σ∈ , đặt pref ( )σ biểu thị tập các tiền tố hữu hạn của σ

pref σ = ∈ ω σ là một tiền tố hữu hạn của σ}

Nghĩa là, nếu σ =A A0 1…thì pref ( )σ ={ε, , ,A A A A A A0 0 1 0 1 2, …}là một tập vô

hạn các tiền tố hữu hạn Với thuộc tính P trên AP:

( ) { 2( )AP | ( ) ( )}

Chẳng hạn như, với dấu vết vô hạn σ ABABAB= …(với A B, ⊆AP), ta có

ra bởi các biểu thức chính quy(AB) ( * A+ε)

Bao đóng của một thuộc tính LT P là tập các dấu vết vô hạn của các tiền tố hữu hạn cũng là tiền tố của P Nói cách khác, các dấu vết vô hạn trong bao đóng của

P không có một tiền tố nào mà không phải là một tiền tố của chính P Như chúng ta

thấy dưới đây, bao đóng là một khái niệm chính trong sự biểu thị tính an toàn và tính sống còn

Bổ đề 2.2 Alternative Characterization of Safety Properties (thay thế đặc tả

của thuộc tính an toàn)

Đặt P là một thuộc tính LT trên AP Thì, P là một thuộc tính an toàn nếu và chỉ nếu closure P( )=P

Chứng minh:

“If”: Ta hãy giả thiết rằng closure P( )=P Để chứng tỏ rằng P là một thuộc

tính an toàn, ta lấy một phần tử σ∈( )2AP ω\ P và chứng tỏ rằng σ bắt đầu với một tiền tố tồi cho P Khi σ∉ ¨ P closure P b ( ) tồn tại một tiền tố hữu hạn σ của σ với

“only if”: Ta hãy giả thiết rằng P là một thuộc tính an toàn Ta phải chứng tỏ

rằng P closure P= ( ) Sự bao hàm P closure P⊆ ( ) đúng cho tất cả các thuộc tính LT

Vẫn còn để cho thấy rằng closure P( )⊆P Ta làm vậy bởi sự mâu thuẫn Ta hãy giả thiết rằng có một vài σ =A A1 2 ∈closure P P( ) \ Khi P là một thuộc tính an toàn và

P

σ ∉ , σ có một tiền tố hữu hạn σ = A A1 n∈BadPref P( )

Với σ∈closure P( ), ta có σ∈pref( )σ ⊆ pref P( ) Do đó, tồn tại một tiền tố ' P

Nói một cách thân mật, thuộc tính an toàn chỉ rõ rằng “một số điều tồi tệ

không bao giờ xảy ra” Đối với các thuật toán loại trừ lẫn nhau, từ “bad” nghĩa là

nhiều hơn một tiến trình trong đoạn tới hạn của nó, trong khi đối với các đèn giao

thông, “bad” là tình huống mà bất cứ khi nào một giai đoạn sáng đỏ không được

đứng trước bởi giai đoạn ánh sáng màu vàng

Một thuật toán có thể dễ dàng đáp ứng một thuộc tính an toàn bởi việc làm đơn giản là không làm gì như thể điều này sẽ không bao giờ dẫn đến tình huống

“bad” Đây thường là điều không mong muốn, các thuộc tính an toàn được bổ sung bằng các thuộc tính mà yêu cầu một số tiến độ Những tính chất như vậy được gọi là

thuộc tính “sống còn” (hoặc đôi khi là “progress” properties) Bằng trực giác, chúng

nói rằng có một số điều tốt sẽ xảy ra trong tương lai

Trong cách tiếp cận của chúng ta, một thuộc tính sống còn (trên AP) được định nghĩa như một thuộc tính LT mà không loại trừ bất kỳ tiền tố nào Nói một cách

thân mật, nó nghĩa là bất kỳ tiền tố hữu hạn nào có thể được mở rộng mà kết quả dấu vết vô hạn thỏa mãn thuộc tính sống còn được xem xét Điều này trái ngược với

thuộc tính an toàn nơi mà nó phải có một dấu vết hữu hạn (the “bad prefix”) để kết

luận rằng một thuộc tính an toàn bị bác bỏ

Định nghĩa 2.4: Thuộc tính LT P live trên AP là một thuộc tính sống còn bất kỳ khi nào ( ) ( )*

2AP live

Do đó, một thuộc tính sống còn (trên AP) là một thuộc tính LT P mà mỗi tiền

tố hữu hạn có thể được mở rộng tới một tiền tố vô hạn mà thỏa mãn P Nói cách