Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh

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

===========oOo==========





HOÀNG PHƢƠNG THỨC





ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA
HỆ THỐNG TƢƠNG TRANH





LUẬN VĂN THẠC SĨ

Hà nội - 2011


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



HOÀNG PHƢƠNG THỨC



ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA
HỆ THỐNG TƢƠNG TRANH



Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 604810



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 - 2011
i



LỜI CẢM ƠN
Trước tiên tôi xin bày tỏ lòng biết ơn sâu sắc tới TS. Phạm Ngọc Hùng, giảng viên
Bộ môn Công nghệ phần mềm - Khoa Công nghệ thông tin - Trường Đại học Công
nghệ - ĐHQGHN. Trong thời gian học và làm luận văn tốt nghiệp, thầy đã dành nhiều
thời gian quý báu và tận tình chỉ bảo, hướng dẫn tôi trong việc nghiên cứu, thực hiện
luận văn.
Tôi xin được cảm ơn các GS, TS đã giảng dạy tôi trong quá trình học tập và làm
luận văn. Các thầy cô đã giúp tôi hiểu thấu đáo hơn lĩnh vực mà mình nghiên cứu để
có thể vận dụng những kiến thức đó vào trong công tác của mình.
Trân trọng cảm ơn đề tài mã số CN.10.03 đã trợ giúp tôi trong quá trình thực
hiện luận văn này.
Xin cảm ơn bạn bè, đồng nghiệp và nhất là các thành viên trong gia đình đã tạo
mọi điều kiện tốt nhất, động viên, cổ vũ tôi trong suốt quá trình học tập và nghiên cứu
để hoàn thành tốt bản luận văn tốt nghiệp này.


Hà nội, tháng 6 năm 2011
Học viên thực hiện


Hoàng Phƣơng Thức

ii



LỜI CAM ĐOAN
Tôi xin cam đoan rằng, đây là kết quả nghiên cứu của tôi trong đó có sự giúp đỡ rất
lớn của thầy hướng dẫn và sự nỗ lực của bản thân. Các nội dung nghiên cứu và kết quả
trong đề tài này hoàn toàn trung thực.
Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được
liệt kê tại phần tài liệu tham khảo ở cuối luận văn.

Hà nội, tháng 6 năm 2011
Học viên thực hiện


Hoàng Phƣơng Thức


iii




MỤC LỤC

Chương 1. Giới thiệu 1
Chương 2. Các kiến thức cơ bản 4
2.1. Labeled Transition Systems (LTSs) 4

2.2. FSP (Finite State Process) 7
2.2.1. Khái niệm FSP 7
2.2.2. Các thành phần của FSP 8
2.3. Phương pháp biểu diễn LTS 14
2.4. LTS an toàn và thuộc tính an toàn 15
2.5. Tính thỏa mãn 16
2.6. Công cụ LTSA 16
Chương 3. Kỹ thuật phát hiện lỗi chương trình sử dụng LTSA 28
3.1. Mô tả bài toán 28
3.2. Kỹ thuật phát hiện lỗi sử dụng LTSA 36
Chương 4. Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh sử dụng LTSA 41
4.1. Phương pháp đặc tả 41
4.1.1. Đặc tả thiết kế của chương trình tương tranh 41
4.1.2. Đặc tả thuộc tính cần kiểm chứng 41
4.2. Kiểm chứng 41
4.3. Áp dụng phương pháp đặc tả vào bài toán tương 42
4.3.1. Đặc tả thiết kế của bài toán chương trình tương tranh 42
4.3.2. Đặc tả thuộc tính cần kiểm chứng 51
4.3.3. Kiểm chứng 52
4.3.4. Hiệu chỉnh thiết kế và kiểm chứng lại 53
4.4. So sánh công cụ LTSA với SPIN 55
Chương 5. Kết luận 41
Tài liệu tham khảo 42

iv



DANH MỤC CÁC HÌNH VẼ VÀ BẢNG BIỂU
Hình 2.1. LTS TURNTILE. 5

Hình 2.2. LTS của tiến trình VAR. 6
Hình 2.3. LTS của LOCK. 6
Hình 2.4. LTS của tiến trình ERROR_LOCK. 7
Hình 2.5. Biểu diễn FSP hành trình bay của máy bay. 7
Hình 2.6. Mô hình hóa hành trình bay của máy bay. 7
Hình 2.7. Minh họa toán tử lựa chọn (|). 8
Hình 2.8. Nhãn a của tiến trình LOCK. 9
Hình 2.9. Chức năng gán lại nhãn trong CLIENT_SERVER. 10
Hình 2.10. Máy trạng thái Gate 11
Hình 2.11. LTS biểu diễn tiến trình ghép nối song song của LOCK và VAR. 13
Hình 2.12. FSP của tiến trình TURNTILE. 14
Hình 2.13. FSP của tiến trình VAR. 14
Hình 2.14. FSP của tiến trình LOCK. 15
Hình 2.15. FSP của tiến trình ERROR_LOCK. 15
Hình 2.16. Mô hình hành động của chiếc ô tô 16
Hình 2.17. LTSA animator điều khiển các hành động trong mô hình 2.16. 17
Hình 3.1. Sơ đồ siêu thị. 28
Hình 3.2. Biểu đồ lớp thiết kế của Supermarket. 29
Hình 3.3. Lớp NumberCanvas. 30
Hình 3.4. Phương thức setcolor 30
Hình 3.5. Phương thức setvalue. 30
Hình 3.6. Lớp Counter và phương thức increment. 31
Hình 3.7. Lớp Simulate. 31
Hình 3.8. Lớp Turnstile. 32
Hình 3.9. Phương thức mysuspend. 32
Hình 3.10. Phương thức activate. 33
Hình 3.11. Phương thức passivate. 33
Hình 3.12. Phương thức run. 34
v

Hình 3.13. Phương thức handleEvent. 34
Hình 3.14. Phương thức init. 35
Hình 3.15. Giao diện chương trình Supermarket. 36
Hình 3.16. Kết quả thử nghiệm chương trình Supermarket. 36
Hình 3.17. Tiến trình VAR. 37
Hình 3.18. Hành động INCREMENT. 37
Hình 3.19. Tiến trình TURNSTILE. 37
Hình 3.20. Tiến trình Supermarket 38
Hình 3.21. Kết quả test được đưa ra bởi Animator. 39
Hình 3.22. Tiến trình TEST và tiến trình CHECK. 39
Hình 3.23. Kết quả sai được đưa ra bởi Animator. 40
Hình 4.1. FSP của tiến trình VAR. 42
Hình 4.2. LTS của tiến trình VAR. 43
Hình 4.3. Miêu tả tiến trình TURNSTILE qua tiến trình RUN. 43
Hình 4.4. Tiến trình RUN. 44
Hình 4.5. Tiến trình INCREMENT. 44
Hình 4.6. Tiến trình TURNSTILE. 44
Hình 4.7. Mô hình LTS của tiến trình TURNSTILE. 46
Hình 4.8. LTS của tiến trình thành phần east. 46
Hình 4.9. LTS của tiến trình thành phần west. 47
Hình 4.10. LTS của tiến trình thành phần south. 47
Hình 4.11. LTS của tiến trình {east,west,south,display}::value:VAR. 49
Hình 4.12. Tiến trình SUPERMARKET. 50
Hình 4.13. Tiến trình TEST và tiến trình CHECK. 51
Hình 4.14. Kết quả kiểm chứng bằng LTSA. 53
Hình 4.15. Định nghĩa lại tiến trình TURNSTILE. 54
Hình 4.16. Định nghĩa lại tiến trình SUPERMARKET. 54
Hình 4.17. Kết quả phân tích sử dụng LTSA. 55

vi




DANH MỤC CÁC TỪ VIẾT TẮT

Viết tắt
Tên đầy đủ
Ý nghĩa
LTS
Labeled Transion System
Máy biến đổi trạng thái đươc
gán nhãn
LTSA
Labeled Transion System
Analyser
Công cụ phân tích để tìm ra
lỗi của hệ thống chuyển tiếp
nhãn
FSP
Finite State Processes
Máy hữu hạn trạng thái- một
ngôn ngữ biểu diễn tương ứng
với LTS
SQA
Software Quality Assurance
Đảm bảo chất lượng phần
mềm
SPIN

Simple Promela Interpreter
Công cụ thực hiện kiểm thử
dựa trên mô hình
V&V
Verification and Validation
Xác minh và thẩm định phần
mềm
1


Chƣơng 1. Giới thiệu
Đảm bảo chất lượng phần mềm (Software Quality Assurance - SQA) [2] là một pha
quan trọng trong quá trình phát triển phần mềm. SQA đang là vấn đề nhận được sự
quan tâm của cộng đồng nghiên cứu và hầu hết các công ty phần mềm. Ở mức cao,
việc đảm bảo chất lượng liên quan đến một loạt các vấn đề như chuẩn và quy trình
quản lý của công ty, môi trường và công cụ phát triển, mô hình phát triển phần mềm
được lựa chọn, kỹ năng của nhân viên,… Ở mức trực tiếp hơn, chất lượng phần mềm
được đảm bảo trên cơ sở hiểu đúng yêu cầu của khách hàng, đặc tả đúng yêu cầu, tạo
ra các thiết kế tốt và chuyển nó thành mã nguồn của phần mềm một cách đúng đắn. Do
đó việc đảm bảo chất lượng phần mềm là rất khó khăn và tốn kém. Các công ty phần
mềm lớn luôn có một bộ phận đặc trách về vấn đề đảm bảo chất lượng phần mềm.
Trong quá trình phát triển phần mềm, kiểm thử phần mềm (software testing) [6]
đang được sử dụng như là một giải pháp chủ yếu nhằm đảm bảo chất lượng phần mềm.
Kiểm thử phần mềm là một chiến lược gồm nhiều bước với một loạt phương pháp thiết
kế các ca kiểm thử (test cases) nhằm phát hiện ra lỗi hoặc khiếm khuyết của phần mềm.
Tuy nhiên, kiểm thử chỉ có thể phát hiện ra lỗi hoặc khiếm khuyết của phần mềm chứ
không chỉ ra được phần mềm không còn lỗi. Đối với các hệ thống đòi hỏi tính đúng
đắn cao như hệ thống điều khiển, hệ thống nhúng,… kiểm thử là không đủ để đảm bảo
được chất lượng của các hệ thống này. Hiện nay, rất nhiều khách hàng hoặc chủ đầu tư
đã yêu cầu đơn vị phát triển phải áp dụng các phương pháp kiểm chứng (software

verification) [8] để chứng minh tính đúng đắn của hệ thống trước khi đưa vào triển
khai.
Các phương pháp kiểm chứng hiện tại chỉ tập trung vào việc chứng minh tính
đúng đắn của chương trình/cài đặt nhằm phát hiện các lỗi lập trình so với thiết kế. Để
thực hiện được điều này, chúng ta phải giả sử rằng thiết kế của phần mềm là đúng. Giả
thiết này không thực tế vì các thiết kế, đặc biệt là thiết kế các hệ thống lớn thường có
lỗi. Vì vậy, vấn đề đảm bảo tính đúng đắn của thiết kế trước khi tiến hành cài đặt có ý
nghĩa quan trọng nhằm nâng cao độ tin cậy và chất lượng phần mềm, nó là một nhân
tố không thể thiếu trong việc đảm bảo chất lượng phần mềm. Thật vậy, nếu chúng ta
không đảm bảo được điều này thì khi chương trình có lỗi xảy ra, chúng ta sẽ không
biết được lỗi là do thiết kế hay do cài đặt. Điều này tiêu tốn rất nhiều tài nguyên, công
sức và chi phí để phát hiện ra lỗi của chương trình. Ngược lại, nếu chúng ta đảm bảo
được rằng thiết kế đã đúng trước khi tiến hành cài đặt sẽ giúp cho chúng ta sớm phát
hiện ra lỗi thiết kế. Việc phát hiện sớm các lỗi thiết kế trước khi cài đặt sẽ giảm đáng
kể chi phí trong sản xuất phần mềm. Hơn nữa, một khi thiết kế đã được chứng minh là
đúng thì khi chương trình có lỗi, chúng ta có thể kết luận rằng đấy là lỗi lập trình.
Mục đích của luận văn là nghiên cứu phương pháp đặc tả và kiểm chứng thiết kế
của chương trình tương tranh để chứng minh tính đúng đắn của thiết kế trước khi cài
đặt. Trong các hệ thống tương tranh, khi có hai hay nhiều luồng cùng truy cập đồng
2


thời và tác động lên tài nguyên dùng chung thì rất dễ xảy ra việc các luồng khác nhau
cùng đọc và ghi lên cùng một phần tử dữ liệu của tài nguyên dùng chung – vấn đề
xung đột tài nguyên. Điều này làm cho kết quả của chương trình bị sai và khi xảy ra
lỗi kiểu này chúng ta thường khó phát hiện ra vì đây là lỗi ngữ nghĩa. Để tìm ra những
lỗi này, chúng ta phải tiến hành phân tích theo một trong hai cách hoặc là đi từ mã
nguồn đến thiết kế hoặc ngược lại đi từ thiết kế đến mã nguồn. Như vậy chính việc
đảm bảo tính đúng đắn của thiết kế đặc biệt trong các dự án lớn với một bộ mã nguồn
đồ sộ nó sẽ giúp cho chúng ta giảm bớt được công sức và chi phí, bên cạnh đó điều

này cũng giúp chúng ta tận dụng được các đặc tả hình thức trong việc phát hiện ra các
lỗi khó như lỗi kiểu này và tiến hành kiểm chứng lại thiết kế khi hệ thống bị thay đổi.
Trong luận văn này, hành vi của các tiến trình (ở mức thiết kế) và các thuộc tính cần
kiểm chứng đều được biểu diễn dưới dạng các máy biến đổi trạng thái được gán nhãn
(Labeled Transision System - LTS) [4]. Chúng tôi sử dụng công công cụ có tên là
Labeled Transision System Analyser (LTSA) [9] để kiểm chứng tự động tính thỏa
mãn của thiết kế hệ thống so với thuộc tính cần kiểm tra. Một cách cụ thể, từ đặc tả
thiết kế của hệ thống cần kiểm chứng, chúng ta biểu diễn hệ thống dưới dạng các tiến
trình thành phần và cần đặc tả chúng một cách hình thức bằng các tiến trình hữu hạn
trạng thái (Finite State Processess - FSP) [5]. Các tiến trình này sẽ được LTSA tự động
chuyển sang dạng LTS tương ứng. Thuộc tính cần kiểm chứng của hệ thống cũng được
đặc tả một cách tương tự. Sử dụng toán tử ghép nối song song (ký hiệu “||”) để ghép
nối các thành phần với nhau để thu được mô hình của toàn bộ hệ thống. Công cụ
LTSA sẽ ghép nối mô hình này với thuộc tính cần kiểm chứng để kiểm tra liệu mô
hình có vi phạm thuộc tính cần kiểm chứng không. Để minh họa cho phương pháp này
chúng tôi xét một ví dụ đơn giản đó là bài toán siêu thị. Chúng tôi xem xét bài toán ở
hai trường hợp: có và không kiểm chứng tính đúng đắn của thiết kế trước khi cài đặt
để so sánh tính hiệu qủa của phương pháp kiểm chứng. Trong trường hợp không kiểm
chứng tính đúng đắn của thiết kế, khi chúng ta cài đặt xong chương trình và tiến hành
kiểm thử trên một số ca kiểm thử thì phát hiện ra lỗi. Trong trường hợp này, chúng ta
không biết lỗi này do lập trình hay do thiết kế nên chúng tôi phải bỏ rất nhiều công sức
để tìm ra lỗi này. Để tìm được lỗi, chúng tôi sử dụng chức năng mô phỏng của công cụ
LTSA để phân tích một cách trực quan quá trình hoạt động của hệ thống. Trong trường
hợp áp dụng kiểm chứng tính đúng đắn của thiết kế, chúng tôi phát hiện rằng thiết kế
bị sai và thu được một phản ví dụ. Phản ví dụ này cho biết tại sao thiết kế bị sai.
Chúng tôi phân tích phản ví dụ này để tìm bản chất của lỗi và tiến hành sửa thiết kế.
Quá trình kiểm chứng tính đúng đắn của thiết kế chỉ kết thúc khi thiết kế thỏa mãn
thuộc tính cần kiểm tra.
Bằng cách tiếp cận này khi có lỗi xảy ra chúng ta biết được lỗi là do cài đặt chứ
không phải do thiết kế. Bên cạnh đó trong quá trình phát triển, khi thiết kế thay đổi vì

thường chỉ thay đổi một số phần mà không phải thay đổi toàn bộ so với thiết kế trước
đó. Do đó chúng ta sử dụng lại được các đặc tả thiết kế của những thành phần không
thay đổi mà không phải thực hiện đặc tả lại lần nữa. Điều này thực sự ý nghĩa đối với
3


những hệ thống lớn mà chúng ta đã mất rất nhiều công sức và chi phí để đặc tả và
kiểm chứng. Do vậy chúng ta giảm bớt được công sức và chi phí trong sản xuất phần
mềm và góp phần làm nâng cao chất lượng phần mềm.
Phần còn lại của luận văn được tổ chức như sau:
Chương 2 trình bày các kiến thức cơ bản được sử dụng trong luận văn gồm: Máy
hữu hạn trạng thái, máy dịch chuyển trạng thái có gán nhãn và công cụ hỗ trợ kiểm
chứng LTSA. Đây là những khái niệm cơ bản mà chúng ta sẽ phải trang bị để có thể
thực hiện đặc tả và kiểm chứng thiết kế của một chương trình tương tranh.
Một kỹ thuật phát hiện lỗi của chương trình tương tranh bằng cách sử dụng khả
năng mô phỏng của công cụ LTSA được trình bày trong Chương 3. Bằng phương pháp
này, chúng ta kiểm tra quá trình hoạt động của hệ thống thông qua một chuỗi các hành
động và từ đó phát hiện ra các sai sót của hệ thống.
Chương 4 trình bày chi tiết phương pháp đặc tả và kiểm chứng hệ thống tương
tranh và việc sử dụng công cụ LTSA để hỗ trợ mục đích này. Một ví dụ minh họa về
hệ thống quan sát số người trong siêu thị cũng được trình bày trong chương này để
minh họa cho các bước trên.
Cuối cùng, chúng tôi trình bày kết luận của luận văn, thảo luận các nghiên cứu liên
quan và trình bày các định hướng cho công việc tiếp theo trong chương 5.

4


Chƣơng 2. Các kiến thức cơ bản
Trong chương này chúng ta sẽ tìm hiểu một số khái niệm về máy hữu hạn trạng thái,

máy dịch chuyển trạng thái có gán nhãn và công cụ hỗ trợ kiểm chứng LTSA. Đây là
những khái niệm cơ bản mà chúng ta sẽ phải trang bị để có thể thực hiện đặc tả và
kiểm chứng thiết kế của một chương trình tương tranh mà chúng ta sẽ tìm hiểu ở các
chương sau.
2.1. Labeled Transition Systems (LTSs)
Chúng tôi sử dụng LTSs [4] để đặc tả hành vi của các thành phần và thuộc tính cần
kiểm chứng. Giả sử Act là tập các hành động có thể quan sát được và  là hành động
đại diện cho tất cả các hành động bên trong của hệ thống, một LTS M là một bộ bốn
<Q, αM, δ, q
0
>, trong đó: Q là một tập hữu hạn các trạng thái không rỗng,
M Act


là
tập các hành động của thành phần (gọi là bảng chữ cái của M),
0
qQ
là trạng thái ban
đầu và
 
 
   
    Q M Q
là hàm chuyển trạng thái. Với π là một trạng thái lỗi của
hệ thống, chúng ta ký hiệu LTS
{ }, , ,Act
  
  
.

Ví dụ 2.1: Hình 2.1 mô tả LTS của tiến trình TURNSTILE = <Q, αM, δ, q
0
>, tiến
trình này dùng để miêu tả việc khách hàng vào siêu thị, trong đó:
- Tập trạng thái Q được biểu diễn dưới dạng số để máy tính có thể hiểu được:
Q = {0, 1, 2, 3, 4, 5, 6, 7}
- Tập các hành động:
αM = {go, arrive, end, value.read[x:T], value.write[x+1] với T=[0 4]}
- Tập quy tắc chuyển trạng thái:

δ

= {(0, go, 1), (1, end, 0), (1, arrive, 2), (2, value.read[0], 7),
(7, value.write[1], 1), (2, value.read[1], 6), (6, value.write[2], 1),
(2, value.read[2], 5), (5, value.write[3], 1), (2, value.read[3], 4),
(4, value.write[4], 1), (2, value.read[4], 3), (3, value.write[5], 1)}
Theo quy tắc này, quá trình chuyển trạng thái của TURNSTILE bắt đầu từ
phép chuyển trạng thái theo nhãn go (hành động go này tương ứng với việc
khách hàng đến siêu thị) để chuyển từ trạng thái thứ không (q
0
) sang trạng thái
thứ một (q
1
), tại trạng thái thứ một có hai lựa chọn chuyển trạng thái, nếu lựa
chọn theo nhãn end (nhãn end tương ứng với việc khách hàng đến cổng siêu thị
và quay trở ra) thì trở về trạng thái thứ không, còn nếu chuyển theo nhãn arrive
(nhãn arrive tương ứng với việc khách hàng qua cổng vào bên trong siêu thị)
thì chuyển sang trạng thái thứ hai (q
2
).

- Trạng thái khởi tạo: q
0
={0}
5












Hình 2.1. LTS TURNTILE.
Ví dụ 2.2: Hình 2.2 mô tả LTS của tiến trình VAR = <Q, αM, δ, q
0
>, tiến trành sử
dụng hai hành động read để mô tả việc đọc và hành động write để viết lên tài
nguyên dùng chung, trong đó:
- Tập trạng thái: Q = {0, 1, 2, 3, 4}.
- Tập các hành động: αM = {read[u], write[u], với u=[0 4]}.
- Tập quy tắc chuyển trạng thái:
δ = {(0, read[0], 0), (0, write[0], 0), (0, write[1], 4), (0, write[2], 3),

(0, write[3], 2), (0, write[4], 1), (1, read[4], 1), (1, write[0], 0),
(1, write[1], 4), (1, write[2], 3), (1, write[3], 2), (1, write[4], 1),
(2, read[3], 2), (2, write[0], 0), (2, write[1], 4), (2, write[2], 3),

(2, write[3], 2), (2, write[4], 1), (3, read[2], 3), (3, write[0], 0),
(3, write[1], 4), (3, write[2], 3), (3, write[4], 1), (3, write[4], 1),
(4, read[1], 4), (4, write[0], 0), (4, write[1], 4), (4, write[2], 2),
(4, write[3], 2), (4, write[4], 1)}
- Trạng thái khởi tạo q
0
={0}.
6


Hình 2.2. LTS của tiến trình VAR.
Ví dụ 2.3: Hình 2.3 mô tả LTS của thuộc tính khóa LOCK = <Q, αM, δ, q
0
>, thuộc
tính này nhằm đảm bảo một tiến trình cần phải nhận được khóa trước khi truy cập vào
tài nguyên dùng chung thông qua hành động acquire và thực giải phóng khóa khi tiến
trình kết thúc bằng hành động release, trong đó:
- Tập trạng thái Q được biểu diễn dưới dạng số: Q = {0, 1}
- Tập các hành động : αM = {acquire, release}
- Tập quy tắc chuyển trạng thái: δ = {(0, acquire, 1), (1, release, 0)}
- Trạng thái khởi tạo: q
0
={0}




Hình 2.3. LTS của LOCK.
Ví dụ 2.4: Hình 2.4 mô tả LTS của thuộc tính ERROR_LOCK sau khi bổ sung
thêm trạng thái lỗi π (thuộc tính này có giá trị là -1) vào thuộc tính LOCK (thuộc tính

LOCK được mô tả ở hình 2.3). ERROR_LOCK = <Q, αM, δ, q
0
>, trong đó:
- Tập trạng thái Q được biểu diễn dưới dạng số: Q = {-1, 0, 1}
- Tập các hành động : αM = {acquire, release}
- Tập quy tắc chuyển trạng thái:
δ = {(0, acquire, 1), (1, release, 0), (0, release, 1), (1, acquire, -1)}
- Trạng thái khởi tạo: q
0
={0}

7


cất cánh -> bay -> hạ cánh -> cất cánh -> bay -> hạ cánh -> ……
Maybay = (catcanh -> bay -> hacanh -> Maybay).





Hình 2.4. LTS của tiến trình ERROR_LOCK.
2.2. FSP (Finite State Process)
2.2.1. Khái niệm FSP
Máy hữu hạn trạng thái (FSP) được tạo ra để mô tả các mô hình tiến trình. FSP có thể
mô tả được những hành động, trạng thái của tiến trình.
Ví du 2.5: Ta lấy một ví dụ đơn giản mô tả các hành động cất cánh, bay, hạ cánh của
một chiếc máy bay:
Ta có thể thấy nếu máy bay 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à máy bay không được sử dụng nữa. Chính vì vậy mô tả trên sẽ

không thể nào đầy đủ được. Tuy nhiên ta hoàn toàn có thể giải quyết vấn đề đó nếu mô
tả các hành động đó bằng FSP:
Hình 2.5. Biểu diễn FSP hành trình bay của máy bay.
FSP có tính đệ quy nên ta có thể dễ dàng giải quyết bài toán trên. Ta có mô hình
được phân tích từ mẫu FSP này được chỉ ra như hình 2.6:







Hình 2.6. Mô hình hóa hành trình bay của máy bay.
8


DRINKS = (red->coffee->DRINKS
|blue->tea->DRINKS ).

Maybay = (catcanh -> bay -> hacanh -> Maybay).
Một chương trình tương tranh bao gồm rất nhiều tiến trình, mỗi tiến trình là sự
thực thi của một tiến trình tuần tự. Một tiến trình được chia làm một hoặc nhiều hành
động nguyên tử ( hành động nguyên tử không thể chia được thành các hành động nhỏ
hơn), các hành động này được thực thi một cách tuần tự. Mỗi hành động gây ra một sự
chuyển tiếp từ trạng thái hiện tại sang trạng thái tiếp theo. Trình tự các hành động xảy
ra có thể được xác định bằng một đồ thị chuyển tiếp. Nói cách khác, chúng ta có thể
mô hình hóa các tiến trình thành các máy hữu hạn trạng thái. Như vậy, chúng ta hoàn
toàn có thể mô hình hóa chi tiết một phần mềm tương tranh với đặc tả là FSP.
2.2.2. Các thành phần của FSP
Action prefix ((x -> P)):

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 động x hoạt động đúng theo mô tả của tiến trình P [1].
Tiến trình P phải viết hoa chữ cái đầu, hành động x viêt bằng chữ cái thường.
Ví dụ 2.6: Ta lấy lại ví dụ trên phần 2.2.1:
Trong đó: Maybay là một tiến trình
catcanh, bay, hacanh là các hành động.
Lựa chọn
Nếu x và y là các hành động, khi đó (x->P|y->Q) mô tả một tiến trình có hành động
đầu tiên là một trong hai hành động hoặc x hoặc là y. Sau khi hành động thứ nhất xảy
ra, các hành vi tiếp theo được mô tả bởi P nếu hành động thứ nhất là x, hoặc được mô
tả bởi Q nếu hành động thứ nhất là y.
Ví dụ 2.7: Hình 2.7 minh họa một máy pha chế, nếu nút đỏ được nhấn thì ta được
cà phê, còn nếu nút xanh được nhấn ta được trà.



Hình 2.7. Minh họa toán tử lựa chọn (|).
9


Tham số tiến trình (Process parameters):
Khi tiến trình và hành động có nhiều giá trị thì thay vì đánh chỉ mục thì chúng ta có thể
tạo tham số để mô tả tiến trình bằng FSP được gọn hơn.
Ví dụ 2.8: Ta lấy ví dụ Gate ở trên:



Trong đó i:1 N có nghĩa i có giá trị lần lượt từ 1 đến N.
Hành động đƣợc đảm bảo (Guarded Action):
Hành động này rất hữu dụng để định nghĩa các hành động cụ thể nhưng muốn xảy ra

phải thỏa mãn một điều kiện nào đó.
Ví dụ 2.9: Mô tả đám đông vào thang máy, thang máy cho phép chở 10 người, nếu số
người quá quy định thì phải ra bớt, ngược lại có thể thêm người vào vì còn nhiều
người đang chờ được vào:




Hành động được đảm bảo bởi “when” đảm bảo cho thang máy hoạt động đúng
công suất. Khi số người quá quy định thì phải ra ngoài bớt, khi số người trong thang
chưa tới giới hạn thì có thể tiếp tục vào.
Nhãn tiến trình
Nhãn a của tiến trình P được ký hiệu là a:P, cho biết rằng mọi hành động của tiến trình
P được gán nhãn có tên là a.
Ví dụ 2.10: Hình 2.8 minh họa nhãn a của tiến trình LOCK được miêu tả ở hình
2.3 (ký hiệu là a:LOCK), theo đó các hành động của tiến trình LOCK được gán nhãn
là a.



Hình 2.8. Nhãn a của tiến trình LOCK.
const N = 3
Gate = ( in[i:1 N] -> out[i] -> Gate).
Count(N=10) = Count[1],
Count[i:1 N] = (when(i<N) enter -> Count[i+1]
| when(i>N) out -> Count[i-1]).
10


Gán lại nhãn

Chức năng gán lại nhãn được áp dụng cho các tiến trình để thay đổi tên của các nhãn
hành động. Cấu trúc của phép gán lại nhãn là:
/{newlabel_1/oldlabel_1, newlabel_n/oldlabel_n}.
Việc gán lại nhãn nhằm đảm bảo rằng các tiến trình hỗn hợp đồng bộ trên các
hành động chia sẽ. Chức năng gán lại nhãn có thể được áp dụng cho cả tiến trình gốc
lẫn tiến trình hỗn hợp. Tuy nhiên, nó thường được áp dụng cho các tiến trình hỗn hợp.
Ví dụ 2.11: Một tiến trình SERVER cung cấp một vài service và một tiến trình
CLIENT gọi service được mô tả như sau:
CLIENT = (call->wait->continue->CLIENT).
SERVER = (request->service->reply->SERVER).
Theo mô tả, CLIENT và SERVER có các bảng chữ cái riêng biệt và không ảnh
hưởng lẫn nhau. Tuy nhiên, bằng cách sử dụng gán lại nhãn, chúng ta có thể kết hợp
hành động call của CLIENT với hành động request của SERVER và cũng tương tự có
thể kết hợp hành động wait của CLIENT với hành động reply của SERVER. Sự kết
hợp được định nghĩa như sau:
||CLIENT_SERVER = (CLIENT || SERVER) /{call/request, reply/wait}.
Hiệu quả của việc gán lại nhãn được nhìn thấy trong máy trạng thái được mô tả ở
hình 2.9. Nhãn call thay thế nhãn request trong mô tả của SERVER và nhãn reply
thay thế nhãn wait trong mô tả của CLIENT.

Hình 2.9. Chức năng gán lại nhãn trong CLIENT_SERVER.
11


Dẫn xuất
Một dẫn xuất [1], [3] t của một LTS
0
, , ,M Q M q

 
là một chuỗi hữu hạn các
hành động
1

in
a a a
sao cho tồn tại một chuỗi các trạng thái
0
, , , ,
in
q q q
thỏa mãn
điều kiện
1
( , , )
i i i
q a q




với i=1 n. Giả sử
,Act

ký hiệu t↑Σ, biểu diễn một dẫn
xuất thu được bằng cách loại bỏ khỏi t tất cả các hành động
a
mà
a
. Tập tất cả các
dẫn xuất của M được gọi là ngôn ngữ đoán nhận M, ký hiệu
( ).LM

Ví dụ 2.12: Với LTS TURNTILE được mô tả trong hình 2.1 thì <go>, <go,
arrive> là các dẫn xuất còn <go, go>, <go, arrive, end> không phải là các dẫn xuất của
TURNTILE.
Lập chỉ mục cho các quy trình và hành động (indexed process and actions)
Khi mô hình các tiến trình và hành động có có những trường hợp những tiến trình và
hành động đó có rất nhiều giá trị. Ta có thể gán nhãn cho các quy trình và hành động
đó và lập chỉ mục cho chúng.
Ví dụ 2.13: FSP mô tả hành động vào, ra của 3 chiếc ô tô khi qua 3 cổng của một trạm
soát vé:




Trong đó [1], [2], [3] là chỉ mục của các hành động in và out.
Kết quả khi phân tích bằng công cụ LTSA:

Hình 2.10. Máy trạng thái Gate
Gate = (in[1] -> out[1] -> Gate
| in[2] -> out[2] -> Gate
| in[3] -> out[3] -> Gate).
12


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


Trong ví dụ này thì Alphabet của WRITE là write[0 3].
Ghép nối song song
Ghép nối song song (được ký hiệu là “||”) là phép toán ghép nối hai thành phần phần
mềm bằng cách đội bộ các hành động chung và gối đầu các hành động còn lại [4]. Giả
sử
1
1 1 1 1 0
, , ,M Q M q

 
và
2
2 2 2 2 0
, , , ,M Q M q

 

ghép nối song song giữa M
1
và
M
2
, ký hiệu
12
MM
được định nghĩa như sau. Nếu
1
M 
hoặc
2
M 
thì
12
.MMP
Ngược lại,
1 2 0
, , , ,M M Q M q

  P
trong đó:

12
x,Q Q Q
12
,M M M
  


12
0 0 0
( , )q q q
và hàm δ được xác định như sau:
(i) Với mọi (q
1
, a, q
2
) ∈ δ
1
và (q’
1
, a, q’
2
) ∈ δ
2
thì ((q
1
, q’
1
), a, (q
2
, q’
2
)) ∈ δ.
(ii) Với mọi (q
1
, a, q
2
) ∈ δ

1
, a ∉ Σ
2
thì q’ ∈ Q
2
ta có ((q
1
, q’), a, (q
2
, q’)) ∈ δ.
(iii) Với mọi (q’
1
, a, q’
2
) ∈ δ
2
, a ∉ Σ
1
thì q ∈ Q
1
ta có ((q, q’
1
), a, (q, q’
2
)) ∈ δ.
Ví dụ 2.15: Kết quả ghép nối song song giữa thành phần LOCK và thành phần
VAR tương ứng được miêu tả trong hình 2.2 và 2.3 là một thành phần tổng hợp
LOCKVAR được miêu tả như hình 2.11 có các thành phần được xác định như sau:
- Tập trạng thái:
Q = Q

1
x Q
2
= {Q
0
, Q
1
, Q
2
, Q
3
, Q
4
, Q
5
, Q
6
, Q
7
, Q
8
, Q
9
}
= {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
- Tập các hành động
M
= {acquire, release, read[u], write[u] | với u=[0 4]}
-
Trạng thái khởi tạo

12
0 0 0
( , )q q q

Nhận xét: Kết quả của việc ghép nối song song 2 hệ thống là một hệ thống mới. Trong
đó các dẫn xuất không được kết nối với trạng thái khởi tạo sẽ bị loại bỏ.
WRITER = (write[1]->write[3]->WRITER) +{write[0 3]}.
13




















Hình 2.11. LTS biểu diễn tiến trình ghép nối song song của LOCK và VAR.
14

2.3. Phƣơng pháp biểu diễn LTS
Để chuẩn bị đầu vào cho các công cụ kiểm chứng nơi mà các thành phần được đặc tả
bằng LTS, chúng ta biểu diễn LTS bằng Finite State Processes [5].
Finite State Processes (FSP)
FSP là ngôn ngữ biểu diễn tương ứng với LTS. FSP dùng để xây dựng mô hình các
tiến trình, nó có thể được phân tích và kiểm tra bởi công cụ có tên là LTSA [9].
Ví dụ 2.16: Hình 2.12 biểu diễn FSP của tiến trình TURNTILE. Tiến trình này bao
gồm các trạng thái {Q
0
, Q
1
, Q
2
, Q
3
, Q
4
, Q
5
, Q
6
, Q
7
} và các hành động {go, arrive, end,
value.read[x:T], value.write[x+1] với T=[0 4]}. Tiến trình TURNTILE được biểu diễn
một cách trực trực quan bởi hình 2.1.

Hình 2.12. FSP của tiến trình TURNTILE.












Hình 2.13. FSP của tiến trình VAR.
TURNSTILE = Q
0
,
Q
0
= (go -> Q
1
),
Q
1

= (end -> Q
0
| arrive -> Q
2
),
Q
2
= (value.read[4] -> Q
3
| value.read[3] -> Q
4

|value.read[2] -> Q
5
| value.read[1] -> Q
6
| value.read[0] -> Q
7
),
Q
3
= (value.write[5] -> Q
1
), Q
4
= (value.write[4] -> Q
1
),
Q
5

= (value.write[3] -> Q
1
), Q
6
= (value.write[2] -> Q
1
),
Q
7
= (value.write[1]-> Q
1
).
VAR = Q
0
,
Q
0
= ({read, write}[0] -> Q
0
| write[4] -> Q
1

| write[3] -> Q
2
| write[2] -> Q
3
| write[1] -> Q
4
),
Q

1
= (write[0] -> Q
0
| {read, write}[4] -> Q
1

| write[3] -> Q
2
| write[2] -> Q
3
| write[1] -> Q
4
),
Q
2
= (write[0] -> Q
0
| write[4] -> Q
1
|
{read, write}[3] -> Q
2
| write[2] -> Q
3
| write[1] -> Q
4
),
Q
3
= (write[0] -> Q

0
| write[4] -> Q
1

| write[3] -> Q
2
| {read, write}[2] -> Q
3
| write[1] -> Q
4
),
Q
4
= (write[0] -> Q
0
| write[4] -> Q
1

| write[3] -> Q
2
| write[2] -> Q
3
| {read, write}[1] -> Q
4
).
15


ERROR_LOCK = Q
0

,
Q
0
= (release -> ERROR | acquire -> Q
1
),
Q
1
= (acquire -> ERROR | release -> Q
0
).
Ví dụ 2.17: Hình 2.13 biểu diễn FSP của tiến trình VAR. Tiến trình này bao gồm
các trạng thái {Q
0
, Q
1
, Q
2
, Q
3
, Q
4
} và các hành động {read, write}. Tiến trình VAR
được biểu diễn một cách trực quan bởi hình 2.2.
Ví dụ 2.18: Hình 2.14 biểu diễn FSP của tiến trình LOCK. Tiến trình này bao gồm
các trạng thái {Q
0
, Q
1
}

và các hành động {acquire, release}. Tiến trình LOCK được
biểu diễn trực quan bởi hình 2.3.




Hình 2.14. FSP của tiến trình LOCK.
Ví dụ 2.19: Hình 2.15 biểu diễn FSP của tiến trình ERROR_LOCK. Tiến trình này
bao gồm các trạng thái {Q
0
, Q
1
, ERROR} và các hành động {acquire, release}. Tiến
trình ERROR_LOCK được biểu diễn trực quan bởi hình 2.4.





Hình 2.15. FSP của tiến trình ERROR_LOCK.
Biểu diễn LTS trực quan và dễ hiểu trong khi FSP mang tính tổng quát và khó
hiểu vì nó định nghĩa một cách đệ quy. Tuy nhiên, hai biểu diễn là tương đương nhau.
Tương ứng với mỗi FSP thì có một biểu diễn LTS và ngược lại. Để biểu diễn được hết
các hệ thống LTS/FSP còn có thêm nhiều từ khóa và cấu trúc khác, có thể tham khảo
trong [5].
2.4. LTS an toàn và thuộc tính an toàn
LTS an toàn là một LTS hữu hạn không chứa bất kỳ một trạng thái lỗi π nào. Thuộc
tính an toàn là thuộc tính đảm bảo không lỗi xảy ra trong quá trình thực hiện của hệ
thống. Một thuộc tính an toàn được biểu diễn như là một LTS an toàn p.

Ví dụ 2.20: LTS của LOCK miêu tả ở hình 2.3 là một LTS trạng thái π mà ở đó
chỉ có phép dịch chuyển vào mà không có phép dịch chuyển ra ngoài, hay nói cách
khác LTS của LOCK không có thuộc tính lỗi π nào. Do đó nó là một LTS an toàn.
Ví dụ 2.21: LTS của tiến trình ERROR_LOCK được miêu tả ở hình 2.4 cho thấy
rằng. Nếu hành động release xảy ra trước hành động acquire hoặc nếu hành động xảy
ra sau hành động acquire lần thứ nhất không phải là hành động release mà lại là hành
LOCK = Q
0
,
Q
0
= (acquire -> Q
1
),
Q
1
= (release -> Q
0
).
16


động acquire nữa thì hệ thống chuyển vào trạng thái lỗi. Để LTS này không có lỗi xảy
ra, thì thuộc tính an toàn được chỉ ra đó là hành động acquire phải xảy ra trước và hành
động này phải luôn theo sau bởi một hành động release mà không phải là hành động
khác. Thuộc tính an toàn này được biểu diễn như là một LTS an toàn LOCK như hình
2.3.
2.5. Tính thỏa mãn
Cho một LTS M, ta nói M thoả mãn thuộc tính p, ký hiệu
M p‘

, nếu và chỉ nếu:
 
LM


:
 
()p L p

 
. Để kiểm chứng một thành phần M thoả mãn một thuộc
tính p, khi đó cả M và
err
P
phải được biểu diễn dưới dạng của LTS an toàn (safety
LTS), sau đó thực hiện phép toán ghép nối song song M||P
err
. Nếu LTS thu được sau
phép ghép nối tồn tại một dẫn xuất có thể tới trạng thái π, khi đó ta nói thành phần M
vi phạm thuộc tính p. Ngược lại, M thoả mãn thuộc tính p.
Ví dụ 2.22: Với LTS VAR được miêu tả ở hình 2.2 và thuộc tính LOCK được
miêu tả ở hình 2.3. Bằng phép toán song song, kết hợp tiến trình VAR với LOCK ta
thu được tiến trình tổng hợp:
LOC_VAR = (LOCK || VAR)
Tiến trình này có LTS được miêu tả ở hình 2.12, hình này cho biết không tồn tại
một dẫn xuất có thể tới trạng thái π. Do đó thành phần VAR thỏa mãn thuộc tính
LOCK.
2.6. Công cụ LTSA
LTSA (Labelled Transition System Analyser) là một công cụ hỗ trợ kiểm chứng với
đặc tả là LTS. LTSA sử dụng để kiểm tra tính mong muốn và không mong muốn cho

tất cả các trình tự có thể có của các sự kiện và hành động. Ta lấy ví dụ LTSA phân tích
một đặc tả LTS cho trạng thái vào, ra của một chiếc ô tô khi qua cầu:




Hình 2.16. Mô hình hành động của chiếc ô tô

CAR = (enter -> exit -> CAR).
17













Hình 2.17. LTSA animator điều khiển các hành động trong mô hình 2.16.
Mỗi hành động được chọn trong Animator sẽ điều khiển các hoạt động tương ứng
trong mô hình.