intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

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

Chia sẻ: Phạm Huy | Ngày: | Loại File: PDF | Số trang:3

91
lượt xem
9
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Trình bày các kiến thức cơ bản liên quan đến đặc tả và kiểm chứng thiết kế của Hệ thống tương tranh 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 Điều khiển các hành động trong mô hình (LTSA). Nghiên cứu 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, từ đó phát hiện ra các sai sót của hệ thống. Trình bày chi tiết phương pháp đặc tả và kiểm chứng hệ...

Chủ đề:
Lưu

Nội dung Text: Báo cáo "Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh "

  1. Đặc tả và kiểm chứng thiết kế của hệ thống tương tranh Hoàng Phương Thức Trường Đại học Công nghệ Luận văn ThS. ngành: Công nghệ phần mềm; Mã số: 60 48 10 Người hướng dẫn: TS. Phạm Ngọc Hùng Năm bảo vệ: 2011 Abstract. Trình bày các kiến thức cơ bản liên quan đến đặc tả và kiểm chứng thiết kế của Hệ thống tương tranh 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 Điều khiển các hành động trong mô hình (LTSA). Nghiên cứu 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, từ đó phát hiện ra các sai sót của hệ thống. 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, và đưa ra một ví dụ minh họa về hệ thống quan sát số người trong siêu thị để minh họa cho các nghiên cứu của luận văn. Keywords. Công nghệ phần mềm; Kiểm thử phần mềm; Hệ thống tương tranh Content Đả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.
  2. 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 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.
  3. 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 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. References Tiếng Anh 1. C. Blundell, D. Giannakopoulou and C. S. Pasareanu (2005), Assume-guarantee testing, InProceedings of the conference on Specification and verification of component-basedsystems, pp.7-14. 2. G. Gordon Schulmeyer (2008), Handbook of Software Quality Assurance Fourth Edition, Artech House, Inc. 3. J. M. Cobleigh, D. Giannakopoulou and C. S. Pasareanu (2003), Learning assumptions for compositional verification, Proceedings of the 9th international conference on Tools and algorithms for the construction and analysis of systems, Springer-Verlag, pp. 331-346. 4. Keller Robert M. (1976), Formal verification of parallel programs, Communications of the ACM, v.19, pp.371-384. 5. Magee Jeff and Kramer Jeff (2006), Concurrency: State Models & Java Programs, 2nd Edition, John Wiley & Sons, Chapter 1- Chapter 7. 6. Paul C. Jorgensen (2002), Software Testing: A Craftsman’s Approach, Second Edition, CRC Press. 7. SPIN Model Checker, http://spinroot/. 8. Steven R. Rakitin (2001), Software Verification and Validation for Practicetioners and Manager, Second edition, Artech House, Inc. 9. http://www.doc.ic.ac.uk/~jnm/book/ltsa/LTSA_applet.html
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2