Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TRẦN QUỐC NAM PHƢƠNG PHÁP KIỂM CHỨNG TÍNH ĐÚNG ĐẮN CỦA CÁC BIỂU ĐỒ TUẦN TỰ UML 2.0 Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã Số: 60 48 01 03 LUẬN VĂN THẠC SĨ Ngành: Công nghệ Thông tin NGƢỜI HƢỚNG DẪN KHOA HỌC: TS TRỊNH THANH BÌNH ĐỒNG HƢỚNG DẪN: TS PHẠM NGỌC HÙNG Hà nội – 2015 i MỤC LỤC MỤC LỤC i LỜI CẢM ƠN iii LỜI CAM ĐOAN iv DANH MỤC THUẬT NGỮ VIẾT TẮT v DANH MỤC HÌNH VẼ vi DANH MỤC BẢNG viii Chương 1: Giới thiệu Chương 2: Phương pháp phân tích biểu đồ nhằm xây dựng mô hình đặc tả 2.1 Biểu đồ UML2.0 2.2 Phương pháp phân tích đối tượng biểu đồ thành khối đơn 11 2.3 Phương pháp sinh ôtômat vào/ra từ khối đơn biểu đồ 14 2.3.1 Trường hợp khối đơn không chứa phân đoạn 16 2.3.2 Trường hợp khối đơn chứa phân đoạn Option 16 2.3.3 Trường hợp khối đơn chứa phân đoạn Alternative 18 2.3.4 Trường hợp khối đơn chứa phân đoạn Loop 19 2.3.5 Trường hợp khối đơn chứa phân đoạn Break 21 2.3.6 Trường hợp khối đơn chứa phân đoạn Parallel 22 2.3.7 Trường hợp khối đơn chứa phân đoạn Strict 23 2.3.8 Trường hợp khối đơn chứa phân đoạn Critical 24 2.3.9 Trường hợp khối đơn chứa phân đoạn Consider 25 2.3.10 Trường hợp khối đơn chứa phân đoạn Ignore 27 2.4 Phương pháp xây dựng ôtômat vào/ra cho đối tượng biểu đồ 28 Chương 3: Công cụ sinh ôtômat vào/ra từ biểu đồ 32 ii 3.1 Giới thiệu công cụ 32 3.2 Thực nghiệm 36 3.2.1 Bài toán đặt chỗ 36 3.2.2 Bài toán máy toán siêu thị 40 3.3 Đánh giá 46 Chương 4: Phương pháp kiểm chứng tính đắn biểu đồ qua ôtômat vào/ra 47 4.1 Kiểm chứng tính đắn biểu đồ qua ôtômat vào/ra 47 4.2 Áp dụng phương pháp kiểm chứng với trường hợp toán đặt chỗ 48 Chương 5: KẾT LUẬN 50 TÀI LIỆU THAM KHẢO 51 iii LỜI CẢM ƠN Trước tiên xin dành lời cảm ơn chân thành sâu sắc đến hai thầy giáo, TS Trịnh Thanh Bình TS Phạm Ngọc Hùng – người hướng dẫn, khuyến khích, bảo tạo cho điều kiện tốt từ bắt đầu hoàn thành công việc Tôi xin dành lời cảm ơn chân thành tới thầy cô giáo khoa Công nghệ thông tin, trường Đại học Công nghệ, ĐH QGHN tận tình đào tạo, cung cấp cho kiến thức vô quý giá tạo điều kiện tốt cho suốt trình học tập, nghiên cứu trường Đồng thời xin chân thành cảm ơn người thân gia đình toàn thể bạn bè giúp đỡ, động viên lúc gặp phải khó khăn việc học tập nghiên cứu chương trình thạc sĩ Đại học Công nghệ, ĐH QGHN iv LỜI CAM ĐOAN Tôi xin cam đoan luận văn thạc sĩ công nghệ thông tin “Phương pháp kiểm chứng tính đắn biểu đồ UML 2.0” công trình nghiên cứu riêng tôi, không chép lại người khác Trong toàn nội dung luận văn, điều trình bày cá nhân tổng hợp từ nhiều nguồn tài liệu Tất nguồn tài liệu tham khảo có xuất xứ rõ ràng hợp pháp Tôi xin hoàn toàn chịu trách nhiệm chịu hình thức kỷ luật theo quy định cho lời cam đoan Hà Nội, ngày … tháng … năm 2015 Trần Quốc Nam v DANH MỤC THUẬT NGỮ VIẾT TẮT STT Từ viết tắt Từ đầy đủ Ý nghĩa DFA Deterministic Finite Automata Ôtômat hữu hạn trạng thái I/O Automata Input/Output Automata Ôtômat vào/ra FG Fragment Phân đoạn SD Sequence Diagram Biểu đồ OP Interaction Operand Toán hạng tương tác vi DANH MỤC HÌNH VẼ Hình 2.1 Phân đoạn Loop .4 Hình 2.2 Phân đoạn Alt Hình 2.3 Phân đoạn Par ví dụ thứ tự thực Hình 2.4 Phân đoạn Opt Hình 2.5 Phân đoạn Break Hình 2.6 Phân đoạn Seq Hình 2.7 Phân đoạn Strict .8 Hình 2.8 Phân đoạn Ignore .8 Hình 2.9 Phân đoạn Consider Hình 2.10 Phân đoạn Critical Hình 2.11 Phân đoạn Neg .10 Hình 2.12 Phân đoạn Assert 10 Hình 2.13 Khối đơn gồm phân đoạn opt .11 Hình 2.14 Khối đơn không chứa phân đoạn ôtômát cho đối tượng User 16 Hình 2.15 Khối đơn chứa phân đoạn Option ôtômat cho đối tượng User 17 Hình 2.16 Khối đơn chứa phân đoạn Alternative ôtômat cho đối tượng User 19 Hình 2.17 Khối đơn chứa phân đoạn Loop ôtômat cho đối tượng User 20 Hình 2.18 Khối đơn chứa phân đoạn Break ôtômat cho đối tượng User 22 Hình 2.19 Khối đơn chứa phân đoạn Paraller ôtômat cho đối tượng Admin .23 Hình 2.20 Khối đơn chứa phân đoạn Strict ôtômat cho đối tượng User 24 Hình 2.21 Khối đơn chứa phân đoạn Critical ôtômat cho đối tượng User.25 vii Hình 2.21 Khối đơn chứa phân đoạn Consider ôtômat cho đối tượng User .26 Hình 2.22 Khối đơn chứa phân đoạn Ignore ôtômat cho đối tượng User 28 Hình 4.1.1 Kiến trúc công cụ 32 Hình 4.1.2 Biểu đồ lớp công cụ .33 Hình 4.1.3 Khối Loop đơn giản 34 Hình 4.1.4 Đầu công cụ với khối Loop đơn giản 35 Hình 4.2.1 Biểu đồ xử lý đặt chỗ .36 Hình 4.2.2 Đầu mong muốn cho đối tượng Oder .38 Hình 4.2.3 Đầu mong muốn cho đối tượng Ticket 38 Hình 4.2.4 Đầu mong muốn cho đối tượng Account .39 Hình 4.2.5 Biểu đồ máy toán siêu thị 40 Hình 4.2.6 Đầu mong muốn cho đối tượng Customer .42 Hình 4.2.7 Đầu mong muốn cho đối tượng Cashier 43 Hình 4.2.8 Đầu mong muốn cho đối tượng Card Processor 44 Hình 4.2.9 Đầu mong muốn cho đối tượng Cash Register 44 viii DANH MỤC BẢNG Bảng 5.1 Mô kiểm chứng thuộc tính P với toán đặt chỗ 49 Chƣơng 1: Giới thiệu Đảm bảo chất lượng vấn đề quan trọng tiêu tốn chi phí cao trình phát triển phần mềm Tự động hóa trình đảm bảo chất lượng tiêu chí hướng tới doanh nghiệp nhằm giảm chi phí phát triển từ khâu thiết kế Ngoài ra, sản phẩm có yêu cầu chất lượng cao hệ thống điều khiển máy bay, tàu ga, kỹ thuật quân sự, y tế v.v nhà đầu tư yêu cầu áp dụng phương pháp hình thức nhằm đảm bảo tính đắn thiết kế trước triển khai Giải pháp phố biến để giải vấn đề áp dụng phương pháp kiểm chứng mô hình để tự động hóa trình kiểm chứng tính đắn thiết kế [2], [6], [9] Để áp dụng phương pháp này, ta cần phải xây dựng mô hình đặc tả xác hành vi hệ thống cần kiểm chứng [4], [10], [11] Tuy nhiên, xây dựng mô hình cho hệ thống phần mềm công việc khó khăn tiềm ẩn nhiều lỗi Các nghiên cứu hầu hết giả sử mô hình có đắn Trong thực tế, giả định khó để thực, từ phía công ty phát triển phần mềm Hạn chế nguyên nhân dẫn đến phương pháp khó áp dụng thực tế Để giải vấn đề nêu trên, hướng tiếp cận sử dụng đầu vào cho phương pháp kiểm chứng từ biểu đồ thiết kế UML Việc đưa phương pháp mô hình hóa biểu đồ UML, biểu đồ UML 2.0, giúp cho việc áp dụng phương pháp kiểm chứng mô hình hoàn toàn thực thực tế Nghiên cứu đề cập [3] tập trung xây dựng ôtômat cho biểu đồ Phương pháp đảm bảo thuộc tính an toàn (safety properties) [7], kiểm tra hành vi cách theo thời gian Cách tiếp cận tính hướng đối tượng vốn có biểu đồ tương tác đối tượng với nhau, gửi nhận loại thông điệp, điểm xuất phát điểm đến chúng, đặc biệt hệ thống tương tranh Vì cách khác ta cần bóc tách xây dựng ôtômat thể hành vi đối tượng mối quan hệ với đối tượng khác từ ta có hành vi hệ thống Một cách tiếp cận để giải vấn đề đề xuất [5] Ý tưởng phương pháp xây dựng ôtômat vào/ra (Input/Output Automata – I/O 38 Hình 4.2.2 Đầu mong muốn cho đối tượng Oder Hình 4.2.3 Đầu mong muốn cho đối tượng Ticket Hình 4.2.2 mô tả đầu mong muốn cho đối tượng Oder Khi nhận thông điệp create, ôtômat chuyển sang trạng thái q1 Nếu thỏa mãn điều kiện getNextItem, ôtômat gửi thông điệp reserver(date, count) chuyển sang trạng thái q2, không, ôtômat gửi thông điệp debit(cost) chuyển sang trạng thái kết thúc q5 Từ q2, kiểm tra điều kiện avaiable thỏa mãn, ôtômat nhận thông điệp add(seats) chuyển sang trạng thái q3, unavaiable nhận thông điệp reject chuyển sang trạng thái q4 Từ q3 q4, điều kiện getNextItem thỏa mãn, ôtômat gửi thông điệp reserver(date, count) chuyển sang trạng thái q2, không, ôtômat gửi thông điệp debit(cost) chuyển sang trạng thái kết thúc q5 Hình 4.2.3 mô tả đầu mong muốn cho đối tượng Ticket Từ trạng thái q0, ôtômat nhận thông điệp 39 reserve(date, count) thỏa mãn điều kiện getNextItem, ôtômat chuyển sang trạng thái q1 Từ q1, ôtômat kiểm tra điều kiện avaiable thỏa mãn gửi thông điệp add(seats) chuyển sang trạng thái q2, unavaiable gửi thông điệp reject() chuyển sang q3 Từ q2 q3, ôtômat tiếp tục nhận thông điệp reserve(date, count) với điều kiện getNextItem trạng thái ôtômat chuyển q1, không kết thúc Hình 4.2.4 mô tả đầu mong muốn cho đối tượng Account Bắt đầu từ trạng thái q0, ôtômat nhận thông điệp debit(cost) chuyển sang trạng thái kết thúc q1 Hình 4.2.4 Đầu mong muốn cho đối tượng Account Kết sinh công cụ ôtômat vào/ra cho đối tượng Đầu công cụ biểu đồ mô tả việc xử lý đặt chỗ thể xác kết mong muốn sau Object Order, id: 001 Tap cac trang thai: q0 q1 q2 q3 q4 q5 Trang thai khoi dau: q0 Tap trang thai ket thuc: q5 Quy tac chuyen trang thai: (q0; null / ? create; q1) (q1; get next item / ! reserve(date,count); q2) (q1; null / ! debit(cost); q5) (q2; available / ? add(seats); q3) (q2; unavailable / ? reject; q4) (q3; get next item / ! reserve(date,count); q2) (q3; null / ! debit(cost); q5) (q4; get next item / ! reserve(date,count); q2) (q4; null / ! debit(cost); q5) Object Ticket, id: 012 Tap cac trang thai: q0 q1 q2 q3 Trang thai khoi dau: q0 Tap trang thai ket thuc: q2 q3 Quy tac chuyen trang thai: (q0; get next item / ? reserve(date,count); q1) 40 (q2; get next item / ? reserve(date,count); q1) (q3; get next item / ? reserve(date,count); q1) Object Account, id: 013 Tap cac trang thai: q0 q1 Trang thai khoi dau: q0 Tap trang thai ket thuc: q1 Quy tac chuyen trang thai: (q0; null / ? debit(cost); q1) 3.2.2 Bài toán máy toán siêu thị Một toán phổ biến xét đến toán mô tả máy toán hàng siêu thị Hàng hóa kiểm tính toán máy có yêu cầu toán Người dùng chọn hình thức toán thẻ tiền mặt Máy tiếp nhận yêu cầu, xử lý toán trả hóa đơn Biểu đồ mô tả toán thể hình 4.2.5 Hình 4.2.5 Biểu đồ máy toán siêu thị 41 File xmi đầu vào toán biểu diễn sau 42 Các ôtômat vào/ra mong muốn cho đối tượng biểu đồ Customer, Cashier, Card Processor, Cash Register mô tả hình 4.2.6, 4.2.7, 4.2.8 4.2.9 Hình 4.2.6 mô tả đầu mong muốn cho đối tượng Customer Ôtômat khởi tạo từ trạng thái q0, thỏa mãn điều kiện item (while item remain) gửi thông điệp unloadItem(itemcost) chuyển sang trạng thái q1, nhận thông điệp requestPayment chuyển sang trạng thái q2 Tại q1, vòng lặp tiếp tục gửi thông điệp unloadItem(itemcost) nhận requestPayment chuyển sang trạng thái q2 Từ q2, Customer chọn cash credit card Trường hợp cash, ôtômat gửi thông điệp payCash() chuyển sang trạng thái q3, từ q3 nhận thông điệp returnChange chuyển sang trạng thái q4, sau nhận thông điệp giveReceipt chuyển sang trạng thái kết thúc q6 Trường hợp credit card, ôtômat gửi thông điệp payCredit() chuyển sang trạng thái q5, từ q5 nhận thông điệp giveReceipt chuyển sang trạng thái kết thúc q6 Hình 4.2.6 Đầu mong muốn cho đối tượng Customer 43 Hình 4.2.7 Đầu mong muốn cho đối tượng Cashier Hình 4.2.7 mô tả đầu mong muốn cho đối tượng Cashier Ôtômat khởi đầu từ trạng thái q0 nhận thông điệp unloadItem(itemcost) với điều kiện item (while item remain) chuyển sang trạng thái q1, gửi requestPayment chuyển sang q4 Từ q1, ôtômat tự gửi nhận thông điệp tallyItem(cost), chuyển trạng thái sang q2 q3 Từ q3, item nhận thông điệp unloadItem(cost) ôtômat quay trở lại q1, gửi requestPayment chuyển sang q4 Từ q4, ôtômat nhận lựa chọn payCash với điều kiện cash chuyển sang q5 payCredit với điều kiện credit card chuyển sang q9 Từ q5, ôtômat gửi thông điệp depositPayment chuyển sang q6, từ q6 ôtômat nhận retrievePayment chuyển sang q7, gửi returnCharge chuyển sang q8 Từ q9, ôtômat gửi thông điệp processCard chuyển sang q10, sau nhận processStatus chuyển sang q11 Từ q8 q11 gửi giveReceive ôtômat chuyển sang trạng thái kết thúc q12 44 Hình 4.2.8 Đầu mong muốn cho đối tượng Card Processor Hình 4.2.9 Đầu mong muốn cho đối tượng Cash Register Hình 4.2.8 mô tả đầu mong muốn cho đối tượng Card Processor Ôtômat khởi đầu với trạng thái q0, nhận thông điệp processCard với điều kiện có credit card chuyển sang trạng thái q1, sau gửi thông điệp processStatus chuyển sang trạng thái kết thúc q2 Hình 4.2.9 mô tả đầu mong muốn cho đối tượng Cash Register Ôtômat khởi đầu với trạng thái q0, nhận thông điệp depositPayment với điều kiện có cash chuyển sang trạng thái q1, sau gửi thông điệp retrieveChange chuyển sang trạng thái kết thúc q2 Kết đầu công với bốn ôtômat tương ứng với bốn đối tượng biểu đồ thể xác so với ôtômat đầu mong muốn mô tả bên Đầu công cụ tương ứng sau Object Cashier, id: 001 Tap cac trang thai: q0 q1 q2 q3 q4 q5 q6 q7 q8 q9 q10 q11 q12 Trang thai khoi dau: q0 Tap trang thai ket thuc: q12 Quy tac chuyen trang thai: (q0; while item remain / ? unloadItem(itemCost); q1) (q0; null / ! requestPayment; q4) (q1; null / ! tallyItem(cost); q2) (q2; null / ? tallyItem(cost); q3) (q3; while item remain / ? unloadItem(itemCost); q1) (q3; null / ! requestPayment; q4) 45 (q4; cash / ? payCash; q5) (q4; credit card / ? payCredit; q9) (q5; null / ! depositPayment; q6) (q6; null / ? retrievePayment; q7) (q7; null / ! returnChange; q8) (q8; null / ! giveReceipt; q12) (q9; null / ! processCard; q10) (q10; null / ? processStatus; q11) (q11; null / ! giveReceipt; q12) Object Customer, id: 020 Tap cac trang thai: q0 q1 q2 q3 q4 q5 q6 Trang thai khoi dau: q0 Tap trang thai ket thuc: q6 Quy tac chuyen trang thai: (q0; while item remain / ! unloadItem(itemCost); q1) (q0; null / ? requestPayment; q2) (q1; while item remain / ! unloadItem(itemCost); q1) (q1; null / ? requestPayment; q2) (q2; cash / ! payCash; q3) (q2; credit card / ! payCredit; q5) (q3; null / ? returnChange; q4) (q4; null / ? giveReceipt; q6) (q5; null / ? giveReceipt; q6) Object CardProcessor, id: 021 Tap cac trang thai: q0 q1 q2 Trang thai khoi dau: q0 Tap trang thai ket thuc: q2 Quy tac chuyen trang thai: (q0; credit card / ? processCard; q1) (q1; null / ! processStatus; q2) Object CashRegister, id: 022 Tap cac trang thai: q0 q1 q2 46 Trang thai khoi dau: q0 Tap trang thai ket thuc: q2 Quy tac chuyen trang thai: (q0; cash / ? depositPayment; q1) (q1; null / ! retrievePayment; q2) 3.3 Đánh giá Sau áp dụng công cụ với nhiều toán, luận văn đánh giá công cụ hoạt động tốt với môi trường máy tính ổn định toán đầu vào mức chấp nhận Đầu công cụ ôtômat vào/ra dạng đối tượng Java, hiển thị lên hình hoàn toàn đáp ứng với kết mong muốn toán Thời gian thực thi công cụ hoàn toàn chấp nhận (với toán đầu vào nhỏ 5000 dòng, công cụ chạy giây) Công cụ số hạn chế đầu vào tệp xmi theo định dạng, đầu đối tượng xuất hình Những hạn chế khắc phục phiên công cụ 47 Chƣơng 4: Phƣơng pháp kiểm chứng tính đắn biểu đồ qua ôtômat vào/ra Sau kết việc mô hình hóa biểu đồ UML2.0 thành ôtômat vào/ra, vấn đề xét đến sử dụng kết để kiểm chứng tính đắn biểu đồ UML2.0 Tư tưởng kiểm chứng tính đắn dựa vào Ôtômat vào/ra đề cập [8]: Để kết nối hệ ôtômat vào/ra, ta coi thông điệp đầu ôtômat đầu vào cho tất ôtômat có đầu vào đón nhận thông điệp Áp dụng tư tưởng vào giải vấn đề, luận văn xây dựng hàm thực hóa việc chuyển đối trạng thái gửi/nhận thông điệp ôtômat, từ tạo tiền đề cho việc kiểm chứng tính đắn biểu đồ với thuộc tính yêu cầu 4.1 Kiểm chứng tính đắn biểu đồ qua ôtômat vào/ra Trước tiên, luận văn xây dựng hàm thực hóa việc chuyển đổi trạng thái gửi/nhận thông điệp ôtômat vào/ra Đầu vào hàm hệ Ôtômat vào/ra (A0, A1, A2, An) luật chuyển xuất phát R0 = 10 11 : Khởi tạo Ôtômat trạng thái xuất phát, R = Asend = A0 : Kiểm tra có Ai đón nhận thông điệp R từ Asend hay không : Nếu không: kết thúc hàm : Nếu có: : Asend = Asend.next(); : Ai = Ai.next(); : Nếu Ai trạng thái kết thúc : Với thông điệp Rulej gửi từ Ai : Asend = Ai; : R = Ai.sendRule; : Áp dụng từ bước Hàm mô khởi tạo với Ôtômat trạng thái q0, đầu vào R= R0 ôtômat gửi Asend (dòng 1) Trước tiên, hàm kiểm tra xem có ôtômat Ai nhận thông điệp R từ Asend không (dòng 2) Điều kiện đón nhận trạng thái Ai 48 có luật chuyển nhận thông điệp R Nếu Ai nhận, hàm chuyển kết thúc (dòng 3) Nếu có, Ai Asend chuyển trạng thái (dòng 5,6) Nếu trạng thái sau chuyển Ai trạng thái kết thúc (Ai tiếp tục gửi thông điệp), với thông điệp gửi từ Ai, ta trỏ Asend Ai, R gán thông điệp gửi từ Ai (dòng 9, 10), sau áp dụng từ bước (2) Để kiểm chứng tính đắn biểu đồ với thuộc tính P, ta đưa P dạng ôtômat vào/ra đưa vào hệ ôtômat từ biểu đồ Trường hợp tồn bước chuyển mà ôtômat thuộc tính thực thi, ta nói thuộc tính thỏa mãn Ngược lại, trường hợp ôtômat xây dựng từ thuộc tính không thực thi, ta nói thuộc tính không thỏa mãn 4.2 Áp dụng phƣơng pháp kiểm chứng với trƣờng hợp toán đặt chỗ Bài toán: kiểm tra tính đắn biểu đồ với thuộc tính P : Account = Account + cost (kiểm tra xem Account có cộng thêm số tiền cost hay không) Ta đưa P cần kiểm tra dạng ôtômat sau đưa vào hệ ôtômat có 3.2.1 Ôtômat từ thuộc tính P Object P, id: 015 Tap cac trang thai: q0 q1 Trang thai khoi dau: q0 Tap trang thai ket thuc: q1 Quy tac chuyen trang thai: (q0; null / ? debit(cost); q1) STT Oder Ticket Account P q0 q0 q0 q0 q1 q0 q0 q0 Asend R create() Oder get next item, 49 reserve(date,count) q2 q1 q0 q0 Ticket available, add(seats) q3 q2 q0 q0 Oder get next item, reserve(date,count) q2 q1 q0 q0 Ticket unavailable, reject q4 q3 q0 q0 Oder debit(cost) q5 q3 q1 q1 Account & P Bảng 5.1 Mô kiểm chứng thuộc tính P với toán đặt chỗ Áp dụng hàm mô 4.1 vào hệ ôtômat sau thêm thuộc tính P, ta bảng mô 5.1 Chi tiết bước thể bảng sau Bước 1, hệ khởi tạo tất ôtômat trạng thái xuất phát q0 thông điệp gửi create() Bước 2, nhận thấy có ôtômat Oder nhận thông điệp create(), ta chuyển trạng thái Oder sang q1, đưa Oder vào vị trí Asend thông điệp gửi get next item/reserve(date,count) Bước 3, ta thấy Ticket đón nhận thông điệp get next item/reserve(date,count), Oder chuyển sang trạng thái q2, Ticket chuyển sang trạng thái q1 đưa vào vị trí Asend, thông điệp gửi từ Ticket available/add(seats) Bước 4, ta thấy Oder đón nhận thông điệp available/add(seats), Ticket chuyển sang trạng thái q2, Oder chuyển sang trạng thái q3 đưa vào vị trí Asend, thông điệp gửi từ Oder get next item/reserve(date,count) Bước 5, ta thấy Ticket đón nhận thông điệp get next item/reserve(date,count), Oder chuyển sang trạng thái q2, Ticket chuyển sang trạng thái q1 đưa vào vị trí Asend, thông điệp gửi từ Ticket unavailable/reject Bước 6, ta thấy Oder đón nhận thông điệp unavailable/add(seats), Ticket chuyển sang trạng thái q3, Oder chuyển sang trạng thái q4 đưa vào vị trí Asend, thông điệp gửi từ Oder debit(cost) Bước 7, ta thấy Account P đón nhận thông điệp debit(cost) từ Oder, Oder chuyển sang trạng thái q5 (kết thúc), Account Q chuyển sang trạng thái q1 (kết thúc) Sau bước, ta thấy thuộc tính P khởi chạy, ta nói biểu đồ thỏa mãn thuộc tính P 50 Chƣơng 5: KẾT LUẬN Trong ngữ cảnh ngành công nghiệp phần mềm đại, yêu cầu đảm bảo chất lượng phần mềm đặt lên cao việc áp dụng kiểm thử tự động vào kiểm chứng tính đắn từ khâu thiết kế giải pháp hàng đầu nhằm đảm bảo chất lượng, tiến độ chi phí phát triển phần mềm Khó khăn việc kiểm chứng tính đắn thiết kế áp dụng toán học vào việc mô hình hóa hành vi đối tượng phần mềm Tuy nhiên, nhà phát triển cung cấp đặc tả cho phần mềm dạng biểu đồ mô tả hành vi thành phần phần mềm ta xây dựng mô hình cho thành phần làm sở cho việc kiểm chứng mô hình, kiểm thử tự động dựa mô hình cho toàn phần mềm Luận văn nghiên cứu phương pháp kiểm chứng tính đắn biểu đồ UML2.0 Từ biểu đồ tuần tự, luận văn xây dựng thuật toán công cụ thực hóa việc mô hình hóa đối tượng ôtômat vào/ra Ngoài ra, luận văn nghiên cứu phương pháp kiểm chứng tính đắn mô hình sinh từ biểu đồ so với số thuộc tính yêu cầu Về mặt thực nghiệm, công cụ hỗ trợ trực tiếp việc sinh mô hình từ biểu đồ mô tả dạng tệp xmi Mô hình thu sở cho việc áp dụng kỹ thuật kiểm chứng mô hình kiểm thử tự động mà đầu vào cho việc sinh giả định hỗ trợ cho kỹ thuật kiểm chứng đảm bảo giả định hay kiểm thử dựa mô hình Ngoài ra, công cụ đóng vai trò to lớn việc tự động hóa số công đoạn việc phát triển phần mềm từ thiết kế, sinh mô hình tự động, sinh mã nguồn, kiểm thử tự động cho nghiên cứu sau Hướng phát triển luận văn nghiên cứu xây dựng hoàn thiện công cụ Phát triển công cụ với đầu vào vẽ biểu đồ tuần tự, kết hợp với thuộc tính cần kiểm tra xác định tính đắn thiết kế Đồng thời, công cụ thực hóa cần cải tiến để chạy với toán lớn 51 TÀI LIỆU THAM KHẢO Tiếng Việt [1] Đỗ Đức Giáo (2011), Toán rời rạc ứng dụng tin học, Nhà xuất giáo dục Việt Nam Tiếng Anh [2] Clarke, E M.; Grumberg, O & Peled, D A (2000), Model checking, MIT, Cambridge, Mass [3] H M Duong, L K Trinh, and P N Hung (2013), “An Assume-Guarantee Model Checker for Component-Based Systems”, The 10th IEEE-RIVF International Conference on Computing and Communication Technologies [4] L B Cuong and P N Hung (2012), “A Method for Generating Models of Blackbox Components”, 4th International Conference on Knowledge and Systems Engineering (KSE 2012), IEEE Computer Society Press, pp 177-222 [5] Zhang, C & Duan, Z (2011), Specification and Verification of UML2.0 Sequence Diagrams Using Event Deterministic Finite Automata., in 'SSIRI (Companion)', IEEE Computer Society, , pp 41-46 [6] J Magee and J Kramer (1990), „Concurrency: State Models and Java Programs‟, John Wiley and Sons [7] P N Hung, N V Ha, T Aoki and T Katayama (2012), “On Optimization of Minimized Assumption Generation Method for Component-based Software Verification”, IEICE Trans on Fundamentals, Special Issue on Software Reliability Engineering, Vol E95-A, No.9, pp 1451-1460 [8] Lynch, N A & Tuttle, M R (1989), 'An introduction to input/output automata', CWI Quarterly 2, 219 246 [9] D Lorenzoli, L Mariani and M Pezz` e (2008), “Automatic generation of software behavioral models”, ACM, Proceedings of the 30th international conference on Software engineering, pp 501-510 [10] J.C Corbett, M.B Dwyer, J Hatcliff, S Laubach, C.S Pasareanu, Robby and Hongjun Zheng (2000), ”Bandera: extracting finite-state models from Java 52 source code”, Software Engineering, Proceedings of the 2000 International Conference on, pp 439-448d [11] O Tkachuk, M.B Dwyer and C.S Pasareanu (2003), “Automated environment generation for software model checking”, Automated Software Engineering, Proceedings 18th IEEE International Conference on, pp 116-127 [12] cand inform Claus-André Ohlhoff (2006) Consistent Refinement of Sequence Diagrams in the UML 2.0 Hamburg: Christian-Albrechts-Universität zu Kiel [...]... trình bày trong chương 2 Chương 4 nghiên cứu phương pháp để kiểm chứng tính đúng đắn của biểu đồ tuần tự thông qua việc kiểm tra tính đúng đắn của các ôtômat vào/ra được sinh ra từ các đối tượng cùng các thuộc tính yêu cầu Chương này nghiên cứu phương pháp mô phỏng sự tương tác giữa các ôtômat vào/ra từ các đối tượng, qua đó kiểm chứng tính đúng đắn của biểu đồ tuần tự đối với thuộc tính yêu cầu Kết luận... chương 5 3 Chƣơng 2: Phƣơng pháp phân tích biểu đồ tuần tự nhằm xây dựng các mô hình đặc tả Để áp dụng các phương pháp kiểm chứng tự động dựa trên mô hình, việc đầu tiên cần làm là xây dựng các mô hình đặc tả thiết kế của phần mềm, ở đây là biểu đồ tuần tự UML2 .0 Đầu vào của bài toán là biểu đồ tuần tự UML2 .0, ta cần xây dựng thuật toán để chuyển đổi các đối tượng của biểu đồ tuần tự thành các ôtômat vào/ra... vào/ra cho các đối tượng trong biểu đồ tuần tự Các mô hình ôtômat vào/ra này cùng với việc đưa vào các thuộc tính sẽ là đầu vào cho các công cụ kiểm chứng hỗ trợ ôtômat vào/ra nhằm kiểm chứng tính đúng đắn của thiết kế Phần còn lại của luận văn được cấu trúc như sau Phương pháp sinh mô hình cho các đối tượng của biểu đồ tuần tự UML2 .0 được giới thiệu trong chương 2 Chương này trình bày phương pháp bóc... tách đối tượng của biểu đồ tuần tự thành các khối đơn, tiếp đó là phương pháp sinh ôtômat vào/ra từ các khối đơn của biểu đồ tuần tự và cuối cùng là phương pháp ghép nối các ôtômat vào/ra được sinh ra từ các khối đơn để được một ôtômat cho cả đối tượng Chương 3 giới thiệu về công cụ thực nghiệm và kết quả thực nghiệm của phương pháp sinh ôtômat vào/ra cho các đối tượng của biểu đồ tuần tự được trình... tuần tự UML2 .0 Biểu đồ tuần tự (Sequence Diagram – SD) thể hiện tương tác giữa các thực thể của hệ thống theo thứ tự trình tự mà các tương tác này xảy ra SD nhấn mạnh sự tương tác giữa các đối tượng và chỉ ra sự tương tác là khía cạnh quan trọng nhất Biểu đồ tuần tự UML2 .0 đưa vào sự kết hợp giữa các phân đoạn (combined fragment), cho phép thực hiện các tương tác phức tạp Thành phần chính của biểu đồ tuần. .. của biểu đồ tuần tự thành một tập các khối đơn (biểu đồ tuần tự và khối đơn được đề cập ở mục 2. 1) Sau đó, thuật toán chuyển đổi được xây dựng để chuyển từng khối đơn đó thành các ôtômat vào/ra Cuối cùng, luận văn xây dựng thuật toán để ghép nối các ôtômat có được thành một ôtômat tương ứng với đối tượng của biểu đồ tuần tự Chi tiết các thuật toán được mô tả trong 3 mục từ 2. 2 đến 2. 4 2. 1 Biểu đồ tuần. .. Phƣơng pháp phân tích đối tƣợng của biểu đồ tuần tự thành các khối đơn Vấn đề đầu tiên được xét đến để giải quyết bài toán phương pháp bóc tách các đối tượng của biểu đồ tuần tự thành các khối đơn Các khối đơn được sinh ra sẽ là đầu vào cho việc chuyển đổi sang ôtômat vào/ra được trình bày ở mục 2. 3 Phương pháp đề xuất yêu cầu thiết kế được biểu diễn bởi biểu đồ tuần tự của các thành phần dưới dạng xmi... để khai báo các message bị loại bỏ trong fragment Ignore hoặc các message cần giữ lại trong fragment Consider - Event nằm trong sequence hoặc trong operand, không nằm trực tiếp trong fragment Thuật toán 2. 1 Phân tích biểu đồ tuần tự thành các khối đơn Đầu vào: Biểu đồ tuần tự biểu diễn dưới dạng tệp xmi Đầu ra: Danh sách các đối tượng của biểu đồ tuần tự được biểu diễn dưới dạng danh sách các khối đơn... singleFragmentList (dòng 40, 41), sau đó singleFragmentList được đưa vào object và object được đưa vào objectList (dòng 42, 43) Sau khi kết thúc đọc tệp xmi, ta được objectList tương ứng với các đối tượng của Biểu đồ tuần tự ban đầu Mỗi phần tử trong objectList là một danh sách các singleFragment tương ứng được bóc tách từ đối tượng đó 2. 3 Phƣơng pháp sinh ôtômat vào/ra từ các khối đơn của biểu đồ tuần tự Vấn đề tiếp.. .2 Automata) [8] cho mỗi đối tượng của biểu đồ tuần tự Ôtômat vào/ra là sự mở rộng của ôtômat hữu hạn trạng thái (Deterministic Finite Automata - DFA) [1] Các trạng thái trong ôtômat vào/ra biễu diễn các ánh xạ từ hành vi tới các đối tượng trong biểu đồ tuần tự Hàm chuyển trạng thái được biểu diễn bởi ánh xạ hai ngôi (điều kiện, hành vi) thể hiện sự tương tác giữa các đối tượng [5] ... cận sử dụng đầu vào cho phương pháp kiểm chứng từ biểu đồ thiết kế UML Việc đưa phương pháp mô hình hóa biểu đồ UML, biểu đồ UML 2. 0, giúp cho việc áp dụng phương pháp kiểm chứng mô hình hoàn toàn... Chương 2: Phương pháp phân tích biểu đồ nhằm xây dựng mô hình đặc tả 2. 1 Biểu đồ UML2 .0 2. 2 Phương pháp phân tích đối tượng biểu đồ thành khối đơn 11 2. 3 Phương pháp sinh ôtômat... 46 Chương 4: Phương pháp kiểm chứng tính đắn biểu đồ qua ôtômat vào/ra 47 4.1 Kiểm chứng tính đắn biểu đồ qua ôtômat vào/ra 47 4 .2 Áp dụng phương pháp kiểm chứng với trường