KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ phần mềm HÀ NỘI - 2010 ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Vương Văn Trường KIỂM CHỨNG CÀI ĐẶT BIỂU ĐỒ TƯƠNG TÁC
VỚI UML 2.0

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ phần mềm Cán bộ hướng dẫn: TS Trương Anh Hoàng
Cán bộ đồng hướng dẫn: ThS Phạm Thị Kim Dung

các anh chị và các bạn.
Một lần nữa, tôi xin chân thành cảm ơn.
Hà Nội, tháng 5 năm 2010

Vương Văn Trường

Tóm tắt

Phần mềm ngày càng được xây dựng và phát triển mạnh mẽ. Phần mềm
được tạo ra phải đảm bảo chất lượng. Kiểm chứng phần mềm là một trong
những giai đoạn quan trọng trong quy trình sản xuất phần mềm. Kiểm chứng
động phần mềm nhằm phát hiện và tìm lỗi trong giai đoạn kiểm thử phần mềm.
Phương pháp lập trình hướng khía cạnh ( Aspect Oriented programming - AOP)
cùng với công nghệ AspectJ ra đời tạo ra hướng phát triển mới cho kiểm chứng
phần mềm, nâng cao khả năng tìm và sửa lỗi phần mềm mà không ảnh hưởng


Mục lục
Chương 1. Mở đầu 1
1.1. Đặt vấn đề 1
1.2. Nội dung bài toán 2
1.3. Tổng quan phương pháp “kiểm chứng cài đặt biểu đồ tương tác với UML 2.0” 2
1.4 . Cấu trúc khóa luận 4
Chương 2. Annotaions , Aspects và UML 2.0 5
2.1. Annotations 5
2.1.1. Khái niệm annotaions 5
2.1.2. Ưu điểm của annotations 5
2.1.3. Cấu trúc annotaions 6
2.1.4. Target annotions 6
2.2. Aspect 7
2.2.1. Lập trình hướng khía cạnh AOP 7
2.2.2. AspectJ 9
2.3. UML 2.0 10
2.3.1. khai niệm về UML 10
2.3.2. Biểu đồ trình tự UML 11
2.4. Xây dựng máy trạng thái từ biểu đồ trình tự 16
2.4.1. Cấu trúc dữ liệu mô tả biểu đồ trình tự 16
2.4.2. Xây dựng máy trạng thái(FSM) 18
2.5. Tổng kết chương 19
Chương 3 . Xây dựng cộng cụ tự động sinh Aspect từ máy trạng thái 20
3.1. Biểu đồ trình tự và các đoạn gộp 20
3.2. Sinh Aspect từ biêu đồ trình tự 21
3.3. Kết luận 23
Chương 4. Thực nghiệm 24
4.1. Xây dựng công cụ 24
4.2. Kiểm chứng một số giao thức thực tế 27

Danh mục các ký hiệu, từ viết tắt
Từ viết tắc Diễn giải
AOP
Aspect-Oriented Programming
FSM
Finie State Machine
OOP
Object Oriented Programming
XML
eXtensible Markup Language
XMI
XML Metadata Interchange
UML
Unified Modeling language

1

Chương 1. Mở đầu 1.1. Đặt vấn đề

Giai đoạn kiểm thử có mục đích kiểm tra tính đúng đắn của sản phầm phần
mềm, kiểm tra xem có đáp ứng được nhu cầu bài toán đặt ra không. Trong thực tế, các
thao tác kiểm thử đơn vị thông thường dựa vào một tập các ca kiểm thử đầu vào và các
đầu ra tương ứng. Do vậy, chỉ kiểm tra được tính đúng sai của đầu vào và đầu ra của
chương trình, không kiểm tra được quá trình hoạt động cuả chương trình có theo đúng
đặc tả ban đầu hay không. Việc không kiểm hợp chúng thành chương trình lớn.
1.2. Nội dung bài toán
Kiểm chứng phần mềm là một phần vô cùng quan trọng trong quá trình phát
triển phần mềm. Vì vậy có rất nhiều phương pháp kiểm chứng phần mềm được xây
dựng như giả lập hay kiểm chứng mô hình. Trong giới hạn khóa luận này, tôi muốn đề
cập đến phương pháp kiểm chứng phần mền dựa trên phương pháp lập trình hướng
khía cạnh(AOP). Cụ thể trong phạm vi bài toán là kiểm chứng đặc tả hoạt động của
các đối tượng trong Java và kiểm tra các tác tử trong thời gian chạy.
Trong cách tiếp cận này, một ứng dụng hướng đối tượng được đặc tả bằng mô
hình UML và được cài đặt bằng ngôn ngữ Java: Sau khi Aspect được sinh ra, chúng sẽ
được đan xen vào mã Java để kiểm tra trong thời gian chạy. Bài toán có nhiệm vụ tạ ra
các Aspect từ biều đồ tuần tự , và dùng AspectJ để đan các Aspect này vào khung
chương trình chính. Khi chạy chương trình, các Aspect này sẽ tự động kiểm tra các
đặc tả giao thức và đưa ra các thông báo lỗi nếu có bất kỳ sự vi phạm nào.
Nhiệm vụ chính của bài toán là xây dựng phương pháp tạo ra các đoạn mã Aspect để
kiểm chứng và xây dựng công cụ Plugin Protocol Verification Generator tự động
sinh ra Aspect kiểm chứng đặc tả giao thức bằng biểu đồ tuần tự UML.
1.3. Tổng quan phương pháp “kiểm chứng cài đặt biểu đồ tương tác với UML 2.0”
Trong khóa luận “KIỂM CHỨNG ĐẶC TẢ UML CHO TÁC TỬ PHẦM
MỀM”[2] đã trình bày phương pháp kiểm chứng đặc tả UML cho tác tử phần mềm,
khóa luận đã đưa ra phương pháp pháp phân tích và kiểm chứng cho một số giao thức
(AB)
n
và [A*B]
n

phương pháp kiểm chứng giao thức sử dụng AOP. Dựa vào bài báo này tôi xây dựng
công cụ tự động sinh Aspect với đầu vào là tài liệu XMI mô tả biểu đồ tuần tự UML
2.0. Phương pháp xây dựng công cụ Plugin Protocol Verification Generator(PPVG
của tôi gồm hai bước.
 Bước 1 : Phân tích tài liệu XMI, lấy thông tin cần thiết để xây dựng máy trạng
thái.
 Bước 2 : Xây dựng bộ tự động sinh Aspect từ FSM : Sử dụng FSM vừa được
sinh ra từ trên, duyệt từng trạng thái trong FSM, áp dụng phương pháp cài đặt
Aspect trong bài báo nói trên, tôi tạo ra các join-point, pointcut và advice từ các
trạng thái đó để hình thành nên mô-đun Aspect.

4

1.4 . Cấu trúc khóa luận
Các phần còn lại của khóa luận được cấu trúc như sau:
Chương 2 giới thiệu về annotations, AspectJ, AOP , UML 2, xây dựng máy trạng thái.
Trong chương này tôi trình bày các kiến thức cơ bản sử dụng trong khóa luận của tôi
và cách xây dựng máy trạng thái cơ bản.
Chương 3 xây dựng công cụ sinh Aspect từ máy trạng thái mô tả biểu đồ trình tự
UML.
Chương 4 cài đặt công cụ tự động sinh Aspect và tiến hành kiểm chứng một số giao
thức.
Chương 5 đưa ra các kết luận của khóa luận và hướng nghiên cứu tương lai.


 Đơn giản.
 Tránh được rất nhiều lỗi trong thời gian chạy: trong lập trình, chúng ta thường
rất sợ lỗi về thời gian chạy. Lỗi được báo ở khâu biên dịch thường ít nguy hiểm và
được giải quyết nhanh chóng bởi lập trình viên nhưng lỗi trong thời gian chạy là
những lỗi khó chịu, khó khăn, mất nhiều thời gian để tìm ra nguyên nhân.
Annotations là một cách để đẩy các lỗi cú pháp trong quá trình cấu hình của khâu
biên dịch. Nghĩa là biên dịch có thể báo nhanh cho lập trình viên một số cấu hình
sai trong lúc dịch. Nếu dùng các phương pháp như lời chú thích, các thuộc tính
hoặc XML thì các lỗi này chỉ được báo trong thời gian chạy bởi chúng đơn thuần
là dữ liệu văn bản.
 Ứng dụng chạy nhanh hơn: Việc dùng định dạng như XML chúng ta phải tốn
thời gian, bộ nhớ để chuyển đổi từ XML sang các dạng đối tượng có API để dễ

1


6

tương tác lệnh như DOM hoặc SAX cũng là một trở ngại. Dùng Annotations thì đỡ
đi được rất nhiều.
2.1.3. Cấu trúc annotaions
Một annotations được định nghĩa như sau :
@interface tên_annotations {
// các các thành phần
}
Các thành phần annotations là danh sách các biến số của nó.
Thông thường annotations được dùng như một chú thích cho các thành phần
trong chương trình như class, biến số, phương thức, hoặc có khi là bất kỳ một dòng
lệnh nào. Để ghi chú cho một thành phần nào đó của chương trình thì annotations
được thêm vào trước thành phần đó. Định dạnh như sau :

public @interface Test_Target {
public String dosomething();
}
Annotations trên được định nghĩa ghi chú cho phương thức, với thành phần
chính là dosomething(). Để sử dụng annotations này thì thêm nó vào trước phương
thức. Ví dụ :
@Test_Target(“test”)
Public void test(){
// do something
}
Đối với annotations dạng này, nếu nó được định nghĩa dùng cho loại đối
tượng nào thì nó chỉ có thể ghi chú cho loại đối tượng đó. Như annotaions ở ví dụ trên,
nó chỉ có thể ghi chú cho đối tượng là một phương thức. Nếu sử dụng nó ghi chú cho
một class hoặc một biến thì sẽ nhận được lỗi.
2.2. Aspect
2.2.1. Lập trình hướng khía cạnh AOP
Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt
một cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung

8

cho kỹ thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đun khác, cho
phép kéo thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là
‘Aspect’ (tạm dịch là ‘lát’ – hàm ý lát cắt đi qua nhiều lớp đối tượng), từ chữ ‘Aspect’
này chúng ta có tên của phương pháp phát triển phần mềm mới: Aspect-oriented
programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ kiểm soát hơn.
Các Aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch và có thể tái sử
dụng. Một dạng biên dịch đặc biệt có tên là Aspect Weaver thực hiện kết hợp các
thành phần riêng lẻ lại thành hệ thống hợp nhất.
AOP gồm 3 bước phái triển :

AspectJ được cấu thành từ join-point, pointcut, advice[7].
Jointpoints là điểm định nghĩa trong chương trình, jointpoint có thể là một lời gọi hàm,
khởi tạo một lớp, khởi tạo một đối tượng. Nhờ join-points mà ta có thể xác định các
điểm mà chức năng cắt ngang hệ thống thêm vào. Join-point có các loại chính sau :
 Join-point tại các hàm khởi tạo.
 Join-point tại các điểm truy cập thuộc tính.
 Join-point tại các điểm truy cập ngoại lệ
Pointcut là tập hợp các joinpont mà bạn sử dụng định nghĩa để thực thi advice.
Pointcut sẽ chọn một jointpoint nào đó và ngữ cảnh tại join-point đó. Cú pháp của
pointcut như sau :
[acess specifier] pointcut pointcut-name([args]) : pointcut-definition;
Ví dụ :
public pointcut test() : call(String Start()) || call(boolean end());
Mã được thực thi ở từng join-point được gọi advice. Có nhiều loại advice:
before - thực thi trước join-point, after - thực thi sau nó.Như vây, Advice là mã sẽ
được thực hiện tại một joint-point mà được chọn bởi một pointcut.
Advice được chia làm các loại sau :
 Before : Được thực hiện trước join-point
 Around: Được thực hiện sau join-point
 Affter : Được thực hiện sau joint-point
AspectJ 5 có nhiều điểm mở rộng hơn so với các AspectJ trước đó, một điểm
nỏi bật là nó có thể sử dụng annotations trong Java 5 như một join-point. Thông
thường annotations trong trường hợp này được định nghĩa như một target annotations.
Target annotaions này có thể được định nghĩa cho lớp, phương thức hoặc một thành

10

phần nào khác. Trong khóa luận của tôi, tôi sử dụng annotaions định nghĩa cho
phương thức.
Với một annotations được định nghĩa cho phương thức. Nó sẽ được ghi chú trước một


 Tích hợp trong thực tế tốt nhất.
UML 2.0 với nhiều thay đổi trong việc mô tả các thành phần trong biểu đồ.
Với sự mở rộng trong mô tả các thành phần như đoạn gộp alt,opt, loop … mang lại
nhiều tiện lợi cho người sử dụng. Dưới đây, tôi sẽ mô tả về một số thành phần trong
biểu đồ trình tự UML 2.0.
2.3.2. Biểu đồ trình tự UML
Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng .
Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message) được
gửi giữa các đối tượng. Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ
xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống. Các biểu đồ
trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục
thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi
thông điệp giữa các đối tượng khi thời gian trôi qua. Các thông điệp được biểu diễn
bằng các đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa
những đường thẳng đứng thể hiện đối tượng. Trục thời gian cùng những lời nhận xét
khác thường sẽ được đưa vào phần lề của biểu đồ. Dưới đây là một ví dụ về biểu đồ
tuần tự. 12

Hình 2.3.2a: Quá trình đăng nhập ATM
Tiếp theo đây, tôi sẽ giới thiệu về các dạng của biểu đồ tuần tự trong UML 2.0.
Uml 2.0 đã có sự thay đổi đáng kể vể cách thức biểu diễn biểu đồ tuần tự. Đầu tiên là
chú thích trong biểu đồ, đặt tên thành thành phần chú thích trong một khung, thành
phần khung được sử dụng như một nền tảng cho UML 2.0[1]. Một thành phần khung
cung cấp một ranh giới cho biểu đồ, xác định vị trí và mối quan hệ của các thành phần
trong biểu đồ. Dưới đây, là mô tả cho khung.


biểu đồ lặp đi lặp lại đã được cải tiến cùng với điều kiện của mảng kết hợp vòng lặp. 15 Hình 2.3.2.3 biểu đồ sử dụng loop
2.3.2.4 . Break
Các khung break được dùng thông dụng để mô hình hóa ngoại trừ sự kiểm
soát.

Hình 2.3.2.4 Biểu đồ sử dụng break

16

Với ví dụ trên, khi kiểm tra điều kiện balance < amount là sai thì thực hiện phần
phía sau của đoạn gộp break. Ngược lại, nếu điều kiện là đúng thì đoạn gộp break
được thực hiện. khi các thông điệp trong đoạn gộp break được thực hiện hết thì các
thông điệp khác bên ngoài không được thực hiện nữa.
2.4. Xây dựng máy trạng thái từ biểu đồ trình tự
2.4.1. Cấu trúc dữ liệu mô tả biểu đồ trình tự
Một biểu đồ trình tự gồm nhiều thành phần, trong đó có các thành phần quan
trọng như đường sống, các thông điệp được trao đổi giữa các đường sống, các đoạn
gộp,… khi miêu tả biểu đồ trình tự ta mô tả như sau:
 Tên lớp trong mã nguồn chương trình tương ứng với tên một đường sống.
 Các thông điệp trao đổi giữa các đường sống mô tả đầy đủ các thành phần như
một phương thức trong lớp tương ứng ở mã nguồn chương trình. Một phương thức
co các thành phần như tên, giá trị trả về, danh sách tham số.

Hình 3.1.1 : Altova Umodel mô tả thành phần trong biểu đồ trình tự.

- xmi.id mô tả id của thông điệp.
- name mô tả tên của thông điệp.
- sendEventId mô tả thành phần nguồn, nơi bắt đầu thông điệp.
- receiveEventId mô tả nơi đến của thông điệp.
- from thông điệp được bắt nguồn từ đường sống nào.
- To thông điệp kết thúc ở đường sống nào.
- sourceState cho biết trạng thái bắt đầu của thông điệp.
- targetState cho biết trạng thái kết thúc của thông điệp.

18

2.4.2. Xây dựng máy trạng thái(FSM)
Trong biểu đồ trình tự, các thông điệp được để kế nhau, chúng mô tả thứ tự
được gọi của các thông điệp. Việc mô tả các thành phần của máy trạng thái phải mô tả
được điều này. Trong máy trạng thái, các tác nhân gây chuyển trạng thái chính là các
thông điệp. Do đó, máy trạng thái được sinh ra phải mô tả được thứ tự trước sau của
các thông điệp. Do đó, máy trạng thái được sinh ra gồm các thành phần dữ liệu sau :
 states danh sách các trạng thái của máy trạng thái.
 events danh sách các thông điệp.
 firstState trạng thái đầu tiên của máy trạng thái.
 lastStates tập các trạng thái cuối của máy trạng thái.
Thuật toán xây dựng máy trạng thái :
Bảng 2.4.2: Thuật toán xây dựng máy trạng thái[2]
Stt tên Mô tả
1 input Tài liệu XMI
2 output Máy trangjt hái được sinh ra nếu không thông báo lỗi
3 Các bước thực hiện

1. Khởi tạo fsm, states, events, firstState,
lastState.