Luận án tiến sĩ Công nghệ thông tin: Đặc tả và kiểm chứng từng phần cho phần mềm dựa trên biểu đồ tuần tự

GIỚI THIỆU

Mô hình của thành phần phần mềm

2.1.1 Hệ thống chuyển trạng thái được gán nhãn

Mỗi thành phần phần mềm được đặc tả bởi một mô hình dùng để biểu diễn các hành vi quan sát được của thiết kế ứng với các thành phần phần mềm Mô hình này được biểu diễn bằng hệ chuyển trạng thái được gan nhãn (Labeled

Transition System — LTS) Bảng chữ cái Ð là tập tất cả những hành động của thành phan phần mềm Act là tập tất cả những hành động quan sát được của thành phần phần mềm Hành động không quan sát được (hành động bên trong) của thành phần phần mềm được ký hiệu là r Một trạng thái đặc biệt của hệ thống - trạng thái lỗi ứng với các lỗi có thể xảy ra được ký hiệu là z Một hệ thống chuyển trạng thái được gán nhãn được định nghĩa như sau. Định nghĩa 2.1 (Hệ thống chuyển trạng thái được gán nhãn [58, 73, 25, 89])

LTS là một bộ gồm bốn thành phần (Q,aM,6,qo), trong đó: e Q là một tập khác rỗng hữu han các trang thái, e aM C Act là tập các hành động quan sát được, gọi là bang chữ cái của M, © 5 CQxaM U{r} x Q là hàm chuyển trạng thái, va

Hình 2.1: Một hệ thống chuyển trạng thái được gán nhãn. ® qo € Q là trạng thái bắt dau.

Kớ hiệu g; + q; khi hành động với nhón a chuyển hệ thống từ trạng thỏi ứ đến trạng thỏi ạ;, lic đú (ứ, a,g;) € 5 Nghia là khi hệ thống ở trạng thỏi g;, nếu thực hiện một hành động a thì chuyển sang q; Tương tự, hệ thống dang ở trạng thái qj nêu thực hiện một hành động a’ chuyển tới trạng thái q, Khi đó, ta được một dãy các hành động q¡ + qj + ge [25].

Một cách tổng quát, nếu ta có một chuỗi các hành động q¡ — +; gy biểu diễn hệ thống thỡ khi nú ở trạng thỏi ứ nú cú thể thực hiện một chuỗi cỏc hành động àaa a„ và kết thúc ở trạng thái qq.

LTS Il = ({r}, Act, 6,7) là một LTS chỉ chứa trạng thái lỗi của hệ thống [25].

Xét một LTS M =(Q,aM, ð, go) vig, € Q, a,a; € aM, với 1 ,ô,qo, #) là một NFA

Output: M’ = (Q’,&’, 6’, q, F’) là DFA tương đương

3 for mỗi ky tự đầu vio c duyệt từ trái qua phải R do

6 switch Nếu các phan tử trên cùng của stack là mot trong các trường hop sau, thay thế chúng theo các trường hợp tương ứng do

7 case \ do thay thế bằng N) theo Công thức (3.1)

8 case a là một ky hiệu trong bang chữ cái do thay thé bằng N„ theo Cong thức

9 case N;|Nx do thay thế bằng Nj\x sử dung Cong thức (3.3)

10 case Nj; Nx do thay thế bằng Nj sử dung Công thức (3.4)

11 case W; * do thay thế bằng Nj sử dụng Công thức (3.5)

12 case (N;) do thay thế bằng Nz

18 otherwise do kết thiicReduction các bước

15 until cho đến khi không áp dung được nữa

V CQ, ta cần tính ð(V,a), Va € 3. domain E = {z: Ay | [x,y] € E} (3.6)

E[S] = {y: 3z € S | [x,y] € E} E(S) gọi là anh của S (3.7) Dat frontier(X) là tập các lá của một cây mà gốc là X Ta có các công thức sau:

I_image(V) = lép|F_domain(V)| (3.9) ôpg(V,>) = {z: dục T_ image(V)|z € frontier(y)} (3.10)

Với mỗi a € Ð, ta có: dr(V,a) = {4€ ôn(V,3) | A(q) = a} (3.11)

Bây giờ ta đã có biểu diễn đầy đủ của ôtômát đuôi tương đương của R Dé sinh mô hình cho thành phần phần mềm đã cho, ta áp dụng Công thức (2.4) để xây dựng MYNNEA và tạo ra các mô hình phần mềm cần thiết. Độ phức tạp: Biểu thức chính quy R có độ dài là r, và có s lần xuất hiện của cỏc kớ tự trong bảng chữ ứ, ta cú thể tớnh toỏn CNNFA trong thời gian O(r) với bộ nhớ sử dụng là O(s) [18].

3.4.5 Tối ưu hóa mô hình

Kết quả của phương pháp sinh mô hình trình bày trong 3.4 là mot NFA nói chung, biểu diễn các hành vi của các thành phần cho trước NFA là DFA trong trường hợp mỗi kí tự trong bảng chữ cái chỉ xuất hiện đúng một lần trong biểu thức chính quy Tuy nhiên điều này khó xảy ra, kết quả của CNNFA là NFAs.

Do đó, ta cần thực hiện các công việc tối ưu hóa mô hình thu được để có thể có mô hình tốt nhất đặc tả cho thành phần phần mềm đã cho Có hai việc cần làm là đơn định hóa NFA thành DFA và tối thiểu hóa DFA thu được.

Chuyển đổi NFA sang DFA

Trong phan này, ta sử dụng thuật toán trong [27] để chuyển đổi NFA sang

DFA tương ứng Cho một NFA M = (Q,%,6,q0,F), thuật toán tạo ra DFA M' =(Q',5M',ð,a.P”) Một DFA 1M“ được xây dựng như sau. © 2 C22, q = {ao}, F’ = {ự e@l/nP #0}, và e 0’ dược định nghĩa như sau: 6'(q',a) = U ¿eyð(4 4), với g' € Q’.

Chi tiết được nờu trong Thuật toỏn 11 Dau tiờn, thuật toỏn thiết lập ứ' = {qo},

Q = {qo} (dũng 2) Đặt ứ' là một phần tử của Q’ (dũng 4) Nếu nú chưa được đỏnh dấu, thuật toỏn tỡm những trang thỏi mà được chuyển từ trạng thỏi ứ bằng các kí tự của bang chữ cái © và thêm những trạng thái này vào Q’ nếu nó chưa ở trong Q’ (từ dòng 5 tới dòng 12) Sau đó, thuật toán đánh dấu trang thái q’ (dòng 14) Quá trình xử lý từ dòng 4 tới dòng 14 được lặp lại cho đến khi không còn phan tử mới nào được thêm vào Q’ Khi đó, tập các trạng thái đoán nhận F’ được tính toán từ phan tử của Q’ mà có chứa trạng thái đoán nhận của

NFA (dòng 16). Độ phức tạp của thuật toán: Với n là số các trạng thái cha NFA M Độ phức tap của Thuật toán 11 là O(n?2").

Algorithm 11: Chuyển đổi từ NFA sang DFA tương đương

Input : M = (Q,>,ô,qo, F) là một NFA

Output: M’ = (Q’,&’,6’,q, F’) la DFA tương đương

5 if q’ không được đánh dấu then

6 for i := 1 to length oƑƒ3) do

15 until không có phan tử mới nào thêm vao Q’

Trong hầu hết các trường hợp, mô hình phần mềm DFA nhận được từ thuật toán trình bày trong Thuật toán 11 là không tối thiểu Vì vậy, ta phải tối thiểu nó để có những mô hình mới và tối ưu Trong phần này, ta sử dụng Thuật toán Hopcroft [45, 27, 46] Cho mot DFA M = (Q,5,ð,qo,F), thuật toán tối thiểu tương đương DFA A = (Q',5#',ổ,q¿,P”) Một vết x € #* phân biệt hai trạng thái p,q € Q’ nếu hoặc ổ(p,z) € F va ð(qg,z) ¢ F hay ô(p,z) ¢ F và ô(qg,z) € F.

Công cụ hỗ trợ và thực nghiệm

Nhằm chứng minh tính đúng đắn và hiệu quả của phương pháp đề xuất, một công cụ đã được xây dựng để mô phỏng cho phương pháp được đề xuất nhằm giảm độ phức tạp so với các nghiên cứu hiện tại Phương pháp đề xuất bao gồm hai quá trình chính là chuyển đổi biểu đồ tuần tự về mô hình đặc tả hành vi và kiểm chứng tích hợp các thành phần Các thiết kế của các thành phần phần mềm được mô tả dưới dạng biểu đồ tuần tự Công cụ đã được xây dựng bằng ngôn ngữ lập trình JAVA mô phỏng cho phương pháp đề xuất Đầu vào của công cu là thiết kế được biểu diễn bởi biểu đồ tuần tự của các thành phần được lưu

Sequence diagrams (xmi, xml) Safety properties | Assumption + cex

Hình 3.13: Kiến trúc công cu sinh mô hình và kiểm chứng tính đúng đắn thiết kế cho các phần mềm dựa trên thành phần. dưới dạng tệp XML Trong công cụ sẽ có một thành phần (Regex generation) phân tích tệp XML và bóc tách biểu đồ đã cho thành các đối tượng riêng biệt để cho ra một biểu thức chính quy tương ứng đặc tả hoạt động của thiết kế Biểu thức chính quy tại bước trên được cung cấp làm đầu vào cho quá trình sinh mô hình (Model generation)dưới dang LTS áp dụng thuật toán CNNFA Các thành phần được mô tả dưới dang LTS cùng với thuộc tinh p (Safety properties) sẽ là đầu vào cho phương pháp kiểm chứng giả định - đảm bảo (AG-Verification) Nếu thiết kế đáp ứng các đặc tính, giả định được trả về Nếu không thỏa mãn, một phản ví dụ sẽ được trả về Hình 3.13 mô tả kiến trúc của công cụ của phương pháp đề xuất.

3.6.2 Thực nghiệm và đánh giá phan sinh mô hình

Uu nhược điểm của phương pháp sinh mô hình CNNFA sẽ được thể hiện rõ khi so sánh với hai phương pháp sinh mô hình trong |43, 27] tác giả đã cài đặt công cụ tạo mô hình có tên là MG! để tiến hành thực nghiệm, so sánh với các phương pháp đã có Trong khi làm thực nghiệm, tác giả sử dụng cùng một tập dữ liệu được dùng xây dựng mô hình trong [27] Dữ liệu cho một số hệ thống điển hình được trình bày trong [73] (tức là, các thành phần gửi, các thành phần điều khiển của hệ thống Cruise Control và thành phan Jitter ) Các thực nghiệm được tiến hành trên một máy tính bình thường với bộ xử lý Intel (R) Core (TM) 13-2120 CPU @ 3.30GHz, 3300MHz, 2 Core(s), 4 bộ xử lý logic(s), tổng số bộ nhớ vat lý 3.40GB, và hệ điều hành Microsoft Windows 7 Ultimate Số các ký hiệu trong bang chữ cái |5| và một lượng lớn các vết trong ngôn ngữ L trong

†httEp://www.uet.vnu.edu.vn/~hungpn/MG

Bảng 3.2: Dữ liệu thực nghiệm

No | Id | Các hệ thống đã áp dụng | |5| | |7|

5 S5 sender-len9 3 9 cột |L| được thể hiện trong Bảng 3.2.

Bảng 3.3: Kết quả thực nghiệm so sánh phương pháp đề xuất với phương pháp ⁄

Id Jol] || || ð| | | Mel ôn |[Thời gian| Bộ nhớ | |A⁄| | |6| | |p| | lôn |Hhời gian| Bo nhớ 51|8| 136 |155| 11 |12| 00.089 | 771,630 |114|113| 11 | 12 | 00.049 | 568,926 52|9|133 |150| 11 |17| 0.079 | 761,366 |113|112| 11 | 17 | 0.066 | 735,675

Bang 3.4: Kết quả thực nghiệm so sánh phương pháp đề xuất với L*-based method

Id |[o|| |Z] || 6] | |r| Sr|Thsi gian| Bộ nhớ | |M|| |6| | |Mrl| lầm |Thời gian| Bộ nhớ

5316 - | - - - - Out |1188}1187) 42 | 49 | 42.168 4,226,692 S418} - | - - - - Out | 172/171} 19 | 18 | 0.074 | 925,113 55|9| 5 |lỗ| 4 | 4] 0.065 (4,477,565 46 | 45) 10 9 | 00.005 | 163,659 Để có kết qua thực nghiệm thể hiện trong các Bảng 3.3 và Bang 3.4, tác giả đã tiến hành thí nghiệm 20 lần cho mỗi hệ thống áp dụng và cho các phương pháp sinh mô hình phần mềm Kết quả thực nghiệm thể hiện trong các Bảng

3.3 và 3.4 là mức trung bình của 20 lần chạy thực nghiệm ở trên Bảng 3.3 và 3.4 chứa các thông tin sau: Chiều dài tối đa của vết cho hai phương pháp sử dụng

L* và thuật toán Thompson trong cột gọi là |ơ|, kích thước của các mô hình tạo ra sau khi áp dụng L*, Thompson and CNNFA thể hiện trong cột |A/p|, số các chuyển trạng thái trong mô hình được thể hiện ở cột |ð|, kích thước của các mô hình tối ưu cuối cùng thể hiện trên cột |A⁄p|, số các chuyển trang thái của các mô hình tối ưu cuối cùng thể hiện trên cột |ôp|, thời gian tính bằng giây dùng để sinh mô hình tối ưu cuối cùng của mỗi phương pháp được thể hiện trên cột thời gian (giây), bộ nhớ tính theo byte được cấp phát cho mỗi phương pháp trong khi sinh mô hình được thể hiện trên cột Bộ nhớ (bytes) Trong các kết quả thu được “Out” có nghĩa là “tràn bộ nhớ” Thực nghiệm trên cho thấy phương pháp đề xuất là hiệu quả.

Từ các kết quả thực nghiệm, tác giả có các ý kiến sau: e Phương pháp đề xuất nhanh hơn nhiều so với hai phương pháp L* và

Thompson e Phương pháp dé xuất không bị giới han bởi chiều dài của các chuỗi của các hành động của các thành phần phần mềm như trong các phương pháp được đề xuất trong [43, 27]. e Phương pháp đề xuất sử dụng ít bộ nhớ hơn so với phương pháp sử dung thuật toán L* Nó sử dụng ít bộ nhớ hơn so với phương pháp sử dụng thuật toán Thompson với dữ liệu thử nghiệm nhỏ Với dữ liệu thử nghiệm lớn, nó sử dụng nhiều bộ nhớ hơn so với phương pháp sử dụng thuật toán

Thompson. e Kích thước của các mô hình được tao ra bằng cách sử dung thuật toán L* là nhỏ gọn hơn so với các mô hình tạo ra bằng các thuật toán Thompson và CNNEA.

Trên đây trình bày phương pháp hiệu quả để sinh các mô hình cho phần mềm dựa trên thành phần bằng cách sử dụng thuật toán CNNFA, phương pháp đề xuất không chỉ độc lập về độ dài tối đa của vết từ các hành động của các thành phần nhưng vẫn có thời gian nhỏ hơn và không gian phức tạp so với các phương pháp đề xuất trong [43, 27] Các mô hình được tạo ra đều tối thiểu và mô tả hành vi tương ứng của các thành phần của phần mềm cần kiểm chứng Các kết quả thực nghiệm chỉ ra rõ sự hiệu quả của phương pháp đề xuất Vì vậy, phương pháp này làm cho các phương pháp tiếp cận dựa trên mô hình cao hơn được Ap dụng thực tế.

Tác giả đang khảo sát để áp dụng phương pháp này cho một số phần mềm thực tế để cho thấy hiệu quả của nó Đồng thời, đang nghiên cứu một phương pháp tổng thể để tạo ra biểu thức chính quy hoàn toàn tự động từ các tài liệu thiết kế Đây là công việc cần thiết để cung cấp đầu vào là các mô hình cho các phương pháp kiểm chứng được đề xuất tiếp theo Vấn đề khó khăn là làm thế nào để tích hợp phương pháp này cùng với một phương pháp kiểm chứng mô hình để cung cấp một giải pháp tổng thể để kiểm chứng mô hình cho các thành phần phần mềm từ các tài liệu thiết kế.

3.6.3 Thực nghiệm và đánh giá phần kiểm chứng giả định - đảm bảo Để khẳng định sự đúng đắn và khả thi của phương pháp, luận án thực hiện các công cụ để hỗ trợ cho các thử nghiệm của một số hệ thống trong [73] có chứa các khối phổ biến trong biểu đồ tuần tự UML 2.0 cho đến khi tạo ra các giả định tương ứng Thời gian sinh các biểu thức chính quy được thể hiện trong

Bảng 3.5: Thời gian sinh các biểu thức chính quy

Stt | Hệ thống Thời gian (ms)

Tác giả tiến hành kiểm tra quá trình sinh mô hình bằng cách sử dụng ba thuật toán L*, Thompson và CNNFA Thời gian sinh các biểu thức chính quy từ ba phương pháp được thể hiện trong Bảng 3.6 Kích thước của mô hình được tạo ra thể hiện trong các cột |A⁄| Các cột |6| cho biết số lượng chuyển trang thái

61 trong các mô hình tạo ra Thời gian được tạo ra (tính theo mili giây) được hiển thi trên cột Time(ms) Các mazlength được sử dụng trong trường hợp sinh mô hình dùng thuật toán L* được hiển thị trên cột M Len “Out” trong cột Time(ms) được hiểu là hết bộ nhớ, đây là trường hợp phương pháp không tạo ra được mô hình khi sử dụng thuật toán tương ứng.

Bảng 3.6: Thời gian sinh mô hình

Stt | Dữ liệu kiểm tra i Tompson CNNFA

|M| | lô| | MLen | Time | |M| | |6| | Time | |M| | lôi | Time

Bang 3.7: Kết qua sinh giả định

No | Hệ thống Kết quả kiểm chứng Thời gian (ms)

4 Mod _ channel in.send.send.in 00.54

Tw Bang 3.6, chúng ta có các nhận xét sau: e Sử dụng các thử nghiệm của hệ thống, quá trình sinh ra mô hình sử dụng

Thuật toán Thompson là nhanh hơn so với hai phương pháp sử dụng L* và phương pháp dùng CNNFA. e Với hệ thống lớn (GasOverControler), sử dụng thuật toán L* khong thé tạo ra mô hình của hệ thống do tràn bộ nhớ. e Sử dụng thuật toán L* để sinh mô hình của hệ thống bị giới hạn bởi chiều đài mazlength của vét được đón nhận bởi các mô hình.

Thời gian của quá trình sinh giả định được thể hiện trên Bảng 3.7 cho thấy thời gian sinh biểu thức chính quy là nhanh.

Về tính đúng đắn của phương pháp đề xuất, tính đúng đắn và tính dừng của phương pháp kiểm chứng giả định - dam bảo đã được chứng minh trong [25, 78]. Tinh đúng đắn của phương pháp sinh mô hình từ biểu đồ tuần tự chưa được chứng minh về mặt lý thuyết mà chỉ dựa trên cơ sở thực nghiệm với một số hệ thống điển hình Với mỗi ví dụ áp dụng, chúng tôi sử dụng phương pháp song mô phỏng để chạy từng bước của thuật toán và so sánh kết quả đạt được với kết quả mong muốn Với các ví dụ áp dụng hiện nay, các kết quả thu được từ quá trình song mô phỏng đều chính xác Tương tự với công cụ cài đặt, chúng tôi cũng tiến hành quá trình song mô phỏng với các ví dụ này và cho kết quả tương tự Tác giả đang nghiên cứu các giải pháp để chứng minh tính đúng đắn của phương pháp đề xuất về mặt lý thuyết.

Giới thiỆU Q0 ng nh vn ene e eee x xà 65 4.2 Các nghiên cứu liên quan - -cccccccssS 67 4.3 Phân tích biểu đồ tuần tự thành các khối đơn

Như đã mô tả ở chương 3, việc chứng minh tính đúng đắn của thiết kế nói chung và biểu đồ tuần tự nói riêng là bài toán quan trọng trong quy trình phát triển phần mềm, đặc biệt là đối với các sản phẩm có yêu cầu chất lượng cao. Một trong những giải pháp phổ biến được biết đến để giải quyết vấn đề này là áp dụng phương pháp kiểm chứng mô hình [23] Dé áp dụng được phương pháp này, điều kiện tiên quyết là phải xây dựng được các mô hình đặc tả hành vi của hệ thống Một trong những hướng tiếp cận quan trọng để giải quyết vấn đề nêu trên là tự động xây dựng mô hình và kiểm chứng tính đúng đắn của các thiết

65 kế được đặc tả bằng biểu đồ UML - một trong những tài liệu thiết kế phổ biến ở các công ty phần mềm.

Hiện nay, đã có nhiều nghiên cứu đề xuất các phương pháp sinh mô hình tự động và tiến hành kiểm chứng dựa trên các biểu đồ UML [3, 40, 43, 57, 59, 67,

68, 76, 59, 85, 90] Trong đó, phần lớn các nghiên cứu về sinh mô hình của biểu đồ tuần tự thường mới chỉ áp dụng cho các phiên bản UML cũ Với các nghiên cứu trên UML 2.0 thì phần lớn chưa xử lý được toàn bộ các khối đơn (fragment) và khối lồng ghép (combined fragment) mà chỉ tập trung vào các khối cơ bản

(khối lặp, khối rẽ nhánh) Các nghiên cứu [43, 59] làm việc trên biểu đồ tuần tự UML 2.0 đã đưa được ra phương pháp chuyển đổi biểu đồ tuần tự về một máy chuyển trạng thái đặc tả toàn bộ hành vi của hệ thống Tuy nhiên, các giải pháp này chưa hỗ trợ đầy đủ các khối đơn và các khối lồng ghép Hơn nữa, hạn chế của việc đặc tả toàn bộ biểu đồ tuần tự trên một máy hữu hạn trạng thái là làm phẳng biểu đồ tuần tự Các giải pháp này vô hình chung làm mất đi tính tương tác giữa các đối tượng (ví dụ, mất quá trình gửi/nhận sự kiện giữa các đối tượng) trong thiết kế Các tác giả trong [68] có đề xuất một phương pháp chuyển đổi trực tiếp từ biểu đồ tuần tự sang ngôn ngữ PROMELA mà không sử dụng mô hình trung gian Hướng tiếp cận này chỉ đáp ứng được việc kiểm chứng biểu đồ tuần tự trên một công cụ kiểm chứng cụ thể là SPIN Trong thực tế, việc sinh mô hình cho biểu đồ tuần tự giúp cho quá trình kiểm chứng có thể được sử dụng trên nhiều công cụ kiểm chứng với các đặc tả khác nhau Hơn nữa, mô hình được sinh ra còn có thể được sử dụng lại cho nhiều mục đích khác (vi dụ, kiểm thử dựa trên mô hình) Dé khắc phục những van đề trên, nghiên cứu trong [90] đã đề xuất một cách tiếp cận mới nhằm sinh mô hình cho các đối tượng trong biểu đồ tuần tự bằng cách sử dụng các ôtômát vào/ra Tuy nhiên, nghiên cứu này chưa hỗ trợ đầy đủ các khối đơn và đặc biệt là các khối lồng ghép Tuy vậy, các nghiên cứu trong [90] chỉ dừng lại ở bước sinh mô hình, chưa sắn liền với một công cụ kiểm chứng cụ thể Trong thực tế, chưa có một công cụ kiểm chứng nào hỗ trợ kiểm chứng trực tiếp các ôtômát vao/ra.

Mặc dù đã có nhiều nghiên cứu quan tâm giải quyết vấn dé đặc ta va kiểm chứng tính đúng đắn của thiết kế phần mềm dựa trên thành phần Tuy nhiên, các vấn đề sau vẫn còn là các bài toán mở và chưa có giải pháp thỏa đáng Với các nghiên cứu trên UML 2.0 thì phần lớn chưa xử lý được toàn bộ các khối đơn và khối lồng ghép mà chỉ tập trung vào các khối cơ bản Một số nghiên cứu chưa tách rời được việc sinh mô hình và kiểm chứng, chưa giải quyết được bài toán bùng no không gian trạng thái.

Nghiên cứu này đề xuất một phương pháp giải quyết các vấn đề trên bằng

66 cách chuyển đổi các đối tượng trong biểu đồ tuần tự UML 2.0 sang các tiến trình

PROMELA để sử dụng công cụ kiểm chứng SPIN nhằm kiểm chứng tính đúng đắn của biểu đồ tuần tự Ý tưởng chính của phương pháp là phân tích cấu trúc của biểu đồ tuần tự, từ đó chuyển đổi các đối tượng trong biểu đồ tuần tự sang ôtômát vào/ra Các ôtômát vào/ra này tiếp tục được chuyển đổi thành các các tiến trình PROMELA Các tiến trình này được sinh ra cùng với thuộc tính cần kiểm chứng đặc tả dưới dạng logic thời gian tuyến tinh (Linear Temporal Logic

- LTL) sẽ làm đầu vào cho công cụ kiểm chứng SPIN Giải pháp này được tích hợp với kết quả nghiên cứu trong [90] để có được một quy trình hoàn chỉnh cho việc đặc tả và kiểm chứng tính đúng đắn của các biểu đồ tuần tự.

4.2 Các nghiên cứu liên quan

Hiện nay, có nhiều phương pháp của các tác giả cùng nghiên cứu về kiểm chứng tinh đúng đắn trong thiết kế dựa trên biểu đồ UML như [43, 59] Với nghiên cứu [59], nhóm tác giả đã đề xuất phương pháp chuyển đổi biểu đồ tuần tự thành một ôtômát trạng thái đặc tả toàn bộ hành vi của hệ thống và tiến hành kiểm chứng sử dụng SPIN Tuy nhiên, phương pháp này chưa xử lý được đầy đủ các khối đơn trong UML 2.0 Nghiên cứu trong [43], các tác giả đã đưa ra hướng nghiên cứu sử dụng biểu thức chính quy làm bước trung gian để sinh mô hình, sau đó tiến hành kiểm chứng bằng phương pháp giả định - đảm bảo

(assume-guarantee verification) [25] Tuy nhiên, các mô hình thu được là không đơn định, và việc tối ưu đòi hỏi nhiều quá trình phức tạp, chi phí thực hiện cao và chỉ kiểm chứng được với các thuộc tính an toàn Các nghiên cứu [43, 59] dùng một mô hình biểu diễn toàn bộ hành vi của hệ thống dẫn đến làm mất tính tương tác giữa các đối tượng trong biểu đồ tuần tự (ví dụ, mất sự tương tác gửi/nhận giữa các đối tượng). Để giải quyết van đề trên, một hướng tiếp cận khác được trình bay trong [90]. Trong các nghiên cứu này, từng đối tượng trong biểu đồ tuần tự được đặc tả hành vi bằng các ôtômát vào/ra Sự tương tác giữa các đối tượng được thể hiện bằng các sự kiện gửi/nhận trong từng ôtômát Tuy nhiên, nghiên cứu trong [90] chưa xử lý hết các khối và trường hợp các khối lồng ghép phức tạp với nhau. Trong nghiên cứu này tác giả đã hỗ trợ hầu hết các khối đơn trong UML 2.0 và xử lý trường hợp các khối lồng ghép Tác giả của nghiên cứu [68] trình bày một phương pháp chuyển đổi trực tiếp từ biểu đồ tuần tự sang PROMELA. Trong phương pháp này, mỗi đối tượng trong biểu đồ tuần tự sẽ được chuyển thành một tiến trình, quá trình gửi/nhận sự kiện được thể hiện bằng các câu

67 lệnh PROMELA Phương pháp này có thể khắc phục hạn chế của các nghiên cứu nêu trên Tuy nhiên, tác giả chưa đưa ra được cách thực hiện cụ thể và xử lý trường hợp các khối lồng ghép Mặt khác, việc chuyển đổi trực tiếp không sử dụng mô hình làm cho phương pháp này thiếu tính linh hoạt, chỉ áp dụng được đối với SPIN mà không áp dụng được đối với các công cụ kiểm chứng khác Hơn nữa, kết quả thu được chỉ giải quyết bài toán kiểm chứng, không tái sử dụng được tại các pha khác trong quy trình phát triển phần mềm.

Bên cạnh biểu đồ tuần tự, nhiều tác giả đã đưa ra nghiên cứu về việc kiểm chứng các dạng biểu đồ UML khác Nghiên cứu [40] và các nghiên cứu [57, 67,

76, 83, 85] đã trình bày phương pháp chuyển đổi biểu đồ hoạt động và biểu đồ chuyển trạng thái sang PROMELA Những công trình nêu trên có thể kết hợp với nghiên cứu trong nghiên cứu này để áp dụng trong thực tế, khi thiết kế được biểu diễn bằng nhiều loại biểu đồ khác nhau.

4.3 Phân tích biểu đồ tuần tự thành các khối đơn

Một biểu đồ tuần tự bao gồm nhiều đối tượng và mỗi đối tượng có nhiều khối đơn lồng ghép với nhau Việc bóc tách một đối tượng của biểu đồ tuần tự thành các khối đơn là rất cần thiết Các khối đơn sau khi được bóc tách sẽ là đầu vào cho việc chuyển đổi sang ôtômát vào/ra sẽ được trình bày ở phần 4.4 Phần này của nghiên cứu đề xuất thiết kế được biểu diễn bởi biểu đồ tuần tự của các đối tượng dưới dạng tệp XML Công cụ được xây dựng phát triển để đọc tệp XML và tách thành các khối đơn của biểu đồ tuần tự.

4.3.1 Định dạng của đầu vào biểu đồ tuần tự

Các quy tắc viết tệp XML được quy định như Hình 4.1 Chi tiết của các quy tác khi viết tệp XML được mô tả như sau. e Cap thé bao ngoài cùng là và < /Sequence>, e Cặp thẻ bao tiếp theo là < /Object> bao gồm id, name và trường type = “Object”, e Tiếp theo là Event hoặc fragment e Event : Event: Gồm trường id, type=”event“, name=“tên message” và event Type= “send” hay “receive”, e Gồm trường id, type = ‘combined frament’, operator (operator có các giá trị là alt, loop, par, v.v.)

pT TTT Tre eee 1 Y

| id, name, type, ! eventType h mm 1 | id, type, 1

Hình 4.1: Biểu diễn của biểu đồ tuần tự bởi tệp XML. e Operand: Bắt buộc phải nằm trong Fragment và ngay sau khai báo thẻ fragment, bao gồm id, type=“operator” (nếu là phân đoạn Consider hoặc Ignore thi operand nằm ngay sau khai báo ), e Constraint: Gồm trường value, trường này chứa tên các message cách nhau bởi dấu cách, ví dụ: Thẻ này đặt giữa 2 thẻ fragment và operand, được dùng để 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, e Event nằm trong sequence hoặc trong operand, không nằm trực tiếp trong fragment, va e Message: Chi nằm trong sequence, không nằm trong operand hoặc fragment, gom trudng id, type=“message”, name=“tén message”, sendEvent va 1a id của event đầu, receiveEvent là id của event cuối.

Ví du 4.1 Thiết kế của biểu đồ tuần tự thể hiện như Hình 4.2 được đưa vé định dang tệp XML như Hình 4.3 để làm đầu uào của thuật toán xử ly biểu đồ tuần tự.

4.3.2 Phân tích biểu đồ tuần tự thành các khối đơn

Sinh mô hình từ các khối đơn của biểu đồ tuần tự

Sau khi đã bóc tách mỗi đối tượng của biểu đồ tuần tự thành các khối đơn tương ứng, phần này trình bày phương pháp sinh ôtômát vào/ra từ các khối đơn, khối chỉ chứa nhiều nhất một phân đoạn của biểu đồ tuần tự [90] Nghiên cứu xây dựng thuật toán chuyển đổi sang ôtômát vào/ra từ các khối đơn chứa một trong chín loại phân đoạn sau: Option, Alternative, Loop, Break, Parallel, Strict, Critical, Consider, Ignore va trường hợp khối không chứa bat ki phân đoạn nào. Đầu vào của thuật toán là các khối đơn của biểu đồ tuần tự được mô tả bằng một bộ sáu SD = (E,FG,OP,C,nưm, frag), trong đó: e Ƒ là tập các sự kiện BE = EU E9, e Ƒ! là tập các sự kiện nhận, e Ƒ là tập các sự kiện gửi, e FG là tập các phân đoạn, trường hợp khối don, FG chứa nhiều nhất một phần tử, e OP là tập các Operand, e € là tập các điều kiện C = {e1,ea, cz}, e num là danh sách các số thứ tự của event từ 0 đến n, và e frag là một hàm chuyển từ E đến F. Đầu ra của thuật toán là một ôtômát vào/ra tương ứng được mô tả bằng một bộ sáu @' = (Q, 32”, 527, 6,40, F), trong đó: ® Q= {4i,4a, qn} là tập các trạng thai,

73 ° yy = {(c,e)|c € C,e € E1} là tập các ký tự vào, e S2 = {(c,e)|c € C,e€ EO} là tập các ký tự ra, ôố=Qx(ỉx E) > Q là tập cỏc luật chuyển ð(q, (c,e)) = đj; e đo là trạng thái khởi đầu, va e F={fi, fo, fm} là tập trạng thái kết thúc. Ôtômát vào/ra đầu ra được xây dựng bởi các quy tắc như sau [90]: e Số lượng các trạng thái trong ôtômát chính bằng số lượng sự kiện trong SD:

|Q\=|E| va Q = {đI 92, On} e Tập các điều kiện của ôtômát tương ứng là C = {cle € C} e Tập các sự kiện của ôtômát tương ứng là tập sự kiện của SD: = {ele € E} e Tập các kí tự vào của ôtômát được xác định: SX’ = {(c,e)|e € C,e € El} e Tập các kí tự ra của ôtômát được xác định: s0 ={(c,e)|lc€ Cre € E0} e Tập các luật chuyển 6 và F được xác định bởi các trường hợp (từ Thuật toán 14 đến Thuật toán 23)

4.4.1 Thuật toán xác định tập các luật chuyển 5 cho ôtômát vào/ra từ khối đơn không chứa phân đoạn nào

Trường hợp này, các khối đơn của biểu đồ tuần tự không chứa một Fragment nào Khi có E = {ele € E} và C = {c|c € Œ}, tập các trạng thái kết thúc F được xác định F = {qn} 6 được xác định bởi Thuật toán 14 Tap các quy tắc chuyển trạng thái của ôtômát vào/ra sẽ được sinh ra bằng cách thêm lần lượt với mỗi i từ 0 đến |E|-1 (dòng 2, 5) các quy tắc ðj=(rue,e;) (nghĩa là 5(qi, (true, ej)) = qj, từ trạng thỏi ứ khụng cú điều kiện sẽ chuyển sang trạng thỏi qj với sự kiện e;) với j= i+1 (dòng 3). Độ phức tạp của thuật toán: Với n là số lượng các sự kiện Độ phức tạp của Thuật toán 14 là O(n).

4.4.2 Thuật toán xác định tập các luật chuyển 6 cho ôtômát vào/ra từ khối đơn chỉ chứa phân đoạn Option

Trường hợp này, khối đơn của biểu đồ tuần tự chứa duy nhất một phân đoạn

Option Sau khi có E = {ele € E} và C = {cle € C}, tập các trạng thái kết thúc

Algorithm 14: Thuật toán xác định tập các luật chuyển ổ cho ôtômát vào /ra từ khối đơn không chứa phân đoạn nào

Input: Khối đơn của biểu đồ tuần tự không chứa phân đoạn nào

Output: Tập các luật chuyển ổ cho ôtômát vào/ra từ khối đơn không chứa phân đoạn nào

F dược xỏc định F = {q„}U {ứĂ|e¿  FG and e¿‡Ă € FG and e, € FG}, 6 được xác định bởi Thuật toán 15 Tap các quy tắc chuyển trạng thai 5 của ôtômát

Algorithm 15: Thuật toán xác định tập các luật chuyển ổ cho ôtômát vào/ra từ khối đơn chỉ chứa phân đoạn Option

Input: Khối đơn của biểu đồ tuần tự chứa duy nhất phân đoạn Option

Output: Tập các luật chuyển ổ cho ôtômát vào/ra từ khối đơn chỉ chứa phân đoạn Option

4 if e; ¢ FG or e;-1 € FG then set 5! =(true, ej)

5 if e;-1 € FG and e; € FG then set &=(e, €;)

7 if j