Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 81 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
81
Dung lượng
687,16 KB
Nội dung
TÓM TẮT Đề tài nghiên cứu sinh liệu test tự động dựa vào kỹ thuật kiểm chứng mô hình, trình phát triển từ kiểm chứng phần cứng đến kiểm chứng cho mô hình phần mềm Test tự động việc sử dụng phần mềm để kiểm soát việc thực thi test, so sánh kết thực tế để dự đoán kết quả, thiết lập tiền điều kiện test điều khiển test khác hàm báo cáo test Kiểm chứng mô hình (model checking) hướng tiếp cận hiệu cho việc đảm bảo chất lượng phần mềm Kĩ thuật áp dụng để chứng minh cách tự động tính đắn phần mềm phần mềm không chạy thông qua phản ví dụ Hiện có nhiều công cụ kiểm chứng mô hình phần mềm NuSMV, SPIN, KRONOS Khóa luận nghiên cứu lý thuyết vè kiểm chứng mô hình, ngôn ngữ SMV dùng để mô hình hóa hệ thống cách sử dụng NuSMV để kiểm chứng mô hình phần mềm Kiểm chứng mô hình thường áp dụng giai đoạn thiết kế việc mô hình hóa thiết kế hệ thống dễ dàng mô hình hóa mã nguồn hệ thống Ngoài ra, việc sớm tìm lỗi thiết kế giúp giảm thiểu rủi ro trình phát triển phần mềm Vì tập trung tìm hiểu đề xuất quy trình kiểm chứng mô hình sử dụng NuSMV giai đoạn thiết kế phần mềm Qua sinh liệu test cho trường hợp kiểm chứng bị sai Đồng thời áp dụng quy trình để sinh liệu test cho toán thang máy LỜI CẢM ƠN Lời cho em xin chân thành cám ơn tới Ths Nguyễn Hồng Tân, thầy trực tiếp hướng dẫn em tần tình suốt năm học vừa qua Em xin bày tỏ lòng biết ơn tới thầy, cô giáo môn Công nghệ phần mềm nói riêng, toàn trường nói chung Các thầy cô dạy bảo, dẫn chúng em tạo điều kiện tốt cho chúng em học tập, suốt trình học đại học, đặc biệt khoảng thời gian làm đồ án tốt nghiệp Tôi xin chân thành cảm ơn tới bạn sinh viên lớp công nghệ phần mềm – K6B tập thể lớp K6H cho ý kiến đóng góp giá trị lời động viên khích lệ thực đề tài Xin cảm ơn bạn bè gia đình động viên, cổ vũ, đóng góp ý kiến, trao đổi suốt trình học tập, nghiên cứu làm việc giúp em hoàn thành đề tài thời hạn Thái Nguyên, tháng 06 năm 2012 Sinh viên Nguyễn Văn Đoàn LỜI CAM ĐOAN Tôi xin cam đoan: Đồ án tốt nghiệp công trình nghiên cứu thực cá nhân thực sở kiến thức lý thuyết kinh điển hướng dẫn khoa học Thạc sỹ Nguyễn Hồng Tân Các nội dung nghiên cứu kết đồ án trung thực chưa công bố hình thức trước bảo vệ Đồ án có sử dụng số nhận xét đánh số liệu tác giả, điều thể phần tài liệu tham khảo Nếu phát có gian lận xin hoàn toàn chịu trách nhiệm trước Hội đồng bảo vệ, kết đồ án Thái Nguyên, tháng 06 năm 2012 Sinh viên Nguyễn Văn Đoàn DANH MỤC TỪ VIẾT TẮT Ký hiệu AG AF AX ACTL* BDD CTL* CTL F LTL OBB OBBD Thuật ngữ All Globally All Future All Next All Computation Tree Logic Binary Decision Diagram Computation Tree Logic branChing-Time-temporal Logic Future Linear Time Logic Ordered Binary Decision Ordered Binary Decision Diagrams MỤC LỤC DANH MỤC HÌNH VẼ Hình 2.1 Quy trình kiểm thử tự động Hình 2.2 Các toán tử CTL Hình 2.3 OBDD cho công thức (a b)(cd) Hình 2.4 Ví dụ hệ thống điều khiển đèn giao thông Hình 3.1 Biểu đồ ca sử dụng hệ thống thang máy Hình 3.2 Biểu đồ lớp hệ thống thang máy Hình 3.3 Biểu đồ lớp hệ thống thang máy Hình 3.4 Biểu đồ trạng thái Hình 3.5 Biểu đồ trình tự Hình 3.6 Biểu đồ cộng tác Hình 3.7 Biểu đồ lớp chi tiết Hình 3.8 Sơ đồ kiến trúc NuSMV Hình 3.9 Kết biên dịch chương trình Hình 3.10 Kết kiểm chứng chương trình Hình 3.11 Dữ liệu test CHƯƠNG 1: TỔNG QUAN Kiểm chứng mô hình kỹ thuật tự động để xác minh trang thái hữu hạn hệ thống Nó có số lợi ích cách tiếp cận truyền thống để giải vấn đề dựa việc mô phỏng, kiểm thử suy luận Phương pháp sử dụng thành công thực hành xác minh thiết kế mạch phức tạp giao thức truyền thông.Thách thức kiểm chứng mô hình giải vấn đề bùng nổ không gian trạng thái Vấn đề xuất hệ thống có nhiều thành phần mà tương tác với tương tác với hệ thống khác mà cấu trúc liệu nhận nhiều giá trị giả sử khác (ví dụ, đường dẫn mạch) Trong trường hợp số trạng thái mục tiêu lớn Trong khoảng 10 năm qua có tiến đáng kể giải vấn đề Chúng ta mô tả cách làm để kiểm chứng mô hình sử dụng để xác minh thiết kế hệ thống phức tạp Chúng ta lưu vết phát triển thuật toán kiểm chứng mô hình khác hướng tiếp cận thảo luận khác mà mục đích để giải vấn đề bùng nổ không gian trạng thái 1.1 Nhu cầu tự động hóa Ngày nay, hệ thống phần cứng phần mềm sử dụng rộng rãi ứng dụng mà lỗi không chấp nhận thương mại điện tử, chuyển mạch mạng điện thoại, đường cao tốc hệ thống điều khiển đường không, dụng cụ y tế ví dụ khác có nhiều để ghi vào danh sách Chúng ta thường đọc cố mà vài lỗi sinh với lỗi phần cứng phần mềm Một ví dụ gần lỗi tên lửa Ariane phát nổ ngày 4/6/1996 sau chưa đầy 40 giây đưa Uỷ ban điều tra tìm thấy nguyên nhân tai nạn lỗi phần mềm máy tính để tính toán di chuyển tên lửa Trong khởi động, ngoại lệ xuất số thực lớn 64 bit chuyển thành số nguyên 16 bit Sự chuyển đổi không bảo vệ mã nguồn điều khiển ngoại lệ gây lỗi Lỗi tương tự sinh lưu lỗi Kết liệu không xác chuyển đến máy tính gây phá huỷ tên lửa Nhóm điều tra lỗi đề nghị vài phương pháp để giải cố tương lai bao gồm việc xác minh phần mềm Ariane Rõ ràng nhu cầu độ tin cậy phần cứng hệ thống phần mềm quan trọng Sự tham gia hệ thống gia tăng không đảm bảo tính đắn chúng Thật không may, không khả thi để tắt hệ thống bị trục trặc để khôi phục an toàn Chúng ta phụ thuộc nhiều vào hệ thống hoạt động liên tục, thực tế vài trường hợp thiết bị an toàn tắt chúng Thậm chí lỗi không nghiêm trọng, hậu việc thay mã quan trọng mạch thể thiệt hại kinh tế Vì thành công Internet hệ thống nhúng điện thoại di động, máy bay hệ thống an toàn khác, phụ thuộc nhiều vào chức đắn cac thiết bị máy tính tương lai Thực tế, tốc độ thay đổi tăng tốc vài năm tới Bởi tốc độ phát triển nhanh chóng công nghệ, trở nên không quan trọng để phát triển phương pháp làm tăng tự tin xác hệ thống 1.2 Tiến trình kiểm chứng phần mềm Áp dụng kiểm chứng mô hình để thiết kế mô hình bao gồm số nhiệm vụ: Mô hình hóa Nhiệm vụ chuyển từ thiết kế thành dạng mà công cụ kiểm chứng mô hình chấp nhận Trong nhiều trường hợp, điều đơn giản nhiệm vụ biên dịch Trong trường hợp khác, hạn chế thời gian nhớ, mô hình hóa thiết kế yêu cầu sử dụng trừu tượng hóa để loại bỏ chi tiết không liên quan không quan trọng Đặc tả Trước xác minh, cần phải xác định trạng thái đặc tả mà thiết kế phải đáp ứng Đặc tả thường đưa số hình thức logic Đối với hệ thống phần cứng phần mềm, người ta thường sử dụng logic thời gian khẳng định hành vi hệ thống tiến hóa theo thời gian Một vấn đề quan trọng đặc tả hoàn chỉnh Kiểm chứng mô hình yêu cầu phương tiện kiểm tra thiết kế mô hình có đáp ứng đặc tả không, thể xác định đặc tả bao gồm tất tính hệ thống phải đáp ứng Xác minh Sự xác minh lý tưởng hoàn toàn tự động Tuy nhiên, thực tế thường liên quan đến người Một hoạt động phân tích kết xác minh Trong trường hợp kết phủ định, người sử dụng thường đưa vết lỗi Điều sử dụng counterEXample tính kiểm tra giúp nhà thiết kế theo dõi xuất lỗi Trong trường hợp này, phân tích lỗi yêu cầu chỉnh sửa hệ thống áp dụng lại thuật toán kiểm chứng mô hình Một vết lỗi kết mô hình hệ thống không xác đặc tả không Một vết lỗi hữu ích xác định sửa hai vấn đề Khả cuối nhiệm vụ xác minh dừng lại không bình thường, kích thước mô hình lớn không phù hợp với nhớ máy tính Trong trường hợp này, cần xác minh lại sau thay đổi số tham số mô hình kiếm tra hay điều chỉnh mô hình 1.3 Trình tự logic kiểm chứng mô hình Các đặc tả diễn tả theo trình tự thời gian, hệ thống tương tác mô hình hóa đồ thị chuyển trạng thái Một thủ tục tìm kiếm hiệu sử dụng để xác định có hay không đồ thị chuyển trạng thái đáp ứng những đặc tả Kỹ thuật phát triển năm 1981 Clarke Allen Emerson Quyelle Sifakis độc lập phát kỹ thuật xác minh tương tự sau Một hướng tiếp cận khác dựa vào việc hiển thị nội dung Otomat phát minh Robert Kurshan phòng thí nghiệm ATT Bell Kỹ thuật có vài lợi ích quan trọng công cụ thử định lý học kiểm tra chứng để xác minh mạch giao thức Quan trọng thủ tục tự động hóa cao Thông thường, người sử dụng cung cấp mức biểu diễn mô hình đặc tả kiểm tra cao Bộ kiểm chứng mô hình kết thúc với câu trả lời true, mô hình đáp ứng đặc tả đưa đếm mẫu thực thi hiển thị mà công thức không đáp ứng Bộ đếm mẫu đặc biệt quan trọng tìm kiếm lỗi nhỏ hệ thống tương tác phức tạp Bộ kiểm chứng mô hình tìm thấy lỗi nhỏ mạch giao thức nhỏ Tuy nhiên, chúng xử lý vấn đề lớn vấn đề bùng nổ không gian trạng thái Khả hệ thống xác minh với độ phức tạp thực tế thay đổi cuối năm 1980 với khám phá cách biểu diễn mối quan hệ chuyển tiếp sử dụng biểu đồ định Nhị phân trình tự (ordered binary decision diAGrams - OBDD) Sự khám phá phụ thuộc đội nghiên cứu sở đơn giản Giả sử hành vi hệ thống tương tác xác định n biến trạng thái logic v ,v ,…., v n Sau mối quan hệ chuyển tiếp hệ thống biểu diễn biểu thức logic sau: R(v1,v2,…., , v’1,v'2, , v'n) Với v ,v , … , v n biểu diễn trạng thái tại, v'1,v'2, ,v'n biểu diễn trạng thái Bằng cách biến đổi công thức tới sơ đồ chuyển tiếp Nhị phân, đại diện ngắn gọn mối quan hệ chuyển tiếp chứa Thuật toán kiếm chứng mô hình nguyên thủy, với cách biểu diễn quan hệ chuyển tiếp gọi kiểm chứng mô hình tượng trưng Bằng cách sử dụng kết hợp này, thực xác minh hệ thống tương tác lớn Thực tế, vài ví dụ có 10 120 trạng thái xác minh Đây điều số lượng nút biểu đồ định Nhị phân phải xây dựng không phụ thuộc vào số lượng trạng thái thực tế kích thước quan hệ chuyển tiếp Bởi bước đột phá cách làm xác minh hệ thống tương tác với độ phức tạp thực tế, số công ty bao gồm Intel, Motorola, Fujitsu ATT bắt đầu sử dụng kiểm chứng mô hình tượng trưng để xác minh mạch giao thức thực Trong vài trường hợp lỗi tìm thấy bỏ qua mô mở rộng Trong biểu tượng biểu diễn làm tăng thêm đáng kể kích thước hệ thống mà xác minh được, nhiều hệ thống thực tế lớn để xử lý Do đó, quan trọng tìm kỹ thuật sử dụng kết hợp phương pháp tượng trưng để mở rộng kích cỡ hệ thống mà xác minh Kỹ thuật khai thác cầu trúc mạch giao thức phức tạp Nhiều hệ thống trạng thái hữu hạn gồm nhiều tiến trình chạy song song Các đặc tả hệ thống cho thường chia thành tính mà mô tả hành vi phần nhỏ hệ thống Một chiến lược rõ ràng để kiểm tra tính cục sử dụng phần hệ thống mà mô tả Nếu cho thấy hệ thống đáp ứng tính cục bộ, kết hợp tính cục đặc tả tổng thể sau hệ thống hoàn chỉnh phải đáp ứng tốt đặc tả Ví dụ, xem xét vấn đề xác minh giao thức truyền thông mô hình hóa ba tiến trình trạng thái hữu hạn: máy phát, vài kiểu mạng máy thu Giả sử đặc tả cho hệ thống liệu truyền cách xác từ máy phát đến máy thu Một đặc tả phải tách thành ba tính băng cục Đầu tiên, liệu truyền cách xác từ máy phát tới mạng Thứ hai, liệu truyền xác từ thiết bị cuối mạng đến thiết bị mạng khác Cuối cùng, máy liệu truyền xác từ mạng tới máy thu Chúng ta xác minh điều ba tính cục sử dụng máy phát mạng, thứ hai sử dụng mạng thứ ba sử dụng mạng máy thu Bằng cách tách xác minh theo cách này, không gồm tất tiến trình tranh tượng bùng nổ không gian trạng thái Kỹ thuật liên quan đến việc sử dụng trừu tượng hóa Kỹ thuật xuất chủ yếu để lý luận hệ thống tương tác gồm đường dẫn liệu Theo truyền thống, trạng thái hữu hạn xác minh phương thức sử dụng hệ thống hướng điều khiển Những phương pháp tượng trưng xử lý vài hệ thống liên quan đến thao tác liệu không tầm thường, phức tạp xác minh thường cao Hướng tiếp cận dựa quan sát đặc tả hệ thống bao gồm đường dẫn liệu thường bao gồm quan hệ đơn giản giá trị liệu hệ thống Ví dụ, xác minh toán tử cộng vi xử lý, yêu cầu giá trị thực tổng giá trị khác Trong tình cho, trừu tượng hóa sử dụng để giảm độ phức tạp kiểm chứng mô hình Sự trừu tượng hóa thường đặc tả cách ánh xạ giá trị liệu thực tế hệ thống tập nhỏ giá trị liệu trừu tượng Bằng cách mở rộng ánh xạ trạng thái chuyển tiếp, đưa phiên trừu tượng hóa hệ thống xem xét Hệ thống trừu tượng thường nhỏ hệ thống thực, kết thường đơn giản để xác minh tính mức trừu tượng CHƯƠNG 2: PHÁT SINH DỮ LIỆU TEST TỰ ĐỘNG & KIỂM CHỨNG MÔ HÌNH 2.1 Phát sinh liệu test tự động 2.1.1 Khái niệm kiểm thử tự động Test tự động việc sử dụng phần mềm để kiểm soát việc thực thi test, so sánh kết thực tế để dự đoán kết quả, thiết lập tiền điều kiện test điều khiển test khác hàm báo cáo test 10 Để hiểu rõ hoạt động hệ thống thường phải xác định số kịch bản, trường hợp cụ thể ca sử dụng Quan hệ kịch ca sử dụng tương tự quan hệ đối tượng lớp Ca sử dụng đề cập đến quan hệ tương tác lớp hệ thống với tác nhân (người sử dụng) Kịch lại tập cụ thể tương tác đối tượng tác nhân xác định Một kịch thông thường hệ thống thang máy xây dựng sau: Người A tầng nhấn nút “mũi tên lên” (↑) để yêu cầu thang máy lên tầng Nút ↑ tầng bật sáng Một thang máy đến tầng Trong thang máy có người B vào từ tầng nhấn nút để lên tầng Nút ↑ tầng tắt Thang máy mở cửa người A vào Người A nhấn nút thang máy Nút số thang máy bật sáng Thang máy đóng cửa lên tầng Thang máy đến tầng 10 Nút số bên thang máy tắt 11 Thang máy mở cửa để người A tầng 12 Thang máy đóng cửa 13 Thang máy tiếp tục lên theo yêu cầu người B 14 v.v Những kịch tương tự trên, không bình thường xẩy như: Ở tầng có người người A vào thang máy đồng thời lại muốn xuống tầng Trong bên thang máy có người B nhấn để lên tầng Khi thang máy lên tầng theo yêu cầu người B (yêu cầu trước) để người xuống tầng Lưu ý: UML có hai biểu đồ mô tả kịch biểu đồ trình tự biểu đồ cộng tác Các tác nhân + Người sử dụng : người sử dụng thang máy nhà 67 Các ca sử dụng + Nhấn nút thang máy: phục vụ cho người cần lên xuống tầng nhà theo yêu cầu + Nhấn nút tầng: phục vụ cho người sử dụng lên xuống 3.Biểu đồ ca sử dụng: Biểu đồ ca sử dụng xây dựng đơn giản sau: Hình 3.1 Biểu đồ ca sử dụng hệ thống thang máy Tất nhiên, không quan tâm đến chức quản lý trì hoạt động hệ thống thang máy, mà tập trung mô hoạt động chúng 3.1.2.2 Biểu đồ lớp Nhiệm vụ bước là: + Xác định lớp (đối tượng) thuộc tính chúng + Xác định mối quan hệ lớp Lưu ý: giai đoạn phân tích cần xác định thuộc tính lớp chưa cần quan tâm đến phương thức Các lớp hệ thống thang máy Ở dựa chủ yếu vào mô tả toán kịch nêu để xác định đại biểu lớp + Lớp nút thang máy, đặt tên NutThangMay + Lớp nut tầng, đặt tên NutTrenTang + Lớp thang máy, đặt tên ThangMay + Lớp cửa thang máy, đặt tên CuaTM Ngoài khái niệm đèn bật sáng hay tắt xem đại biểu lớp, chúng xem chúng thuộc tính lớp nút 68 Phân tích mối quan hệ lớp A/ Dễ nhận thấy hai lớp NutThangMay NutTrenTang có thuộc tính, hành vi tương tự nhau, gộp thành lớp tổng quát, lớp sở chúng Lớp đặt tên NutBam B/ Mỗi lớp ThangMay có m nút ứng với m tầng có n thang máy, nên lớp ThangMay NutThangMay có quan hệ kết hợp m-n Tương tự, lớp ThangMay lớp NutTrenTang có quan hệ kết hợp 1- (2m-2) Biểu đồ lớp hệ thống thang máy phác thảo hình 3.2 Hình 3.2 Biểu đồ lớp hệ thống thang máy Trong trình phân tích tiếp tục phân tích, điều chỉnh làm xác biểu đồ lớp Nhận xét: Biểu đồ lớp nêu có hai lớp NutBamThangMay ThangMay hệ hợp với theo quan hệ m – n không thích hợp cho cài đặt Trong hệ thống điều khiển thang máy, nút bấm không trao đổi trực tiếp với thang máy mà thường thông qua Bộ điều khiển thang máy Từ hai nhận xét thấy cần bổ sung thêm lớp DieuKhienTM để chuyển quan hệ m-n 1-n đồng thời thực việc điều khiển hoạt động thang máy có người nhấn nút yêu cầu lên xuống Biểu đồ lớp hệ thống thang máy mô tả hình 3.3 69 Hình 3.3 Biểu đồ lớp hệ thống thang máy 3.1.2.3 Mô hình hoạt động Mục đích mô hình động thái xây dựng biểu đồ trạng thái để mô tả hoạt động lớp đối tượng Trong hệ thống thang máy, lớp DieuKhienTM trung tâm, điều khiển hoạt động thang máy nút bấm hệ thống Do vậy, tập trung xây dựng biểu đồ trạng thái cho lớp DieuKhienTM Gần tương tự ôtômát hữu hạn, biểu đồ trang thái UML biểu diễn cho ba phương diện: trạng thái, kiện tân từ (điều kiện) Trạng thái thường trực điều khiển “Chờ vòng lặp” (loop), có kiện “Nhấn nút” thoả mãn tân từ “ nút nhấn” chuyển sang trạng thái “Xử lý yêu cầu”, thang máy dừng yêu cầu sử dụng chuyển sang trạng thái “Chờ đợi”, v.v Biểu đồ trạng thái lớp DieuKhienTM mô tả hình 3.4 70 [Nhấn nút] [Không có yêu cầu, cửa đóng] Cho vong lap [button pushed, or unlif] Xu ly yeu cau [elev stopped, no request] [elev moving in d] Cho doi do/ Update request do/ turn on button do/ Close elavator doors [elev stopp request next] Kiem tra de dung Dong cua TM do/ Check request do/ Close doors [no request to stop] [request to stop] Tat nut bam o tang Di chuyen tiep do/ Move ele on floor indirection d do/ Turn off floor button Dung tai tang do/ stop elevator do/ Open doors do/ Update request Xu ly yeu cau tiep theo do/ Move elev one floor in next requyest Tat nut o TM do/ Turn off ele button Hình 3.4 Biểu đồ trạng thái 3.1.2.4 Biểu đồ trình tự Thường với kịch (trong ca sử dụng) cần phải xây dựng biểu đồ trình tự Chúng ta xét kịch nêu phần trước Biểu đồ trình tự tương ứng xây dựng hình 3.5 71 : NSD : NutTrenTang : NutThangMay : DieuKhienTM : ThangMay : CuaTM nhan nut tren tang bat den di len tang tat den mo cua nhan nut o thang may bat den dong cua di len tang tat den dong cua chuyen den tang Hình 3.5 Biểu đồ trình tự 3.1.2.5 Biểu đồ cộng tác Tương tự có biểu đồ cộng tác hình 3.6 : CuaTM 8: dong cua 1: nhan nut o tang 5: mo cua 3: di len tren 12: di den tang : ThangMay : DieuKhienTM 6: nhan nut thang may : NSD 11: dong cua 9: di len tren 2: bat den 7: bat den 4: tat den 10: tat den : NutTrenTang : NutThangMay Hình 3.6 Biểu đồ cộng tác 72 3.1.2.6 Thiết kế lớp chi tiết Biểu đồ lớp xây dựng phần phân tích đề cập đến thuộc tính lớp chưa đề cập đến hoạt động (phương thức) xử lý lớp đối tượng Đây công việc giai đoạn thiết kế Thông qua biểu đồ tương tác (trình tự, cộng tác trạng thái) để phát hành động đối tượng, để xác định phương thức lớp Một hành động gán cho lớp có đối tượng lớp gửi thông điệp cho đối tượng lớp khác Một nguyên tắc chung để thiết kế lớp phải đảm bảo che giấu thông tin, nghĩa biến trạng thái thường phải khai báo private, protected Mọi thao tác biến trạng thái phải cục lớp Một vấn đề thiết kế thiết kế theo trách nhiệm Nếu có đối tượng gửi thông điệp cho đối tượng khác đối tượng phải có trách nhiệm trả lời yêu đối tượng gửi Do vậy, lớp đối tượng hệ thống mô thang máy có phương thức sau: Lớp CuaTM: có hai hàm + closeDoors() – đóng cửa thang máy + openDoors() – mở cửa thang máy Lớp ThangMay: có hai hàm + moveOneFloorDown() – chuyển xuống tầng + moveOneFloorUp() – chuyển lên tầng Lớp DieuKhienTM có hàm: + controllerLoop() - để điều khiển hoạt động thang máy + updateRequest() - cập nhật lại yêu cầu + logEequest()- chặn lại yêu cầu khác Lớp NutBam: có hai hàm + turnButtonOff() – tắt nút bấm + turnButtonOn() – bật nút bấm Hai lớp NutThangMay NutTrenTang kế thừa lớp NutBam nên có hai hàm nêu Cuối cùng, biểu đồ lớp thiết kế chi tiết hình 3.7 73 Lop truu tuong NutBam den : Boolean Phương thức ảo turnButtonOff() turnButtonOn() NutThan gMay NutTrenTang 2m-2 dieu k hien m*n dieu khien n DieuKhienTM controllerLoop() dieu khien dieu khien n CuaTM ThangMay moveOneFloorDown() moveOneFloorUp() closeDoors() openDoors() Hình 3.7 Biểu đồ lớp chi tiết Sau phần thiết kế chi tiết lớp xây dựng thuật toán cho hàm thành phần lớp 3.2 Tìm hiểu công cụ test 3.2.1.Ngôn ngữ SMV Ngôn ngữ SMV dùng để mô tả hệ thống hữu hạn trạng thái Các kiểu liệu mà ngôn ngữ cung cấp bao gồm: kiểu logic (boolean), kiểu số nguyên (bounded interger subrange) kiểu liệu liệt kê symbolic enum Các mô tả hệ thống phức tạp chia nhỏ thành module module thực thi nhiều lần Một chương trình viết ngôn ngữ SMV có phần sau: MODULE tên_module VAR Khai báo biến ASSIGN Mô tả bước chuyển trạng thái hệ thống Kết thúc câu lệnh dấu chấm phẩy (;) 3.2.2 Bộ công cụ kiểm chứng mô hình NuSMV NuSMV công cụ kiểm chứng mô hình trường đại học Carnegie Mellon University (CMU) viện per la Ricerca Scientifica e Tecnolgica (IRST) NuSMV thiết kế với kiến trúc mở, mềm dẻo mô tả đầy đủ để phục vụ cho việc kiểm chứng mô hình phần mềm [4] 74 NuSMV xử lý file viết ngôn ngữ SMV File chứa hệ thống mô hình hóa đặc tả thuộc tính mà hệ thống cần kiểm chứng Sau xử lý, NuSMV đưa thông báo hệ thống có thỏa mãn thuộc tính hay không, hệ thống không thỏa mãn, NuSMV đưa phản ví dụ NuSMV hỗ trợ đặc tả thuộc tính LTL CTL NuSMV có kiến trúc mở, dễ dàng chỉnh sửa, mở rộng hay nâng cấp Kiến trúc NuSMV chia thành module Mỗi module đảm trách tập hợp chức giao tiếp với module khác qua giao diện định nghĩa rõ ràng Phần lõi phần ngoại vi kiến trúc tách biệt rõ ràng nhằm giúp cho module bên sử dụng lại cách độc lập với ngôn ngữ dùng để mô hình hóa hệ thống Kiến trúc NuSMV (hình 3.8) bao gồm module sau: • Kernel: Phần lõi Module cung cấp chức mức độ thấp cấp phát nhớ động, tổ chức cấu trúc liệu Module sử dụng lại hộp đen (black-box) với hàm mô tả rõ ràng • Parser: Bộ phân tích ngữ pháp Module xử lý file viết ngôn ngữ SMV, kiểm tra mặt cú pháp xây dựng cấu trúc biểu diễn cấu trúc bên file xử lý • Compiler: Chương trình dịch Module có chức dịch file SMV sau phân tích ngữ pháp sang định nhị phân (binary decision diagram - BDD) Mô hình hệ thống chuyển thành máy hữu hạn trạng thái nhờ module • Model Checking: Bộ kiểm chứng mô hình Module kiểm tra thuộc tính mô tả CTL sinh phản ví dụ thuộc tính không thỏa mãn mô hình • LTL: Module có chức dịch biểu thức LTL thành hoạt cảnh (tableaux) thích hợp để NuSMV xử lý • Interactive shell: Giao diện tương tác dòng lệnh Module cung cấp giao diện người dùng chế độ dòng lệnh • Graphical user interface: Giao diện đồ họa người dùng Module xây dựng bên module giao diện tương tác dòng lệnh nhằm 75 cung cấp giao diện đồ họa trực quan chương trình cho người sử dụng Hình 3.8 Sơ đồ kiến trúc NuSMV 3.3 Kết Trong phần này, em xin trình bầy kết sử dụng công cụ NuSMV để kiểm chứng mô hình vừa thu qua trình phân tích mô hinh hóa Nhằm đưa nhìn tổng quan cách sử dụng NuSMV Kết kiểm chứng cho thấy mô hình thiết kế hoàn toàn thỏa mãn thuộc tính đặt ra: 76 Hình 3.9 Kết biên dịch chương trình Hình 3.10 Kết kiểm chứng chương trình 77 Hình 3.11 Dữ liệu test KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN Kết đạt được: Đồ án tốt nghiệp sản phẩm tri thức, thông qua thể phần kiến thức mà sinh viên nắm được, trình làm đồ án giúp sinh viên nói chung cá nhân em nói riêng nâng cao kiến thức thực tiễn chuyên ngành mình, học hỏi nhiều kinh nghiệm thực tế từ định hướng rõ ràng nghề nghiệp thân sau trường Kiểm thử môt hướng chuyên sâu chuyên ngành công nghệ phần mềm phù hợp với xu phát triển công nghệ phần mềm Trong thời gian thực đề tài, với giúp đỡ, bảo giáo viên hướng dẫn thầy giáo Th.S Nguyễn Hồng Tân, với nỗ lực thân em đạt thành như: - Nắm quy trình kiểm chứng phần mềm - Nắm quy trình kiểm thử tự động - Nắm khái niệm kiểm chứng mô hình - Sử dụng ngôn ngữ SMV, để mô hình hóa hệ thống - Sử dụng công cụ NuSMV để kiểm chứng mô hình mô hình hóa - Đã áp dụng công cụ NuSMV để kiểm chứng mô hình cho hệ thống thang máy, sinh liệu test tự động cho hệ thống 78 Vấn đề tồn tại: - Tuy nhiên em nhận thấy vài vấn đề tồn phương pháp kiểm chứng mô hình sử dụng công cụ NuSMV là: Thách thức lớn kỹ thuật kiểm chứng phần mềm vấn đề bùng nổ không gian trạng thái Vì hệ thống phần mềm lớn phức tạp, không gian trạng thái cần phải xét vô hạn Do đó, việc duyệt qua trạng thái trở nên không khả thi Một hướng tiếp cận trước áp dụng để kiểm chứng mô hình kỹ thuật trừu tượng hóa Thay kiểm chứng mô hình ban đầu, xây dựng chương trình trừu tượng có không gian trạng thái nhỏ thực kiểm chứng mô hình trừu tượng - Đề tài áp dụng thành công kỹ thuật kiểm chứng mô hình kiểm chứng giai đoạn thiết kế phần mềm Tuy nhiên, thời gian thực đề tài có hạn, nên em chưa thể lưu lại kết sinh liệu test dạng file để tiện theo dõi cho kiểm thử viên Hướng phát triến đề tài: Hướng phát triển đề tài áp dụng NuSMV để kiểm chứng mô hình phần mềm, đưa liệu test cho hệ thống phần mềm nhúng, hệ thống thời gian thực Lưu lại liệu test dạng file liệu 79 TÀI LIỆU THAM KHẢO [1] B Berard, M Bidoit, A Finkel, F Laroussinie, A Petit, L Petrucci, P Schnoebelen Systems and Software Verification: model-checking techniques [2] and tools, 2001 M Bozga, C Daws, O Maler, A Olivero, S Tripakis, and S Yovine Kronos: A Model-Checking Tool for Real-Time Systems Proceedings of the 10th international Conference on Computer Aided Verification (June 28 - July 02, 1998) A J Hu and M Y Vardi, Eds Lecture Notes In Computer Science, [3] vol 1427 Springer-Verlag, London, 546-550 A Cimatti, E Clarke, F Giunchiglia, M Roveri NuSMV: a new [4] symbolic model checker A Cimatti, E Clarke, E Giunchiglia, F Giunchiglia, M Pistore, M Roveri, R Sebastiani, A Tacchella NuSMV 2: An OpenSource Tool for Symbolic Model Checking In Proceedings of the 14th international Conference [5] [6] on Computer Aided Verification (July 27 - 31, 2002) Một vài đồ án tốt nghiệp khóa trước, trường H Giese, Safety – Critical computer systems, AG Softwaretechnik, SCCS-VI-6x, 2003 NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN 80 Thái nguyên, ngày… tháng… năm 20… Giáo viên hướng dẫn (Ký ghi rõ họ tên) Nguyễn Hồng Tân 81 ... 2: PHÁT SINH DỮ LIỆU TEST TỰ ĐỘNG & KIỂM CHỨNG MÔ HÌNH 2.1 Phát sinh liệu test tự động 2.1.1 Khái niệm kiểm thử tự động Test tự động việc sử dụng phần mềm để kiểm soát việc thực thi test, so... Sơ đồ kiến trúc NuSMV Hình 3.9 Kết biên dịch chương trình Hình 3.10 Kết kiểm chứng chương trình Hình 3.11 Dữ liệu test CHƯƠNG 1: TỔNG QUAN Kiểm chứng mô hình kỹ thuật tự động để xác minh trang... 2.1.3.2 Công cụ kiểm thử tự động liệu • Bộ sinh tệp kiểm thử: Những xử lý sinh ra, điền giá trị xác định, vào tệp đọc vào điển hình cho chương trình kiểm thử 13 • Bộ sinh liệu kiểm thử: Những