Chương 1. Các kiến thức cơ bản. Labeled Transition Systems (LTSs). Khái niệm FSP.
Các thành phần của FSP. Phương pháp biểu diễn LTS. LTS an toàn và thuộc tính an toàn. Công cụ LTSA.
Kỹ thuật phát hiện lỗi chương trình sử dụng LTSA. Mô tả bài toán. Kỹ thuật phát hiện lỗi sử dụng LTSA. Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh sử dụng LTSA.
Phương pháp đặc tả. Đặc tả thiết kế của chương trình tương tranh. Đặc tả thuộc tính cần kiểm chứng. Áp dụng phương pháp đặc tả vào bài toán tương.
Đặc tả thiết kế của bài toán chương trình tương tranh. Đặc tả thuộc tính cần kiểm chứng. Hiệu chỉnh thiết kế và kiểm chứng lại. So sánh công cụ LTSA với SPIN.
41 Tài liệu tham khảo. 42 z iv DANH MỤC CÁC HÌNH VẼ VÀ BẢNG BIỂU Hình 2. LTS của tiến trình VAR. LTS của LOCK.
LTS của tiến trình ERROR_LOCK. Biểu diễn FSP hành trình bay của máy bay. Mô hình hóa hành trình bay của máy bay. Minh họa toán tử lựa chọn (|).
Nhãn a của tiến trình LOCK. Chức năng gán lại nhãn trong CLIENT_SERVER. Máy trạng thái Gate. LTS biểu diễn tiến trình ghép nối song song của LOCK và VAR.
FSP của tiến trình TURNTILE. FSP của tiến trình VAR. FSP của tiến trình LOCK. FSP của tiến trình ERROR_LOCK.
Mô hình hành động của chiếc ô tô. LTSA animator điều khiển các hành động trong mô hình 2. Biểu đồ lớp thiết kế của Supermarket. Phương thức setcolor.
Phương thức setvalue. Lớp Counter và phương thức increment. Phương thức mysuspend. Phương thức activate.
Phương thức passivate. Phương thức run. Phương thức handleEvent. Phương thức init.
Giao diện chương trình Supermarket. Kết quả thử nghiệm chương trình Supermarket. Tiến trình VAR. Hành động INCREMENT.
Tiến trình TURNSTILE. Tiến trình Supermarket. Kết quả test được đưa ra bởi Animator. Tiến trình TEST và tiến trình CHECK.
Kết quả sai được đưa ra bởi Animator. FSP của tiến trình VAR. LTS của tiến trình VAR. Miêu tả tiến trình TURNSTILE qua tiến trình RUN.
Tiến trình RUN. Tiến trình INCREMENT. Tiến trình TURNSTILE. Mô hình LTS của tiến trình TURNSTILE.
LTS của tiến trình thành phần east. LTS của tiến trình thành phần west. LTS của tiến trình thành phần south. LTS của tiến trình {east,west,south,display}::value:VAR.
Tiến trình SUPERMARKET. Tiến trình TEST và tiến trình CHECK. Kết quả kiểm chứng bằng LTSA. Định nghĩa lại tiến trình TURNSTILE.
Định nghĩa lại tiến trình SUPERMARKET. Kết quả phân tích sử dụng LTSA. 55 z vi DANH MỤC CÁC TỪ VIẾT TẮT Viết tắt Tên đầy đủ Ý nghĩa Máy biến đổi trạng thái đươc LTS Labeled Transion System gán nhãn Công cụ phân tích để tìm ra Labeled Transion System LTSA lỗi của hệ thống chuyển tiếp Analyser nhãn Máy hữu hạn trạng thái- một FSP Finite State Processes ngôn ngữ biểu diễn tương ứng với LTS Đảm bảo chất lượng phần SQA Software Quality Assurance mềm Công cụ thực hiện kiểm thử SPIN Simple Promela Interpreter dựa trên mô hình Xác minh và thẩm định phần V&V Verification and Validation mềm z 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 z 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 z 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.