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ử

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





NGUYỄN THẾ HUY

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Ử



LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN




Hà Nội - 2014



ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



NGUYỄN THẾ HUY

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Ử


Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103


LUẬN VĂN THẠC SĨ



NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. PHẠM NGỌC HÙNG











Hà Nội – 2014

i

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







ii

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ợ.













iii

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

iv

BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
STT
Ký hiệu

Diễn giải
Tiếng Việt
1
AID
Agent Identification
Định danh tác tử
2
ATA
Airline Ticket Agent
Đại lý vé máy bay
3
FID
Flight Identification
Định danh chuyến bay
4
init
Initial state
Trạng thái khởi tạo
5
INV
Invariant
Bất biến
6
ISTEP
Inductive Step
Bước quy nạp
7
NAT
Natural Number
Số tự nhiên

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
11
TRIVM
Trivial Module
Mô-đun tầm thường

v

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
vi

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
1

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
2

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.















3

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
4

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 SIMPLE-
NAT và hình 2.3 : đặc tả mô-đun NAT+.
1: mod! SIMPLE-NAT {
2: [ Nat ]
3: op 0 : -> Nat { constr }
4: op s : Nat -> Nat { constr }
5: }
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).
5

1: mod! NAT+ {
2: pr(SIMPLE-NAT)
3: op _+_ : Nat Nat -> Nat
4: eq 0 + M:Nat = M .
5: eq s (N:Nat) + M:Nat = s (N + M) .
}
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
6

(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+.
mod! NAT+ {
imports {
pr(SIMPLE-NAT)
}
signature {
op _+_ : Nat Nat -> Nat
}
axioms {
eq 0 + M:Nat = M .
eq s (N:Nat) + M:Nat = s (N + M) .
}
}
Hình 2.5: Tổ chức các thành phần của một mô-đun.
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 mô-đun SIMPLE-NAT và mô-
đ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 (*).
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:
7

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.

8

Chương 3. ĐẶC TẢ HỆ THỐNG ĐA TÁC TỬ SỬ DỤNG
CHUNG ĐA TÀI NGUYÊN
3.1. Giới thiệu bài toán
Một hệ thống có nhiều tài nguyên dùng chung, nơi có nhiều tác tử sử dụng
chung các tài nguyên đó. Tại một trạng thái bất kỳ của hệ thống, có thể có nhiều
tài nguyên khác nhau được sử dụng bởi nhiều tác tử khác nhau, đối với một tài
nguyên xác định thì chỉ có nhiều nhất một tác tử xác định được phép sử dụng tài
nguyên đó. Ta cần đặc tả hệ thống và thuộc tính của hệ thống để đảm bảo tính
đúng đắn cho vấn đề xung đột tài nguyên đối với các tác tử khi sử dụng chung
các tài nguyên đó.
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.


9


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.



10


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.

Theo mô tả đối với hệ thống như trên thì hệ thống cần thỏa mãn các yêu
cầu sau:
- Độc quyền truy xuất đối với mỗi tài nguyên: khi một tác tử có định
danh i bất kỳ đang sử dụng một tài nguyên bất kỳ của hệ thống thì
không một tiến trình có định danh j (j ≠ i) nào khác được sử dụng
tài nguyên mà i đang sử dụng.
- Đố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à r
8
, hàng đợi tương ứng với r
8
là q
8
và chúng
11

đ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 (want
3
) 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 q

8
. Ở trạng thái tiếp theo, khi tác tử 2 có nhu cầu sử dụng tài
nguyên (want
2
) 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 q
8
(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 r
8
), tác tử 3
đang có nhãn là wt và đang ở đỉnh hàng đợi q
8
, 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 r
8
, đồng nghĩa với hành động try
3

thà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 (exit
3
) 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 r
8
(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.
12


Hình 3.3b: Một số kịch bản của hệ thống.
3.2. Phương pháp đặc tả
3.2.1. Đặc tả các tác tử
Hệ thống đa tác tử sử dụng chung đa tài nguyên cho phép đa tác tử thực hiện
việc truy xuất tài nguyên tại một trạng thái bất kỳ của hệ thống. Hệ thống quản
lý mỗi tài nguyên sao cho tại mỗi trạng thái bất kỳ của hệ thống trên mỗi tài
13

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 a
i1
, a
i2
, . . ., a
in
của các tác tử được định nghĩa như sau:
a
ij
: 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_a
ij

: Sys × RId × AId → {true, false}, a
ij
(s, r, i) = s’

(s’ ∈ Sys, s’ ≠ s) nếu con_a
ij
(s, r, i) = true, ngược lại, a
ij
(s, r, i) = s. Trong trường
hợp s’ = a
ij
(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 a
ij
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 a
ij
(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’ = a
ij
(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} ∪ {a
ij
(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:
14

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
15

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.
Bước cơ sở:
{inv(init, r, i, j) = true? | r ∈ RId,

i, j ∈ AId}
Bước quy nạp:
{inv(s, r, i, j) = true | s ∈ Sys, ∀r ∈ RId,
∀i, j ∈ AId } →
{inv(a
kl
(s, r, k), r, i, j) = true | ∀r ∈ RId,
∀i, j, k ∈ AId, ∀l ∈ [1 n] }
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.









16

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.
17

- 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.