các kỹ thuật đặc tả và kiểm chứng cho các bài toán tương tranh

Đề tài tập trung tìm hiểu các kỹ thuật, phương pháp, công cụ tự động kiểm chứng một số bài toán tương tranh ở mức thiết kế.Các mục tiêu được đặt ra như sau: Khảo sát, đánh giá tổng hợp k

Trang 1

Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

Trần Quốc Tuấn

CÁC KỸ THUẬT ĐẶC TẢ VÀ KIỂM CHỨNG

CHO CÁC BÀI TOÁN TƯƠNG TRANH

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

Mã số: 60 48 01

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

NGƯỜI HƯỚNG DẪN KHOA HỌC PGS TS Nguyễn Xuân Huy

Thái Nguyên, năm 2014

Trang 2

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn: “Các kỹ thuật đặc tả và kiểm chứng cho các bài

toán tương tranh” hoàn toàn do tôi thực hiện Các kết quả trình bày trong luận

văn là trung thực

Hải Phòng, ngày 26 tháng 03 năm 2014

Người thực hiện

Trần Quốc Tuấn

Trang 3

LỜI CẢM ƠN

Trước tiên, tôi muốn gửi lời cảm sâu sắc nhất đến PGS TSKH Nguyễn Xuân Huy, người đã trực tiếp giảng dạy và tận tình hướng dẫn tôi trong suốt quá trình học cao học

Tôi cũng trân trong cảm ơn các Thầy, Cô đang công tác tại Viện Công nghệ thông tin Việt Nam,các Thầy, Cô trường Đại học Công nghệ thông tin

và truyền thông – Đại học Thái Nguyên đã về truyền thụ kiến thức để tôi hoàn thiện luận văn này

Tôi gửi lời cảm ơn đến Ban giám hiệu, các Thầy, Cô phòng Đào tạo sau đại học, trường Đại học Công nghệ thông tin và truyền thông – Đại học Thái Nguyên đã quan tâm đến lớp Cao học K11C đặt tại Hải Phòng

Tôi gửi lời cảm ơn đến Ban giám hiệu Trường Đại học Hải Phòng, khoa Công nghệ thông tin, đã tạo điều kiện về thời gian, kinh phí để tôi hoàn thành khóa học

Tôi muốn cảm ơn gia đình, bạn bè cũng như các đồng nghiệp đã chia sẻ

và tạo điều với tôi những lúc khó khăn nhất để tôi có thể hoàn thành khóa học này

Trang 4

MỤC LỤC

LờI CAM ĐOAN 2

LờI CảM ƠN 3

MụC LụC 4

DANH MụC Từ VIếT TắT 6

DANH MụC BảNG 7

DANH MỤC HÌNH VẼ 8

LỜI NÓI ĐẦU 9

CHƯƠNG 1 11

MộT Số BÀI TOÁN TƯƠNG TRANH 11

1.1 Giới thiệu 11

1.2 Bài toán Đọc-Ghi 14

1.3 Bài toán Cung-Tiêu (producer-consumer problem) 14

1.4 Một số vấn đề trong chương trình tương tranh 16

1.5 Kết luận 17

CHƯƠNG 2 18

MộT Số PHƯƠNG PHÁP KIểM CHứNG 18

2.1 Kiểm chứng thiết kế 18

2.2 Kiểm chứng mô hình 19

2.3 Phương pháp hình thức Event-B 20

2.3.1 Máy và ngữ cảnh 20

2.3.2 Phân rã và kết hợp 22

2.4 Sinh mệnh đề cần chứng minh 23

2.5 Máy hữu hạn trạng thái (Finite State Process - FSP) 23

2.5.1 Cú pháp đặc tả trong FSP 25

2.5.2 Quy trình tuần tự 28

2.5.3 Công cụ kiểm chứng LTSA 30

2.6 Kết luận 31

CHƯƠNG 3 32

MộT Số Kỹ THUậT ĐặC Tả VÀ KIểM CHứNG BÀI TOÁN TƯƠNG TRANH 32

Trang 5

3.1 Đặc tả và kiểm chứng bài toán tương tranh sử dụng Event-B 32

3.1.1 Kỹ thuật kiểm chứng sử dụng Event-B 32

3.1.2 Đặc tả Event-B cho bài toán cung cấp tiêu thụ 34

3.1.3 Đặc tả Event-B cho bài toán đọc ghi 36

3.1.4 Kết quả chứng minh tự động 39

3.2 Kỹ thuật đặc tả và kiểm chứng sử dụng FSP 39

3.2.1 Đặc tả FSP cho bài toán đọc ghi 39

3.2.2 Đặc tả FSP cho bài cung cấp tiêu thụ 41

3.3 Kết luận 42

CHƯƠNG 4 43

CÀI ĐẶT THỰC NGHIỆM 43

4.1 Mô hình Đọc và Ghi đơn giản 43

4.2 Thuật toán kiểm tra tính khả tuần tự 44

4.3 Nghi thức khóa chốt hai pha 47

4.4 Mô hình Đọc và Đọc-ghi 47

4.5 Thuật toán kiểm tra tính khả tuần tự của các lịch biểu với các khóa đọc và đọc-ghi 48

4.6 Cài đặt thực nghiệm 50

4.6.1 Kiểm tra tính khả tuần tự trong mô hình Đọc-Ghi đơn giản 50

4.6.2 Kiểm tra tính khả tuần tự trong mô hình Đọc và Đọc-ghi 53

KếT LUậN 54

TÀI LIệU THAM KHảO 55

Trang 6

DANH MụC Từ VIếT TắT

FSP Finite state process Máy hữu hạn trạng thái

LTSA Labelled Transition System

Trang 7

DANH MụC BảNG

Bảng 1.1 Mô tả các bước chuyển khoản của tiến trình P 11

Bảng 1.2 Mô tả các bước chuyển khoản của tiến trình Q 11

Bảng 1.3 Mô tả thực hiện đan xen hai tiến trình P và Q 12

Bảng 3.1 Kết quả chứng minh 38

Bảng 3.2 Đặc tả FSP cho bài toán đọc ghi 39

Bảng 3.3 Đặc tả FSP cho bài toán cung cấp tiêu thụ 41

Trang 8

DANH MỤC HÌNH VẼ

Hình 1.1.Mô tả bài toánĐọc-Ghi bằng hai tiến trình 13

Hình 1.2.Đặc tả bài toán Cung-Tiêu 14

Hình 2.1 Kiểm chứng mô hình 18

Hình 2.2 Mô hình Event-B với máy và ngữ cảnh 20

Hình 2.3 Cấu trúc tổng quát của sự kiện 22

Hình 2.4.Máy trạng thái biểu diễn các hành động bật tắt bóngđèn 23

Hình 2.5.Biểu diễn máy trạng thái cho các hành động của một giảng viên 24

Hình 2.6.Máy trạng thái biểu diễn tiến trình tuần tự BOMP 27

Hình 2.7.Máy trạng thái biểu diễn sự tổng hợpcủa tiến trình tuần tự LOOP 28

Hình 2.8 Máy trạng thái biểu diễn sự tổng hợp song songcủahai tiến trình tuần tự 29

Hình 3.1 Mô hình đặc tả tương tranh tổng quát với Event-B 32

Hình 3.2 Mô hình khởi tạo cho bài toán cung cấp tiêu thụ 33

Hình 3.3 Máy làm mịn cho vấn đề cung cấp tiêu thụ 35

Hình 3.4 Mô hình khởi tạo cho vấn đề đọc ghi 35

Hình 3.5.Máy làm mịn vấn đề đọc ghi 37

Hình 4.1 Ba tiến trình 43

Hình 4.2 Đồ thị thứ tự trước sau của các tiến trình 45

Hình 4.3 Một lịch biểu 46

Hình 4.4 Một lịch biểu gồm bốn tiến trình 49

Hình 4.5 Đồ thì tuần tự hóa của Hình 4.4 50

Trang 9

LỜI NÓI ĐẦU

Phần mềm ngày càng được ứng dụng rộng rãi, tuy nhiên, trong nhiều hệ thống, lỗi của phần mềm gây ra các hậu quả đặc biệt nghiêm trọng, không những thiệt hại về mặt kinh tế mà còn làm tổn thất trực tiếp sinh mạng con người Đến nay, trong công nghiệp phần mềm đã có nhiều phương pháp khác nhau được đề xuất và phát triển để giảm lỗi phần mềm từ pha thiết kế đến cài đặt như các phương pháp kiểm chứng (verification) và kiểm thử (testing)[1] Các phần mềm (chương trình) tương tranh thường gồm nhiều tiến trình, mỗi tiến trình là một chương trình tuần tự thực hiện một tập các câu lệnh tuần

tự Các tiến trình thường cộng tác với nhau thông qua các biến chia sẻ hoặc cơ chế truyền thông điệpđể đồng bộ hay đểtrao đổi dữ liệu

Truy xuất bộ nhớ dùng chung là một trong những hoạt động tương tranh giữa các tiến trình Vấn đề tương tranh trên một tài nguyên dùng chung là vấn

đề lớn cần phải giải quyết triệt để vì nếu nhiều tiến trình truy xuất đồng thời vàomộttài nguyên dùng chung màkhông có sự kiểm soát thì dễ xảy ra lỗi làm

hư hỏng tài nguyên

Các phương pháp kiểm thử (testing) phần mềm chỉ phát hiện được các lỗi

ở mức mã nguồn, chưa phát hiện được các lỗi ở mức logic như các lỗi thiết

kế Với các hệ thống tương tranh việc kiểm thử như quan sát các dữ liệu vào

ra là không khả thi do mỗi lần thực thi các phần mềm tương tranh thường cho các kết quả đầu ra là khác nhau Hơn nữa, việc kiểm chứng phần mềm tại mức

Trang 10

thiết kế nhằm phát hiện lỗi sớm, giảm chi phí phát triển Chính vì vậy vấn đề kiểm chứng bài toán tương tranh tại mức thiết kế là cần thiết

Đề tài tập trung tìm hiểu các kỹ thuật, phương pháp, công cụ tự động kiểm chứng một số bài toán tương tranh ở mức thiết kế.Các mục tiêu được đặt ra như sau:

Khảo sát, đánh giá tổng hợp kiến thức, kết quả nghiên cứu trong lĩnh vực kiểm chứngphần mềm tương tranh, các vấn đề nghiên cứu liên quan

Tìm hiểu các phương pháp đặc tả hình thức Event-B, FSP Ứng dụngcác phương pháp này để đặc tả và kiểm chứng tự động một số bài toán tương tranh

Các phần còn lại của luận văn được cấu trúc như sau:

Chương 1:Luận văn giới thiệu một số bài toán tương tranh và một số phương pháp đặc tả và kiểm chứng các bài toán này

Chương 2:Trình bày một số kiến thức cơ sở về kiểm chứng phần mềm

và các phương pháp hình thức với Event-B, FSP

Chương 3:Luận văn trình bày phương pháp kiểm chứng một số bài toán tương tranh trong chương 1 sử dụng phương pháp hình thức với Event-B và FSP

Chương 4: Luận văn trình bày hai mô hình Ghi đơn giản và ĐọcGhi Ngoài ra luận văn cũng trình bày một số thuật toán kiểm tra tính khả tuần tự của một lịch biểu Áp dụng các thuật toán để cài đặt chương trình bằng DevC++

Đọc-Phần kết luận:Tóm tắt các kết quả đạt được và một số hướng nghiên cứu tiếp theo

Trang 11

CHƯƠNG 1 MộT Số BÀI TOÁN TƯƠNG TRANH

Trong chương này luận văn giới thiệu một số bài toán tương tranhđiển hình, các vấn đề về tương tranh và một số phương pháp đặc tả và kiểm chứng các bài toán này tại mức thiết kế và mã nguồn

1.1 Giới thiệu

Các tiến trình trong một hệ thống tương tranh thường phải được đồng bộ hóa Sự đồng bộ hóa giữa các tiến trình được phân thành hai loại cộng tác hoặc cạnh tranh Một trong những ví dụ điển hình về sự cộng tác giữa các tiến trình là vấn đề cung cấp-tiêu thụ (producer-consumer) với hai tiến trình producer và consumer Trong đó tiến trình producer cung cấp các phần tử dữ liệu, sau đó tiến trình consumer sẽ tiêu thụ nó Cấp phát tài nguyên cho các tiến trình phải giải quyết vấn đề xung đột khi nhiều tiến trình cùng muốn sử dụng tài nguyên chia sẻ như dữ liệu, tệp, máy in, Tính nhất quán của dữ liệu

sẽ bị phá vỡ nếu hai tiến trình đọc-ghi cùng cập nhật chung một tệp tại cùng một thời điểm

Ví dụ[2], giả sử trên máy chủ lưu trữ các tài khoản A, B và C với các giá trị hiện có là A = B = C = 10 triệu đồng Máy chủ cần thực hiện đồng thời hai tiến trình P và Q như sau:

Tiến trình P: chuyển 1 triệu tiền từ tài khoản A sang tài khoản B

Tiến trình Q: chuyển 1 triệu tiền từ tài khoản C sang tài khoản B

Giả sử, thực hiện tuần tự hai tiến trình P,Q Tiến trình P được thực hiện trước sau đó đến tiến trình Q được thực hiện

Trang 12

Bảng 1.1 Mô tả các bước chuyển khoản của tiến trình P

write Y,B; Ghi giá trị Y từ RAM vào B 11

Kết quả: A=9, B=11

Bảng 1.2 Mô tả các bước chuyển khoản của tiến trình Q

Trang 13

Nếu ta thực hiện đan xen hai tiến trình P và Q thì có thể thu đƣợc kết quả nhƣ sau:

Bảng 1.3 Mô tả thực hiện đan xen hai tiến trình P và Q

Trang 14

Do đó vấn đề đặt ra là phải đặc tả ràng buộc về thứ tự thực hiện giữa các tiến trình nhằm bảo đảm tính nhất quán của dữ liệu chia sẻ Không mất tính

tổng quát, học viên mô tả vấn đề này bằng hai bài toán Đọc-Ghi và

Cung-Tiêu như trong Mục 1.2 và Mục 1.3

1.2 Bài toán Đọc-Ghi

Bài toán Đọc-Ghi (readers-writers problem) được mô tả bằng hai tiến

1.3 Bài toán Cung-Tiêu (producer-consumer problem)

Bài toán Cung-Tiêu là một ví dụ điển hình về sự đồng bộ hóa giữa các

tiến trình tương tranh Bài toán này có thể được mô tả thông qua hai tiến trình thực hiện theo các nguyên tắc như sau:

Trang 15

Hình 1.2.Đặc tả bài toán Cung-Tiêu

Trong đó:

producer: là tiến trình tạo và đẩy dữ liệu vào bộ đệm Q bằng phương

thức push(Q), bộ đệm được biểu diễn bằng một hàng đợi với kích thước hữu hạn và cố định;

consumer: lấy các phần tử dữ liệu từ hàng đợi qua phương thức pop(Q);

các tiến trình được thực hiện đồng thời và lặp;

thứ tự thực hiện của các tiến trình tuân theo giao thức = [start,

producer||consumer,stop] tiến trình khởi tạo (init) được thực hiện trước, sau

đó các tiến trình producer và consumer được thực hiện đồng thời Tại trạng thái OPENED, các tiến trình producer và consumer có thể thực hiện các

phương thức push(Q) hoặc pop(Q) để bổ sung hoặc loại bỏ các phần tử của hàng đợi

Khi tiến trình producer gọi phương thức stop() để chuyển sang trạng thái

CLOSED thì các phần tử khác sẽ không được bổ sung hoặc loại bỏ từ hàng đợi

start(Q)

push(Q)

pop(Q )

stop(Q)

Trang 16

Các tiến trình producer và consumer phải bảo đảm không đẩy phần tử

dữ liệu vào hàng đợi nếu nó đã đầy và không lấy dữ liệu nếu nó rỗng

1.4 Một số vấn đề trong chương trình tương tranh

Trong các chương trình tương tranh, có hai thuộc tính cơ bản cần phải bảo đảm là an toàn (safety) và thực hiện được (liveness) Thuộc tính an toàn bảo đảm chương trình luôn thỏa mãn (luôn đúng) các ràng buộc của nó Ví dụ như ràng buộc về sự xung đột (interference) giữa các tiến trình Thuộc tính thực hiện được bảo đảm chương trình cuối cùng sẽ thỏa mãn (sẽ đúng) các ràng buộc của nó Ví dụ như tính dừng của các tiến trình (process termination) và các tiến trình khi muốn truy cập vào tài nguyên chia sẻ (shared resource) thì cuối cùng nó sẽ truy cập được Một số vấn đề về tương tranh liên quan đến hai thuộc tính này được mô tả như sau

Sự xung đột (interference) xảy ra khi hai hoặc nhiều tiến trình đồng thời truy cập một biến chia sẻ, trong đó có ít nhất một tiến trình ghi và các tiến trình khác không có cơ chế rõ ràng để ngăn chặn sự truy cập đồng thời này Khi đó giá trị của biến chia sẻ và kết quả của chương trình sẽ phụ thuộc vào

sự đan xen (interleaving) hay thứ tự thực hiện của các tiến trình Sự xung đột còn được gọi là cạnh tranh dữ liệu (data race)

Khóa chết (deadlock) xảy ra khi hệ thống không thể đáp ứng được bất kỳ tín hiệu hoặc yêu cầu nào Có hai dạng khóa chết, dạng một xảy ra khi các tiến trình dừng lại và chờ đợi lẫn nhau, ví dụ một tiến trình nắm giữ một khóa

mà các tiến trình khác mong muốn và ngược lại Dạng hai xảy ra khi một tiến trình chờ đợi một tiến trình khác không kết thúc Một thuộc tính khác tương

tự như khóa chết khi các tiến trình liên tục thay đổi trạng thái của nó để đáp ứng với những thay đổi của các tiến trình khác mà không đạt được mục đích cuối cùng Sự đói (starvation) liên quan đến sự tranh chấp tài nguyên, vấn đề này xảy ra khi một tiến trình không thể truy cập đến các tài nguyên chia sẻ

Trang 17

1.5 Kết luận

Trong chương này, luận văn đã trình bày một số bài toán tương tranh điển hình và một số vấn đề về tương tranh Trong các chương tiếp theo, học viên trình bày một số kiến thức cơ sở về phương pháp hình thức với Event-B và FSP, các phương pháp này được sử dụng để đặc tả và kiểm chứng tự động các bài toán tương tranh nói trên

Trang 18

CHƯƠNG 2 MộT Số PHƯƠNG PHÁP KIểM CHứNG

Trong chương này luận văn trình bày một số kiến thức cơ sở về kiểm chứng mô hình, phương pháp hình thức với Event-B, máy hữu hạn trạng thái

FSP (Finite state process) Các phương pháp hình thức này được sử dụng để

đặc tả và kiểm chứng một số bài toán tương tranh trong chương 1

2.1 Kiểm chứng thiết kế

Đã có một vài phương pháp, công cụ, được đề xuất để đặc tả và kiểm chứng các chương trình tương tranh Các nghiên cứu này được chia thành hai hướng kiểm chứng thiết kế và kiểm chứng mã nguồn chương trình

Edmunds [6] đề xuất ngôn ngữ đặc tả trung gian Object-oriented Concurrent-B(OCB) để nối liền giữa đặc tả bằng Event-B với sự cài đặt của các chương trình hướng đối tượng, tương tranh Đặc tả OCB sẽ được chuyển

tự động sang mô hình của Event-B và mã chương trình Java Các chương trình Java được chuyển đổi sẽ được kiểm chứng sự tuân thủ theo đặc tả OCB của nó

Ben Younes và L.J Ben Ayed [7] đề xuất các luật để chuyển đổi từ đặc tả bằng biểu đồ hoạt động Activity Diagram của UML sang đặc tả bằng Event-

B Dựa vào cơ chế làm mịn dần của Event-B để đặc tả và kiểm chứng tự động

sự phân rã của các biểu đồ hoạt động của UML thỏa mãn các thuộc tính như tắc nghẽn (deadlock), sự công bằng (fairness) Đóng góp chính của nghiên cứu này là chuyển đổi từ một đặc tả trực quan sang hình thức và dựa vào công

cụ của nó để chứng minh tự động một mô hình thỏa mãn các thuộc tính của

nó Tuy nhiên việc chuyển đổi chưa được thực hiện tự động hoàn toàn, hơn nữa nghiên cứu này mới đưa ra một ví dụ để minh họa khả năng chuyển đổi của nó

Trang 19

Ball [9] đề xuất các mẫu thiết kế để đặc tả sự tương tác giữa các tác tử phần mềm, các mẫu thiết kế sau đó được chuyển đổi sang đặc tả bằng Event-

B Tuy nhiên, việc chuyển đổi từ mẫu thiết kế sang đặc tả bằng Event-B chưa được tự động Giao thức tương tác được đặc tả lại với Event-B dựa vào mẫu thiết kế của nó

2.2 Kiểm chứng mô hình

Phương pháp kiểm chứng mô hình (model checking)[8] được sử dụng để

xác định tính hợp lệ của một hay nhiều tính chất mà người dùng quan tâm trong một mô hình phần mềm cho trước

Cho mô hình M và thuộc tính p cho trước, nó kiểm tra liệu thuộc tính p có thỏa mãn trong mô hình M hay không, kí hiệu M |= p Quy trình kiểm chứng

mô hình được biểu diễn trong (Hình 2.1) Về mặt thực thi, kiểm chứng mô hình sẽ duyệt qua các trạng thái, các đường thực thi có thể trong mô hình M

để xác định tính khả thỏa của p Trong đó các thuộc tính cần kiểm chứng được đặc tả bằng logic thời gian LTL hoặc CTL Mô hình M là một cấu trúc Kripke gồm bốn thành phần M = (S, S0, L, R) trong đó:

S là một tập hữu hạn các trạng thái, S0 S là trạng thái đầu;

R SxS là quan hệ chuyển trạng thái;

L: S  2AP là hàm gán nhãn với AP là tập hữu hạn các mệnh đề nguyên tử được xây dựng từ hệ thống

Đặc tả các thuộc tính cần kiểm chứng (System properties)

Trả lời TRUE, nếu mô hình thỏa mãn đặc tính

FALSE, nếu mô hình không thỏa mãn, phản ví

dụ

Mô hình hệ thống

(System requirements)

Công cụ kiểm chứng (checking tool)

Hình 2.1.Kiểm chứng mô hình

Trang 20

2.3 Phương pháp hình thức Event-B

B[11] là một phương pháp hình thức dùng để đặc tả và kiểm chứng phần mềm Phương pháp B dựa trên lý thuyết tập hợp, ngôn ngữ thay thế tổng quát

và logic vị từ bậc 1 (first order logic) Phương pháp B hỗ trợ quá trình phát triển phần mềm bằng cách làm mịn (refinement) Quá trình này bắt đầu bằng

cách xây dựng các máy trừu tượng, sau đấy làm mịn dần cho đến khi nhận được một máy thực thi, ở mức tương tự như mã nguồn chương trình Quá trình này được bảo đảm sự đúng đắn thông qua việc sinh các mệnh đề cần

chứng minh (proof obligations)

Event-B [10] là một phương pháp hình thức mới, cải tiến của một số phương pháp hình thức khác mà chủ yếu là dựa trên cú pháp của phương pháp

B, được sử dụng để đặc tả và kiểm chứng các hệ thống gồm nhiều thành phần độc lập hoạt động theo nguyên tắc cộng tác và phản ứng lại với các kích thích

từ môi trường Các hệ thống này bao gồm các hệ điều khiển, hệ chuyên gia, các hệ thống phân tán và thường được gọi chung là các hệ thống phản ứng lại

(reactive systems)

Các mô hình Event-B thường được mô tả bởi hai cấu trúc cơ bản: ngữ cảnh (contexts) và máy trừu tượng (machines) Các ngữ cảnh dùng để mô tả phần tĩnh của mô hình, ví dụ như kiểu và các hằng số sử dụng trong phát triển hệ thống, trong khi các máy trừu tượng mô tả phần động, bao gồm trạng thái, các sự kiện tương tác với môi trường

2.3.1 Máy và ngữ cảnh

Các mô hình Event-B[10] được mô tả bởi hai cấu trúc cơ bản là máy

(machine) và ngữ cảnh (context) Trong đó, máy dùng để mô tả phần động

của mô hình bao gồm biến, bất biến, định lý và các sự kiện tương tác với môi

trường Ngữ cảnh mô tả phần tĩnh của mô hình, chứa các tập hợp (set), hằng,

tiên đề và định lý Một mô hình có thể chỉ gồm máy hoặc ngữ cảnh hoặc sự

Trang 21

kết hợp giữa máy và ngữ cảnh Một máy có thể không hoặc tham chiếu một vài ngữ cảnh Các máy và ngữ cảnh của mô hình đƣợc làm mịn bằng cách bổ sung các hằng, biến, bất biến, định lý, sự kiện (Hình 2.2) Biểu diễn cấu trúc tổng quát của máy bên trái và ngữ cảnh bên phải

Trang 22

theorem, events tương ứng là các định lý, sự kiện Trong đó sự kiện mô

tả một hành động sẽ được xảy ra khi điều kiện của nó được thỏa mãn

2.3.2 Phân rã và kết hợp

Mô hình hệ thống với Event-B được bắt đầu từ các sự kiện trừu tượng quan sát được có thể xảy ra trong hệ thống, từ đó đặc tả các trạng thái và hành

vi của hệ thống ở mức trừu tượng cao hơn Một sự kiện e tác động lên (một

danh sách) biến trạng thái v, với điều kiện G(v) và hành động A(v), sẽ được

mô tả như sau:

when G(v) then A(v) end

Vì thế, khi trạng thái v thỏa mãn điều kiện G(v) = true, hành động A(v) sẽ được thực hiện Hình 2.3 biểu diễn cấu trúc tổng quát của một sự kiện Trong đó:

Mệnh đề status có thể là ordinary, convergent (sự kiện phải làm tăng giá

trị các biến của nó), anticipated (sự kiện không được làm tăng giá trị các biến của nó);

mệnh đề refine hiển thị danh sách các sự kiện trừu tượng được làm mịn;

mệnh đề any hiển thị các tham số nếu có;

mệnh đề where chứa các điều kiện để sự kiện được kích hoạt;

mệnh đề with chứa các tham số phải nhận giá trị trả về của sự kiện trừu

tượng tương ứng;

mệnh đề then chứa các hành động của sự kiện Các hành động này sẽ

được thực thi khi các điều kiện của sự kiện được thỏa mãn

Trang 23

2.4 Sinh mệnh đề cần chứng minh

RODIN [4] (Rigorous Open Development Environment for Complex Systems) là một bộ công cụ mã nguồn mở trên nền Eclipse để đặc tả và chứng minh tự động trong Event-B Trong luận văn này học viên sử dụng bộ công cụ RODIN để đặc tả, làm mịn, sinh và chứng minh tự động các mệnh đề cần chứng minh để bảo đảm tính đúng đắn của mô hình bài toán tương tranh.RODIN sẽ kiểm tra tĩnh các máy và ngữ cảnh để sinh ra các mệnh đề bằng bộ sinh mệnh đề cần chứng minh (Proof Obligation Generator)

2.5 Máy hữu hạn trạng thái (Finite State Process - FSP)

Máy hữu hạn trạng thái được sử dụng để đặc tả các mô hình tiến trình FSP có thể biểu diễn các hành động, trạng thái của tiến trình, được định nghĩa

Trang 24

Định nghĩa 2.1 (Máy hữu hạn trạng thái)Máy hữu hạn trạng thái là một

on → off → on → off → on → off → …

Nhƣ vậy, nếu bóng đèn còn hoạt động đƣợc thì các hành động này sẽ liên tục xảy ra đến khi nào mà nó không đƣợc sử dụng nữa Chính vì vậy việc đặc

tả nhƣ trên là không đầy đủ

Tuy nhiên ta hoàn toàn có thể giải quyết vấn đề này bằng một đặc tả FSP nhƣ sau:

SWITCH = (on – > off – >SWITCH )

Trong đó: SWITCH là một tiến trình, on, off là các hành động.Hình 2.4

biểu diễn máy trạng thái cho các hành động bật, tắt một bóng đèn

Trang 25

Ví dụ 2: Giả sử chúng ta cần đặc tả các hành động lên lớp, giảng bài, nghỉ của một giảng viên nhƣ sau:

lên lớp– >giảng bài– >nghỉ– >lên lớp– >giảng bài– >nghỉ– > …

Nhƣ vậy, nếu một giảng viên còn công tác thì các hành động này sẽ tếp tục xảy ra đến khi nào giảng viên ngừng công việc này Chính vì vậy việc đặc

tả nhƣ trên là không đầy đủ

Tuy nhiên ta hoàn toàn có thể giải quyết vấn đề này bằng một đặc tả FSP nhƣ sau:

GIANGVIEN = (lenlop – >giangbai– > nghi – >GIANGVIEN)

Trong đó: GIANGVIEN:là một tiến trình;lenlop, giangbai, nghi: là các

hành động.Hình 2.5 biểu diễn máy trạng thái cho các hành động lên lớp,

giảng bài và nghỉ của một giảng viên

Hình 2.5.Biểu diễn máy trạng thái cho các hành động của một giảng viên

2.5.1 Cú pháp đặc tả trong FSP

Action prefix ((x – > P))[5]: Nếu x là một hành động và P là một tiến

trình thì một action frefix (x – > P) mô tả một tiến trình trong đó các hành

nghi

Trang 26

động x hoạt động đúng theo mô tả của tiến trình P Tiến trình P phải viết hoa chữ cái đầu, hành động x viết bằng chữ cái thường

Lựa chọn (Choice)[5]: Nếu x, y là các hành động thì (x – > Q | y – > P)

mô tả một tiến trình trong đó các hành động đầu tiên tham gia là x hoặc y,các hành động tiếp theo hoạt động theo mô tả của Q nếu hành động đầu tiên xảy

ra là x, các hành động tiếp theo hoạt động theo mô tả của P nếu hành động đầu tiên xảy ra là y

Lập chỉ mục cho các tiến trình và hành động (indexed process and actions): Khi mô hình các tiến trình và hành động có những trường hợp

những tiến trình và hành động đó có rất nhiều giá trị Ta có thể gán nhãn cho các quy trình và hành động đó và lập chỉ mục cho chúng [5]

Ví dụ: FSP mô tả hành động vào, ra của 3 chiếc ô tô khi qua 3 cổng của một trạm soát vé:

Gate = (in[1] – > out[1] – > Gate

| in[2] – > out[2]  Gate| in[3] – > out[3]

– > Gate)

Trong đó Gate là một tiến trình, in, out là các hành động vào ra của các ô tô, [1], [2], [3] là chỉ mục của các hành động in và out tương ứng với 3 chiếc ô tô vào, ra khi qua cổng soát vé

Tham số tiến trình (Process parameters) [5]: khi tiến trình và hành động có

nhiều giá trị thì thay vì đánh chỉ mục, chúng ta có thể tạo tham số để mô tả tiến trình bằng FSP được gọn hơn

Trang 27

Trong ví dụ trên ta có:

const N = 3 Gate = ( in[i:1 N] – > out[i] – > Gate)

Trong đó i:1 N có nghĩa i có giá trị lần lượt từ 1 đến N

Hành động được đảm bảo (Guarded Action) [5]: thường rất hữu dụng để

định nghĩa các hành động cụ thể nhưng muốn xảy ra phải thỏa mãn một điều kiện nào đó Ví dụ mô tả đám đông vào thang máy, thang máy cho phép chở

10 người, nếu số người quá quy định thì phải ra bớt, ngược lại có thể thêm người vào vì còn nhiều người đang chờ được vào:

Count(N=10) = Count[1], Count[i:1 N] = (when(i<N) enter – > Count[i+1]

| when(i>N) out – > Count[i-1])

Hành động được đảm bảo bởi “when” đảm bảo cho thang máy hoạt động đúng công suất Khi số người quá quy định thì phải ra ngoài bớt, khi số người trong thang chưa tới giới hạn thì có thể tiếp tục vào

Alphabet của tiến trình (Process Alphabet)[web2]: Alphabet của một

tiến trình là một tập hợp tất cả cách hành động mà nó có thể tham gia Ta lấy một ví dụ định nghĩa WRITE sử dụng write[1] và write[3]:

WRITER = (write[1] – >write[3] – >WRITER) +{write[0 3]}

Trong ví dụ này thì Alphabet của WRITE là write[0 3]

Trang 28

2.5.2 Quy trình tuần tự

Các tiến trình trong FSP được chia làm 3 loại [web2]:

- Các tiến trình cục bộ (local process) được định nghĩa là một trạng thái trong một tiến trình cơ bản

- Tiến trình cơ bản (primitive process) được xác định bởi tập hợp các tiến trình cục bộ Một tiến trình cục bộ được xác định bằng cách sử dụng STOP, ERROR, tiền hành động (Action prefix) và lựa chọn (choice)

- Tiến trình tuần tự (sequential process) là một tiến trình có thể kết thúc Một tiến trình có thể kết thúc nếu một tiến trình cục bộ END có thể được với

tới từ trạng thái bắt đầu của nó

- Tiến trình cục bộ END: Tiến trình cục bộ END biểu thị trạng thái mà

tiến trình kết thúc thành công Một tiến trình đúng đắn khi không có hành động nào tiếp theo xảy ra sau END Về mặt ngữ nghĩa nó tương tự như STOP Tuy nhiên, STOP là một trạng thái mà tiến trình tạm ngưng quá sớm, thường

là do deadlock STOP được sử dụng khi ta muốn kết thúc một tiến trình Ví

dụ sau mô tả tiến trình hẹn giờ một quả bom:

Hình 2.6.Máy trạng thái biểu diễn tiến trình tuần tự BOMP

Trong đó, BOMB, E lần lượt là các trạng thái đầu và kết thúc tick là các

hành động đếm thời gian, bang biểu diễn hành động nổ bom

Sự tổng hợp các tiến trình tuần tự: Nếu Q là một tiến trình tuần tự, P là một tiến trình cục bộ, sau đó P;Q biểu diễn cho sự tổng hợp tuần tự như vậy khi P kết thúc, P;Q sẽ trở thành tiến trình Q

Trang 29

Nếu chúng ta định nghĩa tiến trình SKIP = END then P; SKIP ≡ P and SKIP; P ≡ P Một sự tổng hợp tuần tự trong FSP luôn luôn có dạng: SP1;SP2;….;SPn;LP (Local Process)

Nơi SP1;…;SPn là sự tổng hợp tuần tự và LP là tiến trình cục bộ Một sự tổng hợp tuần tự có thể xuất hiện ở bất cứ chỗ nào trong định nghĩa của một tiến trình cơ bản mà một tiến trình cục bộ tham chiếu đến có thể xuất hiện

Ví dụ tiến trình P123 và LOOP:

Hình 2.7.Máy trạng thái biểu diễn sự tổng hợpcủa tiến trình tuần tự LOOP

Sự tổng hợp song song các tiến trình tuần tự: Sự tổng hợp song song SP1

|| SP2 của hai tiến trình tuần tự SP1 và SP2 kết thúc khi cả hai tiến trình cùng kết thúc Nếu kết thúc có thể tới đƣợc trong SP1 || SP2 thì nó là tiến trình tuần

tự

Trang 30

Hình 2.8 biểu diễn một ví dụ về sự tổng hợp song song của tiến trình tuần tự:

Hình 2.8 Máy trạng thái biểu diễn sự tổng hợp song song

củahai tiến trình tuần tự

Trong đó S và P (S| |P) là sự tổng hợp song song của hai tiến trình tuần

tự vì trạng thái kết thúc E có thể tới được trong các tiến trình S và P

2.5.3 Công cụ kiểm chứng LTSA

LTSA (Labeled Transision System Analyser - LTSA)là công cụ kiểm chứng tự động tính thỏa mãn của các thuộc tính của một mô hình tương tranh cho trước Một cách cụ thể, từ đặc tả thiết kế của hệ thống cần kiểm chứng, chúng ta biểu diễn hệ thống dưới dạng các tiến trình thành phần và cần đặc tả hình thức chúng bằng các máy hữu hạn trạng thái (Finite State Processess - FSP) Các tiến trình này sẽ được công cụ LTSA tự động chuyển thành hệ thống chuyển trạng thái có gán nhãn LTS (Labeled Transision System) tương ứng Các thuộc tính cần kiểm chứng của hệ thống cũng được đặc tả một cách tương tự Sử dụng toán tử ghép nối song song (ký hiệu “||”) để ghép nối các thành phần với nhau để thu được mô hình của toàn bộ hệ thống Công cụ

Định dạng
Số trang	61
Dung lượng	1,7 MB