Chứng minh tính đúng đắn cho bài toán xung đột tài nguyên cho các hệ đa tác tử

Tuy nhiên, phương pháp kiểm chứng mô hình chỉ áp dụng được với các hệ thống có số lượng tác tử là hữu hạn và phải xây dựng được máy hữu hạn trạng thái đặc tả chính xác hành vi của hệ thố

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LỜI CAM ĐOAN

Tôi xin cam đoan rằng, luận văn thạc sĩ công nghệ thông tin “Chứng minh tính đúng đắn cho bài toán xung đột tài nguyên cho các hệ đa tác tử” là sản phẩm nghiên cứu của riêng cá nhân tôi dưới sự giúp đỡ rất lớn của Giảng viên hướng dẫn là TS Phạm Ngọc Hùng, tôi không sao chép lại của người khác Những điều đã được trình bày trong toàn bộ nội dung của luận văn này hoặc là của chính cá nhân tôi, hoặc là được tổng hợp từ nhiều nguồn tài liệu Tất cả các tài liệu tham khảo đều có nguồn gốc rõ ràng và được trích dẫn hợp pháp

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình

Hà nội, ngày 26 tháng 06 năm 2014 Người cam đoan

Nguyễn Thế Huy

LỜI CẢM ƠN

Trước tiên, tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc đến thầy giáo, TS Phạm Ngọc Hùng - người đã dành nhiều tâm huyết, tận tình chỉ bảo và giúp đỡ tôi trong suốt quá trình kể từ khi tôi bắt đầu học môn học do thầy giảng dạy, rồi tôi xin thầy hướng dẫn đề tài, cho đến khi tôi hoàn thành luận văn này

Tôi xin gửi lời cảm ơn chân thành tới các thầy cô giáo khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội - nơi tôi đã theo học trong thời gian qua Các thầy cô đã cung cấp cho tôi những kiến thức quý báu, tạo điều kiện tốt nhất cho tôi trong suốt quá trình học tập và nghiên cứu tại trường

Cuối cùng, tôi xin chân thành cảm ơn những người thân trong gia đình, đặc biệt là bố mẹ tôi đã luôn động viên và ủng hộ tôi Xin cảm ơn bạn bè cùng khóa đã giúp đỡ tôi trong quá trình học tập

Luận văn này được thực hiện với sự hỗ trợ của đề tài mã số QG.12.50 do Đại học Quốc Gia Hà Nội tài trợ

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ivv

DANH MỤC HÌNH VẼ v

Chương 1 GIỚI THIỆU 1

Chương 2 TỔNG QUAN VỀ CafeOBJ 3

2.1 Giới thiệu 3

2.2 Đặc tả và kiểm chứng trong CafeOBJ 6

2.3 Ví dụ minh họa 6

Chương 3 ĐẶC TẢ HỆ THỐNG ĐA TÁC TỬ SỬ DỤNG CHUNG ĐA TÀI NGUYÊN 8

3.1 Giới thiệu bài toán 8

3.2 Phương pháp đặc tả 12

3.2.1 Đặc tả các tác tử 12

3.2.2 Không gian trạng thái 13

3.2.3 Đặc tả các thuộc tính bất biến 13

3.3 Kiểm chứng hệ thống đa tác tử sử dụng chung đa tài nguyên 14

Chương 4 ĐẶC TẢ VÀ CHỨNG MINH TÍNH ĐÚNG ĐẮN CHO HỆ THỐNG ĐẠI LÝ VÉ MÁY BAY 16

4.1 Mô tả bài toán trong hệ chuyển trạng thái quan sát được - OTS (Observational Transition System) 16

4.2 Đặc tả hệ thống với CafeOBJ 18

4.3 Chứng minh tính đúng đắn của hệ thống 25

Chương 5 KẾT LUẬN 41

TÀI LIỆU THAM KHẢO 42

PHỤ LỤC 1 43

PHỤ LỤC 2 54

BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

3 FID Flight Identification Định danh chuyến bay

8 OTS Observational Transition System Hệ chuyển trạng thái quan

sát được

9 RID Resource Identification Định danh tài nguyên

10 SMV Symbolic Model Verifier

Bộ công cụ kiểm chứng mô hình được phát triển bởi Ken McMillan

DANH MỤC HÌNH VẼ

Hình 2.1: Định nghĩa mô-đun trong CafeOBJ 4

Hình 2.2: Đặc tả mô-đun SIMPLE-NAT trong CafeOBJ 4

Hình 2.3: Đặc tả mô-đun NAT+ trong CafeOBJ 5

Hình 2.4: Hội thoại giữa CafeOBJ với người dùng 5

Hình 2.5: Tổ chức các thành phần của một mô-đun 6

Hình 2.6: Các công đoạn chứng minh tính chất (*) 7

Hình 3.1: Lưu đồ mô tả quá trình hoạt động của hệ thống cũng như tính chất độc quyền truy xuất của các tác tử đối với mỗi tài nguyên 9

Hình 3.2: Thao tác của hệ thống đối với mỗi hàng đợi tương ứng với mỗi tài nguyên 10

Hình 3.3a: Một số kịch bản của hệ thống 11

Hình 3.3b: Một số kịch bản của hệ thống 12

Hình 3.4: Định nghĩa tập hữu hạn các hành động của các tác tử 13

Hình 3.5: Định nghĩa đệ quy không gian trạng thái của hệ thống đa tác tử sử dụng chung đa tài nguyên 13

Hình 3.6: Định nghĩa thuộc tính bất biến của hệ đa tác tử sử dụng chung đa tài nguyên 14

Hình 3.7: Chứng minh thuộc tính bất biến luôn thỏa mãn 14

Hình 3.8: Quy trình chứng minh các thuộc tính bất biến của hệ đa tác tử sử dụng chung đa tài nguyên 15

Hình 4.1: Mô hình hệ thống đại lý vé máy bay được mô tả trong hệ chuyển trạng thái quan sát được – OTS 17

Hình 4.2a: Phần đặc tả đầu tiên của mô-đun ATA 18

Hình 4.2b: Đặc tả phương thức pc tại trạng thái khởi tạo của hệ thống (init) 19

Hình 4.2c: Đặc tả chi tiết cho phương thức queue tại trạng thái khởi tạo (init) của hệ thống 19

Hình 4.2d: Khai báo các biến S, AI, AJ, QI, FI trước khi sử dụng 20

Hình 4.2e: Đặc tả chi tiết phương thức c-want 20

Hình 4.2f: Đặc tả chi tiết phương thức want 21

Hình 4.2g: Đặc tả chi tiết phương thức queue 21

Hình 4.2h: Đặc tả chi tiết phương thức c-try 21

Hình 4.2i: Đặc tả chi tiết phương thức try 22

Hình 4.2j: Đặc tả chi tiết phương thức exit và c-exit 23

Hình 4.3: Đặc tả mô-đun TRIVM 23

Hình 4.4: Đặc tả mô-đun QUEUE 23

Hình 4.5: Đặc tả mô-đun LABEL 24

Hình 4.6: Đặc tả mô-đun AID định danh các tác tử 24

Hình 4.7: Đặc tả mô-đun FID định danh cho chuyến bay 24

Hình 4.8: Đặc tả mô-đun INV 25

Hình 4.9: Đặc tả mô-đun ISTEP 26

Hình 4.10: Chứng minh tính đúng đắn của thuộc tính bất biến inv tại trạng thái khởi tạo init của hệ thống 26

Hình 4.11: Chứng minh tính đúng đắn của thuộc tính bất biến inv trong trường hợp tổng quát với phương thức chuyển trạng thái want 27

Hình 4.12: Bảng phân tách các trường hợp cần chứng minh cho thuộc tính bất biến inv với phương thức chuyển trạng thái want 28

Hình 4.13: Kiểm chứng trường hợp c-want(s,Fi,Ak), Ai = Ak, Aj = Ak 29

Hình 4.14: Kiểm chứng trường hợp c-want(s,Fi,Ak), Ai = Ak, not (Aj = Ak) 29

Hình 4.15: Kiểm chứng trường hợp c-want(s,Fi,Ak), not (Ai = Ak), Aj = Ak 30

Hình 4.16: Trường hợp c-want(s,Fi,Ak), not (Ai = Ak), not (Aj = Ak) 31

Hình 4.17: Kết quả trường hợp c-want(s,Fi,Ak), not (Ai = Ak), not (Aj = Ak) 31 Hình 4.18: Kiểm chứng trường hợp c-want(s,Fi,Ak), not (Ai = Ak),

not (Aj = Ak) sử dụng INST, TRANS, HIDE 32

Hình 4.19: Kiểm chứng trường hợp not c-want(s,Fi,Ak) 33

Hình 4.20: Kiểm chứng trường hợp 1 của phương thức try 34

Hình 4.21: Kiểm chứng try với trường hợp 2 35

Hình 4.22: Kết quả trả về của đoạn lệnh kiểm chứng try với trường hợp 2 35

Hình 4.23: Phần đặc tả của bổ đề lemma1 35

Hình 4.24: Bổ đề đúng đắn được rút ra từ lemma1 35

Hình 4.25: Kiểm chứng try với trường hợp 2 sau khi áp dụng bổ đề đúng đắn được rút ra từ lemma1 36

Hình 4.26: Kiểm chứng try với trường hợp 3 37

Hình 4.27: Kết quả trả về của đoạn lệnh kiểm chứng try với trường hợp 3 37

Hình 4.28: Bổ đề đúng đắn được rút ra từ bổ đề lemma1 37

Hình 4.29: Kết quả kiểm chứng try với trường hợp 4 38

Hình 4.30: Kiểm chứng try với trường hợp 5 38

Hình 4.31: Các trường hợp xem xét với want 39

Hình 4.32: Các trường hợp xem xét với try 40

Hình 4.33: Các trường hợp xem xét với exit 40

Chương 1 GIỚI THIỆU

Kiểm chứng mô hình (model checking) [5, 6, 9] và các kỹ thuật kiểm thử (testing) đang được xem là các giải pháp chủ yếu nhằm đảm bảo chất lượng cho các sản phẩm phần mềm nói chung và các hệ thống đa tác tử nói riêng Các kỹ thuật kiểm thử chỉ có khả năng phát hiện ra lỗi hoặc khiếm khuyết của hệ thống chứ không thể chỉ ra được hệ thống không còn lỗi Do đó, nếu chỉ áp dụng các

kỹ thuật kiểm thử không thôi thì chưa đủ để đảm bảo chất lượng của hệ thống, đặc biệt là đối với những hệ thống yêu cầu độ tin cậy cao Để giải quyết vấn đề này, một trong những phương pháp đang được áp dụng phổ biến là phương pháp kiểm chứng mô hình Hiện nay có nhiều phương pháp hỗ trợ việc đặc tả và kiểm chứng phần mềm theo hướng tiếp cận mô hình như SMV [7], NuSMV [8], v.v Tuy nhiên, phương pháp kiểm chứng mô hình chỉ áp dụng được với các hệ thống có số lượng tác tử là hữu hạn và phải xây dựng được máy hữu hạn trạng thái đặc tả chính xác hành vi của hệ thống Đây là một trong những điểm yếu của phương pháp này, bởi vì trên thực tế, đối với các hệ đa tác tử, số lượng các tác tử là thường xuyên thay đổi trong các giai đoạn phát triển hệ thống, thậm chí

là trong quá trình thực thi hệ thống Mặt khác, vấn đề bùng nổ không gian trạng thái là hoàn toàn có thể xảy ra khi áp dụng phương pháp kiểm chứng mô hình cho hệ thống lớn mà ở đó số lượng các tác tử chưa biết trước Trong trường hợp này, phương pháp chứng minh định lý (theorem proving) là rất phù hợp để chứng minh tính đúng đắn của các hệ đa tác tử

Vấn đề cần giải quyết trong luận văn này là chứng minh tính đúng đắn cho bài toán xung đột tài nguyên cho các hệ đa tác tử sử dụng chung đa tài nguyên Tài liệu [2] đã chứng minh được tính đúng đắn của một số thuộc tính bất biến của hệ thống đa tác tử với chỉ một tài nguyên dùng chung Do đó, khi áp dụng vào hệ thống với đa tài nguyên dùng chung thì về tư tưởng chứng minh là tương tự nhưng về mặt phương pháp đặc tả thì không còn đúng nữa Luận văn này tập trung nghiên cứu một phương pháp đặc tả và kiểm chứng các hệ đa tác

tử sử dụng chung đa tài nguyên và sau đó để cụ thể hóa, luận văn này đã áp dụng vào việc đặc tả và chứng minh tính đúng đắn cho hệ thống đại lý vé máy bay bằng việc sử dụng bộ chứng minh định lý CafeOBJ [3, 4]

Phần còn lại của luận văn này được cấu trúc như sau Chương 2 trình bày tổng quan về ngôn ngữ CafeOBJ, đây là công cụ để hỗ trợ việc đặc tả và kiểm chứng phần mềm theo tư tưởng của chứng minh định lý (theorem proving) Chương 3 trình bày việc đặc tả và kiểm chứng các hệ đa tác tử sử dụng chung đa

tài nguyên Chương này giới thiệu về hệ thống đa tác tử sử dụng chung đa tài nguyên, phương pháp đặc tả và kiểm chứng các hệ đa tác tử sử dụng chung đa tài nguyên Chương 4 trình bày việc đặc tả và chứng minh tính đúng đắn cho hệ thống đại lý vé máy bay Trong chương này trình bày một ví dụ minh họa cho việc đặc tả và kiểm chứng các hệ đa tác tử sử dụng chung đa tài nguyên Một hệ thống quản lý việc đặt vé máy bay của các đại lý vé máy bay là một ví dụ điển hình cho một hệ thống đa tác tử sử dụng chung đa tài nguyên Mô tả bài toán đặt

vé máy bay bằng ngôn ngữ tự nhiên và sau đó là mô tả bài toán này trong hệ chuyển trạng thái quan sát được – OTS (Observational Transition System) Từ

đó, đặc tả và kiểm chứng tính đúng đắn cho hệ thống đại lý vé máy bay bằng bộ chứng minh định lý CafeOBJ Chương 5 là kết luận và định hướng phát triển của đề tài Phần cuối cùng là tài liệu tham khảo và phụ lục

Chương 2 TỔNG QUAN VỀ CafeOBJ 2.1 Giới thiệu

CafeOBJ [3, 4] là một ngôn ngữ đặc tả đại số, có khả năng thực thi dựa trên nhiều cơ sở lôgic khác nhau, phần lớn dựa vào các đại số ban đầu và các đại số được suy diễn Ngôn ngữ này hỗ trợ phương pháp kiểm chứng dựa trên các kỹ thuật đặc tả đại số và phương pháp quy nạp toán học nhằm mục đích kiểm chứng tính đúng đắn của các chương trình với miền trạng thái là vô hạn Ngôn ngữ CafeOBJ bao gồm ba lôgic cơ bản:

Order-sorted logic (lôgic được sắp xếp theo thứ tự): một kiểu có thể là một

kiểu con của kiểu khác Thí dụ, tập hợp các số tự nhiên là tập con của tập hợp các số hữu tỷ, điều này khẳng định tính hợp lệ rằng 3 phải bằng 6/2 Chúng cũng thực hiện việc kế thừa các phép toán, nghĩa là, một phép toán trên tập hợp các hữu tỷ cũng tự động được sử dụng trên tập hợp các số tự nhiên Hơn nữa, mối quan hệ kiểu con ở đây còn cho phép chúng ta có một cách đơn giản hơn để xác định các phép toán cục bộ và việc xử lý các ngoại lệ

Rewriting logic (lôgic biến đổi): thêm vào đó, để bằng nhau các biểu thức phải

hợp lệ về tính đối xứng, chúng ta có thể sử dụng quan hệ bắc cầu, không nhất thiết phải là trực tiếp Điểm mạnh của việc sử dụng quan hệ bắc cầu là rất thuận tiện trong việc thể hiện tính đồng thời hoặc tính bất định

Hidden sorts (các kiểu ẩn): chúng ta có hai loại tương đương, một là tương

đương cực tiểu (là việc đồng nhất hóa hai vế, chúng tương đương khi và chỉ khi chúng giống nhau thông qua các điều kiện và phương trình đã có) Loại tương đương còn lại là được dùng cho kiểu ẩn, hai vế tương đương với nhau khi và chỉ khi chúng phản ứng như nhau với cùng một bộ quan sát

Một tính năng rất hữu ích khác của CafeOBJ là có khả năng truyền tham

số (parameters) Có nhiều kiểu dữ liệu trừu tượng như kiểu dữ liệu danh sách (lists), kiểu dữ liệu tập hợp (sets), kiểu dữ liệu hàng đợi (queues), kiểu dữ liệu ngăn xếp (stacks) , chúng ta có thể định nghĩa mỗi kiểu dữ liệu này bằng một loại mô-đun trong CafeOBJ có khả năng truyền tham số (parameterised modules), mô-đun dạng này có các thành phần cơ bản được truyền qua tham số

từ bên ngoài vào

Việc đặc tả trong CafeOBJ là thông qua các mô-đun Khi khai báo một

mô-đun ta có thể bắt đầu với từ khóa module hoặc mod Trong CafeOBJ có ba

kiểu khai báo mô-đun: mod!, mod* và mod Hiện tại, trong quá trình thực thi ngôn ngữ CafeOBJ không phân biệt ba kiểu khai báo trên, tuy nhiên việc khai báo rõ kiểu của mô-đun là rất cần thiết, nó giúp cho việc hiểu về đặc tả của mô-đun đó một cách đầy đủ, chính xác, đặc biệt là đối với các hệ thống phức tạp

Một mô-đun không có tham số trong CafeOBJ được khai báo với cú pháp được trình bày như trong hình 2.1

module module_name {

module_element *

}

Hình 2.1: Định nghĩa mô-đun trong CafeOBJ

Chi tiết của định nghĩa mô-đun trong hình 2.1 như sau:

Module_name là tên của mô-đun cần định nghĩa, module_element là các

thành phần của mô-đun, thành phần của một mô-đun có thể là các khai báo của

việc kế thừa từ các mô-đun khác (import declaration), hoặc việc khai báo các biến (sort declaration), hoặc việc khai báo các phép toán (operation declaration), hoặc việc khai báo các biến (variable declaration), hoặc việc khai báo các phương trình (equation declaration), hoặc việc khai báo các dịch chuyển (transition declaration)

Chúng ta cùng xem xét hai ví dụ trong hình 2.2: Đặc tả mô-đun NAT và hình 2.3 : đặc tả mô-đun NAT+

Hình 2.2: Đặc tả mô-đun SIMPLE-NAT trong CafeOBJ

Chi tiết của khai báo trong hình 2.2 như sau:

Để khai báo và định nghĩa cho một mô-đun, đầu tiên ta khai báo kiểu của mô-đun sau đó đến tên của mô-đun (dòng 1) Định nghĩa kiểu dữ liệu Nat (dòng

2), định nghĩa hằng số 0 thuộc kiểu dữ liệu Nat ta bắt đầu bằng từ khóa op (dòng

3), định nghĩa phép toán s (phép tăng một số tự nhiên lên 1 đơn vị) ta bắt đầu

bằng từ khóa op (dòng 4)

Hình 2.3: Đặc tả mô-đun NAT+ trong CafeOBJ

Chi tiết của khai báo trong hình 2.3 như sau:

Mô-đun NAT+ kế thừa mô-đun SIMPLE-NAT (dòng 2), khi kế thừa từ

một mô-đun khác, trong CafeOBJ hỗ trợ ba kiểu kế thừa: protecting, extending

và using, có thể viết ngắn gọn hơn là: pr, ex và us Dòng 3 là việc khai báo phép toán cộng, ta bắt đầu với từ khóa op, phép toán này có hai đối số kiểu Nat, kết

quả của phép toán này cũng có kiểu Nat Dòng 4 là việc định nghĩa một phương trình với phép cộng số 0 với một số bất kỳ thuộc kiểu Nat, ta bắt đầu bằng từ

khóa eq, kết quả trả về là chính nó, đặc tả này đã gộp cả việc khai báo biến M

thuộc kiểu Nat, chú ý rằng, sau mỗi phương trình ta phải cách ra một dấu cách

và kèm theo đó là một dấu chấm “.” Dòng 5 là định nghĩa phương trình với vế trái là phép cộng của phép toán s tăng biến N lên một đơn vị với biến M, vế phải

là phép toán s tăng kết quả của phép cộng N và M lên một đơn vị

Như vậy ta đã đặc tả xong hai mô-đun SIMPLE-NAT và NAT+ Bây giờ

ta lưu file đặc tả này với tên example1.mod Để đọc đặc tả các mô-đun ta đã lưu trong file example1.mod, ta chạy chương trình CafeOBJ lên, sau đó chỉ đến

đường dẫn lưu file vừa rồi, tiếp đến ta gõ từ khóa in, cách ra một dấu cách và gõ

example1.mod vào

Chương trình CafeOBJ đọc đặc tả thành công thì sẽ có thông báo như sau: processing input : example1.mod

defining module! SIMPLE-NAT _* done

defining module! NAT+ _ * done

CafeOBJ>

Hình 2.4: Hội thoại giữa CafeOBJ với người dùng

Để việc đặc tả được rõ ràng hơn, CafeOBJ hỗ trợ việc tổ chức các thành phần của một mô-đun vào ba khối chính (blocks) là : khối imports – nơi khai báo các mô-đun mà mô-đun hiện tại tham chiếu đến, khối signature - nơi định nghĩa các kiểu dữ liệu và các phép toán, khối axioms – nơi khai báo các biến

(variables), các phương trình (equations), các dịch chuyển (transitions) Hình 2.5 mô tả chi tiết việc tổ chức các khối của mô-đun NAT+

2.2 Đặc tả và kiểm chứng trong CafeOBJ

Sau khi đã đặc tả hệ thống và các thuộc tính của hệ thống, chúng ta bắt đầu với công đoạn kiểm thử các thuộc tính có thỏa mãn với đặc tả hay không CafeOBJ

hỗ trợ kiểm chứng theo phương pháp quy nạp toán học

2.3 Ví dụ minh họa

Trong ví dụ này trình bày việc chứng minh tính chất kết hợp của phép cộng “+”

các số tự nhiên với mô-đun NAT+ đã được đặc tả trong phần 2.1

Tính chất kết hợp của phép cộng “+” ba số tự nhiên A, B, C được phát biểu như sau:

(A + B) + C = A + (B + C), với A, B, C là các số tự nhiên bất kỳ (*)

Ta đã đặc tả hệ thống các số tự nhiên với đun SIMPLE-NAT và đun NAT+ , tính chất (*) chính là thuộc tính của hệ thống mà ta cần chứng minh Hình 2.6 là các công đoạn chứng minh cho tính chất (*)

mô-open NAT+ + EQL

Khai báo 3 số tự nhiên a, b, c bất kỳ

ops a b c : -> Nat

Bước cơ sở:

red ((0 + b) + c) = (0 + (b + c))

Đặt giả thiết:

eq (a + b) + c = a + (b + c)

Bước quy nạp:

red ((s(a) + b) + c) = (s(a) + (b + c))

close

Hình 2.6: Các công đoạn chứng minh tính chất (*)

Sau khi thực hiện trong chương trình CafeOBJ ta thu được kết quả đều là

true Điều đó chứng tỏ thuộc tính (*) đã được chứng minh

Hệ thống có bao nhiêu tài nguyên thì cần có bấy nhiêu hàng đợi tương ứng, các hàng đợi này sẽ dùng chung cho tất cả các tác tử Mỗi hàng đợi sẽ ứng với một tài nguyên, tác tử nào muốn sử dụng tài nguyên nào thì trước hết nó phải tồn tại trong hàng đợi tương ứng với tài nguyên đó

Với mỗi tác tử i bất kỳ khi tham gia vào hệ thống thì sẽ được hệ thống gán cho nhãn rm, khi tác tử đang ở trong hàng đợi thì chúng có nhãn là wt, khi tác tử đang sử dụng tài nguyên thì chúng có nhãn là cs Việc gán nhãn cho mỗi tác tử như vậy là để hệ thống quản lý được trạng thái của từng tác tử, từ đó ra quyết định xử lý

Ban đầu, với mỗi tác tử i khi tham gia vào hệ thống và chưa có nhu cầu sử dụng tài nguyên thì được hệ thống gán nhãn là rm (tác tử đang ở miền dư) Khi một tác tử nào đó yêu cầu sử dụng tài nguyên thì nhãn mới của nó lúc này là wt

và được hệ thống đẩy vào cuối của hàng đợi tương ứng với tài nguyên mà tác tử muốn sử dụng Nếu tác tử đang ở đỉnh hàng đợi thì nó sẽ được sử dụng tài nguyên tương ứng với hàng đợi đó và nhãn mới của nó lúc này là cs Khi tác tử kết thúc việc sử dụng tài nguyên của mình thì hệ thống sẽ thay nhãn của tác tử từ

cs thành rm (lúc này tác tử trở lại miền dư)

Lưu đồ trong hình 3.1 mô tả quá trình hoạt động của hệ thống cũng như tính chất độc quyền truy xuất của các tác tử đối với mỗi tài nguyên

Hình 3.1: Lưu đồ mô tả quá trình hoạt động của hệ thống cũng như tính chất độc

quyền truy xuất của các tác tử đối với mỗi tài nguyên

Ta có thể thấy được hoạt động của hệ thống thông qua các thao tác của hệ thống trên mỗi hàng đợi tương ứng với mỗi tài nguyên Xét một hàng đợi bất kỳ, khi một tác tử nào đó có nhu cầu sử dụng tài nguyên thì hệ thống sẽ đẩy tác tử này vào hàng đợi tương ứng với tài nguyên mà tác tử này có nhu cầu sử dụng Sau đó, hệ thống sẽ thực hiện vòng lặp để kiểm tra xem tác tử nào đang ở đỉnh của hàng đợi này để cho phép tác tử đó sử dụng tài nguyên Hình 3.2 minh họa cho quá trình này

Hình 3.2: Thao tác của hệ thống đối với mỗi hàng đợi tương ứng với mỗi tài

- Đối với mỗi tác tử: nếu tại một thời điểm, một tài nguyên bất kỳ của hệ thống chưa được sử dụng bởi bất kỳ tác tử nào và đang có ít nhất một tác tử muốn sử dụng tài nguyên đó thì một tác tử trong số

đó phải được sử dụng tài nguyên

- Đối với việc khởi tạo trạng thái ban đầu: mọi hàng đợi trong hệ thống đều rỗng, mọi tác tử đều đang ở miền dư

Chúng ta cùng xem xét một số kịch bản của hệ thống trên một hàng đợi tương ứng với một tài nguyên bất kỳ

Giả sử tại một trạng thái bất kỳ của hệ thống đang tồn tại ba tác tử có định danh lần lượt là 1, 2 và 3 tham gia vào hệ thống, cả ba tác tử này đều muốn sử dụng một tài nguyên có định danh là r8, hàng đợi tương ứng với r8 là q8 và chúng

đang ở miền dư rm Ở trạng thái tiếp theo, khi tác tử 3 có nhu cầu sử dụng tài nguyên (want3) thì hệ thống gán nhãn wt cho tác tử 3, thực hiện đẩy tác tử 3 vào đuôi hàng đợi q8 Ở trạng thái tiếp theo, khi tác tử 2 có nhu cầu sử dụng tài nguyên (want2) thì hệ thống gán nhãn wt cho tác tử 2, thực hiện đẩy tác tử 2 vào đuôi hàng đợi q8 (tác tử 2 nằm sau tác tử 3) Ở trạng thái tiếp theo, khi miền găng cs đang trống (không có tác tử nào đang sử dụng tài nguyên r8), tác tử 3 đang có nhãn là wt và đang ở đỉnh hàng đợi q8, hệ thống thực hiện gán nhãn cs cho tác tử 3 (cho tác tử 3 sử dụng tài nguyên r8, đồng nghĩa với hành động try3thành công) Ở trạng thái tiếp theo, khi tác tử 3 đang có nhãn là cs và kết thúc việc sử dụng tài nguyên (exit3) thì hệ thống sẽ gán nhãn rm cho tác tử 3, đồng thời xóa phần tử ở đỉnh của r8 (tác tử 3), lúc này tác tử 3 quay trở lại miền dư của hệ thống cùng với tác tử 1 ở đó từ trước Các kịch bản ở các trạng thái tiếp theo của hệ thống cũng được giải thích tương tự Hình 3.3a và hình 3.3b mô tả một số kịch bản của hệ thống

Hình 3.3a: Một số kịch bản của hệ thống

nguyên chỉ có duy nhất một tác tử truy xuất Gọi RId là tập các định danh của

các tài nguyên, r là một tài nguyên bất kỳ, r ∈ RId

Gọi AId là tập các định danh của các tác tử, RId là tập các định danh của

các tài nguyên và Sys là không gian trạng thái của hệ thống đa tác tử sử dụng

chung đa tài nguyên, với mỗi tác tử i ∈ AId, mỗi tài nguyên r ∈ RId, ta có tập

hữu hạn các hành động ai1, ai2, , ain của các tác tử được định nghĩa như sau:

aij: Sys × RId × AId → Sys với j = 1, , n

Hình 3.4: Định nghĩa tập hữu hạn các hành động của các tác tử

Với s ∈ Sys và con_aij : Sys × RId × AId → {true, false}, aij(s, r, i) = s’ (s’ ∈ Sys, s’ ≠ s) nếu con_aij(s, r, i) = true, ngược lại, aij(s, r, i) = s Trong trường

hợp s’ = aij(s, r, i) ta nói s’ là trạng thái tiếp theo của s khi tác tử i thực hiện

thành công hành động aij tại trạng thái s

3.2.2 Không gian trạng thái

Không gian trạng thái của hệ thống đa tác tử (ký hiệu không gian trạng thái là

Sys) là tập vô hạn các trạng thái bắt đầu từ trạng thái khởi tạo của hệ thống (ký

hiệu trạng thái khởi tạo là init) Tại mỗi trạng thái s ∈ Sys, trên mỗi tài nguyên r

∈ RId nếu một trong các tác tử i ∈ AId thực hiện thành công hành động aij(s, r, i)

với j = 1, …, n thì hệ thống sẽ chuyển đến một trạng thái tiếp theo s’ (s’ = aij(s, r,

i) , s’ ≠ s) Không gian trạng thái của hệ thống đa tác tử sử dụng chung đa tài

nguyên được định nghĩa đệ quy như sau:

Sys = {init} ∪ {aij(s, r, i) | s ∈ Sys,

r ∈ RId, i ∈ AId, j ∈ [1 n] }

Hình 3.5: Định nghĩa đệ quy không gian trạng thái của hệ thống đa tác tử sử

dụng chung đa tài nguyên

3.2.3 Đặc tả các thuộc tính bất biến

Trước khi triển khai một hệ thống nói chung và hệ đa tác tử nói riêng, có một số

thuộc tính của chúng mà ta cần kiểm chứng tính đúng đắn Nghiên cứu này tập

trung giải quyết thuộc tính bất biến - thuộc tính phổ biến của các hệ thống nói

chung Thuộc tính bất biến là tính chất mà hệ thống phải thỏa mãn tại mọi trạng

thái của hệ thống

Đối với hệ thống này, thuộc tính bất biến được định nghĩa:

inv: Sys × RId × AId × AId → { true, false}

Hình 3.6: Định nghĩa thuộc tính bất biến của hệ đa tác tử sử dụng chung đa tài

nguyên

Để chứng minh một thuộc tính bất biến của hệ thống này luôn luôn thỏa

mãn, ta cần chứng minh được:

∀s ∈ Sys, ∀r ∈ RId, ∀i, j ∈ AId

Chứng minh: inv(s, r, i, j) = true

Hình 3.7: Chứng minh thuộc tính bất biến luôn thỏa mãn

3.3 Kiểm chứng hệ thống đa tác tử sử dụng chung đa tài nguyên

Hiện nay, để chứng minh tính đúng đắn của các hệ đa tác tử thì phương pháp

được áp dụng phổ biến là kiểm chứng mô hình [5, 6, 9] Tuy nhiên, một trong

những hạn chế lớn nhất của kiểm chứng mô hình là vấn đề bùng nổ không gian

trạng thái khi áp dụng cho hệ thống lớn [9] Vì lý do đó mà phương pháp kiểm

chứng mô hình khó áp dụng được trong thực tế Mặt khác, phương pháp kiểm

chứng mô hình chỉ áp dụng được cho các hệ thống có không gian trạng thái hữu

hạn, nhưng các hệ đa tác tử có số lượng tác tử là không được biết trước hoặc vô

hạn thì không gian trạng thái của hệ thống có thể là vô hạn Chính điều này đã

làm cho phương pháp kiểm chứng mô hình đối với các hệ đa tác tử là không thể

áp dụng được

Để chứng minh tính đúng đắn của các hệ đa tác tử sử dụng chung đa tài

nguyên ta có thể áp dụng phương pháp chứng minh theo tư tưởng của quy nạp

toán học Giả sử ta cần chứng minh thuộc tính inv đúng với mọi trạng thái của

hệ thống, đầu tiên ta cần chỉ ra thuộc tính inv đúng ở trường hợp cơ sở, nghĩa là

ta đi kiểm tra thuộc tính inv có thỏa mãn tại trạng thái khởi tạo hay không

(inv(init, r, i, j) = true đúng hay không ?), nếu sai thì ta có thể dừng việc chứng

minh ở đây và kết luận hệ thống không thỏa mãn với thuộc tính inv, nếu đúng

thì ta chuyển sang bước chứng minh quy nạp Ở bước chứng minh quy nạp, việc

đầu tiên ta cần giả sử thuộc tính inv đúng tại một trạng thái s bất kỳ (s ∈ Sys) ,

tức là ta có inv(s, r, i, j) = true Ta cần đi chứng minh thuộc tính inv cũng đúng

tại tất cả các trạng thái tiếp theo của s Các trạng thái tiếp theo của s là các trạng

thái của hệ thống thu được bằng cách một tác tử bất kỳ thực hiện một hành động

của nó ở trạng thái s Nếu thuộc tính inv thỏa mãn tại tất cả các trạng thái tiếp

theo của s thì hệ thống thỏa mãn thuộc tính inv Ngược lại, ta kết luận hệ thống

không thỏa mãn thuộc tính inv Trong quá trình chứng minh tính đúng đắn của

thuộc tính inv, tại mỗi trạng thái tiếp theo của s có nhiều trường hợp kết quả thu

được không phải là true hoặc false mà là một biểu thức logic, trong trường hợp

này, ta cần cung cấp thêm tri thức (các tiên đề hoặc hệ quả) cho hệ thống để rút

gọn biểu thức và có thể chứng minh tính thỏa mãn của thuộc tính này Để tìm

được các hệ quả, ta có thể dựa vào các tính chất của hệ thống liên quan đến

thuộc tính inv, nhiều trường hợp việc tìm kiếm, suy luận gặp khó khăn và mất

nhiều thời gian Trước khi cung cấp các hệ quả tìm được cho hệ thống, chúng

cần được chứng minh tính đúng đắn như các thuộc tính riêng biệt của hệ thống

Quy trình chứng minh tính thỏa mãn của thuộc tính inv bằng phương pháp quy

nạp toán học được mô tả trong hình 3.8

Hình 3.8: Quy trình chứng minh các thuộc tính bất biến của hệ đa tác tử sử dụng

chung đa tài nguyên

Chương 4 ĐẶC TẢ VÀ CHỨNG MINH TÍNH ĐÚNG ĐẮN CHO HỆ THỐNG ĐẠI LÝ VÉ MÁY BAY

Ở chương 3 ta đã đặc tả các hệ đa tác tử sử dụng chung đa tài nguyên và

đề xuất phương pháp chứng minh các thuộc tính bất biến của hệ thống bằng phương pháp quy nạp toán học Trong chương này sẽ trình bày một ví dụ cụ thể

để minh chứng cho việc đặc tả và chứng minh tính đúng đắn của hệ thống đa tác

tử sử dụng chung đa tài nguyên

Hệ thống đại lý vé máy bay là một hệ thống đa tác tử sử dụng chung đa tài nguyên Hệ thống cần quản lý nhiều đại lý vé máy bay (gọi tắt là đại lý) (đa tác tử) đang hoạt động, các đại lý vé máy bay này đặt vé từ nhiều các hãng hàng không khác nhau để có vé của nhiều chuyến bay khác nhau từ các hãng hàng không này Số lượng các đại lý là không biết trước, số lượng này tăng lên hoặc giảm đi tùy vào thị trường Hệ thống cần quản lý nhiều chuyến bay khác nhau (đa tài nguyên) từ nhiều các hãng hàng không khác nhau Tại một thời điểm, đối với một chuyến bay, hệ thống chỉ cho phép một đại lý đặt vé (sử dụng tài nguyên), sau khi xử lý đại lý này xong thì mới đến lượt các đại lý tiếp theo Vấn

đề xung đột sẽ xảy ra nếu các đại lý đồng thời đặt vé trên một chuyến bay (vấn

đề xung đột tài nguyên), bởi vì số vé còn lại của một chuyến bay tại một thời điểm có thể nhỏ hơn tổng số vé mà các đại lý cùng đặt ở chuyến bay này

Ta cần đặc tả các thành phần và thuộc tính của hệ thống, sau đó chứng minh vấn đề xung đột tài nguyên không được phép xảy ra trong hệ thống

4.1 Mô tả bài toán trong hệ chuyển trạng thái quan sát được - OTS

(Observational Transition System)

Ở phần trên, ta đã mô tả hệ thống bằng ngôn ngữ tự nhiên và cũng đã định nghĩa được một số thành phần quan trọng của hệ thống, bằng việc hiểu hệ thống như thế, ở phần này chúng ta sẽ đặc tả hệ thống trong hệ chuyển trạng thái quan sát được - OTS

- Các kiểu dữ liệu

Queue: Kiểu dữ liệu hàng đợi

ATASys: Là kiểu dữ liệu thể hiện không gian trạng thái của hệ thống

Label: Là kiểu dữ liệu thể hiện các nhãn của các đại lý, bao gồm : rm, wt

và cs

AId: Kiểu dữ liệu thể hiện các định danh của các đại lý

FId: Kiểu dữ liệu thể hiện các định danh của các chuyến bay

- Các phương thức trực quan

pc: Phương thức trực quan có giá trị trả về là nhãn của một đại lý tại một

trạng thái của hệ thống

queue: Phương thức trực quan có giá trị trả về là hàng đợi tương ứng với

mỗi chuyến bay ở một trạng thái của hệ thống

- Các phương thức chuyển trạng thái

want: Phương thức chuyển trạng thái được hệ thống thực hiện với nhãn

rm, phương thức này có giá trị trả về là trạng thái tiếp theo của hệ thống,

với ba tham số đầu vào có kiểu dữ liệu lần lượt là: Không gian trạng thái của hệ thống, định danh của chuyến bay, định danh của tác tử

try: Phương thức chuyển trạng thái được hệ thống thực hiện với nhãn wt,

phương thức này có giá trị trả về là trạng thái tiếp theo của hệ thống và ba

tham số đầu vào giống như phương thức want

exit: Phương thức chuyển trạng thái được hệ thống thực hiện với nhãn cs,

phương thức này có giá trị trả về là trạng thái tiếp theo của hệ thống và ba

tham số đầu vào giống như phương thức want

Hình 4.1: Mô hình hệ thống đại lý vé máy bay được mô tả trong hệ chuyển trạng

thái quan sát được – OTS

4.2 Đặc tả hệ thống với CafeOBJ

Xuất phát từ mô hình hệ thống trong hệ chuyển trạng thái quan sát được - OTS,

ta đặc tả hệ thống trong CafeOBJ Gọi mô-đun cần đặc tả hệ thống là ATA (Airline Ticket Agent) với các thành phần: kiểu ẩn *[ATASys]* thể hiện không gian trạng thái của hệ thống, pc là phương thức trực quan trả về nhãn của một đại lý ứng với một chuyến bay tại một trạng thái bất kỳ Các nhãn là: rm, wt, cs Mô-đun ATA kế thừa các mô-đun: LABEL (mô-đun đặc tả cho các nhãn của các đại lý), mô-đun FID (mô-đun đặc tả cho các chuyến bay), Mô-đun QUEUE

(mô-đun đặc tả cho kiểu dữ liệu hàng đợi) (từ dòng 1 đến 3), khai báo kiểu ẩn

ATASys (kiểu không gian trạng thái của hệ thống) (dòng 4), khai báo trạng thái khởi tạo init (dòng 5), khai báo các phương thức trực quan pc và queue (dòng 6

và 7), khai báo các phương thức chuyển trạng thái (từ dòng 7 đến dòng 10) Các mô-đun này sẽ được đặc tả cuối cùng Hình 4.2a là phần đặc tả đầu tiên của mô-

đun ATA, ở phần này cho ta một cái nhìn tổng quan các thành phần và phương thức của mô-đun ATA , ở phần đầu tiên này chưa có định nghĩa cụ thể cho các phương thức trực quan pc, queue và các phương thức chuyển trạng thái want, try, exit

3: pr(QUEUE(AID{sort Elt -> AId,

sort EltErr -> AIdErr,

op none -> none})) 4: *[ATASys]*

Đặc tả trạng thái khởi tạo của hệ thống

5: op init : -> ATASys

Các phương thức trực quan

6: bop pc : ATASys FId AId -> Label

7: bop queue : ATASys FId -> Queue

Các phương thức chuyển trạng thái

8: bop want : ATASys FId AId -> ATASys

9: bop try : ATASys FId AId -> ATASys

10: bop exit : ATASys FId AId -> ATASys

Hình 4.2a: Phần đặc tả đầu tiên của mô-đun ATA

Với mô-đun hệ thống ATA được đặc tả như trên, chúng ta chưa thể sử dụng được để chứng minh tính đúng đắn của hệ thống Việc tiếp theo chúng ta cần khai báo các luật (các tiên đề), đặc tả chi tiết các trạng thái, các phương thức trực quan, các phương thức chuyển trạng thái và các điều kiện chuyển trạng thái của hệ thống

Phương thức pc là một phương thức trực quan, ý nghĩa của nó là xác định

nhãn của một đại lý bất kỳ ứng với một chuyến bay bất kỳ, tại một trạng thái bất

kỳ của hệ thống nên phương thức này có ba tham số đầu vào: S, FI, AI với S thuộc kiểu dữ liệu ATASys (kiểu dữ liệu trạng thái của hệ thống), FI thuộc kiểu

dữ liệu FId (kiểu dữ liệu định danh của các chuyến bay) và AI thuộc kiểu dữ liệu AId (kiểu dữ liệu định danh của các đại lý) Đầu ra của phương thức trực quan

pc là một giá trị thuộc kiểu nhãn của các đại lý (Label) Tại trạng thái khởi tạo (init), nhãn của bất kỳ đại lý nào ứng với bất kỳ chuyến bay nào đều có giá trị là

rm Hình 4.2b là phần đặc tả tiếp theo của mô-đun ATA, ở phần này là đặc tả cho phương thức trực quan pc, xác định nhãn của các đại lý tại trạng thái khởi tạo của hệ thống (init)

11: eq pc(init,FI:FId,AI:AId) = rm

Hình 4.2b: Đặc tả phương thức pc tại trạng thái khởi tạo của hệ thống (init) Phần đặc tả tiếp theo của module ATA chúng ta đi đặc tả chi tiết cho phương thức queue tại trạng thái khởi tạo của hệ thống (init) Tại trạng thái khởi

tạo của hệ thống, mọi hàng đợi tương ứng với mỗi chuyến bay đều rỗng nên ta

có đặc tả như sau:

12: eq queue(init, FI:FId) = empty

Hình 4.2c: Đặc tả chi tiết cho phương thức queue tại trạng thái khởi tạo (init)

Các phương thức chuyển trạng thái want, try và exit của hệ thống sẽ cần

phải sử dụng đến các tham số đầu vào thuộc kiểu dữ liệu không gian trạng thái

trạng thái (ATASys), kiểu dữ liệu đại lý (AId), kiểu dữ liệu hàng đợi (Queue) và kiểu dữ liệu chuyến bay (FId) Do đó, trong phần đặc tả tiếp theo của mô-đun

ATA chúng ta cần khai báo các biến thuộc các kiểu tương ứng trước khi sử dụng

13: var S : ATASys

14: vars AI AJ : AId

15: var QI : Queue

16: var FI : FId

Hình 4.2d: Khai báo các biến S, AI, AJ, QI, FI trước khi sử dụng

Phương thức c-want dùng để kiểm tra xem một đại lý bất kỳ AI có đủ điều kiện để chuyển sang nhãn wt ứng với chuyến bay bất kỳ FI, tại trạng thái S bất

kỳ hay không Nếu nhãn của AI ứng với FI tại tại trạng thái S là rm (tức là đại lý bất kỳ AI chưa có nhu cầu sử dụng chuyến bay bất kỳ FI) thì phương thức c- want trả về giá trị true, ngược lại phương thức c-want trả về giá trị false Do đó, đầu vào của phương thức c-want là ba tham số với kiểu dữ liệu lần lượt là: ATASys, FId, AId Đầu ra của phương thức c-want có kiểu dữ liệu logic, hình 4.2e là phần đặc tả tiếp theo của mô-đun ATA, đặc tả phương thức c-want

17: op c-want : ATASys FId AId -> Bool {strat: (0 1)} 18: eq c-want(S,FI,AI) = (pc(S,FI,AI) = rm)

Hình 4.2e: Đặc tả chi tiết phương thức c-want

Nếu một đại lý bất kỳ AI chưa có nhu cầu sử dụng một chuyến bay bất kỳ

FI thì sau khi thực hiện lệnh want tại trạng thái S ứng với chuyến bay bất kỳ FI thì lúc này nhãn của AJ tại trạng thái mới want(S, FI, AI) là wt nếu như AI = AJ Ngược lại, nhãn của AJ là không thay đổi so với trạng thái trước đó (chỉ có nhãn của AI là thay đổi) (dòng 19)

Nếu phương thức kiểm tra điều kiện c-want của AI ứng với chuyến bay FI tại trạng thái S trả về giá trị False (nghĩa là AI không đủ điều kiện để thực hiện lệnh want ứng với chuyến bay FI tại trạng thái S) thì sau khi thực hiện lệnh want, trạng thái của hệ thống không thay đổi so với trước đó (dòng 20) Hình 4.2f là phần đặc tả tiếp theo của mô-đun ATA, đặc tả chi tiết cho phương thức chuyển trạng thái want

19: ceq pc(want(S,FI,AI),FI,AJ) = (if AI = AJ then

wt else pc(S,FI,AJ) fi) if c-want(S,FI,AI)

20: ceq want(S,FI,AI) = S if not c-want(S,FI,AI)

Hình 4.2f: Đặc tả chi tiết phương thức want

Nếu đại lý bất kỳ AI chưa sử dụng chuyến bay bất kỳ FI thì sau khi thực hiện lệnh want tài trạng thái S, AI được đẩy vào đuôi của hàng đợi tương ứng với chuyến bay FI tại trạng thái S đó Phần đặc tả tiếp theo của mô-đun ATA, đặc

tả chi tiết cho phương thức queue như hình 4.2g

21: ceq queue(want(S,FI,AI),FI) = put(AI,queue(S,FI))

if c-want(S,FI,AI)

Hình 4.2g: Đặc tả chi tiết phương thức queue

Phần đặc tả tiếp theo của mô-đun ATA chúng ta sẽ đặc tả chi tiết cho phương thức try và điều kiện của nó là phương thức c-try như hình 4.2h

Phương thức c-try để kiểm tra xem một đại lý bất kỳ AI có đủ điều kiện để thực hiện lệnh try ứng với chuyến bay bất kỳ FI tại trạng thái S hay không Nếu tại trạng thái S, nhãn của đại lý AI ứng với chuyến bay FI là wt (tức là AI đang

có nhu cầu sử dụng chuyến bay FI) và cộng thêm với điều kiện là AI đang ở đỉnh của hàng đợi ứng với chuyến bay FI thì kết quả trả về của hàm c-try khi kiểm tra điều kiện của đại lý AI ứng với chuyến bay FI tại trạng thái S là true Ngược lại, phương thức c-try trả về giá trị false

22: op c-try : ATASys FId AId -> Bool {strat: (0 1 )} 23: eq c-try(S,FI,AI) = (pc(S,FI,AI) = wt and

top(queue(S,FI)) = AI)

Hình 4.2h: Đặc tả chi tiết phương thức c-try

Đối với phương thức try, nếu phương thức c-try tại trạng thái S, của đại lý bất kỳ AI ứng với chuyến bay bất kỳ FI thỏa mãn (tức là c-try(S, FI, AI) = true) thì sau khi thực hiện lệnh try đại lý AI ứng với chuyến bay FI tại trạng thái S, nhãn của đại lý AJ tại trạng thái mới try(S, FI, AI) là cs nếu như AI = AJ Ngược lại, nhãn của đại lý AJ tại trạng thái try(S, FI, AI) là không thay đổi so với trạng

thái trước đó

Nếu tại trạng thái S, khi thực hiện phương thức kiểm tra c-try của đại lý

AI ứng với chuyến bay FI cho giá trị false thì sau khi thực hiện lệnh try đại lý AI

ứng với chuyến bay FI tại trạng thái S, trạng thái của hệ thống vẫn là S, không

thay đổi

Đối với hàng đợi queue ứng với chuyến bay FI tại trạng thái try(S, FI, AI)

là không thay đổi so với thời điểm nó ở trạng thái S

Phần đặc tả tiếp theo của mô-đun ATA sẽ đặc tả chi tiết cho phương thức try như hình 4.2i

24: ceq pc(try(S,FI,AI),FI,AJ) = (if AI = AJ then cs else pc(S,FI,AJ) fi) if c-try(S,FI,AI)

25: ceq try(S,FI,AI) = S if not c-try(S,FI,AI)

26: eq queue(try(S,FI,AI),FI) = queue(S,FI)

Hình 4.2i: Đặc tả chi tiết phương thức try

Phương thức chuyển trạng thái của hệ thống cuối cùng ta cần đặc tả là

phương thức exit cùng với điều kiện của nó là c-exit Phương thức exit sẽ giải phóng chuyến bay bất kỳ FI khỏi việc sử dụng của đại lý bất kỳ AI tại trạng thái

S, đưa AI trở về với nhãn rm Để có thể thực hiện được phương thức chuyển trạng thái exit thì điều kiện c-exit phải được thỏa mãn, có nghĩa là nhãn của AI đối với chuyến bay FI tại trạng thái S phải là cs

Nếu tại trạng thái S, AI đang sử dụng chuyến bay FI thì sau khi thực hiện lệnh exit đối với đại lý AI ứng với chuyến bay FI thì nhãn của AJ ứng với chuyến bay FI tại trạng thái mới exit(S, FI, AI) là rm nếu AI = AJ Ngược lại, nhãn của AJ là không thay đổi so với trạng thái trước đó

Khi thực hiện lệnh exit thành công, hàng đợi ứng với chuyến bay FI tại trạng thái mới exit(S, FI, AI) sẽ được thay thế bởi hàng đợi ứng với FI tại trạng thái S mà đã loại bỏ phần tử ở đỉnh là AI

Nếu tại trạng thái S, khi thực hiện lệnh exit mà phương thức kiểm tra exit không thỏa mãn thì sau khi thực hiện lệnh exit, trạng thái của hệ thống vẫn

c-là S, không thay đổi Phương thức exit và c-exit được đặc tả chi tiết trong phần đặc tả dưới đây và cũng là phần cuối cùng của mô-đun ATA trong hình 4.2j

27: op c-exit : ATASys FId AId -> Bool{strat:(0 1 2)} 28: eq c-exit(S,FI,AI) = (pc(S,FI,AI) = cs)

29: ceq pc(exit(S,FI,AI),FI,AJ) = (if AI = AJ then rm else pc(S,FI,AJ) fi) if c-exit(S,FI,AI)

30: ceq queue(exit(S,FI,AI),FI) = get(queue(S,FI))

if c-exit(S,FI,AI)

31: ceq exit(S,FI,AI) = S if not c-exit(S,FI,AI) }

Hình 4.2j: Đặc tả chi tiết phương thức exit và c-exit

Như đã trình bày trong phần đầu của phần đặc tả mô-đun ATA, trước khi

kế thừa các đun QUEUE, LABEL, AID, FID, chúng ta cần đặc tả các đun này Mô-đun QUEUE cho phép tạo ra hàng đợi tương ứng với từng chuyến bay, các phép toán trên hàng đợi là: put, get, top Mô-đun LABEL đặc tả nhãn của các đại lý tại các trạng thái khác nhau của hệ thống Mô-đun AID đặc tả định danh cho các đại lý Mô-đun FID đặc tả cho định danh của các chuyến bay

3: op empty : -> Queue {constr}

4: op _,_ : Queue Elt.D -> Queue {constr l-assoc} Các phép toán trên hàng đợi

5: op put : Elt.D Queue -> Queue

6: op get : Queue -> Queue

7: op top : Queue -> EltErr.D

8: op empty? : Queue -> Bool

Các biến trong CafeOBJ

Hình 4.6: Đặc tả mô-đun AID định danh các tác tử

Hình 4.7: Đặc tả mô-đun FID định danh cho chuyến bay

1: mod* AID {

Khai báo 3 kiểu dữ liệu AIdConst là kiểu con của kiểu AId, kiểu AId là kiểu con của kiểu AIdErr

2: [AIdConst < AId < AIdErr]

3: op none : -> AIdErr Khai báo hằng none thuộc kiểu AIdErr

4: pred (_=_) : AIdErr AIdErr {comm}

4.3 Chứng minh tính đúng đắn của hệ thống

Với việc đặc tả hệ thống như trên, ta cần xây dựng mô-đun INV để kiểm chứng tính đúng đắn cho việc sử dụng chung các chuyến bay của hệ thống hay nói cách khác chính là việc chứng minh xung đột không được phép xảy ra trong quá trình thực thi hệ thống

1: mod INV{

2: pr(ATA)

3: pred inv : ATASys FId AId AId

Tương đương với

op inv : ATASys FId AId AId -> Bool

Chi tiết của mô-đun INV như sau:

Mô-đun INV kế thừa mô-đun ATA với kiểu protecting (dòng 2) Định nghĩa thuộc tính bất biến inv như một phép toán với 4 tham số đầu vào, các tham

số này có kiểu dữ liệu lần lượt là: kiểu dữ liệu không gian trạng thái ATASys, kiểu dữ liệu chuyến bay FId, kiểu dữ liệu đại lý AId và kiểu dữ liệu cuối cùng cũng là kiểu dữ liệu AId, đầu ra của inv thuộc kiểu logic Bool (dòng 3).Các bước tiếp theo của mô-đun (từ dòng 4 đến dòng 6) là khai báo bốn biến để làm tham số cho phép toán inv bao gồm: biến S thuộc kiểu dữ liệu không gian trạng thái ATASys, biến AI và AJ thuộc kiểu dữ liệu đại lý AId, biến FI thuộc kiểu dữ liệu chuyến bay FId Bước cuối cùng là khai báo ý nghĩa của thuộc tính bất biến inv (dòng 7), (((pc(S,FI,AI) = cs) and (pc(S,FI,AJ) = cs)) implies AI = AJ) có nghĩa là: (((pc(S,FI,AI) = cs) ˄ (pc(S,FI,AJ) = cs)) => AI = AJ), đây là một biểu thức logic, biểu thức logic này có giá trị chân lý là false ở duy nhất một trường hợp là: pc(S,FI,AI) = cs là true và pc(S,FI,AJ) = cs là true nhưng AI = AJ là false, còn lại tất cả các trường hợp khác thì biểu logic này đều cho giá trị chân lý

là true Cũng có nghĩa là: tại một trạng thái S nào đó, nếu có hai đại lý khác nhau AI, AJ cùng đang sử dụng một chuyến bay là FI thì thuộc tính bất biến inv

sẽ có giá trị false Nếu như ta chứng minh được tại mọi trạng thái S thuộc không

gian trạng thái ATASys, giá trị của thuộc tính bất biến inv luôn luôn là true, nghĩa là không có trường hợp tại một trạng thái S nào đó mà có hai đại lý khác nhau AI, AJ cùng đang sử dụng một chuyến bay FI thì có nghĩa là vấn đề xung đột trong quá trình sử dụng các chuyến bay của các đại lý là không xảy ra

Để áp dụng tư tưởng quy nạp của CafeOBJ trong việc chứng minh tính đúng đắn của các thuộc tính bất biến của hệ thống, ta cần xây dựng thêm mô-đun ISTEP để chứng minh trong trường hợp tổng quát

1: mod ISTEP{

2: pr(INV)

s được hiểu là trạng thái hiện tại

s' được hiểu là trạng thái tiếp theo của s

3: ops s s' : -> ATASys

Bước chứng minh quy nạp

4: pred istep : AId AId

Các biến trong CafeOBJ

Hình 4.10: Chứng minh tính đúng đắn của thuộc tính bất biến inv tại trạng thái

khởi tạo init của hệ thống

Kết quả trả về của inv sau khi thực hiện đoạn lệnh trên là true Chứng tỏ thuộc tính bất biến inv thỏa mãn tại trạng thái khởi tạo init của hệ thống