Khóa luận Kiểm chứng cài đặt biểu đồ tương tác với UML 2.0
ĐẠ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
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
HÀ NỘI - 2010
Lời cảm ơn
Trước tiên tôi xin gửi lời cảm ơn chân thành tới TS.Trương Anh Hoàng, Bộ
môn Công nghệ phần mềm, Khoa Công nghệ thông tin, Trường Đại học Công nghệ,
Đại học Quốc Gia Hà Nôi – người đã định hướng đề tài và tận tình hướng dẫn chỉ bảo
tôi trong suốt quá trình thực hiện khóa luận tốt nghiệp này.
Tôi cũng xin chân thành cảm ơn ThS Phạm Thị Kim Dung, Bộ môn Công nghệ phần
mềm, Khoa Công nghệ thông tin, Trường Đại học Công nghệ, Đại học Quốc Gia Hà
Nội – Người đồng hướng dẫn và chỉ bảo tôi trong quá trình thực hiện khóa luận của
này.
Tôi cũng xin trân trọng cảm ơn quý thầy cô trong Khoa Công nghệ thông tin, Trường
Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy, truyền đạt kiến
thức quý báu trong suốt bốn năm học làm nền tảng cho tôi thực hiện khóa luận tốt
nghiệp này.
Con xin cảm ơn cha mẹ và gia đình đã sinh ra và nuôi dạy con khôn lớn, luôn
cạnh động viên và ủng hộ con trên con đường mà con đã yêu thích và lựa chọn.
Cảm ơn các bạn sinh viên Khoa Công nghệ thông tin khóa 2006 – 2010. Các
bạn giúp đỡ và ủng hộ tôi rất nhiều cũng như đóng góp nhiều ý kiến quý báu, qua đó,
tôi hoàn thiện khóa luận tốt hơn.
Mặc dù đã rất nỗ lực, cố gắng nhưng chắc hẳn khóa luận của tôi vẫn còn nhiều
sót. Tôi rất mong nhận được nhiều những ý kiến đánh giá, phê bình của quý thầy của
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
đến mã nguồn hệ thống. Từ yêu cầu thực tế, khi mô hình UML đang là sự lựa
chọn phổ biến cho mô hình hóa hệ thống phần mềm ở giai đoạn thiết kế, việc
kiểm chứng các ràng buộc giữa các tương tác trong biểu đồ trình tự UML là rất
cần thiết. Cùng với yêu cầu thực tế đề ra và lựa chọn AOP là giải pháp giải
quyết vấn đề, trong phạm vi khóa luận, tôi xin trình bày phương pháp sinh mã
AspectJ tự động phục vụ cho việc kiểm chứng phần mềm với công cụ là plugin
Create Aspect tự động sinh mã AspectJ dựa trên phương pháp này. Nội dung
chính của phương pháp này dựa trên các kiến thức về AOP, UML, XML,
ANNOTATIONS để chuyển đổi các giao thức ràng buộc đối tượng đặc tả bời
biểu đồ UML sang modun aspect phục vụ cho việc kiểm chứng. Ý nghĩa thực
tiễn là việc sinh ra mã aspect sẽ đan xen vào chương chình thực hiện việc kiểm
chứng các ràng buộc giữa các đối tượng trong thời gian chạy.
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
4.2.1. Kiểm chứng biểu đồ truy cập thông tin cơ bản của một máy ATM .................................27
4.2.2. Kiểm chứng biểu đồ loop...............................................................................................32
4.2.3. Kiểm chứng biểu đồ tổng quát .......................................................................................36
4.3. Kết luận................................................................................................................................44
Chương 5. Kết luận........................................................................................................................45
Phụ lục .............................................................................................................................................47
Phụ lục A : Tài liệu XMI mô tả biểu đồ trình tự.............................................................................47
Danh mục các ký hiệu, từ viết tắt
Từ viết tắc
Diễn giải
Aspect-Oriented Programming
Finie State Machine
Object Oriented Programming
eXtensible Markup Language
XML Metadata Interchange
Unified Modeling language
AOP
FSM
OOP
XML
XMI
UML
Chương 1. Mở đầu
1.1. Đặt vấn đề
Ngày nay công nghệ thông tin đã được ứng dụng vào tất cả các lĩnh vực trong
đời sống xã hội, từ những ứng dụng đơn giản nhất đến các ứng dụng phức tạp, từ
những ứng dụng gia đình đến các ứng dụng cho các tổ chức lớn đều có mặt các sản
phẩm công nghệ thông tin. Có thể nói nó đã làm thay đổi diện mạo xã hội, đưa nền văn
minh nhân loại lên một tầng cao mới. Một phần quan trọng của Công nghệ thông tin là
Công nghệ phần mềm….. Cùng với sự phát triển vượt bậc của các công nghệ phần
cứng đã hỗ trợ cho Công nghệ phần mềm phát triển mạnh mẽ.
Hiện nay, phần mềm được coi là sản phẩm chính của công nghệ thông tin, quá
trình làm phần mềm thông thường được trải qua quy trình nghiêm ngặt. Quy trình này
được chia ra làm nhiều giai đoạn : thu thập yêu cầu, phân tích, thiết kế, xây dựng,
kiểm tra., triển khai và bảo trì phần mềm. Đối với phần mềm, việc đảm bảo chất lưng
của phần mềm là vô cùng quan trọng. Do đó, vấn đề đặt ra là phải kiểm tra, xác định
và sửa được các lỗi phát sinh trong quá trình sản xuất phần mềm, đó là công việc của
giai đoạn kiểm tra. Việc phát hiện lỗi phần mềm càng muộn thì gây hậu quả càng lớn,
tốn nhiều thời gian và công sức sửa lỗi, thậm chí có thể phải xây dựng lại toàn bộ hệ
thống từ đầu, có khi gây thất bại cho toàn dự án phần mềm. Chính vì vậy các phương
pháp phát hiện lỗi sớm để giảm thiểu công sức để sửa chúng ra đời. Để phát hiện hiện
những lỗi phần mềm, phần mềm phải được kiểm chứng(Verification) và thẩm
định(Valication)[5]. Kiểm chứng phần mềm là kiểm tra xem phần mếm có thiết kế
đúng và thực thi đúng như đặc tả không yêu cầu không. Thẩm định phần mềm là giai
đoạn có sự hỗ trợ của khách hàng nhằm kiểm tra xem phần mềm có đáp ứng được yêu
cầu của họ không.
Mục đính chính của kiểm chứng phần mềm là làm giảm thiểu số lỗi mà phần
mềm có thể gặp đến mức thấp nhất có thể chấp nhận được. Chính vì vậy, nó có vai trò
vô cùng quan trọng trong toàn bộ quy trình phát triển phần mềm cũng như trong ngành
phát triển phần mềm hiện nay. Nó thu hút được mối quan tâm của nhiều nhà nghiên
cứu.
1
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 .Nhưng trong khóa luận đó, chưa giải quyết được một số vấn đề như:
- Mới chỉ dừng ở kiểm tra một số giao thức đơn giản.
- Chỉ có thể kiểm tra cho các biểu đồ thường, hoặc biểu đồ theo Agent UML.
Đối với, các giao thức được mô tả bằng UML 2 trở lên thì công cụ không thể
thực hiện được.
2
- Việc tự động sinh Aspect chưa thực sự hoàn thiện. Aspect được sinh ra sau đó
được lưu lại. Để sử dụng Aspect này thì phải đưa nó vào trong project cần thiết.
- Aspect sinh ra có phạm vi trong toàn project. Tức là, bất kỳ lớp nào có một
phương thức được mô tả như ở trong pointcut thì đều chịu tác dụng của Aspect.
Điều này, nhiều khi gây nên lỗi.
- Tài liệu XMI đầu vào của công cụ đã được thu gọn chỉ chứa các thành phần
cần thiết.
Phát triển từ khóa luận trên, tôi đã giải quyết được các vấn đề trên. Aspect được
sinh ra trực tiếp gắn vào project cùng tên với file xmi. Giao thức được kiểm chứng đa
dạng. Được thiết kế theo UML 2.0, Các điều kiện lặp, lựa chọn sử dụng mô tả đoạn
gộp như đoạn gộp alt, loop. Aspect sinh ra có thể đảm bảo sự kiểm tra cho một phương
thức được người dùng đánh dấu.
Do sự khác nhau giữa cách mô tả UML 2.0 và trước đây, nên cấu trúc để lưu
giữ cũng như Aspect sinh ra cũng khác nhiều so với ở công cụ PVG. Phát triển từ công
cụ PVG nhưng tôi đã thay đổi nhiều để phù hợp với đặc tả giao thức bằng UML2.0.
Bài toán bắt đầu với đầu vào là một biểu đổ tuần tự UML 2.0, các biểu đồ này
được tạo ra bằng công cụ Altova Umodel 2010 hoặc Altova Umodel 2010 plugin, các
biểu đồ này sẽ được xuất ra dưới dạng XMI. Sau đó, lấy các thông tin cần thiết về các
đối tượng của biểu đồ và chuyển thành một máy trạng thái (FSM). Lập trình viên sẽ
phát triển các mô-đun nghiệp vụ chính từ biểu đồ này và các biểu đồ còn lại. Song
song với nó là quá trình xây dựng Aspect từ máy trạng thái. Bài báo “Checking
Interface Interaction Protocols Using Aspect-Oriented Programming”[3] đã xây dựng
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.
3
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.
4
Chương 2. Annotaions , Aspects và UML 2.0
2.1. Annotations
Có lẽ các khái niệm về Annotations hiện nay được nhiều người biết đến, vì vậy
ở đây tôi sẽ trình bày ngắn gọn các khái niệm cơ bản và đặc điểm chính của của
Annotations.
2.1.1. Khái niệm annotaions
Annotations1 trước tiên được hiểu là một dạng metadata. Metadata là đặc tả dữ
liệu cho một đối tượng, giá trị gì đó. Chẳng hạn các tập tin mp3, ảnh, hoặc một bài viết
có thể có metadata định dạng XML là RSS. Đặc tả dữ liệu là một tập giá trị chứa
những thông tin gắn gọn, cơ bản mô tả về đối tượng nào đó. Chẳng hạn, với một bài
hát thì metadata có thể bao gồm: tên ca sĩ trình bày, tên nhạc sĩ, bài hát này hát trong
bao lâu,... Metadata không phải là "siêu dữ liệu" như một số người từng dịch từ tiếng
Anh sang tiếng Việt.
2.1.2. Ưu điểm của annotations
Annotations là một kỹ thuật mới đầy triển vọng, hứa hẹn mang lại nhiều lợi ích
cho việc phát triển phần mềm, dưới đây là một số lợi ích của annotations.
Tường minh: Nhìn vào lớp trên bạn có thể thấy rõ mục đích.
Đơ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 http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html
5
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 :
@tên_annotations(<danh sách đối số>) Tên_thành_Phần
Ví dụ: sử dụng annotaions cho phương thức .
@Override
public String toString(){
return
super.toString() +"Testing annotation name:
'Override'";
}
Annotations trên định sử dụng nhằm khẳng định phương thức toString được
ghi đè lên phương thức của lớp cha.
2.1.4. Target annotions
Annotations rất đa dạng, có rất nhiều loại annotations, nhưng tôi chỉ đề cập đến
Target annotaions vì đây là annotations mà tôi dùng cho khóa luận. Sau đây, tôi sẽ
trình bày về loại annotaions này.
Target annotations các chú thích kiểu này có đích tới là class. Bao gồm các loại.
@Target(ElementType.TYPE)— Áp dụng cho bất kỳ các yếu tố nào của class
@Target(ElementType.FIELD)—Có thể áp dụng cho các lĩnh vực và các thuộc
tính
6
@Target(ElementType.METHOD)—Có thể áp dụng cho mức độ method
@Target(ElementType.PARAMETER)—Áp dụng cho các thông số của các
methods
@Target(ElementType.CONSTRUCTOR)— Áp dụng cho constructors
@Target(ElementType.LOCAL_VARIABLE)—Áp dụng cho các biến địa
phương
@Target(ElementType.ANNOTATION_TYPE)—Loại hình tuyên bố là một
chú thích
Ví dụ :
@Target(ElementType.METHOD)
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
7
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 :
Phân tích các yêu cầu để xác định vấn đề chung và vấn đề đan nhau.
Xây dựng thể hiện từng vấn đề riêng biệt.
Tổng hợp các thể hiện.
Trình biên dịch AOP thực hiện theo hai bước :
Kết hợp các hành vi riêng lẻ.
Chuyển đổi thông tin kết quả sang dạng mã thực thi.
Các ưu điểm của AOP[4]:
Mô đun hoá những vấn đề đan nhau: AOP xác định các vấn đề một cách tách
biệt hạn chế tối thiểu việc nhập nhằng mã, cho phép mô đun hoá cả vấn đề liên
quan đến nhiều lớp đối tượng.
Dễ dàng phát triển hệ thống: Việc thêm chức năng mới có thể thực hiện dễ dàng
bằng cách tạo Aspect mới mà không cần quan tâm đến vấn đề đan nhau. Khi thêm
các mô đun mới vào hệ thống, các Aspect hiện có sẽ đan kết với chúng và tạo nên
sự phát triển chặt chẽ.
Cho phép để lại quyết định thiết kế tương lai: Một thiết kế tốt phải tính đến cả
yêu cầu hiện tại và tương lai, việc xác định yêu cầu tương lai là một công việc khó
khăn. Nếu bỏ sót những yêu cầu tương lai có thể bạn sẽ phải thay đổi hay thực hiện
lại nhiều phần hệ thống. Với AOP, người thiết kế hệ thống có thể để lại các quyết
định thiết kế cho những yêu cầu tương lai nhờ thực hiện theo
Tái sử dụng mã tốt hơn: Các Aspect là những mô đun riêng biệt, được kết hợp
linh động – đây chính là yếu tố quan trọng để tái sử dụng mã. AOP cho phép tái sử
dụng mã tốt hơn OOP.
8
2.2.2. AspectJ
AspectJ là một mở rộng của lập trình hướng khía cạnh AOP để giúp cho việc
học và phát triển ứng dụng Java dựa trên AOP dễ dàng nhanh chóng. AspectJ giúp cho
việc mô-đun hóa các vấn đề quan tâm trong việc phát triển ứng dụng dễ dàng hơn như
là: kiểm tra và xử lý lỗi, đồng bộ hóa, tối ưu hóa hiệu quả, theo dõi, tìm lỗi.
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
9
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
phương thức nào đó. Khi đó Aspect sẽ định nghĩa phương thức đó dưới dạng như sau :
@Tên_annotations Tên_phương_thức(danh sách đối số).
Ví dụ:
pointcut test() : call(@Implement * m());
Ví dụ trên, pointcut được kích hoạt khi một phướng thức m() được ghi chú bởi
annotations @Implement được gọi.
2.3. UML 2.0
2.3.1. khái niệm về UML
UML (Unified Modeling Language) là một ngôn ngữ chuẩn cho việc cụ thể
hóa, trực quan hóa, xây dựng và tạo tài liệu cho một hệ thống phần mềm, cũng như
cho mô hình doanh nghiệp và những hệ thống khác. UML miêu tả một loạt các kỹ
thuật công nghệ tốt nhất đã được kiểm chứng và thành công trong nhiều hệ thống lớn
và phức tạp. UML là một phần quan trọng trong việc phát triển các phần mềm hướng
đối tượng và trong quy trình phát triển phần mềm. UML sử dụng hầu hết các ký hiệu
đồ họa để mô tả bản thiết kế của các dự án phần mềm. Sử dụng UML sẽ giúp cho các
nhóm dự án có thể dễ dàng giao tiếp, khai thác những tiềm năng thiết kế, và phê chuẩn
thiết kế kiến trúc của phần mềm.
Những mục đích chính trong việc thiết kế của UML là:
Cung cấp cho người dùng với một tài liệu đọc để sử dụng, có ý nghĩa như một
ngôn ngữ mô hình trực quan, vì vậy họ có thể phát triển và trao đổi các mô hình có
ý nghĩa.
Cung cấp cơ chế đặc tả và khả năng mở rộng để mở rộng các khái niệm cốt
lõi.
Không phụ thuộc vào ngôn ngữ lập trình cụ thể và các quy trình phát triển
Cung cấp một cơ sở chính thức cho việc hiểu những ngôn ngữ mô hình hóa.
Gia tăng sự phát triển của thị trường các công cụ hướng đối tượng
Hỗ trợ sự phát triển ở mức cao hơn các khái niệm như collaborations,
frameworks, patterns and components.
10
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ự.
11
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.
Hình 2.3.2b mô tả một khung cơ bản
Với biểu đồ tuần tự, có tất cả 12 loại đoạn gộp được định nghĩa:alt, opt, break,
par, seq, strict, neg, critical, ignore, consider, assert, loop . Nhưng trên thực tế chỉ có 4
dạng là được sử dụng chủ yếu đó là : alt,opt, loop và break. Sau đây tôi sẽ trình bày về
4 loại này.
2.3.2.1. Alt
Mục đích là tìm kiếm sự lựa chọn tổng thể có thể thay thế lẫn nhau giữa hai
hoặc nhiều trình tự thông điệp. Các sự thay thế cho phép sự mô hình hóa cổ điển (if
else)“nếu thì” (ví dụ : nếu tôi mua ba thứ thì tôi được giảm giá 15 % ; hoặc tôi được
giảm giá 10%).
12
Hình 2.3.2.1 biểu đồ trình tự sử dụng alt
2.3.2.2. Opt
Mảng kết hợp opt(sự tùy chọn) được sử dụng để mô hình một trình tự sẽ xảy ra,
giả sử trong điều kiện nhất định; nếu không trình tự sẽ không xảy ra. Sự tùy chọn được
sử dụng để mô tả một mệnh để đơn giản “if then” (nếu thì) (ví dụ: nếu có ít hơn 5 cái
bánh trên bàn thì thêm 2 cái bánh nữa) .
Chú thích của mảng kết hợp tùy chọn tương tự đối với mảng kết hợp thay thế, ngoại
trừ nó chỉ có một toán hạng và không bao giò có trạng thái “else”.
13
Hình 2.3.2.2 biểu đồ dùng opt
2.3.2.3. Loop
Đôi khi bạn sẽ cần một trình tự lặp đi lặp lại. Trong UML 2.0 mô hình hóa một
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.
14
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
15
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ự.
Để xậy dựng được máy trạng thái(FSM) đầu tiên cần phải có cấu truc dữ liệu
mô tả biểu đồ trình tự. Hai thành phần quan trọng cần xây dựng là đường sống và
thông điệp được trao đổi giữa các đường sống.
Bằng việc phân tích tài liệu XMI , các lớp mô tả thành phần đường sống và thông điệp
giữa các đường sống được cài đặt. Lớp LifeLine mô tả một đường sống.
class Lifeline {
private String id, className, name;
private boolean isMultiObject;
16
String objectName;
/////
}
Trong tài liệu XMI, một đường sống được định nghĩa trong thẻ lifeline và nó có
các thành phần quan trọng như:
- xmi.id cho biết id của đường sống.
- name mô tả tên của đường sống.
Đối với phương thức trao đổi giữa hai đường sống được cài đặt thông qua lớp
Message. Lớp này được cài đặt như sau :
public class Message implements Comparable<Message>{
private String id, name;
private String sendEventId, receiveEventId;
String className;
Lifeline from, to;
String sourceState, targetState;
//////////
}
Trong tài liệu XMI, môt thông điệp được đặc tả trong thẻ message, với một
thông điệp có các thành phần chính như sau :
- 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.
17
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
1
tên
input
Mô tả
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.
2. Đọc file XMI, lấy các thành phần cần thiết:
thông điệp, trạng thái,…
3. Duyệt từng thông điệp, đưa vào events.
3.1. Nếu là thông điệp cuối thì thêm trạng thái
kết thúc vào lastStates.
3.2. Nếu là thông điệp bắt đầu , thêm trạng thái
nguồn vào firstState.
3.3. Nếu là thông điệp trung gian, lưu các dữ
liệu vào máy trạng thái
18
2.5. Tổng kết chương
Trong chương này, tôi đã trình bày một số khái niệm cơ bản về annotations,
AspectJ, annotaions trong AspectJ, UML, biểu đồ trình tự UML 2. Đây là các nền tảng
trong khóa luận của tôi. Để xây dụng công cụ sinh Aspect tự động. Đồng thời tôi cũng
trình bày thuật toán xây dựng máy trạng thái cơ bản.
19
Chương 3. Xây dựng cộng cụ tự động sinh Aspect từ máy trạng thái
3.1. Biểu đồ trình tự và các đoạn gộp
Trong một biểu đồ trình tự UML2.0, các đoạn gộp là một trong các thành phần
quan trọng. Để xây dựng được máy trạng thái thì cần mô tả được đầy đủa các yếu tố
này. Có 4 loại đoạn gộp hay được sử dụng là alt, opt, loop, break. Do đó, cần xây dựng
cấu trúc dữ liệu để lưu trữ chúng.
Áp dụng phương pháp phân tích tài liệu XMI, các lớp mô tả khối gộp như sau.
Hình 4.1 Sơ đồ biểu diễn các thành phần khối gộp
Lớp CombinedFragment chịu trách nhiệm mô tả một đoạn gộp trong biểu đồ
trình tự. Là một trong những thành phần quan trọng trong biểu đồ trình tự của UML2.
Trong XMI một đoạn gộp được mô tả trong thành phần fragment với
xmi:type="uml:CombinedFragment". Trong thành phần này, một đoạn gộp được mô tả
bởi các thành phần như sau :
Xmi.Id : cho biết id của đoạn gộp.
Name : cho biết tên của đoạn gộp.
interactionOperator : cho biết dạng của fragment là alt, loop,break hay opt …
20
Ngoài ra các thành phần xmi.id và xmi.uuid có thể giúp chúng ta tình các message
thuộc vào đoạn gộp bằng cách so sánh các id của đoạn gộp với các senEvent của
message.Dưới đây là mô tả về lớp CombinedFragment.
public class CombinedFragment {
String id;
Vector<Message> message;
public Message firstMessageAfterFragment;
//////
}
Lớp Loop,opt,break các một lớp con của lớp CombinedFragment về cơ bản lớp
này kế thừa các thành phần của lớp CombinedFragment. Chúng không có thêm thành
phần nào. Để xác định chúng, trong quá trình phần tichs tài liệu XMI chúng ta so sánh
thành phần interactionOperator để xác định.
Lớp Alt là một lớp con của lớp CombinedFragment, khác với 3 lớp con trên,
đôi với alse chúng ta cần quan tâm đến các thành phấn khác của nó. Alt là một mô tả
điểu kiện chọn có trên hai điều kiện, chúng ta phải mô tả được điều này.Vì lý do đó,
ngoài các thành phần như lớp cha lớp Alt còn có các thành phần Dưới đây là mô tả về
lớp Alt.
public class Alt extends CombinedFragment{
Vector<Message> ifMessage;
Vector<Message> elseMessage;
//}
Sau đó, máy trạng thái sẽ được sinh ra như phân tích ở chương 2.
3.2. Sinh Aspect từ biểu đồ trình tự
Việc kiểm chứng giao thức trên nhiều lớp đối tượng trong biểu đồ trình tự có
thể coi như việc gọi tuần tự các phương thức. Giao thức được mô tả dưới dạng một
FSM. Do đó, hành vi chuyển trạng thái là đúng khi:
21
- Trạng thái trước đó có gọi hàm chuyển trạng thái không.
- Điểu kiện chuyển trạng thái có thỏa mãn không.
Khi thỏa mãn các điều kiện trên, thì sự chuyển trạng thái được thực hiện đúng
và sẽ chuyển qua trạng thái mới. Như vậy, các join-point được xác định các điểm
chuyển trạng thái; before advice sẽ chứa các hành vi kiểm tra sự chuyển trạng thái này
là đúng hay sai. Sau đó, mã trạng thái được thay đổi; after advice chứa các hành vi
kiểm tra điều kiện loop,alt, break, opt và kiểm tra điều kiện dừng.
Để tiện cho việc kiểm tra, Trạng thái ban đầu của máy trạng thái ta đặt là “0”,
dùng một biến Id để xác định tên các trạng thái hiện tại(ArrayList<String> Id).
Tại before, kiểm tra xem phương thức gây biến đổi trạng thái có phải bắt đầu từ
một trạng thái có thể hiện tại hay không? Nếu vi phạm thì thông báo lỗi. Sau đó cập
nhật lại trạng thái hiện tại. Trạng thái hiện tại được đặt mặc định ban đầu là “0”.
Tại after advice. Khi này trạng thái hiện tại đã là trạng thái mới. Khi đó ta kiểm
tra xem trạng thái này có thuộc alt, loop, opt hay break không, để đưa ra các hướng
giải quyết tương ứng. Nếu nó là một trong các trạng thái kết thúc thì đưa ra thông báo
tổng quát về qua trình thực hiện.
Thuật toán sinh mã Aspect như sau :
Bảng 3.2: Thuật toán sinh mã Aspect
Bước
Nội dung
1
Duyệt danh sách các trạng thái FSM, lấy các trạng thái rồi lấy tập
các thông điệp gây ra biến đổi trạng thái. Dùng các hàm để xử lý các
thông điệp này và đưa nó về dạng @Implement * ten_ham(<danh sach
doi so>). Sau đó đưa chúng vào pointcut. Việc này giúp chúng ta chỉ
cần một pointcut.
2
3
4
Duyệt danh sách các trạng thái trong FSM lấy các trạng thái
nguồn và các trạng thái đích tương ứng để tạo ra các điều kiện kiểm tra.
Tạo các pointcut, advice bằng cách thay thế các xâu tương ứng
vừa được tạo ra ở trên vào vị trí cần thiết.
Kết hợp pointcut advice thành Aspect cần thiết
22
Việc kiểm chứng cho từng thành phần đoạn gộp của biểu đồ trình tự lại có điểm
khác nhau.
Đối với break, opt khi trạng thại của chúng được kích hoạt thì ta đưa ra thông
báo. Trạng thái kích hoạt một đoạn gộp break hoặc opt là trạng thái đầu tiên cuả nó.
Do đó, khi một phương thức nào đó, kích hoạt sự chuyển trạng thái đến trạng thái này
thì ta thông báo sự chuyển trạng thái đó.
Đối với loop, nó cũng có trạng thái kích hoạt như trên. Nhưng với loop ta cần
đếm số lần xuất hiện của nó. Do đó, ta dùng biến có tên dạng loop+<tên trạng thái> để
đếm số lấn. Tại before, khi một trạng thái loop được kích hoạt thì ta tăng số lần đếm
nó lên.Ví dụ: ta có một trạng thái kích hoạt loop là “2”. Ta đặt tên cho biến đếm lad
loop2 và khởi tạo nó ban đầu là 0.
Đối với alt, Tương tự nó có các trạng thái kích hoạt, nhưng khác với loop,
break, opt. Với alt có nhiều trạng thái kích hoạt, do đó ta cần chỉ ra nó kích hoạt theo
hướng nào.
3.3. Kết luận
Trong chương này, tôi đã trình bày về cách xây dựng cấu trúc dữ liệu để mô tả
các đoạn gộp. Từ đó, đưa các thông tin về các đoạn gộp vào máy trạng thái.
Tại chương này, tôi đã trình bày về phương pháp sinh Aspect từ máy trạng thái
để kiểm tra giao thức sinh ra từ biểu đồ tuần tự. Nội dung chính của phương pháp là
duyệt qua các trạng thái của FSM, tìm các thành phần tương ứng và đưa vào Aspect
dưới dạng các pointcut và các advice. Aspect được đưa ra kiểm chứng được hầu hết
các giao thức mô tả bằng biều đồ trình tự UML như vòng lặp loop, lựa chọn một thành
phần(opt), lựa chọn nhiều thành phần(đoạn gộp alt) và đoạn gộp break. Đây là mở
rộng của UML 2.
Aspect được sinh ra sẽ đan vào chương trình nguồn giúp cho việc kiểm chứng
cho chương trình Java được thiết kế theo đặc tả của biểu đồ trình tự tương ứng.
23
Tải về để xem bản đầy đủ
56 trang
11/04/2025
140
Bạn đang xem 30 trang mẫu của tài liệu "Khóa luận Kiểm chứng cài đặt biểu đồ tương tác với UML 2.0", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- khoa_luan_kiem_chung_cai_dat_bieu_do_tuong_tac_voi_uml_2_0.pdf
