Đồ án môn học: Nghiên cứu về AOP

Chia sẻ: Nguyên Hoàng | Ngày: | Loại File: PDF | Số trang:66

Thêm vào BST

Báo xấu

177
lượt xem 31
download

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

Đồ án môn học: Nghiên cứu về AOP là đề tài nghiên cứu của nhóm sinh viên nhằm giới thiệu về AOP cũng như những ứng dụng của của phương pháp lập trình này. Đến với tài liệu này sẽ giúp nâng cao hơn nữa về khả năng lập trình và hiểu biết thêm về các thiết kế cho từng đối tượng trên nền AOP.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Đồ án môn học: Nghiên cứu về AOP

 ĐỒ ÁN MÔN HỌC NGHIÊN CỨU VỀ AOP GIẢNG VIÊN HƯỚNG DẪN: HUỲNH QUYẾT THẮNG
1 Giới thiệu ................................................................................................................ 6 1.1 Mục đích và cấu trúc của tài liệu ...................................................................... 6 1.2 Các thuật ngữ ................................................................................................... 6 1.3 Hạn chế của các phương pháp lập trình hiện tại ................................................ 7 2 Các đặc điểm của AOP ............................................................................................ 8 2.1 Quản lý các concern hệ thống........................................................................... 9 2.2 Phương pháp luận của AOP ........................................................................... 12 2.2.1 Ưu điểm của AOP .................................................................................. 13 2.2.2 Những nhược điểm ................................................................................. 13 2.3 Một số công cụ hỗ trợ làm việc với AOP ........................................................ 14 3 Giới thiệu AspectJ ................................................................................................. 14 3.1 Giới thiệu ....................................................................................................... 14 3.2 Một số khái niệm ........................................................................................... 14 3.2.1 Join point ............................................................................................... 15 3.2.2 Pointcut .................................................................................................. 16 3.2.3 Advice.................................................................................................... 16 3.2.4 Introduction............................................................................................ 17 3.2.5 Aspect .................................................................................................... 18 3.2.6 Static crosscutting .................................................................................. 19 3.3 Một số ứng dựng cơ bản của AOP .................................................................. 20 4 Giải quyết bài toán với AOP .................................................................................. 21 4.1 Sử dụng AOP trong bước thiết kế................................................................... 21 4.2 Sử dụng AOP trong bước thi công.................................................................. 22 4.3 Sử dụng AOP trong bước kiếm tra ................................................................. 22 4.4 Sử dụng AOP trong giai đoạn bảo trì.............................................................. 23 5 Triển khai một số pattern trên AspectJ ................................................................... 23 5.1 Các mẫu thiết kế cho việc tạo đối tượng ......................................................... 24 5.1.1 Singleton pattern .................................................................................... 24 5.1.2 Prototype pattern .................................................................................... 26 5.1.3 Abstract Factory pattern ......................................................................... 28 5.1.4 Factory Method pattern .......................................................................... 30 5.1.5 Builder pattern ....................................................................................... 31 5.2 Các mẫu thiết kế cho cấu trúc của đối tượng .................................................. 32 5.2.1 Composite pattern .................................................................................. 32 5.2.2 Flyweight pattern ................................................................................... 35
5.2.3 Bridge Pattern ........................................................................................ 37 5.2.4 Decorator pattern.................................................................................... 38 5.2.5 Adapter pattern....................................................................................... 39 5.2.6 Proxy Pattern.......................................................................................... 40 5.3 Các mẫu thiết kế cho hành vi của đối tượng ................................................... 42 5.3.1 Observer pattern ..................................................................................... 42 5.3.2 Command Pattern ................................................................................... 46 5.3.3 Iterator pattern........................................................................................ 50 5.3.4 Mediator pattern ..................................................................................... 51 5.3.5 Chain of Responsibility Pattern .............................................................. 53 5.3.6 Memento Pattern .................................................................................... 56 5.3.7 Visitor Pattern ........................................................................................ 58 5.3.8 Strategy pattern ...................................................................................... 61 5.3.9 State Pattern ........................................................................................... 63 6 Kết luận ................................................................................................................. 64 7 Tài liệu tham khảo ................................................................................................. 66
Mục lục hình ảnh Hình 1: Mô hình các concern mức hệ thống ..................................................................... 9 Hình 2: Mô hình ánh xạ yêu cầu người dùng sử dụng AOP............................................ 10 Hình 3: Mô hình đa chiều về sự phụ thuộc giữa các module với nhau ............................ 10 Hình 4: Mô hình ánh xạ từ các concern hệ thống sang các phương pháp lập trình truyền thống ..................................................................................................................... 11 Hình 5: Các module yêu cầu logging đều phải nhúng các đoạn mã để gọi logging API .. 11 Hình 6: Giải quyết các concern hệ thống bằng phương pháp AOP ................................. 12 Hình 7: Các giai đoạn phát triển sử dụng phương pháp AOP ......................................... 13 Hình 8: Cấu trúc của aspect trừu tượng với interface và các hàm được định nghĩa để hỗ trợ Singleton pattern .............................................................................................. 25 Hình 9:Một ứng dụng trước và sau khi được tác động bởi Singleton pattern .................. 25 Hình 10: Các bước thực hiện của mẫu thiết kế Singleton trong ứng dụng....................... 26 Hình 11: Cấu trúc của PrototypePattern aspect .............................................................. 27 Hình 12:Một ứng dụng trước và sau khi được tác động bởi Prototype pattern ................ 28 Hình 13: Sử dụng Prototype pattern trong ứng dụng ...................................................... 28 Hình 14: Lược đồ UML của AbstractFactory Pattern ..................................................... 29 Hình 15: Lược đồ UML của factory method pattern ...................................................... 30 Hình 16: Cấu trúc của CompositePattern aspect ............................................................. 32 Hình 17: Mô hình các đối tượng trước khi áp dụng Composite pattern........................... 34 Hình 18: Mô hình các đối tượng sau khi áp dụng Composite pattern.............................. 35 Hình 19: Hoạt động của composite pattern trong ứng dụng ............................................ 35 Hình 20: Cấu trúc của FlyweightPattern aspect .............................................................. 35 Hình 21:Cấu trúc của XWindowBridge aspect ............................................................... 37 Hình 22: Sử dụng các hành vi của lớp Window trong ứng dụng ..................................... 38 Hình 23: Cấu trúc của DecoratorPattern aspect .............................................................. 38 Hình 24:Lớp TextDisplay trước và sau khi áp dụng DecoratorPattern............................ 39 Hình 25: Áp dụng Adapter pattern ................................................................................. 40 Hình 26: Cấu trúc của ProxyPattern aspect .................................................................... 40 Hình 27: Cấu trúc của ObserverPattern aspect ............................................................... 43 Hình 28: Cấu trúc lớp trước khi áp dụng ObserverPattern .............................................. 44 Hình 29:Cấu trúc lớp sau khi áp dụng ObserverPattern .................................................. 45 Hình 30:Sử dụng ObserverPattern trong ứng dụng ......................................................... 45 Hình 31: Cấu trúc của CommandPattern và các hàm hỗ trợ pattern ................................ 46 Hình 32: Trước khi áp dụng CommandPattern............................................................... 48
Hình 33:Trước khi áp dụng CommandPattern................................................................ 48 Hình 34: Sử dụng CommandPattern trong ứng dụng ...................................................... 49 Hình 35: IteratorPatternAspect và interface định nghĩa vài trò của pattern ..................... 50 Hình 36: Mô tả sự tương tác của EmployeeIteration với ứng dụng ................................. 51 Hình 37: Cấu trúc của MediatorPattern aspect ............................................................... 51 Hình 38: Trước và sau khi áp dụng Mediator pattern ..................................................... 53 Hình 39: Cấu trúc của ChainOfResponsibilityPattern aspect .......................................... 53 Hình 40: Sau khi áp dụng ChainOfResponsibilityPattern ............................................... 55 Hình 41:Sử dụng ChainOfResponsibilityPattern trong ứng dụng .................................. 56 Hình 42: Cấu trúc của MementoPattern aspect............................................................... 57 Hình 43: Sử dụng MementoPattern trong ứng dụng ....................................................... 58 Hình 44: Cấu trúc của Visitor pattern aspect .................................................................. 58 Hình 45: Cấu trúc của Computeur ................................................................................. 60 Hình 46: Cấu trúc Computeur sau khi áp dụng Visitor pattern ....................................... 60 Hình 47:Sử dụng VisitorPattern trong ứng dụng ............................................................ 61 Hình 48:Cấu trúc của StrategyPattern aspect ................................................................. 62 Hình 49: Cấu trúc các lớp sắp xếp khi chưa áp dụng StrategyPattern ............................. 62 Hình 50: Cấu trúc các lớp sắp xếp sau khi áp dụng StrategyPattern................................ 62 Hình 51: Sử dụng Strategy Pattern trong ứng dụng ........................................................ 63 Hình 52: Sử dụng state pattern trong ứng dụng .............................................................. 64
1 Giới thiệu Việc chuyển đổi các yêu cầu của người dùng vào trong một hệ thống phần mềm bao giờ cũng rất khó khăn, mặc dù hiện nay đã có rất nhiều phương pháp tiếp cận như lập trình hướng đối tượng, hướng thành phần, các design pattern ...Chúng cũng đã giải quyết được một số vấn đề nhưng vẫn chưa có một phương pháp nào thoả mãn việc giải quyết các yêu cầu đan xen ở mức hệ thống, các yêu cầu này được mô tả bằng khái niệm crosscutting concern. Các nhà nghiên cứu lý thuyết đã đưa ra mô hình AOP để giải quyết các vấn đề mà các mô hình lập trình hiện tại chưa đáp ứng được hoặc đáp ứng được nhưng việc thực hiện nó quá phức tạp. AOP không phát minh và điều gì mới mà chỉ giải quyết các vấn đề đã tồn tại theo cách tốt hơn. (How to do the bad things in better way) 1.1 Mục đích và cấu trúc của tài liệu Tài liệu này được tổng hợp từ nhiều nguồn khác nhau (xem phần tài liệu tham khảo), bao gồm các cuốn sách, các bài báo, các luận văn …về vấn đề nghiên cứu và ứng dụng AOP trong ngành công nghệ phần mềm. Tài liệu nhằm mục đích tìm hiểu mô hình AOP và đi sâu trình bày một trong những kỹ thuật quan trọng của ngành công nghệ phần mềm hiện nay là design pattern trên mô hình AOP Trước khi đọc tài liệu này bạn cần có kiến thức cơ bản về kỹ thuật lập trình hướng đối tượng, các mẫu thiết kế, các kiến trúc của phần mềm, … trong ngành công nghệ phần mềm hiện nay. Đồng thời cũng cần kinh nghiệm thực tế về những khó khăn mà các phương pháp lập trình hiện tại đang gặp. Tài liệu được chia thành 2 phần chính sau Phần thứ nhất, từ mục 1 đến 5: Trình bày các vấn đề cơ bản về AOP, giới thiệu một phiên bản thi công của nó là AspectJ, cú pháp và các khái niệm của AspectJ. Ngoài ra trong phần này, tài liệu cũng đề cập đến các ứng dụng thích hợp cho việc áp dụng AOP. Phần thứ 2, từ mục 6 đến hết: Trình bày cách triển khai các mẫu thiết kế (design pattern) đã được sử dụng trong mô hình OOP sang mô hình AOP, cụ thể là triển khai trên cú pháp của AspectJ. 1.2 Các thuật ngữ Trước khi đi vào tìm hiểu về AOP (một phương pháp lập trình mới) chúng ta cần hiểu một số thuật ngữ trong ngành công nghệ phần mềm hiện nay.
crosscutting concerns Chỉ các quan hệ giữa các module trong một hệ thống phần mềm. refactoring Refactoring là một kỹ thuật trong công nghệ phần mềm mà mã nguồn chương trình được cấu trúc lại nhằm đảm bảo tính mềm dẻo, mở rộng chức năng của chương trình đồng thời mã chương trình dễ hiểu hơn cho người đọc. middleware Là lớp trung gian trong các hệ thống phần mềm . Một số middleware tiêu biểu như EJB của Sun, Net Framework của Microsoft AOP Mô hình lập trình hướng tương quan design pattern Là giải pháp thực hiện khi thiết kế các ứng dụng nhằm đảm bảo chất lượng, tăng tính mềm dẻo, tính trong sáng của mã chương trình. Một số pattern hay được sử dụng như IOC (Inversion of Control), Singleton, Proxy, Abstract Factory Class 1.3 Hạn chế của các phương pháp lập trình hiện tại Có lẽ khái niệm về AOP hiện nay đã được nhiều người biết đến, vì vậy ở đây ta chỉ trình bày lại ngắn gọn các khái niệm cơ bản và các đặ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 cần bắt đầu tìm hiểu sự hạn chế của 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. Có lẽ các câu hỏi thường gặp nhất trong ngành công nghệ phần mềm hiện nay là:Thiết kế một phần mềm như thế nào được gọi là đủ? Các hệ thống tốt cần xem xét đến những yêu cầu hiện tại và cả những yêu cầu tiềm tàng trong tương lai. Sự lơ là các yêu cầu trong tương lai có thể dẫn đến thay đổi nhiều phần của hệ thống hoặc có thể phải xây dựng lại. Hay nói một cách khác, các thiết kế có khả năng đáp ứng nhu cầu cho tương lai kém có thể dẫn đến hiện tượng “tràn thiết kế”, khó hiểu, hệ thống phình ra không mong muốn. Từ đó hình thành một yêu cầu có một thiết kế có thể đáp ứng được các yêu cầu trong tương lai mà không ảnh hưởng đến chất lượng.
Phương pháp lập trình OOP hiện tại đã tạo ra một cuộc cách mạng lớn trong công nghệ phần mềm, ảnh hưởng đến tất cả các pha từ xác định yêu cầu, phân tích, thiết kế, cài đặt, kiểm thử đến các hệ quản trị cơ sở dữ liệu ... Tuy nhiên, người ta nhận thấy OOP modul hoá yêu cầu theo kiểu mô phỏng một đối tượng (object) trong thế giới thực. Nhưng sự mô phỏng này chỉ dừng ở mức tĩnh. Các đối tượng trong OOP hoạt động theo qui trình: Sinh-Hoạt động-Tử, nhưng ở thế giới thực, thường thì một object có một chu kỳ sống: Sinh-Hoạt động-Phát triển-Tử. Ở đây, 'Phát triển' là điều quan trọng, giải quyết được nó tức bạn đã giải quyết được tính tiến hoá, thay đổi yêu cầu của bài toán phần mềm. Theo OOP, bạn phải cân nhắc giữa dự đoán trước các yêu cầu phát triển  Phát triển phần mềm nặng nề, hoặc bỏ qua các yêu cầu phát triển tương lai  hệ thống thiếu tính khả mở, tiến hoá. Nhược điểm trên của OOP là thấy rõ nhất, nhược điểm thứ hai là: Một hệ thống thực tế là sự đan xen nhau giữa các yêu cầu. Lấy ví dụ: Bạn cần xử lý nghiệp vụ truy xuất dữ liệu. Trong bản thiết kế, bạn có thể phân công trách nhiệm này cho một object cụ thể nào đó và vấn đề này rất bình thường. Nhưng cùng với yêu cầu nghiệp vụ trên, thường thì cần bổ sung vào các yêu cầu: Chứng thực, Phân quyền, Bảo mật, Lưu vết... Như vậy trong method TruyXuatDuLieu() của một đối tượng được chỉ định nào đó, bạn phải bổ sung code cho các yêu cầu nêu trên. Tình trạng này, người ta gọi là sự chồng chéo giữa các yêu cầu. Nó làm nên một hệ thống lộn xộn, khó bảo trì, phát triển, tính tiến hoá cũng bị ảnh hưởng. Vì khi cần bổ sung thêm một nghiệp vụ nào khác, bạn phải thay đổi tất cả các yêu cầu nghiệp vụ liên quan. 2 Các đặc điểm của AOP AOP được xây dựng trên các phương pháp lập trình hiện tại như OOP và lập trình có cấu trúc.., bổ sung các khái niệm và cấu trúc để module hoá các quan hệ đan xen. 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 thi các quan hệ cơ bản dưới hình thức lớp. Các aspect trong hệ thống đóng gói các quan hệ đan xen lại với nhau. Chúng sẽ qui định cách các module khác nhau gắn kết với nhau để định hình lên hệ thống cuối cùng. Nền tảng cơ bản AOP khác với OOP là cách quản lý các quan hệ đan xen.Việc thực thi của từng quan hệ của AOP bỏ qua các hành vi được tích hợp vào nó. Ví dụ, bussiness module sẽ không quan tâm nó cần được log hoặ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.
2.1 Quản lý các concern hệ thống Concern là các yêu cầu cụ thể hay mối quan tâm đặc trưng được xác định để thoả mãn mục tiêu chung của hệ thống. Hệ thống phần mềm là sự gắn kết của tập các concern. Ví dụ, hệ thống ngân hàng bao gồm các concern sau đây: quản lý khách hàng và quản lý tài khoản, các giao dịch nội ngân hàng, các giao dịch ATM, chăm sóc khách hàng, lưu giữ các thực thể trong hệ thống, xác nhận truy cập các dịch vụ, …Ngoài ra một phần mềm còn phải đảm bảo khả năng dễ hiểu, dễ bảo hành và duy trì, dễ phát triển. Concern được chia làm hai loại 1. Concern thành phần: Thể hiện các chức năng nội tại của một module. 2. Concern đan xen: Thể hiện các quan hệ ràng buộc giữa các module trong hệ thống Một ứng dụng doanh nghiệp điển hình có thể bao gồm các concern đan xen sau: authentication, logging, resource pooling, performance, storage management, data persistence, security, multithread safety, transaction integrity, error checking… Các concern được phục vụ cho một vài module. Ví dụ, logging tác động tới tất cả module trong hệ thống, authencication tác động tới module có yêu cầu kiểm soát truy cập Hình 1: Mô hình các concern mức hệ thống Việc xác định được các concern trong hệ thống, chúng ta sẽ tập trung vào các concern một cách độc lập và sẽ giảm độ phức tạp của hệ thống.
Hình 2: Mô hình ánh xạ yêu cầu người dùng sử dụng AOP Hình 3: Mô hình đa chiều về sự phụ thuộc giữa các module với nhau Các concern đan xen nhau giữa các module, các kỹ thuật thi công hiện tại sẽ trộn chúng vào một module. Hình sau minh hoạ sự thực hiện này: Với mô hình biểu diễn nhiều chiều của các concern được ánh xạ trên các ngôn ngữ một chiều như sau.
Hình 4: Mô hình ánh xạ từ các concern hệ thống sang các phương pháp lập trình truyền thống Trong thiết kế phần mềm cách tốt nhất để đơn giản các hệ thống phức tạp là xác định các concern rồi module hoá chúng. OOP được thiết kế để phục vụ việc module hoá các concern cơ bản, nhưng khi gặp concern mức hệ thống thì OOP không đáp ứng được yêu cầu. Hình sau minh hoạ một ví dụ thiết kế dùng phương pháp truyền thống. Ngay cả khi bạn có một bản thiết kế tốt của logging module như: cung cấp các API trừu tượng (Abstract API), giấu cách định dạng log message…Các module còn lại vẫn cần phải nhúng các đoạn mã để gọi các logging API. Hình 5: Các module yêu cầu logging đều phải nhúng các đoạn mã để gọi logging API
Đây chính là vấn đề sẽ được giải quyết bằng AOP, sử dụng AOP các module khác không cần chứa đoạn mã gọi logging API. Hình 7 chỉ ra cách thực hiện module logging dùng AOP có cùng chức năng với cách sử dụng OOP, như đã được chỉ ra trên hình vẽ, cách thực hiện log bây giờ chỉ tồn tại trong logging module và logging aspect. Các modulek khác không chứa bất kỳ đoạn mã nào gọi đến logging API. Như vậy các yêu cầu đan xen giữa logging module và các module khác được thực hiện duy nhất trong một module hay logging aspect. Với phương pháp module hoá này bất cứ sự thay đổi yêu cầu nào về logging chỉ ảnh hưởng duy nhất đến logging aspect. Hình 6: Giải quyết các concern hệ thống bằng phương pháp AOP 2.2 Phương pháp luận của AOP Việc phát triển các hệ thống sử dụng AOP tương tự như phát triển các hệ thống sử dụng các phương thức khác: xác đinh concern, thực hiện chúng, kết hợp lại để thành hệ thống cuối cùng. Tuy nhiên cộng đồng nghiên cứu AOP đề xuất ba bước thực hiện sau: 1. Aspectual decomposition: Trong bước này chúng ta phân tách các yêu cầu nhằm xác định các concern lõi và concern đan xen. Các concern lõi được tách ra khỏi các concern đan xen. 2. Concern Implementation: Thực thi các concern một cách độc lập
3. Aspectual Recomposotion: Trong bước này chúng ta chỉ ra các quy lật kết hợp bằng cách tạp ra các aspect. Quá trình này còn được gọi là quá trình dệt mã, sử dụng các thông tin trong aspect để cấu thành hệ thống đích Hình 7: Các giai đoạn phát triển sử dụng phương pháp AOP 2.2.1 Ưu điểm của AOP Khi sử dụng AOP để giải quyết các bài toán chúng ta cần suy nghĩ về thiết kế và thi công hệ thống theo một phương thức mới, với AOP ta sẽ có các ưu điểm sau 1. Tách biệt chức năng hơn của các module độc lập 2. Tính module hoá cao hơn 3. Phát triển hệ thống dễ dàng hơn 4. Kết nối muộn thiết kế 5. Tăng khả năng sử dụng lại mã 6. Giảm thời gian thi công hệ thống 7. Giảm giá thành của sản phẩm 2.2.2 Những nhược điểm Mặc dù AOP có các ưu điểm trên khi thiết kế và thi công một hệ thống,nhưng trên thực tế AOP cũng có một vài đặc điểm gay trở ngại sau 1. AOP thực ra không giải quyết các vấn đề mới, không giải quyết được vấn đề vẫn chưa được giải quyết. AOP giải quyết các bài toán theo cách tốt hơn 2. AOP không là cứu cánh cho các thiết kế cẩu thả 3. AOP phá vỡ tính đóng gói (encapsulation)
2.3 Một số công cụ hỗ trợ làm việc với AOP AOP hiện nay đã được nghiên cứu và áp dụng vào hầu hết các ngôn ngữ như Java, C, C#, Python, PHP .. Tên dự án Địa chỉ 1. AspectJ Aspectj.org 2. AspectWerkz Aspectwerkz.codehaus.org 3. Jboss AOP Jboss.org 4. Sping AOP www.spring framework.org 5. Aspect# Aspectsharp.sourceforge.net 6. AspectC++ Aspectc.org 7. JAC Jac.objectweb.org 3 Giới thiệu AspectJ 3.1 Giới thiệu 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 bao gồm hai phần: đặc tả ngôn ngữ và phần thực thi. Phần đặc tả ngôn ngữ sẽ chỉ ra cách viết code, với AspectJ các concern cơ bản được viết bằng Java, các concern hệ thống được thực hiện bởi AspectJ. AspectJ đã được plugin vào công cụ phát triển Eclipse (eclipse.org) và được đánh giá là sản phẩm tốt nhất hiện nay về AOP 3.2 Một số khái niệm Như đã biết mục đích của AOP là module hoá các concern đan xen nhau. AspectJ định nghĩa 2 loại concern: 1. concern đan xen tĩnh (static crosscutting): Là sự gắn kết thay đổi trong một cấu trúc tĩnh (class, interface, aspect). Nghĩa là khi chúng ta thực hiện một thay đổi đến các cấu trúc dữ liệu tĩnh để đáp ứng các yêu cầu của bài toán. 2. concern đan xen động (dynamic crosscutting): là sự gắn kết các hành vi mới vào chương trình, hầu hết các concern đan xen trong AspectJ là concern đan xen động. AspectJ sử dụng dự mở rộng của Java để chỉ ra các luật gắn kết cho concern tĩnh và concern động.
3.2.1 Join point Join point là một khái niệm cở bản của AspectJ, Join point có thể là bất kỳ điểm nào có thể xác định được khi thực hiện chương trình. Có thể là lời gọi đến một phương thức hoặc một lệnh gán cho một biến của đối tượng. Trong AspectJ mọi thứ đều xoay quanh join point. public class Account { ... void credit(float amount) { balance + = amount; } } Join point được phân loại như sau  join point tại các phương thức  join point tại hàm dựng (contructor)  join point tại điểm truy cập các thuộc tính  join point tại điểm điều khiển ngoại lệ: Được biểu diễn trong khối điều khiển ngoại lệ try { account.debit(amount); } catch (InsufficientBalanceException ex) { postMessage(ex); OverdraftManager.applyOverdraftProtection(account, amount); }  join point tại các advice: public aspect MannersAspect { before() : deliverMessage() { System.out.print("Hello! "); } } public aspect LoggingAspect { after() : loggedOperations() { ... _logger.log(...); ... }
} 3.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 joint point đó. Ví dụ một pointcut có thể chọn một join point là một 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 đối 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ụ: execution(void Account.creadit(float)) Bảng ánh xạ giữa các join point được chọn cho các point cut Thực hiện phương thức execution(MethodSignature) Gọi phương thức call(MethodSignature) Thực hiện hàm dựng execution(ConstructorSignature) Gọi hàm dựng call(ConstructorSignature) Khởi tạo class staticinitialization(TypeSignature) Đọc thuộc tính get(FieldSignature) Ghi thuộc tính set(FieldSignature) Thực hiện điều khiển ngoại lệ execution handler(TypeSignature) Khởi tạo đối tượng initialization(ConstructorSignature) Tiền khởi tạo đối tượng preinitialization(ConstructorSignature) Thực hiện advice adviceexecution() 3.2.3 Advice Là mã được thực hiện tại một join point mà đã được chọn bởi pointcut. Advice tương tự cấu trúc của hàm cung cấp các thức các hành động đan xen tại các join point mà nó được chọn bởi point cut. Pointcut và advice sẽ hình thành nên các luật đan kết các quan hệ đan xen. Advice được chia thành 3 loại sau 1. before: Được thực hiện trước join point 2. after: Được thực hiện sau join point 3. around: Bao quanh sự thực hiện join point, advice này có thể thực hiện vòng, thực hiện tiếp của mã nguồn ban đầu hoặc thực hiện thay đổi ngữ cảnh (tham số của hàm, …)
Giả sử ta có pointcut được khai báo như sau pointcut connectionOperation(Connection connection) : call(* Connection.*(..) throws SQLException)&& target(connection); Ta có thể xây dựng các advice như sau: before(Connection connection):connectionOperation (connection) { System.out.println("Performing operation on " + connection); } Object around(Connection connection) throws SQLException : connectionOperation (connection) { System.out.println("Operation " + thisJoinPoint + " on " + connection+ " started at " + System.currentTimeMillis()); proceed(connection); System.out.println("Operation " + thisJoinPoint + " on " + connection + " completed at " + System.currentTimeMillis()); } Nếu trong around advice muốn thực hiện thao tác tại join point, phải sử dụng từ khoá proceed(). 3.2.4 Introduction Introduction là một lệnh chỉ ra sự thay đổi đến một class, interface, aspect. Nó tạo ra sự thay đổi tĩnh đến các module mà không trực tiếp ảnh hưởng đến các hành vi của module đó. Ví dụ có thể thêm một phương thức hoặc một trường vào lớp nào đó hoặc sửa đổi cấu trúc thừa kế của một đối tượng. Ví dụ khai báo sau sẽ sửa đổi cấu trúc thừa kế của đối tượng Account. declare parents: Account implements BankingEntity; Introduction là khái niệm sinh ra để can thiệp vào các cấu trúc tĩnh, trong AOP nó được dùng để xử lý các quan hệ đan xen tĩnh (static crosscutting). Chúng ta sẽ đề cập đến vấn đề này trong phần static crosscutting.
3.2.5 Aspect Aspect là phần tử tập trung của AspectJ, giống như class trong Java. Aspect chứa mã thể hiện các luật đan kết cho concern. Join point, pointcut, advice, introduction được kết hợp trong aspect. Aspect được khai báo theo mẫu sau [access specification] aspect [extends class-or-aspect-name] [implements interface-list] [(Pointcut)] { ... aspect body } Ví dụ sau khai báo một aspect: public aspect ExampleAspect { before() : execution(void Account.credit(float)) { System.out.println("About to perform credit operation"); } declare parents: Account implements BankingEntity; declare warning : call(void Persistence.save(Object)) : "Consider using Persistence.saveOptimized()"; } Một số tính chất của khái niệm aspect tương tự khái niệm class  Aspect có thể chứa các thuộc tính và phương thức  Aspect chứa các thuộc tính truy cập: private, public, protected ..  Aspect có thể khai báo như một aspect trừu tượng: public abstract aspect AbstractLogging { public abstract pointcut logPoints(); public abstract Logger getLogger(); before() : logPoints() { getLogger().log(Level.INFO, "Before: " + thisJoinPoint); } }  Aspect có thể thừa kế class, abstract aspect và thi công các interface public aspect BankLogging extends AbstractLogging {
public pointcut logPoints() : call(* banking..*(..)); public Logger getLogger() { return Logger.getLogger("banking"); } }  Aspect có thể nhúng trong class và interface như một aspect nằm trong Ngoài các tính chất tương tự class như trên, aspect cũng có một số đặc điểm khác so với class như sau:  Aspect không thể khởi tạo trực tiếp  Aspect không thể thừa kế từ một aspect khác (không phải trừu tượng)  Aspect có thể được đánh dấu như quyền 3.2.6 Static crosscutting Trong AOP chúng ta thường xuyên can thiệp vào các quan hệ đan xen động sử dụng advice, và cũng cần thiết các hành động can thiệp vào các cấu trúc tĩnh. Trong khi các concern đan xen động sẽ sửa đổi sự thực hiện các thủ tục của chương trình thì sự đan xen tĩnh sẽ sửa đổi các cấu trúc như class, interface, các aspect khác và các hành vi tại điểm dịch chương trình. 3.2.6.1 Giới thiệu thành viên Aspect thường xuyên giới thiệu các thành viên hoặc các phương thức vào trong một lớp aspect . AspectJ cung cấp một có chế được gọi là introduction để giới thiệu các thành viên vào trong các class hoặc interface. Đoạn mã dưới đây mô tả cách giới thiệu 2 thành viên là thuộc tính minimumBalance và phương thức getAvailable() vào lớp Account. Các thành viên được giới thiệu vào một lớp cũng có thể được chỉ ra quyền truy nhập như khai báo các thành viên của một lớp. Ví dụ từ khoá private chỉ ra thành viên chỉ được truy cập từ aspect giới thiệu nó. public aspect MinimumBalanceRuleAspect { private float Account._minimumBalance; public float Account.getAvailableBalance() { return getBalance() - _minimumBalance; } after(Account account) : execution(SavingsAccount.new(..)) && this(account) { account._minimumBalance = 25;
} before(Account account, float amount)throws InsufficientBalanceException : execution(* Account.debit())&& this(account) && args(amount) { if (account.getAvailableBalance() < amount) { throw new InsufficientBalanceException( "Insufficient available balance"); } } 3.2.6.2 Sửa đổi cấu trúc thừa kế Khi thực thi các quan hệ đan xen thường xuyên cần tác động đến tập các class hoặc interface mà chúng có chung một kiểu cơ sở. AspectJ có thể sửa đổi cây thừa kế của một lớp đã tồn tại để khai báo các lớp cha hoặc các interface của lớp đó miễn là không ảnh hưởng đến qui luật thừa kế của Java. Mẫu khai báo như sau: declare parents : [ChildTypePattern] implements [InterfaceList]; declare parents : [ChildTypePattern] extends [Class or InterfaceList]; Ví dụ : Aspect khai báo tất cả các class và interface trong gói entities thực thi Identifiable interface. aspect AccountTrackingAspect { declare parents : banking..entities.* implements Identifiable; ... tracking advices } 3.3 Một số ứng dựng cơ bản của AOP Dưới đây là một số ứng dụng điển hình sử dụng các ưu điểm của AOP trong việc thiết kế và triển khai 1. Các kỹ thuật điều khiển, giám sát (monitor): Các kỹ thuật điều khiển, giám sát như logging, tracing, profiling là những kỹ thuật chung để hiểu được các hành vi xảy ra trong hệ thống. Ví dụ trong hệ thống nhà băng người quản trị muốn theo dõi thông tin mỗi giao dịch trong hệ thống như tên tài khoản, thời gian giao dịch. Vì các chức năng này xuyên suốt qua các module của ứng dụng nên khi triển khai các kỹ thuật này với AOP là một cách tiếp cận tốt nhất có thể