Giao thức được mô tả bằng biểu đồ trình tự là giao thức liên quan đến nhiều lớp
đối tượng khác nhau, nhưng xét cho cùng, nó cũng g ần giống với giao thức trên một lớp đối tượng được mô tả bằng biểu đồ trạng thái. Nó cũng quy đ ịnh dãy các phương
thức sẽ được gọi trong chương trình và l ập trình viên sẽ phải gọi các phương thức trong các lớp khác nhau đúng theo trình tự như vậy. Việc kiểm chứng, xét cho cùng cũng chính là để kiểm tra xem lập trình viên gọi các phương thức có đúng như giao
thức đặc tảban đầu không. Do đó, Máy trạng thái mô tả biểu đồ trình tự tôi xây dựng cũng tương tự với máy trạng thái mô tả biểu đồ trạng thái. Gồm ba thành phần dữ liệu:
HashMap<String, Set<String>> fsm = null; HashSet<String> entrySigs, exitSigs;
- entrySigs: Mô tảphương thức bắt đầu của giao thức - exitSigs: Mô tảphương thức kết thúc giao thức
- fsm: Là một HashMap, với key một phương thức bất kỳkhác phương thức mở đầu và phương thức kết thúc giao thức. Value chính là phương thức
ngay trước nó trong giao thức.
Một câu hỏi đặt ra là: Trong biểu đồ trình tự, các phương thức (thông điệp) được mô tả theo một dãy và đư ợc đánh số thứ tự tự động bắt đầu từ 1, như vậy thì cần ba thành phần dữ liệu để mô tả một dãy gọi phương thức như vậy có phải là thừa không? Tôi xin trả lời là không hề thừa chút nào. Vì trong khi kiểm chứng, theo như bài báo
[5] đề cập, không phải trong chương trì nh, mỗi lớp đối tượng được đặc tả ở đây chỉ được khởi tạo và thực hiện một lần. Lập trình viên có thể thực hiện giao thức nhiều lần bằng cách khai báo các biến khác nhau của các lớp đối tượng này. Ví dụ: Ta mô tả
giao thức giữa hai đối tượng A và B với hai thông điệp A -> B và B -> A. Ta có thể khai báo hai đối tượng của lớp A: là a1, a2 và hai đối tượng của lớp B là b1, b2 cùng thực hiện giao thức này. Cụ thể việc tựđộng ánh xạ giao thức cho từng đối tượng của lớp như thế nào, tôi sẽ trình bày ở phần sau. Phần này tôi chỉ tập trung vào việc mô tả
thuật toán xây dựng máy trạng thái mô tả biểu đồ trình tự UML dựa vào tài liệu XMI
đặc tả biểu đồ trình tự và các cấu trúc dữ liệu đã được xây dựng ở phần trước. Thuật toán xây dựng FSM mô tả biểu đồ trình tự UML:
47 - Input: tài liệu XMI
- Output: FSM nếu xây dựng được, nếu không sẽ báo lỗi. - Các bước thực hiện:
o Khởi tạo fsm, entrySigs, exitSigs.
o Đọc file XMI, lấy ListMessage, ListClasfierRoles, ListReturn, ListArgument và ListTransitions.
o Duyệt từng Message trong ListMessage.
Nếu nó là messageđầu tiên, lấy các dữ liệu về tên lớp, kiểu trả về, các tham số truyền vào cho vào entrySigs và cho vào fsm với key là tên thông điệp hoàn chỉnh, value là “START”.
Nếu nó là message kết thúc, lấy dữ liệu tạo thành message
hoàn chỉnh (bao gồm tên lớp, kiểu trả về…), lưu vào
exitSigs. Lưu vào fsm với key là message hoàn chỉnh vừa
lưu vào exitSigs và value là Set chứa hàm ngay hoàn chỉnh
ngay trước đó.
Nếu nó là message trung gian, lấy dữ liệu hoàn chỉnh về
message hiện thời và message ngay trước đó. Lưu vào fsm
với key là message hiện thời, value là Set chứa message
ngay trước đó.
4.3 Kết luận
Trong chương này, tôi đã trình bày phương pháp xây d ựng FSM từ một tài liệu
XMI đặc tả biểu đồ UML. Nó gồm một số bước cơ bản như: phân tích tài liệu XMI,
đánh dấu các thẻ cần lấy dữ liệu, chọn ra các thuộc tính cần lấy dữ liệu, từđó xây dựng các cấu trúc dữ liệu mô tả các thành phần cơ bản của biểu đồ. Tiếp theo, xây dựng các cấu trúc dữ liệu mở rộng để có thể lưu trữđược toàn bộ các dữ liệu quan trọng về các thành phần của biểu đồ. Cuối cùng là xây dựng FSM từ các dữ liệu mô tả biểu đồ
UML bằng các đối tượng trong Java. Kết quả của bước này chính là FSM mô tả giao thức mà biểu đồ UML đã đ ặc tả. Đây cũng chính là đ ầu vào cho bộ sinh mô-đun
48
Chương 5. Xây dựng công cụ tự động sinh aspect từ
máy trạng thái
Xây dựng công cụ tự động sinh aspect từ máy trạng thái chính là bước thứ hai trong nghiên cứu của tôi về “phương pháp kiểm chứng đặc tả UML cho tác tử phần mềm”. Mục tiêu của bước này là tạo dựng được công cụ tự sinh aspect từ máy trạng
thái đã được tạo ra theo phương pháp đã trình bày ởchương 4.Aspect này sẽđược đan vào chương trình chính thông qua trình biên d ịch AspectJ nhằm thực thi nhiệm vụ
kiểm chứng.
5.1 Đặt vấn đề
Trong chương 2 nói về lập trình hư ớng khía cạnh, tôi đã trình bày chi tiết về
aspect và cấu trúc của nó. Một aspect phải có đầy đủ các thông tin về các quy tắc đan
(join point và pointcut) và mã kiểm chứng (được cài đặt trong advice). Từ đó trình biên dịch AspectJ mới có thể đan chúng vào chương trình chính ph ục vụ quá trình kiểm chứng. Từ nội dung nghiên cứu của bài báo “Checking Interface Interaction Protocols Using Aspect-Oriented Programming” [5] và khóa luận của tôi, phương
pháp cài đặt aspect từ máy trạng thái bao gồm các bước cơ bản sau:
Bước 1: Xác định quy tắc đan – căn cứ vào các giao thức cần kiểm chứng để xác định các join point sẽ cần theo dõi xem có vi phạm hay không trong thời gian chạy. Từ các join point này sẽ xây dựng các pointcut trong aspect.
Bước 2: Xây dựng hành vi đan – đây chính là bước viết mã kiểm chứng trong phần advice. Ta cần xác định các hành vi mà hệ thống cần thực thi và những điều kiện làm cho ràng buộc về giao thức bị vi phạm.
Bước 3: Tổng hợp aspect – Khi đã xác đ ịnh được pointcut và advice, aspect sẽ được hình thành theo mẫu sau:
<phạm vi truy cập> aspect <tên aspect> {
Vùng pointcut;
Vùng advice; }
49