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

1


Số hóa bởi Trung tâm Học liệu

ĐẠ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
2

Số hóa bởi Trung tâm Học liệu

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

3


Số hóa bởi Trung tâm Học liệu


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.


4


Số hóa bởi Trung tâm Học liệu

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
5


Số hóa bởi Trung tâm Học liệu

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


6


Số hóa bởi Trung tâm Học liệu


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

Từ viết tắt
Từ đầy đủ
Diễn giải
FSP
Finite state process

Máy hữu hạn trạng thái
LTSA
Labelled Transition System
Analyser
Công cụ kiểm chứng đặc
tả cho FSP
RODIN
Rigorous Open Development
Environment for Complex
Systems
Công cụ kiểm chứng đặc
tả cho Event-B
UML
Unified Modeling Language
Ngôn ngữ mô hình hóa
thống nhất
OCB
Object-oriented Concurrent-B
Ngôn ngữ đặc tả trung
gian giữa Event-B và
chƣơng trình hƣớng đối
tƣợng, tƣơng tranh



7


Số hóa bởi Trung tâm Học liệu

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




8


Số hóa bởi Trung tâm Học liệu


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




9


Số hóa bởi Trung tâm Học liệu



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
10


Số hóa bởi Trung tâm Học liệu

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 Đọc-Ghi đơn giản và Đọc-
Đọ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++.
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.

11


Số hóa bởi Trung tâm Học liệu

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.

12


Số hóa bởi Trung tâm Học liệu

Bảng 1.1. Mô tả các bƣớc chuyển khoản của tiến trình P
Tiến trình P
Diễn giải
A
X
B
Y

open A;
Mở mục A
10



read A, X;
Đọc dữ liệu từ Avào X

10


X := X-1;
Giảm từ X đi 1

9


write X,A;
Ghi giá trị X từ RAM vào A
9



close A;
Đóng mục A

Open B;
Mở mục B


10

read B,Y;
Đọc dữ liệu từ B vào Y



10
Y := Y+1;
Cộng thêm 1 vào Y



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


11

close B;
Đóng mục B

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
Tiến trình Q
Diễn giải
C
Z
B
V
open C;
Mở mục C
10



read C,Z;
Đọc dữ liệu từ C vào Z

10


Z := Z-1;
Giảm từ Z đi 1

9


write Z,C;
Ghi giá trị Z từ RAM vào C
9

close C;
Đóng mục C




Open B;
Mở mục B


11

read B, V;
Đọc dữ liệu từ B vào V



11
V := V+1;
Cộng thêm 1 vào V



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

12

close B;
Đóng mục B




Kết quả: B=12, C=9

Sau khi thực hiện tuần tự hai tiến trình thì sẽ thu đƣợc kết qủa là:
A = 9, B = 12, C = 9; Kiểm chứng: A + B + C = 30 đúng.
13


Số hóa bởi Trung tâm Học liệu

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
TT
Tiến trình P
Tiến trình Q
A
B
C

X
Y

Z
V



10
10
10





1
open A;









2
read A,X;

10



3
X := X-1;





9



4

open C;








5

read C,Z;

10

6

Z := Z-1;






9

7
write X,A;

9

8
close A;









9

write Z,C;


9





10

close C;

11
open B;









11
read B,Y;






10


12

open B;

12

read B,V;







10
13
Y := Y+1;






11


14

V := V+1;







11
15
write Y,B;


11






16
close B;

17

write V,B;

11






18

close B;









Kết quả: A = 9; C = 9; B = 11. Kiểm chứng: A + B + C = 29
Nhận xét: Kết quả trên là không chính xác.
14


Số hóa bởi Trung tâm Học liệu

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
trình hoạt động nhƣ sau:









Trong đó:
R: là tiến trình chỉ đọc; W: là tiến trình có thể đọc hoặc ghi; FileF là một
đơn vị dữ liệu.
Tại mỗi thời điểm, trên FileF có thể có một hoặc nhiều tiến trình chỉ đọc
(R), nhƣng không có tiến trình nào đƣợc ghi.
Tiến trình ghi (W)chỉ đƣợc thực hiện khi không có tiến trình khác nào
đang đọc hoặc đang ghi ngoài tiến trình hiện tại.
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:
FileF
R

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


Số hóa bởi Trung tâm Học liệu










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
)
OPENED
CLOSED
stop(Q)
16


Số hóa bởi Trung tâm Học liệu

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


Số hóa bởi Trung tâm Học liệu


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.



18

Số hóa bởi Trung tâm Học liệu

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

19


Số hóa bởi Trung tâm Học liệu

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, S
0
, L, R) trong đó:
S là một tập hữu hạn các trạng thái, S
0
S là trạng thái đầu;
R SxS là quan hệ chuyển trạng thái;
L: S  2
AP
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
20


Số hóa bởi Trung tâm Học liệu

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ự
21


Số hóa bởi Trung tâm Học liệu

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.












Trong đó:
<machine_identifier>, <context_identifier > tƣơng ứng là định danh
của máy và ngữ cảnh,
refines, extends là từ khóa làm mịn, mở rộng từ một máy và ngữ cảnh
nào đó,
sees, set là các khai báo tham chiếu đến ngữ cảnh và khai báo các tập
hợp của ngữ cảnh;
variables, constants là các khai báo biến và hằng của máy và ngữ cảnh;
invariant, axiom là các bất biến và tiên đề;
Hình 2.2. Mô hình Event-B với máy và ngữ cảnh.
<context_identifier >
extends
<context_identifier_list >
sets
<set_identifier_list >
constants
<constant_identifier_list >

axioms
<label >:<predicate >
…
theorems
<label >:<predicate >
…
end
(b) Ngữ cảnh
<machine_identifier>
refines
<machine_identifier>
sees
< context_identifier_list >
variables
<variables_identifier_list >
invariants
<label >:<predicate >
…
theorems
< label >:<predicate >
variant
<variant >
events
<events_list >
end
(a) Máy
22


Số hóa bởi Trung tâm Học liệu

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.



23


Số hóa bởi Trung tâm Học liệu

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
nhƣ sau:
<event_identifier>
status
{ordinary, convergent, anticipated}

refines
< event_identifier_list >
any
< parameter_identifier_list >
where
<label >:<predicate >
…
with
< label >:<witness >
…

then
< label >:<action >
…
end


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


Số hóa bởi Trung tâm Học liệu

Đị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
bộ 4 P =(S, A, , q). Trong đó:
S là tập hữu hạn các trạng thái;
, với biểu diễn tập các tiến trình P, L tập các nhãn,
tập các hành động;
∆ SxAxS biểu diễn mỗi quan hệ chuyển trạng thái;
qϵS là trạng thái bắt đầu.
Ví dụ 1: Giả sử chúng ta cần đặc tả các hành động bật, tắt một bóng đèn
điện nhƣ sau:
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.

1
0
on
off
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.

25


Số hóa bởi Trung tâm Học liệu

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
lenlop
giangbai
0
1
2
nghi