Phương pháp để kiểm chứng cài đặt

Một phần của tài liệu đặc tả và kiểm chứng các phần mềm tương tranh (Trang 49 - 60)

Từ trước tới nay chúng ta vẫn quen với cách phương pháp kiểm thử quen thuộc như: kiểm thử hộp trắng, kiểm thử hộp đen… Các phương pháp này có thể chỉ ra được chương trình có lỗi hay không. Tuy nhiên chúng không thể chỉ ra được chương trình liệu có còn lỗi hay không. Hệ thống tương tranh có rất nhiều luồng được xử lý cùng một lúc, có những trường hợp xung đột giữa các luồng mà các phương pháp kiểm thử trên không kiểm tra được. Chính vì vậy đòi hỏi phải có một phương pháp kiểm chứng trực quan, một phương pháp hình thức có thể thể hiện được từng hoạt động nhỏ nhất của phần mềm bằng cách đặc tả chi tiết từng câu chữ của mã nguồn, nhờ đó kiểm chứng được phần mềm một cách trọn vẹn.

Khi đã có một thiết kế đúng đắn và chính xác thì việc kiểm chứng phần mềm chỉ cần đối chiếu xem chương trình đó có hoạt động chính xác theo thiết kế hay không. Cách đơn giản nhất là biên dịch chương trình đó thành chính ngôn ngữ mà chúng ta đã thiết kế. Cụ thể là chuyển chương trình thành một bộ quy trình FSP và sử dụng công cụ hỗ trợ phân tích LTSA của nó. Bằng việc kiểm tra xem bộ quy trình đó có thỏa mãn thiết kế hay không? Chúng ta có thể biết được phần mềm có thỏa mãn thiết kế?

Ở chương 3, chúng ta đã nghiên cứu thiết kế bài toán “SingleLandBridge”. Mã nguồn của chương trình được viết bằng Java. Chúng ta sẽ tìm hiểu phương pháp chuyển mã nguồn Java thành FSP và thực hành chuyển mã nguồn bài toán “SingleLandBridge” thành một bộ FSP.

4.2 Cách chuyển từ mã nguồn Java sang FSP

Chúng ta hãy tìm hiểu mối tương quan giữa Java và FSP để có thể chuyển từ mã nguồn Java thành FSP.

Đặc tả và kiểm chứng các phần mềm tương tranh

Bảng 4.3.2a Những toán tử tương đương giữa FSP và Java

Java FSP ++ (cộng 1) .inc -- (trừ 1) .dec = (bằng) = | (hoặc) | ! (not) ! == (so sánh bằng) == > (lớn hơn) > < (nhỏ hơn) < & (và) &

Tuy nhiên trên FSP chỉ thực hiện được trên các phép toán với số nguyên.

Bảng 4.3.2b: Các thành phần cơ bản khi chuyển từ Java sang FSP:

++a a.inc

--a a.dec

a = true a.write[true]

a = false a.write[false]

if(a == 0) … a.read[v:Int] -> if v = 0 then … if(a > 0) … a.read[v:Bool] -> if v > 0 then …

while (!a) … WHILE = (a.read[v:Bool] -> if(!v) then…

Bây giờ, chúng ta sẽ lấy một ví dụ để nghiên cứu cách chuyển từ Java sang FSP: Đây là một hàm trong mã nguồn Java của bài toán “SingleLandBridge” được lấy từ trang web[3] chính thức của cuốn sách Concurrency: State models and Java programes second edition[1]:

synchronized void redExit(){

--nred; if (nred==0) notifyAll(); }

Phương pháp chuyển mã nguồn Java sang FSP là chuyển lần lượt từng câu, chữ trong mã Java thành FSP. Tên hàm Java sẽ được gán nhãn trạng thái bắt đầu trong FSP.

- Các phương thức trong Java sẽ là các trạng thái được gán nhãn tương ứng với tên phương thức trong Java.

- Vòng lặp trong Java cũng là các trạng thái được gán nhãn tương ứng với tên vòng lặp trong Java.

- Các biến trong Java thành các hành động trong FSP. Đây là FSP đặc tả mã nguồn Java trên:

const N = 3 range Int = 0..N

set VarAlpha = {read[Int],dec}

REDEXIT = (acquire -> redExit

-> nred.dec // nred--

-> nred.read[v:Int] // if (nred==0) notifyAll()

-> if (v == 0) then (notifyAll -> CONTINUE) else CONTINUE ),

Đặc tả và kiểm chứng các phần mềm tương tranh

CONTINUE

= (release -> REDEXIT).

4.3 Ứng dụng để chuyển mã nguồn bài toán “SingleLandBridge”

Chúng ta chuyển các hàm trong lớp SafeBridge của lớp SingleLandBridge được lấy từ trang web[3] chính thức của cuốn sách “Concurrency: State Models & Java Programs second edition[1]”, đây là mã nguồn giải quyết bài toán “SingleLandBridge”

Đây là mã nguồn Java của lớp SafeBridge: class SafeBridge extends Bridge {

private int nred = 0; private int nblue = 0;

synchronized void redEnter() throws InterruptedException { while (nblue>0) wait();

++nred; }

synchronized void redExit(){ --nred;

if (nred==0) notifyAll(); }

synchronized void blueEnter() throws InterruptedException { while (nred>0) wait();

++nblue; }

synchronized void blueExit(){ --nblue; if (nblue==0) notifyAll(); } Ví dụ đặc tả phương thức redExit bằng LTS const N = 3 range Int = 0..N

set VarAlpha = {read[Int],dec}

REDEXIT = (acquire -> redExit -> nred.dec

-> nred.read[v:Int]

-> if (v == 0) then (notifyAll -> CONTINUE) else CONTINUE ),

CONTINUE

Đặc tả và kiểm chứng các phần mềm tương tranh

4.5 Kiểm chứng cài đặt

Sau khi đã chuyển xong mã nguồn thành bộ FSP, chúng ta tiến hành kiểm tra bộ FSP này. Các bước kiểm tra giống với cách kiểm tra thiết kế ở chương 3.

Chúng ta tiến hành kiểm chứng mẫu phương thức redExit:

Hình 4.5a: Mở tệp SafeBridge bằng công cụ LTSA

Chúng ta tiến hành kiểm chứng phương thức redExit:

Check safety:

Hình 4.5b: Check safety phương thức redExit

Đặc tả và kiểm chứng các phần mềm tương tranh

Check progress:

Hình 4.5c: Check prgress phương thức redExit

Phương thức không hề có progess nào vi phạm. Như vậy phương thức hoàn toàn không chứa lỗi, bây giờ chúng ta sẽ tiến hành kiểm tra xem phương thức có đúng với thiết kế không.

Compile:

Hình 4.5d: Máy trạng thái REDEXIT

Mô tả ngắn gọn ý nghĩa của mô hình:

- Một xe đỏ rời cầu (redExit) thì số xe đỏ trên cầu sẽ giảm đi một (nred.dec). - Nếu không còn xe đỏ trên cầu (nred.read[0]) thì thông báo cho các xe khác biết (notifyAll).

- Nếu vẫn còn xe đỏ trên cầu (nred.read[1..3]) thì xe sau lại tiếp tục rời cầu.

Ta tiến hành kiểm tra máy trạng thái REDEXIT này với máy trạng thái tương ứng trong thiết kế:

Đặc tả và kiểm chứng các phần mềm tương tranh

Hình 4.5e: Máy trạng thái REDEXIT trong thiết kế.

Qua so sánh hai mô hình ta thấy mô hình trong phương thức redExit hoàn toàn thỏa mãn thiết kế. Đối với các phương thức còn lại ta tiến hành đặc tả và kiểm chứng tương tự như phương thức redExit. Sau khi kiểm chứng toàn bộ các phương thức ta sẽ có một kết quả kiểm chứng đầy đủ về cài đặt của applet này.

4.6 Kết luận

Với việc biên dịch tỷ mỉ mã nguồn Java thành FSP như trên, chúng ta đã kiểm tra được một cách toàn diện chương trình cài đặt. Từng hàm trong Java được kiểm tra một cách trực quan, nhờ đó có thể tìm ra được những lỗi tiềm ẩn rất khó phát hiện cũng như những sai sót so với thiết kế.

Chương 5: Kết luận

Trong khóa luận, em đã tìm hiểu được những khái niệm cơ bản về phương pháp mô hình hóa, 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ách sử dụng công cụ LTSA.

Từ những kiến thức đã thu được, chúng ta có thể thực hiện kiểm chứng một phần mềm tương tranh bằng cách đặc tả thiết kế và mã nguồn của phần mềm bằng FSP rồi sử đụng công cụ LTSA để kiểm chứng. Phương pháp này cho kết quả kiểm chứng cũng như độ an toàn của phần mềm rất cao.

Hiện tại, em mới chỉ ứng dụng để kiếm chứng một applet vì khi chuyển mã nguồn của phần mềm thành FSP thì phải chuyển chính xác từng câu chữ một. Tuy nhiên, với một đội ngũ kiểm thử viên đông đảo và chuyên nghiệp chúng ta hoàn toàn có thể ứng dụng kiểm chứng những phần mềm lớn hơn và có độ phức tạp cao hơn.

Đặc tả và kiểm chứng các phần mềm tương tranh

Tài liệu tham khảo

Tài liệu tiếng Anh

[1] Jeff Magee and Jeff Kramer: Concurrency: State Models & Java Programs second edition, sách điện tử, 2006

[2] Dr. Richard S. Hall, concurrent programing, slide, 2001

Websites:

[3] http://www.doc.ic.ac.uk/~jnm/book/book_applets/concurrency.html

[4] http://www.doc.ic.ac.uk/~jnm/book/ltsa/LTSA_applet.html

Một phần của tài liệu đặc tả và kiểm chứng các phần mềm tương tranh (Trang 49 - 60)

Tải bản đầy đủ (DOC)

(53 trang)
w