1. 4 Cấu trúc khóa luận
4.3 Kiểm chứng giao thức:
Giả thiết cần kiểm chứng biểu đồ như trong hình 9.Việc kiểm chứng giao thức sẽ làm được những việc sau :
- Kiểm tra xem mã nguồn chương trình có thực hiện tuần tự các phương thức như trong thiết kế của biểu đồ trình tự hay không: Từ thiết kế trên, khi ta viết mã chương trình thì chương trình phải tuân thủ các nguyên tắc trong bản thiết kế trên như: phương thức void message1() phải được gọi trước phương thức void message2(), phương thức void message2() gọi trước phương thức void message4(). Trước void message2() thì phải gọi void message1() trước…
Để giải quyết vấn đề này bằng AOP ta đặt tên cho các trạng thái của chương trình khi chương trình thực thi bằng mã aspect. Ban đầu là trạng thái mở đầu(state_start), sau khi gọi 1 phương thức thì trạng thái sẽ bị thay đổi và được đánh dấu ở phương thức đó. Sau cùng là trạng thái kết thúc.
- Kiểm chứng xem mã nguồn có đáp ứng các ràng buộc nếu có không : Là việc xác minh các tiền điều kiện và hậu điều kiện được miêu tả trong biểu đồ tuần tự là đã được xác minh hay chưa. Trong hình 9 mô tả ràng buộc với phương thức void message2(). Trước khi gọi void message2() thì kiểm tra x=0 có đúng hay không. Sau khi gọi void message2() thì x>0 có đúng hay không. Việc kiểm chứng các ràng buộc như vậy là không khó khăn chỉ có điều khi ràng buộc thể hiện một cách phức tạp thì chúng ta phải viết tách các điều kiện ra thành từng điều kiện nhỏ để có thể kiểm chứng.
- Thông báo lỗi và chỉ ra lỗi trong đoạn cài đặt của chương trình: Khi có lỗi cài đặt được phát hiện thì mã kiểm chứng cho in ra dòng thông báo lỗi ở vị trí liên quan để người kiểm tra có thể dễ dàng sửa lại cho đúng.
41
Trường hợp Sequence diagram định nghĩa các combindedFragment thì việc kiểm chứng sẽ xác minh cả các combindedFragment mà có chứa điều kiện có được thực thi đúng không. Ví dụ như Loop là một combindedFragment, chương trình sẽ kiểm tra xem Loop có được thực hiện đúng không, về số vòng lặp, giao thức lặp….
Trong trường hợp không định nghĩa một CombindedFragment nào trong biểu đồ tuần tự thì việc kiểm chứng giao thức sẽ là kiểm chứng cài đặt trên sequence diagram. Tức là sẽ kiểm tra đơn thuần mã thực thi có thực hiện tuần tự như trong thiết kế biểu đồ tuần tự hay không.
Duyệt các trạng thái : Các trạng thái được đặt vào Enumeration và được duyệt lần lượt để đặt các trạng thái vào sau khi phương thức được gọi.
Chương 5 Xây dựng công cụ sinh mã từ máy trạng thái 5.1 Tổng quan về xây dựng công cụ sinh mã từ máy trạng thái.
Dựa vào cấu trúc của mã aspect tôi đã trình bày ở phần trên, tôi tiến hành phương pháp cài đặt mã aspect từ máy trạng thái. Mã aspect kiểm thử gồm các pointcut Việc cài đặt mã aspect bao gồm những việc sau đây :
- Lấy các thành phần cần sử dụng trong tài liệu XMI . - Duyệt các trạng thái từ FSM.
- Xác định số pointcut cần đặt vào. Số pointcut cần thiết bằng số lượng phương thức trong chương trình.
- Xác định các hành vi mà hệ thống cần thực thi, những điều kiện ràng buộc cho các giao thức. Trước khi gọi phương thức thì trạng thái của hệ thống phải ra sao, có những điều kiện gì đi kèm, sau khi gọi phương thức thì điều kiện ra sao. Trong bước này ta xác định các mã kiểm chứng Advice.
Sau khi xác định được các pointcut và advice, tổng hợp mã trên theo cấu trúc cú pháp của AspectJ.
5.1.1 Lấy các thành phần trong tài liệu XMI.
Truy xuất các đường đời (Lifeline)
Một đường đời trong tệp XMI được biểu diễn bởi phần tử có thẻ là <lifeline> trong đó có nhiều thuộc tính, ta chỉ quan tầm tới hai thuộc tính là id và name. Ta sẽ lưu hai thuộc tính này trong đó name thì ta chỉ quan tâm tới tên lớp (nhớ lại quy tắc tên một đường đời là objectName:ClassName ) tức là sau dấu hai chấm còn bỏ đi tên đối tượng.
Vì trong một biểu đồ có thể có nhiều đường đời có cùng tên lớp nhưng khác nhau tên đối tượng do vậy, mỗi khi ta truy xuất thêm một đường đời mới ta lại phải kiểm tra xem trước đó đã có đường đời nào cùng lớp với nó hay chưa nếu có rồi thì tên đối tượng sẽ được đặt theo quy tắc sau: object1, object2, …
Sau khi lưu hết các phần tử này, kết quả ta sẽ có được một dãy các đường đời đã vẽ trên biểu đồ.
Truy xuất các thông điệp (Message)
Một thông điệp được biểu diễn bởi phần tử có thẻ là <message> trong đó ta quan tâm tới thuộc tính id, name, sendEvent, receiveEvent và messageSort. Tên của thuộc tính ta sẽ chỉ lấy lại tên của phương thức còn bỏ đi phần tham số. Từ hai thuộc tính sendEvent
43
và receiveEvent, thông qua phần tử <fragment> mà có thuộc tính xmi:type= “uml:MessageOccurrenceSpecification ta sẽ tìm ra đường đời nguồn và đích của thông điệp đấy. Từ thuộc tính messageSort ta sẽ biết được thông điệp đấy thuộc loại nào trong bảy loại thông điệp đã nêu trên.
Kết quả ta sẽ thu được một dãy các thông điệp. Tuy nhiên có một vấn đề là thứ tự các thông điệp sẽ là thông điệp nào được vẽ trước sẽ có thứ tự trước chứ không theo thứ tự thông điệp bên trên sẽ có thứ tự trước. Do vậy ta phải dựa vào tọa độ của các thông điệp để sắp xếp lại danh sách các thông điệp theo đúng trình tự của chúng trên biểu đồ. Thủ tục thực hiện là ta phải tìm trong phần tử có thẻ <guiDiagramLink> id của thông điệp sau đó tính tọa độ rồi sắp xếp lại theo thứ tự các tọa độ. Cuối cùng ta sẽ có một dãy các thông điệp theo đúng thứ tự mong muốn.
Truy xuất các đoạn gộp( Combinded Fragment)
Các đoạn gộp chỉ có một Interaction Operand sẽ được truy xuất như sau. Giả sử với đoạn gộp có Interaction Operator là loop thì trong tệp XMI sẽ nằm trong phần tử có thẻ <fragment> mà có thuộc tính xmi:type=“uml:CombinedFragment” và thuộc tính interactionOperator= “loop”. Từ phần tử này ta sẽ lấy ra thuộc tính id và tìm trong phần diagrams xem phần tử <guiDiagramGuiLink> nào có thuộc tính guiLink_Element trùng với id của loop. Qua đó, loop sẽ có các tọa độ về vị trí, chiều cao, chiều rộng. Rồi ta sẽ tìm xem các thông điệp nào có tọa độ nằm trong loop thì sẽ lưu lại, đánh dấu thông điệp đầu tiên và cuối cùng bên trong loop. Ta cần lưu thêm thông điệp ngay sau loop mà không phải là một thông điệp trả lời vì cần thiết cho việc xây dựng máy trạng thái sau này.
Những đoạn gộp chỉ có một Interaction Operand khác như Option và Break cũng làm tương tự như với loop chỉ khác là ở thuộc tính interactionOperator bây giờ sẽ là “opt” hay “break”.
OPT
Break
Đối với những đoạn gộp có nhiều Interaction Operand như Alternative thì bước đầu tiên ta cũng làm tương tự như với bên trên với thuộc tính interactionOperator=“alt”. Sau đó khi lấy các tọa độ về kích thước thì ta phải lấy thêm tọa độ của các đường thẳng phân cách giữa các Interaction Operand. Từ đấy ta sẽ xác định các thông điệp bên trong đoạn
45
gộp thuộc về Operand nào, thông điệp nào là mở đầu và thông điệp nào là kết thúc Operand đó. Ngoài ra ta phải xác định thêm thông điệp đầu tiên không phải thông điệp trả lời sau đoạn gộp này.
5.1.2. Sinh mã Aspect từ biểu đồ tuần tự UML
Chúng ta tiến hành kiểm thử aspect để giải quyết bài toán với đầu vào là biểu đồ tuần tự UML dưới dạng file XMI. Máy trạng thái đã đọc được nội dung từ file XMI và lấy ra được một số thông tin. Nhưng để sinh ra mã nguồn kiểm thử tôi phải định nghĩa thêm một số phương thức quan trọng tương tác với các trạng thái của FSM là getBeforeState,
getCondition, getPreCon, getPos. getBeforeState lấy ra các trạng thái có thể tiến tới trạng thái cho trước,getPreCon lấy ra điều kiện trước, getPoss: lấy ra điều kiện sau,
getCondition lấy ra điều kiện cụ thể là gì. Ngoài ra cần định nghĩa hàm chuanhoa để sửa
lại hiển thị của các trạng thái và các phương thức cho đúng. Đặc biệt do trong biểu đồ tuần từ không cho phép đặc tả tiền điều kiện và hậu điều kiện một cách tường minh, vì vậy để giải quyết vấn đề này tôi sử dụng một thành phần khác trong biểu đồ tuần từ là Comment, nội dung trong thành phần này là để tôi định nghĩa các ràng buộc về tiền điều kiện và hậu điều kiện, lấy ra và sử lý các tiền điều kiện và hậu điều kiện là từ nội dung của thành phần comment này.
File kiểm chứng Aspect ta sẽ dùng :
- Before advice : Kiểm tra xem giá trị của biến state hiện thời có bằng giá trị của các trạng thái trước nó có thể chuyển trạng thái khi gọi phương thức hiện thời hay không. Mặt khác, kiểm tra các ràng buộc tiền điều kiện của phương thức. Nếu vi phạm thì sẽ báo lỗi.
- After advice: Đặt lại giá trị mới cho biến state sau khi thay đổi trạng thái được gọi. Thực hiện các phép kiểm tra hậu điều kiện, kiểm tra tính đúng đắn của giao thức.
5.1.3. Thuật toán sinh mã aspect được cài đặt như sau :
- Duyệt lần lượt tất cả các event (phương thức) trong FSM. Thiết lập trạng thái cho lần lượt mỗi khi một phương thức được gọi:
+ Sau khi gọi một phương thức, đổi trạng thái cho nó trong after advice.
+ Dùng before advice kiểm tra state trước nó có phải là các trạng thái có thể chuyển đến trạng thái hiện thời không. Bằng cách lấy tất cả các trạng thái có thể gọi đến phương thức hiện tại và so sánh với state hiện tại. Nếu sai thì báo lỗi.
-Lấy ra các precondition và pos-condition để kiểm chứng. Nếu sai với điều kiện trong precondition và pos-condition thì báo lỗi. Trước tiên ta phải lấy ra ràng buộc trong tài liệu XMI, và được lấy từ thành phần Comment. Commnent được biểu diễn trong tài liệu XMI là tag< ownedComment> mà có các thuộc tính là xmi:type = “uml:Comment” và thuộc tính body = “” chính là nội dung chúng ta cần quan tâm. Nội dung trong thuộc tính body chúng ta cần định nghĩa chính xác theo khuân mẫu : body = “pre/pos: condition:Message”.
Trong đó :
- pre/ pos : xác định kiểu của điều kiện là tiền điều kiện hay là hậu điều kiện. - Conditon : biểu diễn ràng buộc cụ thể là gì.
- Message: biểu diễn tên của thông điệp liên quan.
Như trong hình trên, thuộc tính body của ownComment là :pre:x=0:message2 có nghĩa: kiểu của điều kiện là tiền điều kiện(pre),điều kiện ràng buộc là x =0 và là tiền điều kiện trước khi gọi Message2.
Pos:x>0:message2 có nghĩa: kiểu của điều kiện là hậu điều kiện(pos), điều kiện ràng buộc là x>0 và là hậu điều kiện sau khi gọi message2.
- Vòng lặp (Loop) biểu diễn các giao thức cơ bản, ta cần sử lý vòng lặp nếu có. Các phương thức được đặt trong vòng lặp để thể hiện chúng được lặp bao nhiều lần. Đây là CombindedFragment chủ yếu để tạo ra các giao thức phức tạp. Việc kiểm chứng này ở mức đơn giản nhất là kiểm chứng tính đúng đắn ở một vòng lặp. Tức là kiểm tra xem trong vòng lặp đó số lần lặp, các phương thức lặp với tuần tự đó là phải chính xác.
47
Việc kiểm chứng giao thức AnBm có các vấn đề sau :
Thứ nhất Kiểm chứng việc thực hiện m lần gọi phương thức A và n lần phương thức B. Việc này được thực hiện dễ dàng bằng cách đặt 2 biến nguyên counta và countb, biến counta được tăng l sau khi gọi xong phương thức A, countb được tăng thêm 1 sau khi gọi phương thức B. Việc kiểm tra gọi n lần phương thức B chỉ được thực hiện khi đã gọi n lần phương thức A. after(): pc_A(){ counta=0; } after(): pc_B(){ countb=0; }
Thứ 2: Kiểm chứng việc gọi liên tiếp m lần phương thức A và liên tiếp n lần phương thức B. Việc này được thực hiện như sau, đầu tiên, gọi 2 biến checka và checkb, khởi tạo giá trị ban đầu cho 2 biến này = 0. Hai biến này được tăng lên 1 khi một phương thức bất kì được gọi. pointcut pc() : call(* *.*(*)); before() : pc() { checka++; checkb++; }
checka bằng 0 khi phương thức A được gọi, checkb bằng 0 khi phương thức B được gọi. after(): pc_A(){ checka=0; } after(): pc_B(){ checkb=0; }
Bằng cách này ta biết được sự liên tiếp khi gọi các phương thức A và B. Chỉ có ở vị trí khi bắt đầu gọi đến phương thức A, khi đó checka là khác 0, nhưng counta chắc chắn là bằng 0. Vì vậy nên khi counta bằng 0 và checka khác 0 thì vẫn đúng. Ngược lại couta khác 0 và checka khác 0 là sai.
System.out.println("Error");
result = false;
}
Biến boolean result được khởi tạo là true, biến này được gán bằng false khi các điều kiện không được thỏa mãn. Khi kết thúc chương trình, nếu biến result = true thì giao thức đã kiểm tra là đúng, ngược lại nếu result = false thì giao thức đã kiểm chứng sai.
Kiểm chứng tính đúng đắn trong biểu đồ tuần tự(Sequence diagram) Việc kiểm chứng biểu đồ tuần tự bao gồm :
- Kiểm chứng việc đặc tả trong biểu đồ tuần tự có đúng với khi cài đặt không. - Kiểm tra tính đúng đắn khi cài đặt, có cả tiền điều kiện và hậu điều kiện.
Việc kiểm chứng đặc tả trong biểu đồ tuần tự có đúng với đặc tả không là việc kiểm chứng việc gọi lần lượt các phương thức sao cho đúng đắn. Tuân thủ quy tắc trong khi cài đặt. Việc kiểm chứng này được thực hiện bằng thuật toán sau đây :
- Đặt các biến state nguyên là biến trạng thái. Trong biểu đồ có n phương thức thì sẽ có n+1 trạng thái bao gồm trạng thái đầu và trạng thái kết thúc.
- Sau mỗi lời gọi phương thức thì đặt cho nó ở một trạng thái.
- Hàm getBeforeState(Event e) sẽ lấy ra tất cả các trạng thái mà có thể gọi tới phương thức e.
- Kiểm tra các tiền điều kiện ràng buộc và hậu điều kiện ràng buộc đối với mỗi phương thức.
- lấy và so sánh các trạng thái của từng trạng thái trong biểu đồ xem có đúng với đúng với trạng thái thực của nó không. Dùng mã aspect để kiểm chứng.
49
Chương 6 Kết luận
6.1 Kết luận về khóa luận
Trong quá trình thực hiện đề tài này, tôi đã tìm hiểu những kiến thức cơ bản về kiểm chứng phần mềm giúp cho việc phát hiện và sửa lỗi phần mềm nhằm đảm bảo chất lượng của phần mềm, các kiến thức cơ bản về UML, Sequence Diagram về chi tiết các thành phần, cách sử dụng và biểu diễn chúng. Tôi đã tìm hiểu các kiến thức về AOP và áp dụng các kiến thức này để xây dựng phương pháp kiểm thử dựa vào những đặc tính ưu việt của AOP. Các mô đun aspect chứa mã kiểm chứng có thể cắt ngang can thiệp vào một thành phần của hệ thống và tách biệt hoàn toàn với chương trình ban đầu. Đây là một khả năng rất hay và mạnh mẽ của AOP. Quá trình kiểm chứng phần mềm mà tôi đề cập trong khóa luận được tóm tắt lại như sau:
Từ biểu đồ trình tự UML đặc tả giao thức, xuất biểu đồ này dưới dạng tài liệu XMI, tiếp đó phân tích tài liệu XMI, máy trạng thái tương tác vơi tài liệu XMI cho ra được biểu đồ trạng thái. Với việc phát triển thêm một số thành phần cho máy trạng thái và xây dựng các mô đun cho việc sinh mã aspect kiểm chứng cho các giao thức cơ bản, tôi đã xây dựng được công cụ sinh mã kiểm chứng tự động bằng aspect từ tài liệu XMI mô tả giao thức. Với chương trình này tôi có thể kiểm chứng được hầu hết các giao thức định nghĩa được trên biểu đồ tuần tự. Khi thực hiện khóa luận tôi cũng gặp phải những khó khăn khi xây dựng công cụ sinh mã kiểm chứng tự động. Việc biểu diễn ràng buộc trong biểu đồ trình tự là rất khó,bằng phương pháp của tôi có thể giải quyết triệt để các ràng buộc đơn giản. Nhưng khi ràng buộc là tổ hợp của rất nhiều ràng buộc nhỏ lẻ bắt buộc phải tách chúng ra