intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

LUẬN VĂN:KIỂM CHỨNG ĐẶT TẢ UML CHO TÁC TỬ PHẦN MỀM

Chia sẻ: Lan Lan | Ngày: | Loại File: PDF | Số trang:93

116
lượt xem
37
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Trong quy trình phát triển phần mềm, kiểm chứng phần mềm đóng vai trò quan trọng trong việc đảm bảo tính đúng đắn của hệ thống trong suốt quá trình thực thi. Nó có nhiệm vụ phát hiện và dò tìm lỗi cho giai đoạn kiểm thử phần mềm. Phương pháp lập trình hướng khía cạnh (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, giúp nâng cao chức năng dò tìm, sửa lỗi phần mềm mà không ảnh hưởng tới mã nguồn hệ thống....

Chủ đề:
Lưu

Nội dung Text: LUẬN VĂN:KIỂM CHỨNG ĐẶT TẢ UML CHO TÁC TỬ PHẦN MỀM

  1. ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Vũ Sỹ Vương KIỂM CHỨNG ĐẶT TẢ UML CHO TÁC TỬ PHẦN MỀM 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 - 2009
  2. ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Vũ Sỹ Vương KIỂM CHỨNG ĐẶT TẢ UML CHO TÁC TỬ PHẦN MỀM 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: Tiến sỹ Trương Anh Hoàng HÀ NỘI - 2009
  3. Lời cám ơn Trước tiên tôi xin gửi lời cảm ơn sâu sắc 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 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 những 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 bê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 2005 – 2009. 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 đó, giúp 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 thiế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ô, 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 2009 Vũ Sỹ Vương
  4. Tóm tắt nội dung Trong quy trình phát triển phần mềm, kiểm chứng phần mềm đóng vai trò quan trọng trong việc đảm bảo tính đúng đắn của hệ thống trong suốt quá trình thực thi. Nó có nhiệm vụ phát hiện và dò tìm lỗi cho giai đoạn kiểm thử phần mềm. Phương pháp lập trình hư ớng khía cạnh (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, giúp nâng cao chức năng dò tìm, s ửa lỗi phần mềm mà không ảnh hưởng tới mã nguồn hệ thống. Từ yêu cầu thực tế, khi mà mô hình UML đang là sự lựa chọn phổ biến cho việc 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 giao thức ràng buộc đối tượng, giao thức ràng buộc giữa các tác tử trong hệ đa tác tử được mô tả trong biểu đồ trạng thái và biểu đồ trình tự UML, AUML là rất cần thiết trong thời gian chạy. Dựa vào yêu cầu thực tế đặt ra cùng với việc lựa chọn AOP làm 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ã aspect phục vụ cho mục đích kiểm chứng phần mềm và xây dựng công cụ Protocol Verification Generator (PVG) tự động sinh mã aspect dựa trên phương pháp này. Nội dung chính của phương pháp là dựa vào các kiến thức về AOP và UML, XML, AUML, JADE framework để chuyển đổi các giao thức ràng buộc đối tượng được đặc tả bởi biểu đồ UML, giao thức tương tác giữa các tác tử trong hệ đa tác tử được đặc tả bởi biểu đổ AUML sang các mô-đun aspect phục vụ quá trình kiểm chứng. Ý nghĩa th ực tiễn của bài toán là việc sử dụng mã aspect vừa được tạo ra đan vào chương ình chính thông qua b ộ đan (aspect tr weaver) của AspectJ để thực hiện nhiệm vụ kiểm chứng các giao thức ràng buộc giữa các đối tượng, các tác tử trong thời gian chạy.
  5. Mục lục Chương 1. Mở đầu ..................................................................................................1 Đặt vấn đề ................................................................................................1 1.1 Nội dung bài toán .....................................................................................2 1.2 1.3 Tổng quan phương pháp “Kiểm chứng đặc tả UML cho tác tử phần mềm” .................................................................................................................3 Cấu trúc khóa luận ...................................................................................4 1.4 Chương 2. Giới thiệu lập trình hướng khía cạnh (Aspect-Oriented Programming) và AspectJ ...............................................................................................................6 Phương pháp lập trình hướng khía cạnh ..................................................6 2.1 2.1.1 Sự hạn chế của lập trình hướng đối tượng (OOP)...............................6 2.1.2 Lập trình hướng khía cạnh (AOP) .......................................................9 2.2 AspectJ ...................................................................................................12 2.2.1 Join point ...........................................................................................12 2.2.2 Pointcut ..............................................................................................12 2.2.3 Advice ...............................................................................................13 2.2.4 Aspect ................................................................................................14 2.2.5 Cơ chế họa động của AspectJ............................................................15 2.3 Sử dụng AOP Phát triển ứng dụng và phương pháp kiểm chứng dựa trên AOP .............................................................................................................15 Kết luận ..................................................................................................17 2.4 Chương 3. Agent UML và JADE framework.......................................................18 Ngôn ngữ mô hình hóa UML ................................................................18 3.1 3.1.1 Khái niệm ..........................................................................................18 3.1.2 Biểu đồ trạng thái (State Diagram) ...................................................18 3.1.3 Biểu đồ trình tự (Sequence Diagram) ...............................................19 3.2 XML (eXtensible Markup Language) ...................................................20 3.2.1 Cơ bản về XML .................................................................................20
  6. 3.2.2 XML DOM ........................................................................................22 3.3 XMI (XML Metadata Interchange) .......................................................24 3.4 AUML (Agent UML) ............................................................................25 3.4.1 Tác tử phần mềm là gì? .....................................................................25 3.4.2 Phần mềm hướng Agent ....................................................................26 3.4.3 AUML (Agent Unified Modeling Language) ...................................28 3.5 Java Agent DEvelopment Framework (JADE) .....................................31 3.5.1 Khái niệm về JADE...........................................................................31 3.5.2 Cấu trúc của JADE platform .............................................................32 3.5.3 Một số lớp quan trọng trong thư viện JADE .....................................33 Kết luận ..................................................................................................34 3.6 Chương 4. Xây dựng máy trạng thái từ biểu đồ UML .........................................35 Biểu đồ trạng thái...................................................................................35 4.1 4.1.1 Quy tắc biểu diễn giao thức bằng biểu đồ trạng thái.........................35 4.1.2 Xây dựng cấu trúc dữ liệu mô tả biểu đồ trạng thái UML ................36 4.1.3 Xây dựng FSM mô tả biểu đồ trạng thái UML .................................40 Biểu đồ trình tự UML ............................................................................42 4.2 4.2.1 Cách biểu diễn giao thức giữa nhiều đối tượng bằng biểu đồ trình tự UML ...........................................................................................................42 4.2.2 Xây dựng cấu trúc dữ liệu mô tả biểu đồ trình tự UML ...................43 4.2.3 Xây dựng FSM mô tả biểu đồ trình tự UML ....................................46 Kết luận ..................................................................................................47 4.3 Chương 5. Xây dựng công cụ tự động sinh aspect từ máy trạng thái...................48 Đặt vấn đề ..............................................................................................48 5.1 Sinh aspect từ FSM mô tả biểu đồ trạng thái UML ...............................49 5.2 Sinh aspect từ FSM mô tả biểu đồ trình tự UML ..................................50 5.3 Mở rộng .................................................................................................51 5.4 Sinh mã aspect kiểm chứng giao thức (AB)n.........................................52 5.5
  7. 5.5.1 Giao thức (AB)n là gì? .......................................................................52 5.5.2 Thuật toán kiểm chứng giao thức (AB)n ...........................................53 5.5.3 Sinh mã aspect kiểm chứng giao thức (AB)n ....................................54 Kết luận ..................................................................................................54 5.6 Chương 6. Thực nghiệm .......................................................................................55 Xây dựng công cụ PVG .........................................................................55 6.1 Kiểm chứng một số giao thức thực tế ....................................................56 6.2 6.2.1 Giao thức của các ứng dụng Applet ..................................................56 6.2.2 Kiểm chứng giao thức biểu diễn giao thức ghi nợ ở một máy ATM 60 6.2.3 Kiểm chứng giao thức [A*B] n..........................................................64 6.2.4 Kiểm chứng giao thức tương tác tác tử .............................................66 Kết luận ..................................................................................................70 6.3 Chương 7. Kết luận ...............................................................................................71 Kết luận về khóa luận ............................................................................71 7.1 Hướng phát triển trong tương lai ...........................................................72 7.2 Phụ lục ..................................................................................................................73 Phụ lục A: Tài liệu XMI mô tả biểu đồ trạng thái UML ..................................73 Phụ lục B: Tài liệu XMI mô tả biểu đồ trình tự UML ......................................75 Phụ lục C: Agent Customer (Customer.java) ...................................................78 Phụ lục D: Agent ShoppingCart (ShoppingCart.java)......................................81 Phụ lục E: Aspect Template .............................................................................83
  8. Danh mục ký hiệu, từ viết tắt AOP Aspect-Oriented Programming FSM Finite State Machine JADE Java Agent DEvelopment Framework OOP Object Oriented Programming PVG Protocol Verification Generator XMI XML Metadata Interchange XML eXtensible Markup Language UML Unified Modeling Language
  9. 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 của đời sống xã hội. Nó đã tạo ra một diện mạo mới cho xã hội và nhờ đó nền văn minh nhân loại đã đư ợc nâng lên một tầm cao mới. Nói đến công nghệ thông tin là nói đến công nghệ phần mềm – một phần không thể tách rời của công nghệ thông tin. Hiện nay ngành công nghệ phần mềm trên thế giới đã và đang phát triển như vũ bão. Những tiến bộ vượt bậc của khoa học kỹ thuật phần cứng đã tạo điều kiện thuận lợi cho công nghệ phần mềm ngày càng phát triển không ngừng. Phần mềm được coi là sản phẩm chính của công nghệ phần mềm, được phát triển theo các mô hình, quy trình phát triển đặc biệt. Quá trình phát triển phần mềm bao gồm rất 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. Trong các giai đoạn đó giai đoạn kiểm tra, phát hiện, xác định và sửa các lỗi phần mềm là rất quan trọng để đảm bảo chất lượng của một phần mềm. Các lỗi phần mềm có thể gây thiệt hại to lớn về tiền bạc, thời gian và công sức của con người. Lỗi phần mềm được phát hiện càng muộn thì càng gây hậu quả nghiêm trọng, tốn rất nhiều thời gian và công sức để sửa chữa lỗi, thậm chí có thể phải xây dựng lại toàn bộ hệ thống từ đầu. Chính ví vậy cần có các phương pháp phát hiện lỗi sớm nhằm giảm thiểu công sức để sửa chúng. Để phát hiện ra những lỗi phần mềm, phần mềm cần phải được kiểm chứng (Verification) và thẩm định (Valication) [13]. Kiểm chứng phần mềm là kiểm tra xem phần mềm có được thiết kế đúng và thực thi đúng như đặc tả yêu cầu hay 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 các yêu cầu của họ hay không. Mục đích chính của kiểm chứng phần mềm là làm giảm thiểu lỗi phần mềm tới mức 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 và trong ngành công nghệ phần mềm hiện nay. Nó đã và đang thu hút được mối quan tâm của rất nhiều nhà nghiên cứu. Giai đoạn kiểm thử trong quy trình phát triển phần mềm có mục đích kiểm tra tính đúng đắn của sản phầm phần mềm. Trên thực tế, các thao tác kiểm thử đơn vị chỉ đánh giá đượ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 logic của chương trnh có theođúng đ ặc tả ban đầu hay ì 1
  10. không. Những đơn vị chương trình nhỏ này nếu không được kiểm tra kỹ sẽ có thể gây ra thiệt hại nặng nề khi tích hợp chúng để tạo thành chương trình hoàn ch ỉnh. Vấn đề đặt ra là cần có phương pháp kiểm chứng các đặc tả giao thức giữa các đối tượng, các tác tử ngay trong thời gian chạy, đánh giá xem trong thời gian chạy đối tượng hay tác tử phần mềm có vi phạm các giao thức ràng buộc đã được đặc tả hay không, và từ đó đảm bảo chắc chắn hơn tính đúng đắn của sản phầm phần mềm. Trong khóa luận này, tôi xin giới thiệu phương pháp tự động sinh mã aspect kiểm chứng đặc tả giao thức trong thời gian chạy, dựa trên phương pháp lập trình h ớng khía cạnh (Aspect – ư Oriented Programming). 1.2 Nội dung bài toán Hiện nay có rất nhiều phương pháp kiểm chứng phần mềm như giả lập hay kiểm chứng mô hình. Trong phạm vi bài toán được đặt ra ở đây, tôi muốn đề cập tới phương pháp kiểm chứng phần mềm dựa trên phương pháp lập trình hư ớng khía cạnh (AOP) [7, 12]. Lĩnh vực kiểm chứng cụ thể trong phạm vi bài toán là kiểm chứng giao thức đặc tả hoạt động của các đối tượng Java và kiểm chứng giao thức giữa các tác tử trong hệ đa tác tử (giao thức được mô tả bằng biểu đồ trạng thái và biểu đồ trình tự UML, AUML) 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; một hệ đa tác tử được đặc tả bằng các biểu đồ AUML và được cài đặt dựa trên JADE framework. Các aspect sau đó sẽ được đan vào khung mã Java đ ể kiểm tra tại bất kỳ thời điểm nào trong thời gian chạy, các đối tượng Java, các tác tử phần mềm hoạt động vi phạm giao thức đã đ ặc tả (aspect là mô-đun cắt ngang hệ thống). Bài toán có nhiệm vụ là tạo ra được các aspect từ biểu đồ trạng thái và biểu đồ trình tự UML; dùng công cụ AspectJ để đan các aspect này vào khung chương tr Java chính . Khi đó, trong quá ình ch ạy của chương trnh, các tr ình ì đoạn mã aspect sẽ tự động kiểm tra các đặc tả giao thức và đưa ra thông báo lỗi khi có bất kỳ vi phạm nào xảy ra. Trong khi phương pháp kiểm thử đơn vị chỉ xác định được tính đúng đắn của đầu vào và đầu ra của chương trình, không ki ểm tra được những lỗi logic thì phương pháp kiểm tra tính đúng đắn ngay tại thời gian chạy của chương trình sẽ đem lại hiệu quả rất lớn. 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, xây dựng công cụ Protocol Verification Generator(PVG) tự động sinh mã aspect kiểm chứng từ đặc tả giao thức bằng biểu đồ trạng thái và biểu đồ trình tự UML, AUML. Tôi xin đề cập hướng nghiên cứu kiểm chứng đặc tả UML cho tác tử 2
  11. phần mềm để kiểm chứng giao thức giữa các đối tượng Java trong thời gian chạy và kiểm chứng giao thức giữa các tác tử trong hệ đa tác tử được xây dựng trên JADE framework. Từ một biểu đồ trạng thái hay biểu đồ trình tự UML, AUML xuất ra tài liệu XMI đặc tả các biểu đồ này. Các tài liệu XMI chính là đầu vào cho công cụ cần xây dựng. Dựa vào các kiến thức về UML, XML tôi sẽ phân tích tài liệu XMI, xây dựng máy trạng thái (FSM) mô tả các biểu đồ UML, AUML. Sử dụng máy trạng thái vừa tạo để sinh ra mã aspect phục vụ cho việc kiểm chứng sau này. Mã aspect chính là đầu ra cuối cùng của công cụ. 1.3 Tổng quan phương pháp “Kiểm chứng đặc tả UML cho tác tử phần mềm” Bài toán bắt đầu với đầu vào là một biểu đồ trạng thái hay biểu đồ trình tự UML, các biểu đồ này sẽ được xuất ra dạng XMI. Sau đó, lấy ra các thông tin cần thiết mô tả 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ừ hai biểu đồ này và các biểu đồ UML khác còn lại. Song song với nó là quá trình xây dựng các mô-đun cắt ngang hệ thống thành các aspect từ máy trạng thái. Bài báo “Checking Interface Interaction Protocols Using Aspect-oriented Programming” [5] đã xây d ựng phương pháp kiểm chứng giao thức xử dụng AOP. Dựa vào nội dung phương pháp này tôi đ xây d ựng công cụ tự động ã hóa việc sinh các mô-đun aspect với đầu vào là tài liệu XMI mô tả biểu đồ trạng thái hay biểu đồ trình tự UML. Phương pháp xây dựng công cụ Protocol Verification Generator của tôi gồm hai bước: Bước1: Phân tích tài liệu XMI, lấy các thông tin cần thiết mô tả biểu đồ - UML để xây dựng máy trạng thái. Đầu tiên, tôi sẽ phân tích tài liệu XMI, xây dựng các cấu trúc dữ liệu mô tả các thành phần của biểu đồ UML bằng ngôn ngữ Java, sau đó sử dụng thư viện XML DOM đọc tài liệu XMI này, lấy dữ liệu theo cấu trúc đã định nghĩa trước, tạo ra FSM. Bước 2: Xây dựng bộ sinh tự động aspect từ FSM: Sử dụng FSM vừa - được sinh ra, 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 sẽ tạo ra các join point, pointcut và advice từ các trạng thái đó để hình thành mô-đun aspect. Trong hình minh họa dưới đây, tôi sẽ xây dựng công cụ Protocol Verification Generator. Kết quả thu được là các đoạn mã aspect sẽ được đan vào chương trình Java thông qua trình biên dịch AspectJ. Kết quả cuối cùng của quá trình này chính là hệ 3
  12. thống có chứa những đoạn mã kiểm chứng. Trong quá trình thực thi, kể cả trong thời gian chạy, bất cứ khi nào xảy ra vi phạm ràng buộc đã đ ịnh nghĩa trong biểu đồ UML thì chương trình đ ều báo thông báo lỗi cho lập trình viên, chỉ ra vị trí dòng mã nguồn sai đặc tả trong mã nguồn của chương trình. Nh ờ đó, lập trình viên có thể kiểm soát được hệ thống và làm cho hệ thống chạy ổn định và đúng đắn hơn. UML Use Case Diagram Class Diagram XMI File Protocol Sequence Diagram (*.xmi, *.xml) Specification State Diagram ……. AspectJ Generator Java code AspectJ Weaver AspectJ code Bytecode with Protocol checking Hình 1.1: Quy trình kiểm chứng phần mềm dựa vào AOP 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 phân bố như sau: Chương 2: Giới thiệu về phương pháp lập trình hướng khía cạnh. Trong chương này tôi sẽ đưa ra những so sánh giữa hai phương pháp OOP và AOP, từ đó nêu bật những ưu điểm của AOP; vai trò và ý ngh c ủa AOP đối với công nghệ phần mềm ĩa hiện nay. Đồng thời, tôi cũng gi ới thiệu công cụ AspectJ – một cài đặt của AOP cho ngôn ngữ lập trình Java. Chương 3: Trình bày sơ qua v ề các kiến thức về: UML, XML, XMI; trình bày một số khái niệm về tác tử phần mềm, phần mềm hướng agent và AUML – mở rộng từ UML để mô tả các hệ thống dựa tác tử. Giới thiệu JADE – một framework hỗ trợ xây dựng hệ đa tác tử trên ngôn ngữ Java. Đây là nền tảng kiến thức căn bản để xây dựng công cụ tự sinh mã aspect trong khóa luận của tôi. Chương 4: Trình bày phương pháp xây dựng máy trạng thái mô tả biểu đồ trạng thái và biểu đồ trình tự UML. Trong chương này, tôi sẽ trình bày cách phân tích tài 4
  13. liệu XMI mô tả các biểu đồ UML, từ đó xây dựng các cấu trúc dữ liệu cần thiết để lấy dữ liệu từ tài liệu XMI hình thành nên máy trạng thái. Chương 5: Xây dựng công cụ tự sinh mã aspect từ máy trạng thái. Trong chương này, tôi sẽ trình bày chi tiết thuật toán sinh mã aspect từ máy trạng thái mô tả biểu đồ UML. Đồng thời tôi trình bày ph ương pháp sinh m aspect kiểm chứng giao ã thức (AB)n – một mở rộng cho công cụ Protocol Verification Generator. Chương 6: Cài đặt công cụ Protocol Verification Generator tự sinh aspect. Sau đó, tiến hành kiểm chứng một số giao thức thực tế. Chương 7: Đưa ra các kết luận của khóa luận và hướng nghiên cứu tiếp theo trong tương lai. 5
  14. Chương 2. Giới thiệu lập trình h ớng khía cạnh ư (Aspect-Oriented Programming) và AspectJ 2.1 Phương pháp lập trình hướng khía cạnh Có lẽ các khái niệm về lập trình hướng khía cạnh (AOP) hiện nay đã được nhiều người biết đến, vì vậy ở đây tôi sẽ chỉ trình bày lại ngắn gọn các khái niệm cơ bản và đặc điểm chính của AOP. Để trả lời được câu hỏi AOP là gì? Tại sao phải có AOP? chúng ta sẽ bắt đầu tìm hiểu sự hạn chế của các phương pháp lập trình hiện tại trong việc đáp ứng các yêu cầu ngày càng phức tạp của các hệ thống phần mềm. 2.1.1 Sự hạn chế của lập trình hướng đối tượng (OOP) Như chúng ta đã bi ết trong OOP người ta cố gắng mô tả thế giới thực thành các đối tượng với các thuộc tính và phương thức; cùng với các tính chất của lập trình hướng đối tượng như: tính trừu tượng, tính đóng gói, tính kế thừa và đa h đã làm ình thay đổi hoàn toàn ngành công nghiệp phần mềm. Hình 2.1: OOP Ta xét một bài toán cụ thể: Cần xây dựng một chương trình vẽ hình đơn giản như hình vẽ mô tả dưới đây: 6
  15. Hình 2.2: Mô tả chương trình vẽ hình đơn giản Một phân tích đơn giản cho yêu cầu của bài toán: Các hình học cơ bản: điểm, đoạn thẳng, hình chữ nhật, hình tròn… - Hiển thị các hình ở các vị trí khác nhau trong khung vẽ. - Phải cập nhật lại hình tại vị trí mới mỗi khi di chuyển, co giãn hình. - Sử dụng OOP ta sẽ mô hình hóa yêu cầu thành các đối tượng như sau: Lớp Shape: là một lớp Abstract chứa phương thức moveBy(int, int) – di - chuyển hình. Lớp Display: hiển thị hình ảnh. - Lớp Point: mô tả một điểm hình học. Chứa hai thuộc tính là hai tọa độ x, y - và được kế thừa từ lớp Shape. Lớp Line: mô tả đoạn thẳng, chứa hai thuộc tính là hai điểm mút của đoan - thẳng và cũng được kế thừa từ lớp Shape. Ở đây tôi không đi quá sâu vào đặc tả bài toán, chỉ mô tả một số lớp đơn giản nhất. Dưới đây là sơ đồ lớp cho bài toán vẽ hình: 7
  16. Hình 2.3: Sơ đồ lớp cho bài toán vẽ hình Mô hình hóa thành các lớp như vậy ta thấy bài toán đã tương đối ổn. Bây giờ vấn đề đặt ra là mỗi khi ta thay đổi tọa độ của một điểm hay co giãn hình, di chuyển hình ta lại phải vẽ lại hình ở vị trí mới – tức là phải update lại Display. Xét lớp đơn giản nhất là lớp Point, Khi đặt lại tọa độ x, tọa độ y, hay di chuyển Point từ vị trí này sang vị trí khác, ta đều phải update lại Display thông qua phương thức display.update(this). Như vậy, cùng một phương thức display.update(this), ta phải gõ lại ở ba vị trí khác nhau ứng với ba sự thay đổi. Hãy thử tưởng tượng xem nếu chương trình c ủa chúng ta đủ lớn và có khoảng vài ngàn sự thay đổi kiểu như thế thì dòng mã nguồn display.update(this) sẽ phải xuất hiện ở hàng ngàn chỗ khác nhau. Đối với lớp Line hay các lớp khác cũng vậy. Mỗi khi có sự thay đổi hình thì ngay sau sự thay đổi đó sẽ có dòng mã nguồn display.update(this) đi kèm theo nó. Hình 2.4: Cập nhật hình khi có sự thay đổi 8
  17. Giả sử chương trình v ẽ hình của chúng ta đã hoàn thành m ỹ mãn với đầy đủ các chức năng cơ bản. Đột nhiên, khách hàng yêu cầu cần phải ghi lại những sự thay đổi khi vẽ hình ra một file log.txt. Ôi! Điều này thực sự là rất khổ sở cho lập trình viên khi phải dò lại toàn bộ mã nguồn, xem đoạn nào có sự thay đổi hình, chèn thêm vàođó một dòng mã nguồn có chức năng lưu vết ra file log.txt. Ta có thể chia các chức năng của một phần mềm ra làm hai loại chính: Thứ nhất là các chức năng thực hiện các nghiệp vụ chính, nghiệp vụ cơ - bản của hệ thống (ví dụ như chức năng vẽ điểm, vẽ đoạn thẳng, vẽ hình khối trong bài toán vẽ hình ở trên). Thứ hai, những chức năng dàn trải trên rất nhiều các mô-đun nghiệp vụ - chính – được gọi là các chức năng cắt ngang hệ thống (ví dụ: cập nhật hình, lưu vết, bảo mật) hay được gọi là crosscutting concern. OOP có thể giải quết rất tốt những chức năng chính của hệ thống, nhưng lại gặp rất nhiều khó khăn trong việc giải quyết các chức năng cắt ngang hệ thống. Khi sử dụng OOP để thực hiện các chức năng cắt ngang hệ thống, hệ thống sẽ gặp phải hai vấn đề chính, đó là: chồng chéo mã nguồn (Code tangling) và dàn trải mã nguồn (Code scattering) [12]. Chồng chéo mã nguồn: Mô-đun chính của hệ thống ngoài việc thực hiện - các yêu cầu chính, nó còn phải thực hiện các yêu cầu khác như: tính đồng bộ, bảo mật, lưu vết, lưu trữ. Như vậy, trong một mô-đun có rất nhiều loại mã khác nhau, hiện tượng này gọi là chồng chéo mã nguồn. Điều này làm cho tính mô-đun hóa của hệ thống giảm đi, khả năng sử dụng lại mã nguồn thấp, khó bảo trì hệ thống. Dàn trải mã nguồn: Cùng một mã nguồn của các chức năng cắt ngang hệ - thống được cài đặt lặp đi lặp lại rất nhiều lần ở nhiều mô-đun chính của hệ thống. Ví dụ như trong chương trnh vẽ hình ở trên, mã nguồn của chức ì năng cập nhật hình, l u v ết xuất hiện ở tất cả các mô-đun của hệ thống. ư Hiện tượng này gọi là dàn trải mã nguồn. 2.1.2 Lập trình hướng khía cạnh (AOP) Lập trình hướng khía cạnh được xây dựng trên các phương pháp lập trình hiện tại như lập trình hư ớng đối tượng, lập trình có cấu trúc, bổ sung thêm các khái niệm và cấu trúc để mô-đun hóa các chức năng cắt ngang hệ thống (crosscutting concern). Với AOP, các quan hệ cơ bản sử dụng các phương pháp cơ bản. Nếu sử dụng OOP, sẽ thực 9
  18. thi các quan hệ cơ bản dưới hình thức lớp (class). Các aspect trong hệ thống đóng gói các chức năng cắt ngang hệ thống lại với nhau. Chúng sẽ quy định cách các mô-đun khác nhau gắn kết với nhau để hình thành lên hệ thống cuối cùng. Nền tảng cơ bản của AOP khác với OOP là cách quản lý các chức năng cắt ngang hệ thống. Việc thực thi của từng chức năng cắt ngang AOP bỏ qua các hành vi được tích hợp vào nó. Ví dụ một mô-đun nghiệp vụ sẽ không quan tâm nó cần được lưu vết hoặc được xác thực như thế nào, kết quả là việc thực thi của từng concern tiến triển một cách độc lập. Quay trở lại với ví dụ về chương trình vẽ hình đơn giản ở phần trên. Nếu sử dụng AOP, các chức năng cắt ngang hệ thống: cập nhật hình, lưu vết sẽ được giải quyết theo cách sau: Thay vì tích hợp chức năng các mô-đun cắt ngang hệ thống (cập nhật hình, lưu vết) ngay trong mô-đun nghiệp vụ chính; lập trình viên sẽ tách chúng ra thành các mô- đun mới, gọi là aspect. Hình 2.5 minh họa cho việc thực thi chức năng cập nhật hình bằng AOP và dưới đây là mã nguồn của aspect đó public aspect UpdateSignaling { pointcut updateDisplay(): execution(void *.setX(int)) || execution(void *.setY(int)) || execution(void *.moveBy(int,int)); after(): updateDisplay() { display.update(this); } } Hình 2.5: Dùng AOP giải quyết bài toán vẽ hình 10
  19. Sau khi định nghĩa một aspect như vậy thì bất cứ khi nào có sự thay đổi về hình (setX, setY, moveBy) chương trnh s ẽ tự động gọi chức năng cập nhật hình, cụ thể ở ì đây là phương thức display.update(this) mà ta không cần phải lục lọi lại các đoạn mã nguồn để thêm nó dòng mã nguồn này vào. (các khái niệm cơ bản của aspect như: advice, join point, pointcut, aspect tôi sẽ trình bày cụ thể trong phần 2.2 nói về AspectJ). Phương pháp luận của AOP 2.1.2.1 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 nối chúng lại để tạo nên hệ thống cuối cùng. AOP bổ xung cho OOP bằng việc hỗ trợ một dạng mô-đun khác, cho phép kéo theo thể hiện chung của các vấn đề đan nhau vào một khối. Khối này gọi là ‘aspect’ (tạm dịch là ‘lát’ – hàm ý cắt ngang qua nhiều lớp đối tượng). Từ chữ ‘aspect’ này chúng ta có mội phương pháp lập trình mới: Aspect-Oriented Programming. Nhờ mã được tách riêng biệt, các vấn đề đan xen 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 việc kết hợp các thành phần riêng lẻ thành một hệ thống thống nhất. Ưu điểm của AOP 2.1.2.2 AOP là một kỹ thuật mới đầy triển vọng, hứa hẹn đem 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ụ thể của AOP [12]: Mô-đun hóa những vấn đề đan xen nhau: AOP xác định vấn đề một - cách riêng biệt, cho phép mô-đun hóa những vấn đề liên quan đến nhiều lớp đối tượng. Tái sử dụng mã nguồn 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ã nguồn. Cho phép mở rộng hệ thống dễ dàng hơn: Một thiết kế tốt phải tính đến - cả những yêu cầu hiện tại và tương lai, việc xác định các yêu cầu trong tương lai là một công việc khó khăn. Nhưng nếu bỏ qua các yêu cầu trong tương lai, có thể bạn sẽ phải thay đổi hay thực hiện lại nhiều phần của hệ thống. Với AOP, người thiết kế hệ thống có thể để lại quyết định thiết kế cho những yêu cầu trong tương lai nhờ thực hiện các aspect riêng biệt. 11
  20. 2.2 AspectJ AspectJ là sự mở rộng theo mô hình AOP của ngôn ngữ Java, với sự mở rộng này mã chương trình viết bằng Java sẽ tương thích với chương trình viết bằng AspectJ. AspectJ gồm hai phần cơ bản là: Đặc tả ngôn ngữ: Chỉ ra cách viết mã, với AspectJ các chức năng cơ bản - của hệ thống sẽ được viết bằng Java còn các chức năng cắt ngang hệ thống sẽ được thực hiện bởi AspectJ. Phần thực thi: Cung cấp các công cụ biên dịch, gỡ lỗi. AspectJ đã đư ợc - plugin vào công cụ phát triển Eclipse (http://www.eclipse.org/) và được đánh giá là sản phẩm tốt nhất hiện nay về AOP. Một số khái niệm cơ bản trong AspectJ: 2.2.1 Join point Join point là bất kỳ điểm nào có thể xác định được khi thực hiện chương trình [7, 12]. Ví dụ: lời gọi hàm, khởi tạo đối tượng. Join point chính là vị trí mà các hành động thực thi cắt ngang được đan vào. Trong AspectJ mọi thứ đều xoay quanh join point. Một số loại join point chính trong AspectJ: Join point tại hàm khởi tạo (constructor). - Join point tại các phương thức. - Join point tại các điểm truy cập thuộc tính. - Join point tại các điểm điều khiển ngoại lệ: Được điều khiển trong khối - điều khiển ngoại lệ. 2.2.2 Pointcut Pointcut là một cấu trúc chương trình mà nó ch ọn các join point và ngữ cảnh tại các join point đó [7, 12]. Ví dụ một pointcut có thể chọn một join point là lời gọi đến một phương thức và lấy thông tin ngữ cảnh của phương thức đó như đối tượng chứa phương thức đó, các tham số của phương thức đó. Cú pháp của pointcut được khai báo như sau: [access specifier] pointcut pointcut-name([args]) : pointcut- definition; Ví dụ: public pointcut test(): call(void Line.setP1(Point)); 12
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2