DANH MỤC CÁC TỪ VIẾT TẮT 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ế
Trang 3LỜ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
Trang 4LỜ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
Trang 5MỤ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
Trang 6DANH 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
Trang 7Hì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
Trang 8DANH MỤC CÁC TỪ VIẾT TẮT
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
Trang 9Chươ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
Trang 10thờ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
Trang 11nhữ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
Trang 12Chươ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, δ, q0>, trong đó: Q là một tập hữu hạn các trạng thái không rỗng, M Actlà tập các hành động của thành phần (gọi là bảng chữ cái của M), q0Q 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
α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 (q0) sang trạng thái thứ một (q1), 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 (q2)
- Trạng thái khởi tạo: q0={0}
Trang 13Hì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, δ, q0>, 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 q0 ={0}
Trang 14Hì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, δ, q0>, 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: q0={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, δ, q0>, 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: q0 ={0}
Trang 15cấ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
Trang 16DRINKS = (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
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 (|)
Trang 17Tham 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
Count[i:1 N] = (when(i<N) enter -> Count[i+1]
| when(i>N) out -> Count[i-1])
Trang 18Ví 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
Trang 19Dẫn xuất
Một dẫn xuất [1], [3] t của một LTS M Q,M, , q0 là một chuỗi hữu hạn các hành động a1 a i a n sao cho tồn tại một chuỗi các trạng thái q0, , , ,q i q n thỏa mãn điều kiện (q i1, , )a q i i 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 L M( ).
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)
Trang 20Alphabet 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ả
M Q M q và 2
M Q M q ghép nối song song giữa M 1 và
M 2, ký hiệu M1M2 được định nghĩa như sau Nếu M1 hoặc M2 thì
M PM Ngược lại, M1PM2Q,M,,q0, trong đó:
QQ Q1x 2,M M1M2, 1 2
0 ( ,0 0)
q q q và hàm δ được xác định như sau:
(i) Với mọi (q1, a, q2) ∈ δ1 và (q’1, a, q’2) ∈ δ2 thì ((q1, q’1), a, (q2, q’2)) ∈ δ (ii) Với mọi (q1, a, q2) ∈ δ1, a ∉ Σ2 thì q’ ∈ Q2 ta có ((q1, q’), a, (q2, q’)) ∈ δ (iii) Với mọi (q’1, a, q’2) ∈ δ2, a ∉ Σ1 thì q ∈ Q1 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 = Q1 x Q2 = {Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q9}
= {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
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]}
Trang 21Hình 2.11 LTS biểu diễn tiến trình ghép nối song song của LOCK và VAR
Trang 222.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 {Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7} 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
Q0 = ({read, write}[0] -> Q0 | write[4] -> Q1
| write[3] -> Q2 | write[2] -> Q3 | write[1] -> Q4),
Q1 = (write[0] -> Q0 | {read, write}[4] -> Q1
| write[3] -> Q2 | write[2] -> Q3 | write[1] -> Q4),
Trang 23ERROR_LOCK = Q0, Q0= (release -> ERROR | acquire -> Q1),
Q1= (acquire -> ERROR | release -> Q0)
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 {Q0, Q1, Q2, Q3, Q4} 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 {Q0, Q1} 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 {Q0, Q1, 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 = Q0,
Q0= (acquire -> Q1),
Q1= (release -> Q0)
Trang 24độ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
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)
Trang 25Hì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
Trang 26Chương 3 Kỹ thuật phát hiện lỗi chương trình sử dụng LTSA
Trong các chương trình tương tranh, khi có hai hay nhiều luồng cùng truy cập đồng 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 Chương này trình bày một kỹ thuật để phát hiện lỗi trong các chương trình tương tranh bằng cách
sử dụng công cụ LTSA Bố cục của chương gồm hai phần:
1 Mô tả và xây dựng chương trình giải quyết bài toán tương tranh
2 Kỹ thuật phát hiện lỗi hệ thống tương tranh sử dụng LTSA
3.1 Mô tả bài toán
Có một siêu thị gồm có ba cửa phía tây, cửa phía đông và cửa phía nam, khách hàng
có thể vào siêu thị thông qua một trong ba cửa này, sơ đồ siêu thị được biểu diễn như hình 3.1 Người quản lý muốn biết có bao nhiêu người trong siêu thị tại một thời điểm bất kỳ nào đó
Hình 3.1 Sơ đồ siêu thị
Chúng ta chỉ xét đến trường hợp đơn giản là mọi người chỉ được phép vào mà không được phép ra khỏi siêu thị Chương trình tương tranh để thực hiện tính số người theo yêu cầu bao gồm ba luồng đồng thời và một biến đếm đối tượng chia sẽ Mỗi một luồng điều khiển một cổng và thưc hiện tăng biến đếm đối tượng chia sẽ khi có một người qua cổng vào siêu thị Chương trình tương tranh được xây dựng có bốn lớp bao gồm:
Trang 27(i) Lớp NUMBERCANVAS có dạng của lớp CANVAS trong ngôn ngữ Java, dùng để vẽ một số nguyên lên màn hình
(ii) Lớp COUNTER là lớp quản lý các đối tượng chia sẽ Lớp này sử dụng đối tượng display của lớp Numbercanvas để vẽ và hiển thị giá trị biến đếm đối tượng chia sẽ lên màn hình
(iii) Lớp TURNSTILE có dạng của Thread trong ngôn ngữ Java, lớp này dùng để quản lý hai luồng tương ứng với ba cửa tây và cửa đông Lớp TURNSTILE sử dụng đối tượng display của lớp Numbercanvas để vẽ và hiển thị giá trị số khách hiện thời vào mỗi cổng tương ứng với mỗi luồng
(iv) Lớp SUPERMARKET có dạng của Applet như trong ngôn ngữ Java, lớp này dùng để quản lý cả hệ thống siêu thị Lớp SUPERMARKET sử dụng các đối tượng eastD, westD và counterD của lớp NumberCanvas để vẽ nên giao diện chương trình
Các phương thức và mối quan hệ giữa các lớp được miêu tả trong biểu đồ lớp như hình 3.2
Hình 3.2 Biểu đồ lớp thiết kế của Supermarket
Một số phương thức cơ bản mà luận văn áp dụng được miêu tả như sau:
(i) Lớp NumberCanvas dùng để vẽ một số nguyên lên màn hình, các phương thức của lớp NumberCanvas được miêu tả trong hình 3.3