Kết quả sai được đưa ra bởi Animator

Một phần của tài liệu Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh (Trang 38 - 41)

Hình 3.23. Kết quả sai được đưa ra bởi Animator.

Kết quả ở hình 3.23 cho thấy rằng các increment bị mất là do các biến chia sẽ mà cụ thể ở đây là biến đếm đối tượng chia sẽ không được cập nhật tự động. Do đó cả luồng east và west đều đọc giá trị 0 và viết giá trị 1. Nên khi hành động end xảy ra thì giá trị biến lưu giữ là 1 còn tổng số sự kiện arrive là 2. Vậy hai giá trị này không bằng nhau nên có một lỗi ERROR xảy ra.

Từ phân tích và kết quả thử nghiệm trên ta thấy rằng mặc dù về mặt logic thì đúng nhưng chương trình hoạt động vẫn bị sai và các increment bị mất là do hành động read và write xen kẽ nhau một cách tùy tiện mà không có sự ràng buộc nào cả hay nói cách khác chương trình hoạt động sai chính là do lỗi ngữ nghĩa xảy ra ở khâu thiết kế.

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

Một bản thiết kế đặc biệt là thiết kế của hệ thống tương tranh, dù cẩn thận và chi tiết đến đâu cũng có thế tồn tại thiếu sót, chính vì vậy mô hình hóa thiết kế là một cách để kiểm chứng hiệu quả nhất. Phương pháp mô hình hóa được sử dụng rất rộng rãi trong kỹ thuật nhằm mô tả những đặc trưng của đối tượng đang quan tâm. Chúng ta gọi quá trình này là quá trình đặc tả đối tượng. Khi chúng ta kiểm tra trên mô hình sẽ cho kết quả tương đương với kết quả kiểm tra trên đối tượng thực. Trong thiết kế cũng vậy, mô hình hóa thiết kế sẽ cho phép chúng ta kiểm tra tính đúng đắn của nó trước khi đưa vào cài đặt. Đây là yêu cầu bắt buộc trong quy trình phát triển phần mềm đặc biệt là các phần mềm có yêu cầu chất lượng cao. Chương này trình bày một kỹ thuật đặc tả và kiểm chứng thiết kế của hệ thống tương tranh sử dụng công cụ LTSA.

4.1. Phƣơng pháp đặc tả

4.1.1. Đặc tả thiết kế của chƣơng trình tƣơng tranh

Chương trình tương tranh là chương trình có sự kết hợp của hai hay nhiều tiến trình có chia sẽ tài nguyên dùng chung với nhau và chúng có cùng một số thao tác lên phần dữ liệu dùng chung này tại cùng một thời điểm. Để thực hiện đặc tả chương trình tương tranh, chúng tôi đặc tả mỗi tiến trình của nó dưới dạng một máy hữu hạn trạng thái được gán nhãn (LTS) bằng ngôn ngữ FSP (Ngôn ngữ FSP và các thành phần của nó được miêu tả trong chương 2 – Các kiến thức cơ bản). Khi có được đặc tả của tất cả các tiến trình của chương trình dưới dạng các máy hữu hạn trạng thái được gán nhãn, chúng tôi xây dựng đặc tả của cả chương trình bằng cách ghép nối các đặc tả của các tiến trình bằng phép toán ghép nối song song như định nghĩa ở Chương 2.

4.1.2. Đặc tả thuộc tính cần kiểm chứng

Thực hiện kiểm chứng tức là xem xét chương trình có thỏa mãn thuộc tính cần kiểm chứng hay không. Trong luận văn này, chúng tôi chỉ quan tâm đến các thuộc tính an toàn – một lỗi nào đó không được xảy ra trong quá trình thực hiện của chương trình. Để thực hiện điều này, trước hết chúng ta sẽ mô hình hóa thuộc tính này dưới dạng một máy hữu hạn trạng thái được gán nhãn (tương tự như đặc tả của các tiến trình) bằng ngôn ngữ FSP. Đặc tả này sau đó sẽ được bổ sung thêm một trạng thái lỗi và các hàm chuyển từ tất cả các trạng thái của thuộc tính đến trạng thái này. Các hàm chuyển này mô tả các hành động dẫn đến trạng thái lỗi của hệ thống.

4.2. Kiểm chứng

Kiểm chứng hệ thống tương tranh nói riêng hay đối với việc kiểm chứng của một hệ thống bất kỳ là việc xem xét hệ thống này có thỏa mãn các thuộc tính cần kiểm chứng hay không? Đối với kiểm chứng thiết kế cũng vậy, sau khi chúng ta đã có đặc tả của thiết kế và thuộc tính cần kiểm chứng, bằng phép ghép nối song song chúng ta tích hợp các thành phần này để được thành phần tổng hợp của hệ thống.

Tư tưởng của việc kiểm chứng là duyệt xem có tồn tại ít nhất một dẫn xuất từ trạng thái khởi tạo trong tiến trình tổng hợp này có thể dẫn đến trạng thái lỗi π hay không (về trạng thái lỗi π được định nghĩa ở phần 2.1). Nếu có một dẫn xuất như thế thì chúng ta nói rằng thiết kế của chúng ta vi phạm thuộc tính mà chúng ta cần kiểm chứng. Ngược lại, nếu không có dẫn xuất đến trạng thái lỗi π thì thiết kế của chúng ta thỏa mãn thuộc tính cần kiểm chứng.

Để thực hiện điều này một cách tự động, chúng ta sử dụng công cụ LTSA (Về công cụ LTSA được miêu tả ở chương 2) với đầu vào là LTS của tiến trình cần kiểm chứng để kiểm tra xem thiết kế của chúng ta có vi phạm thuộc tính cần kiểm chứng không. Trong trường hợp thiết kế bị sai chúng ta sẽ tiến hành phân tích kết quả được trả lại bởi LTSA để tìm ra nguyên nhân bị sai để từ đó tiến hành hiệu chỉnh thiết kế và thực hiện kiểm chứng lại.

4.3. Áp dụng phƣơng pháp đặc tả vào bài toán tƣơng

Để minh họa cho phương pháp đặc tả và kiểm chứng, chúng tôi tiến hành đặc tả và kiểm chứng thiết kế của một hệ thống tương tranh Supermarket đã được miêu tả bằng ngôn ngữ FSP như trình bày ở chương 3 và được miêu tả trong hình 3.20.

4.3.1. Đặc tả thiết kế của bài toán chƣơng trình tƣơng tranh

Như chỉ ra trong hình 3.20, thiết kế hệ thống Supermarket có bốn thành phần. Do đó để đặc tả thiết kế này chúng ta sẽ tiến hành đặc tả từng thành phần bằng cách miêu tả từng thành phần này như một tiến trình và mỗi tiến trình được miêu tả dưới dạng một máy hữu hạn trạng thái bằng ngôn ngữ FSP. Quá trình đặc tả được miêu tả như sau:

Hằng số N=4 là phạm vi tham số của tiến trình, tập các hành động gồm có hai hành động value.read và value.write : set VarAlpha = {value.{read[T],write[T]}}

Tiến trình VAR xuất phát từ VAR[0], u là chỉ số của tiến trình và phạm vi của u=[0..4]. Tiến trình VAR được miêu tả dưới dạng ngôn ngữ FSP như hình 4.1.

Hình 4.1. FSP của tiến trình VAR.

LTS tương ứng với tiến trình VAR có các thành phần như sau:

- Tập các trạng thái : Q = {VAR[0] , VAR[1], VAR[2], VAR[3], VAR[4]} = {0, 1, 2, 3, 4}

- Trạng thái ban đầu : Q0 = {VAR[0]} = {0}

- Tập nhãn các hành động L = {read[u:T], write[u:T]}

VAR = VAR[0],

VAR[u:T] = (read[u] -> VAR[u] | write[v:T] -> VAR[v]).

- Tập quy tắc chuyển trạng thái δ như sau:

Với mỗi VAR[u] tương ứng với một trạng thái trong máy hữu hạn trạng thái sẽ có hai lựa chọn cho hành động tiếp theo hoặc là read[u] ->VAR[u] hoặc là

write[v:T]->VAR[v] với v = [0..4]. Do đó với mỗi trạng thái thứ u ta có số phép chuyển trạng thái ở bước tiếp theo là tích Đề các ((read[u] -> VAR[u]) x (write[v:T] -> VAR[v]).

Máy hữu hạn trạng thái LTS đầy đủ của tiến trình VAR được miêu tả như hình 4.2.

Hình 4.2. LTS của tiến trình VAR.

Tiến trình TURNSTILE có nhãn hành động đầu tiên là go, và được định nghĩa thông qua tiến trình cục bộ RUN như hình 4.3.

Một phần của tài liệu Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh (Trang 38 - 41)

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

(55 trang)