Hình 4.2.8 mô tả đầu ra mong muốn cho đối tượng Card Processor. Ôtômat khởi đầu với trạng thái q0, nếu nhận được thông điệp processCard với điều kiện có credit card sẽ chuyển sang trạng thái q1, sau khi gửi đi thông điệp processStatus thì chuyển sang trạng thái kết thúc q2.
Hình 4.2.9 mô tả đầu ra mong muốn cho đối tượng Cash Register. Ôtômat khởi đầu với trạng thái q0, nếu nhận được thông điệp depositPayment với điều kiện có cash sẽ chuyển sang trạng thái q1, sau khi gửi đi thông điệp retrieveChange thì chuyển sang trạng thái kết thúc q2.
Kết quả đầu ra của công với bốn ôtômat tương ứng với bốn đối tượng của biểu đồ tuần tự thể hiện chính xác so với các ôtômat đầu ra mong muốn được mô tả bên trên. Đầu ra của công cụ tương ứng như 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)<004>; q1) (q0; null / ! requestPayment<005>; q4)
(q1; null / ! tallyItem(cost)<013>; q2) (q2; null / ? tallyItem(cost)<013>; q3)
(q3; while item remain / ? unloadItem(itemCost)<004>; q1) (q3; null / ! requestPayment<005>; q4)
(q4; cash / ? payCash<008>; q5) (q4; credit card / ? payCredit<011>; q9) (q5; null / ! depositPayment<014>; q6) (q6; null / ? retrievePayment<015>; q7) (q7; null / ! returnChange<009>; q8) (q8; null / ! giveReceipt<012>; q12) (q9; null / ! processCard<016>; q10) (q10; null / ? processStatus<017>; q11) (q11; null / ! giveReceipt<012>; 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)<004>; q1) (q0; null / ? requestPayment<005>; q2)
(q1; while item remain / ! unloadItem(itemCost)<004>; q1) (q1; null / ? requestPayment<005>; q2)
(q2; cash / ! payCash<008>; q3)
(q2; credit card / ! payCredit<011>; q5) (q3; null / ? returnChange<009>; q4) (q4; null / ? giveReceipt<012>; q6) (q5; null / ? giveReceipt<012>; 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<016>; q1) (q1; null / ! processStatus<017>; q2)
Object CashRegister, id: 022 Tap cac trang thai: q0 q1 q2
Trang thai khoi dau: q0 Tap trang thai ket thuc: q2 Quy tac chuyen trang thai:
(q0; cash / ? depositPayment<014>; q1) (q1; null / ! retrievePayment<015>; q2)
3.3. Đánh giá
Sau khi áp dụng công cụ với rất nhiều bài toán, luận văn có thể đánh giá công cụ hoạt động tốt với môi trường máy tính ổn định và bài toán đầu vào ở mức chấp nhận được. Đầu ra của công cụ là các ôtômat vào/ra dưới dạng đối tượng của Java, được hiển thị lên màn hình hoàn toàn đáp ứng với kết quả mong muốn của các bài toán. Thời gian thực thi của công cụ là hoàn toàn chấp nhận được (với bài toán đầu vào nhỏ hơn 5000 dòng, công cụ chạy dưới 5 giây).
Công cụ vẫn còn một số hạn chế như đầu vào là tệp xmi theo định dạng, đầu ra là đối tượng được xuất ra màn hình. Những hạn chế này sẽ được khắc phục trong các phiên bản tiếp theo của công cụ.
Chƣơng 4: Phƣơng pháp kiểm chứng tính đúng đắn của biểu đồ tuần tự qua ôtômat vào/ra
Sau những kết quả của việc mô hình hóa biểu đồ tuần tự UML2.0 thành các ôtômat vào/ra, vấn đề tiếp theo được xét đến là sử dụng kết quả đó để kiểm chứng tính đúng đắn của biểu đồ tuần tự UML2.0. Tư tưởng về kiểm chứng tính đúng đắn dựa vào Ôtômat vào/ra được đề cập trong [8]: Để kết nối một hệ các ôtômat vào/ra, ta coi một thông điệp đầu ra của một ôtômat là đầu vào cho tất cả các ôtômat có đầu vào đón nhận thông điệp đó. Áp dụng tư tưởng đó vào giải quyết vấn đề, luận văn xây dựng một hàm hiện thực hóa việc chuyển đối trạng thái và gửi/nhận thông điệp giữa các ôtômat, từ đó tạo tiền đề cho việc kiểm chứng tính đúng đắn của biểu đồ với thuộc tính yêu cầu.
4.1. Kiểm chứng tính đúng đắn của biểu đồ tuần tự qua ôtômat vào/ra ôtômat vào/ra
Trước tiên, luận văn xây dựng hàm hiện thực hóa việc chuyển đổi trạng thái cũng như gửi/nhận các thông điệp giữa các ôtômat vào/ra.
Đầu vào của hàm là một hệ các Ôtômat vào/ra (A0, A1, A2,.. An) và luật chuyển xuất phát R0 = <c, E0>.
1 : Khởi tạo các Ôtômatở trạng thái xuất phát, R = <c, E0>. Asend = A0 2 : Kiểm tra có Ai đón nhận thông điệp R từ Asend hay không
3 : Nếu không: kết thúc hàm. 4 : Nếu có:
5 : Asend = Asend.next(); 6 : Ai = Ai.next();
7 : Nếu Ai không phải trạng thái kết thúc
8 : Với mỗi thông điệp Rulej được gửi từ Ai 9 : Asend = Ai;
10 : R = Ai.sendRule; 11 : Áp dụng từbước 2
Hàm mô phỏng được khởi tạo với các Ôtômat đều ở trạng thái q0, đầu vào R= R0
và ôtômat gửi là Asend (dòng 1). Trước tiên, hàm kiểm tra xem có ôtômat Ai nào nhận thông điệp R từ A không (dòng 2). Điều kiện đón nhận là trạng thái hiện tại của A
có luật chuyển khi nhận thông điệp R. Nếu không có Ai nào nhận, hàm chuyển về kết thúc (dòng 3). Nếu có, cả Ai và Asend đều chuyển về trạng thái tiếp theo (dòng 5,6). Nếu trạng thái sau khi chuyển của Ai không phải trạng thái kết thúc (Ai vẫn tiếp tục gửi thông điệp), với mỗi thông điệp có thể được gửi từ Ai, ta trỏ Asend về Ai, R được gán bằng 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 đúng đắn của biểu đồ tuần tự với thuộc tính P, ta đưa P về dạng ôtômat vào/ra rồi đưa vào hệ các ôtômat từ biểu đồ tuần tự. Trường hợp tồn tại một bước chuyển mà ở đó ôtômat của thuộc tính được thực thi, ta nói thuộc tính đó được 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 được 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 bài toán đặt chỗ
Bài toán: kiểm tra tính đúng đắn của biểu đồ tuần tự với thuộc tính P : Account = Account + cost (kiểm tra xem Account có được cộng thêm một số tiền cost hay không)
Ta đưa P cần kiểm tra về 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)<011>; q1)
STT Oder Ticket Account P Asend R
1 q0 q0 q0 q0 create()
reserve(date,count)
3 q2 q1 q0 q0 Ticket available,
add(seats)
4 q3 q2 q0 q0 Oder get next item,
reserve(date,count)
5 q2 q1 q0 q0 Ticket unavailable, reject
6 q4 q3 q0 q0 Oder debit(cost)
7 q5 q3 q1 q1 Account & P
Bảng 5.1. Mô phỏng kiểm chứng thuộc tính P với bài toán đặt chỗ.
Áp dụng hàm mô phỏng ở 4.1 vào hệ ôtômat sau khi đã thêm thuộc tính P, ta được bảng mô phỏng 5.1. Chi tiết các bước được thể hiện trong bảng như sau. Bước 1, hệ khởi tạo tất cả ôtômat ở trạng thái xuất phát q0 và thông điệp được gửi là 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 và thông điệp được gửi đ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 được chuyển sang trạng thái q2, Ticket được chuyển sang trạng thái q1 và được đưa vào vị trí Asend, thông điệp gửi tiếp theo từ Ticket là
available/add(seats). Bước 4, ta thấy Oder đón nhận thông điệp available/add(seats), Ticket được chuyển sang trạng thái q2, Oder được chuyển sang trạng thái q3 và được đưa vào vị trí Asend, thông điệp gửi tiếp theo từ Oder là 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 được chuyển sang trạng thái q2, Ticket được chuyển sang trạng thái q1 và được đưa vào vị trí Asend, thông điệp gửi tiếp theo từ Ticket là
unavailable/reject. Bước 6, ta thấy Oder đón nhận thông điệp unavailable/add(seats), Ticket được chuyển sang trạng thái q3, Oder được chuyển sang trạng thái q4 và được đưa vào vị trí Asend, thông điệp gửi tiếp theo từ Oder là debit(cost). Bước 7, ta thấy Account và P đều đón nhận thông điệp debit(cost) từ Oder, Oder được chuyển sang trạng thái q5 (kết thúc), Account và Q đều chuyển sang trạng thái q1 (kết thúc). Sau 7 bước, ta thấy thuộc tính P được khởi chạy, ta nói biểu đồ tuần tự thỏa mãn thuộc tính P.
Chƣơng 5: KẾT LUẬN
Trong ngữ cảnh của ngành công nghiệp phần mềm hiện đại, khi yêu cầu về đảm bảo chất lượng của phần mềm được đặt lên rất cao thì việc áp dụng kiểm thử tự động vào kiểm chứng tính đúng đắn ngay từ khâu thiết kế là một giải pháp hàng đầu nhằm đảm bảo chất lượng, tiến độ cũng như chi phí phát triển của phần mềm. Khó khăn duy nhất của việc kiểm chứng tính đúng đắn của thiết kế là áp dụng toán học vào việc mô hình hóa các hành vi của đối tượng trong phần mềm. Tuy nhiên, nếu nhà phát triển cung cấp một đặc tả cho phần mềm đó dưới dạng một biểu đồ tuần tự mô tả các hành vi của thành phần phần mềm thì ta có thể xây dựng mô hình cho thành phần đó làm cơ sở cho việc kiểm chứng mô hình, kiểm thử tự động dựa trên mô hình cho toàn bộ phần mềm.
Luận văn này đã nghiên cứu phương pháp kiểm chứng tính đúng đắn của biểu đồ tuần tự UML2.0. Từ biểu đồ tuần tự, luận văn xây dựng thuật toán và công cụ hiện thực hóa việc mô hình hóa các đối tượng bằng ôtômat vào/ra. Ngoài ra, luận văn còn nghiên cứu phương pháp kiểm chứng tính đúng đắn của mô hình được sinh ra từ các biểu đồ tuần tự so với một 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 đồ tuần tự được mô tả dưới dạng tệp xmi. Mô hình thu được không những là cơ sở cho việc áp dụng các kỹ thuật kiểm chứng mô hình trong kiểm thử tự động mà còn là đầ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 trên mô hình. Ngoài ra, công cụ này còn đóng vai trò to lớn trong việc tự động hóa một số công đoạn của 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 và cho các nghiên cứu sau này.
Hướng phát triển tiếp theo của luận văn là nghiên cứu xây dựng và hoàn thiện công cụ. Phát triển công cụ với đầu vào là bản vẽ của biểu đồ tuần tự, kết hợp cùng với thuộc tính cần kiểm tra và xác định được tính đúng đắn của thiết kế. Đồng thời, công cụ hiện thực hóa cũng cần được cải tiến để có thể chạy với các bài toán lớn.
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 trong tin học, Nhà xuất bản 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 Black-
box 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
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.