Báo cáo lập trình hướng khía cạnh
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (330.55 KB, 36 trang )
MỤC ĐÍCH BÀI BÁO CÁO:
-Tổng quan về phương pháp luận lập trình
-Giớ thiệu và khái quát về phương pháp lập trình hướng lát cắt
1
MỤC LỤC
Chương II. Lập trình hướng khía cạnh - AOP (Aspect-oriented programming).........................................................14
2.1.Giới thiệu.......................................................................................................................................................... 14
............................................................................................................................................................................... 14
2.1.1.Các thuật ngữ............................................................................................................................................. 15
2.1.2 Hạn chế của các phương pháp lập trình hiện tại......................................................................................... 16
2.2.Các đặc điểm của AOP....................................................................................................................................... 18
2.2.1.Quản lý các concern hệ thống.................................................................................................................... 18
2.2.2.Phương pháp luận của AOP........................................................................................................................ 22
*Ưu điểm của AOP........................................................................................................................................... 23
*Những nhược điểm....................................................................................................................................... 23
2.2.3.Một số công cụ hỗ trợ làm việc với AOP..................................................................................................... 23
2.3.Giới thiệu AspectJ............................................................................................................................................. 24
2.3.1.Giới thiệu................................................................................................................................................... 24
2.3.2.Một số khái niệm....................................................................................................................................... 24
1.Join point..................................................................................................................................................... 24
2.Pointcut....................................................................................................................................................... 26
3.Advice.......................................................................................................................................................... 26
4.Introduction................................................................................................................................................. 28
5.Aspect.......................................................................................................................................................... 28
6.Static crosscutting........................................................................................................................................ 29
2.4.Một số ứng dựng cơ bản của AOP................................................................................................................. 31
Chương III. Demo lập trình hướng khía cạnh - AOP (Aspect-oriented programming)...............................................33
Kết luận.................................................................................................................................................................. 35
KẾT QUẢ TÌM ĐƯỢC................................................................................................................................................ 35
- Tìm kiếm được ứng dụng đã sử dụng lập trình hướng lát cắt................................................................................35
tài liệu tham khảo................................................................................................................................................... 36
6
2
CHƯƠNG I. LỊCH SỬ HÌNH THÀNH VÀ PHÁT TRIỂN CỦA LẬP TRÌNH
1.1. Lịch sử hình thành và phát triển
1.1.1 Kỹ thuật lập trình giai đoạn thứ nhất của MTĐT
Lập trình, hay nói chính xác hơn là học lập trình là một cơng việc nặng
nhọc, năng xuất thấp. Có thể nói năng xuất lập trình đứng cuối bảng so với các
hoạt động trí tuệ khác. Cho đến nay, năng xuất của lập trình viên chỉ dao động
trong khoảng 4-5 lệnh/ngày. Một sản phẩm phần mềm có thể được thiết kế và cài
đặt trong khoảng 6 tháng với 3 lao động chính. Nhưng để kiểm tra và tiếp tục tìm
lỗi, hồn thiện sản phẩm đó phải mất thêm chừng 3 năm. Hiện tượng này là phổ
biến trong tin học, người ta khắc phục nó bằng một mẹo nhỏ có tính chất thương
mại như sau: Thay vì sửa sản phẩm, người ta cơng bố bản sửa đó dưới dạng một
phiên bản mới.
Ví dụ: Ta thấy hệ điều hành DOS 4.0, chỉ tồn tại một thời gian ngắn được
thay bẳng DOS 5.0, .....tương tự cho hệ điều hành Window.....
Trong thời kỳ đầu của tin học, khoảng những năm 50, người ta lập trình
bằng các ngôn ngữ bậc thấp.
o Việc nạp và theo dõi hoạt động của chương trình một cách trực tiếp theo
chế độ trực tuyến (on-line), tìm & diệt lỗi (debugging) như ta hay làm ngày nay là
khơng thể được.
o => Lập trình viên ngày xưa làm việc thận trọng hơn ngày nay rất nhiều.
Trước những năm 60, người ta coi lập trình như một hoạt động nghệ thuật,
nhuốm màu sắc tài nghệ cá nhân hơn là khoa học. Một người nắm được một ngơn
ngữ lập trình và một số mẹo vặt tận dụng cấu hình phần cứng cụ thể của máy tính
có thể được xem là chuyên gia nắm bắt được những bí mật của “nghệ thuật lập
trình”.
1.1.2 Cuộc khủng hoảng PM những năm 60
Những năm 60 đã bùng nổ “ cuộc khủng hoảng về đảm bảo phần mềm”
được đặc trưng bởi hai hiện tượng sau đây:
- Chi phí cho tin học q lớn, trong đó chi phí cho phần mềm chiếm tỉ lệ
3
cao và ngày càng tăng so với chi phí cho kỹ thuật tin học (phần cứng).
o Năm 1965 tổng chi phí cho tin học trên Thế giới chiếm 250 tỉ Franc.
o Rất nhiều đề án lớn nhằm ứng dụng tin học bị thất bại liên tiếp. Nguyên
nhân thất bại chủ yếu là do phần đảm bảo sản phẩm
- Để giải quyết những vướng mắc trong kỹ thuật lập trình, các nhà tin học
lý thuyết đã đi sâu vào nghiên cứu, tìm hiểu bản chất của ngơn ngữ, thuật tốn và
các hoạt động lập trình và nâng nội dung của nó lên thành nguyên lý khoa học.
Các kết quả nghiên cứu điển hình như:
+ Dijkstra trong nghiên cứu của mình đã chỉ ra rằng: “động thái của
chương trình có thể được đánh giá một cách tường minh qua các cấu trúc lặp, rẽ
nhành, gọi đề quy...” và rằng ”... tay nghề của lập trình viên tỷ lệ nghịch với tốn
tử goto mà anh ta viết trong chương trình”
+ Gues trong bài báo của mình đã phân tích sâu sắc ngun nhân dẫn đên
tình trọng trong lập trình dùng goto bừa bãi sẽ biến chương trình thành một mớ
rối rắm như món mì sợi.
+ Gries phê phán trong các trường đại học, người ta dạy ngơn ngữ lập
trình chứ khơng dạy kỹ thuật lập trình, người ta dạy các mẹo để lập trình chứ
khơng quan tâm đến các ngun lý & phương pháp luận lập trình.
1.1.3 Những tư tưởng cách mạng trong lập trình
Tính cách mạng của những quan điểm khoa học nẩy nở trong giai đoạn này
thể hiện ở những điểm sau đây:
o Chương trình máy tính và lập trình viên trở thành đối tượng nghiên cứu
của lý thuyết lập trình
o Vấn đề cơ bản đặt ra đối với lý thuyết lập trình là “làm thế nào có thể làm
chủ được sự phức tạp của hoạt động lập trình”.
Do trí tuệ của từng cá nhân lập trình viên là có hạn mà các vấn để thực tiễn
cần giải quyết bằng các công cụ tin học là lớn và phức tạp. Vấn đề đặt ra là liệu có
thể phân bài tốn lớn thành những bài tốn nhỏ có độ phức tạp thấp để giải riêng,
sau đó tổng hợp kết quả lại được không?
4
Các kết quả nghiên cứu đạt được:
+ Năm 1969, Hoere phát biểu các tiên đề phục vụ cho việc chứng minh tính
đúng đắn của chương trình và phát hiện tính chất bất biến của vịng lặp. Sau đó
Dijkstra và Hoere đã phát triển ngơn ngữ lập trình có cấu trúc.
+ Để triển khai được các nguyên lý lập trình Wirth đã thiết kế và cài đặt
ngôn ngữ ALGOL W – một biến thể của ALGOL – 60. Sau này ALGOL W tiếp tục
được hồn thiện để trở thành ngơn ngữ lập trình Pascal. Đây là ngơn ngữ giản dị,
trong sáng về cú pháp, dễ minh họa các tư tưởng của lập trình hiện đại => Rất
phù hợp trong giảng dạy.
+ Năm 1978, Kernighan và Ritchie đã thiết kế ra ngôn ngữ lập trình C.
Cuộc cách mạng lập trình diễn ra những năm 60 – 70 đem lại cho chúng ta
những nhận thức sau đây:
o Lập trình là một trong những lĩnh vực khó nhất của tốn học ứng dụng.
Có thể coi lập trình như một khoa học nhằm đề xuất các nguyên lý và phương
pháp nâng cao hiệu xuất lao động cho lập trình viên. Năng xuất ở đây cần
định hướng trước hết đến:
Tính đúng đắn của chương trình
Tính dễ đọc, dễ hiểu, dễ thực hiện của chương trình
Tính dễ sửa đổi của chương trình
Tận dụng tối đa khả năng của thiết bị mà vẫn không phụ thuộc vào
thiết bị.
o Tóm lại: Kỹ thuật lập trình hay ở mức độ rộng hơn là CNPM nhằm hướng
đến mục tiêu cuối cùng là “Sử dụng tối ưu sự phối hợp giữa người và máy”.
o Người ta chỉ kiểm sốt được tính đúng đắn của một đối tượng nào đó nếu
nó được kiến trúc một cách đơn giản và trong sáng.
Lập trình viên phải thốt khỏi những ràng bc cụ thể về văn phạm của
ngơn ngữ lập trình, phải diễn đạt một cách trong sáng và đúng đắn các chỉ thị (chứ
không phải biết bao nhiêu ngôn ngữ) – đây là tiêu chuẩn số 1.
5
Trong lập trình, một số lập trình viên mới hay bị cột chặt vào những ngơn
ngữ lập trình cụ thể. Thực chất của quá trình lập trình là “người ta khơng lập trình
trên một ngơn ngữ cụ thể mà lập trình hướng đến nó”
1.1.4 Triển khai chương trình theo sắc thái công nghệ
Công nghệ sản xuất một sản phẩm phần mềm nào đó thường bao gồm các
giai đoạn sau:
1. Tìm hiểu nhu cầu của khách hàng
Đây là bước hình thành nên bài toán
2. Xác định các chức năng cần có của sản phẩm
3. Chia nhỏ các chức năng thành các nhóm độc lập tương đối với nhau. Mỗi
nhóm sẽ ứng với một bộ phần hợp thành của sản phẩm
Ví dụ: Để sản xuất hộp bia, người ta phân chia cơng nghệ này thành các giai
đoạn (nhóm các chức năng) sau đây:
a. Chuẩn bị nguyên liệu
b. Lên men
d. Ướp hương liệu
e. Đóng hộp
f. Đóng thùng
g. Nhập kho
Chú ý rằng, mỗi cơng đoạn bao gồm nhiều chức năng khác nhỏ hơn.
Ví dụ:
+ Cơng đoạn a) chuẩn bị ngun liệu có thể bao gồm:
Chuẩn bị lúa đại mạch,
Chuấn bị hoa bia,
....
+ Cơng đoạn c) làm hộp có thể gồm:
Cắt tấm nhôm,
Dập hộp,
In nhãn.
6
4. Giao việc thiết kế và sản xuất sản mỗi bộ phần của sản phẩm này cho
từng người hoặc nhóm người.
5. Các nhóm triển khai cơng việc: Thực hiện các bước thiết kế, sản xuất, thử
nghiệm. Trong quá trình này, các nhóm thường xuyên liên hệ với nhau nhằm hạn
chế tối đa các công việc trùng lặp và đảm bảo tính tương thích khi ghép nối các bộ
phận.
6. Ghép nối các bộ phận/chi tiết thành phẩm
7. Thử nghiệm sản phẩm, sửa nếu cần.
8. Bán và giao lô sản phẩm đầu tiên cho khách hàng
9. Thu thập thông tin phản hồi từ phía người sử dụng. Quyết định sửa lại
bản sản phẩm, cải tiến hoặc hủy bỏ việc sản xuất sản phẩm này.
Trên đây là quy trình sản xuất sản phẩm nói chung. Nhóm làm phần mềm
cũng thực hiện ngần ấy nhiệm vụ ở các giai đoạn tương ứng. Trong nhóm các cách
chuyên viên cho từng nhiệm vụ.
- Phân tích viên + lãnh đạo nhóm: Đảm nhận các nhiệm vụ từ 1- 4
o Sản phẩm thu được sau giai đoạn 4 là phần đầu của hồ sơ phần mềm gồm:
Các đặc tả yêu cầu
Các đặc tả chức năng của phần mềm cũng như các module tương ứng.
- Giai đoạn 5: Dành cho các nhóm triển khai cơng việc
o Các nhóm trưởng lại tiếp tục phát triển bộ hồ sơ = cách bổ sung thêm các
đặc tả chi tiết, tinh chế dần từng bước cho đến khi nhận được những
chương trình con viết trên ngơn ngữ lập trình cụ thể
o Các lập trình viên cũng tham gia vào việc:
Phân tích các nhiệm vụ con
Đặc tả từng khối chức năng trong nhóm của mình, đặc tả tốt có thể giao
nhiệm vụ mã hóa cho máy tính
Mã hóa:
Chuyển biểu diễn của thuật toán từ dạng đặc tả sang dạng mã nguồn (sử
dụng ngơn ngữ lập trình cụ thể).
7
Khi mã hóa cũng nên tận dụng quỹ thuật tốn và quỹ chương trình:
+ Vì thời gian giao nộp sản phẩm rất hạn hẹp, nên tìm và sử dụng lại những
mơ đun, thủ tục hoặc thuật tốn đã có sẵn.
+ Để thực hiện được điều này không phải là dễ, nó địi hỏi một ý thức trách
nhiệm cao của mọi thành viên trong tập thể. Ở đây, nguyên tắc “mình vì mọi
người, mọi người vì mình” được coi là đắc dụng. Khi viết một phần mềm nào đó,
dù nhỏ, bạn ln có ý thức rằng mình viết cho nhiều người dùng. Có ý thức đó,
ngồi cái lợi là bạn sẽ thận trọng cho sản phẩm của mình, bạn cịn thực hiện được
đóng góp quan trọng vào quỹ thuật tốn và quỹ chương trình, mà ở đó, bạn cũng
có quyền khai thác các sản phẩm trí tuệ của người khác.
+ Có thể nói, khơng có lĩnh vực nào con người phung phí chất xám nhiều
như trong tin học. Với năng xuất thảm hại là 4-5 lệnh/ngày, người ta làm ra hàng
vạn, hàng triệu module, chương trình, hệ thống ... để thực hiện cùng một cơng
việc.
* Trao đổi với các nhóm khác để:
nhận được những thủ tục dùng chung và thông hiểu lẫn nhau:
* Muốn hiểu biết tốt nên:
- Dùng cùng một thứ ngôn ngữ đặc tả, nhằm mô tả những yếu tố sau của
chương trình:
- Các phép biến đổi
- Các kết quả cần đạt được ở mỗi điểm của chương trình.
- Hành động theo cùng một nguyên tắc: Nguyên tắc hành động đảm bảo tính
trong sang, dễ hiểu là triển khai chương trình theo cấu trúc từ trên xuống dưới và
tinh chế dần
-Hướng dẫn cách sử dụng các chi tiết sản phẩm do nhóm mình phát triển.
- Giai đoạn 6: Do chuyên viên trưởng về lập trình thực hiện, chuyên viên
này cần:
+ Trực tiếp tham gia vào các hoạt động 1-4
+ Theo dõi tiến độ hoạt đông 5
8
+ Bám sát hoạt động của giai đoạn 7
- Nhiệm vụ 7: Do chuyên viên kiểm thử thực hiện
- Nhiệm vụ 8+9: Do một chuyên gia Marketing + lãnh đạo nhóm thực hiện.
Chuyên gia này cần tham gia vào các hoạt động từ 1-4. Các nhóm cần có sự tư vấn
của
+ Các chuyên gia đảm bảo toán học và các chuyên gia thuật toán.
+ Các cố vấn kỹ thuật: Tư vấn, trợ giúp nhóm lựa chọn thiết bị (phần cứng),
thuật toán, phầm mềm trợ giúp...
1.2 Các phương pháp luận hiện nay.
1.2.1 Phương pháp luận là gì ?
Phương pháp luận là một cách tiếp cận để giải quyết vấn đề nào đó. Phương
pháp luận lập trình là cách tiếp cận để viết ra các chương trình (theo quan điểm lý
thuyết). Theo quan điểm kỹ thuật, phương pháp luận lập trình cịn được gọi là kỹ
thuật lập trình
1.2.2 Các phương pháp triển khai chương trình
•
Triển khai chương trình từ trên xuống dưới và từ dưới lên trên
Khi vận dụng nguyên lý phân mức bài tốn theo cấp độ trừu tượng hóa,
chúng ta làm quen với hai cách tiếp cận từ trên xuống và từ dưới lên.
Cách tiếp cận thứ nhất (Top – Down) được tác giải của ngôn ngữ Pascal
đề xuất vào thập kỷ 70 và đặt tên là làm mịn dần. Điều quan trọng của q trình
làm mịn dần/hay chính xác dần chương trình là phải tiến hành đồng thời với chính
xác hóa dữ liệu. Cách tiếp cận này giúp ta xuất phát từ máy giải trừu tượng đi dần
đến máy giải cụ thể được trang bị bởi ngôn ngữ lập trình cụ thể.
Cách tiếp cận thứ 2 (Bottom - up) xuất phát từ những viên gạch đầu tiên
để thiết kế nền móng, và từng tầng, từng tầng cho đến khi nhận được một kiến trúc
hồn chỉnh (ví dụ được vận dụng trong giáo dục, đào tạo). Cách tiếp cận này
thường được vận dụng trong trường hợp chiến lược giải bài tốn chưa được nghiên
cứu.
Q trình trừu tượng hóa được chia làm nhiều mức. Mỗi mức nói chung
9
được xác định bởi 4 công cụ: Ngôn ngữ, Cấu trúc dữ liệu, Các thao tác, Máy
giải.Trong đó:
+ Ngơn ngữ: là công cụ dùng để mô tả CTDL và các thao tác cần thiết.
Ngôn ngữ ở các mức trừu tượng ở mức trên có thể là ngơn ngữ tự nhiên hoặc ngơn
ngữ tự nhiên có cấu trúc (phi hình thức hoặc bán hình thức)
+ Máy giải: Ở mức cao, máy giải là máy trừu tượng (máy giả định). Càng ở
mức trên thì mức độ trừu tượng càng cao theo nguyên tắc “thấy cây chưa quan
trọng bằng thấy rừng”.
Quá trình trừu tượng hóa được chính xác dần và mịn dần ở các mức dưới
cho đến khi nhận được chương trình hồn chỉnh viết trên ngơn ngữ lập trình cụ thể
để chạy trên ngơn ngữ cụ thể.
•
Làm mịn dần (tinh chế dần từng bước)
Năm 1956, chuyên gia tâm lý học George Miller đã chỉ ra rằng: Tại một thời
điểm, chúng ta chỉ có khả năng tập trung vào khoảng 7 vấn đề khó khăn cần giải
quyết. Phát biểu này được gọi là luật của Miller (Miller’s Law) [Miller, 1956]. Tuy
nhiên, một vấn đề cần giải quyết lại chia thành nhiều hơn 7 vấn đề con cần giải
quyết, để hạn chế lượng thông tin/các vấn đề giải quyết tại một thời điểm ta sử
dụng kỹ thuật “tinh chế từng bước” – “stepwise refinement”.
Tinh chế từng bước là một kỹ thuật giải quyết vấn đề có thể được định nghĩa
như cơng cụ để cắt tỉa các quyết định chi tiết đến các giai đoạn sau để tập trung
vào các vấn đề quan trọng/các vấn đề chính. Như luật của Miller đã đưa ra, tại một
thời điểm ta chỉ có thể tập trung giải quyết khoảng 7 khó khăn.
Tinh chế từng bước được vận dụng trong nhiều kỹ thuật kỹ nghệ phần mềm
như, các kỹ thuật phân tích, thiết kế, cài đặt, kiểm thử và tích hợp.
1.2.3 Các phương pháp luận lập trình
Phương pháp luận lập trình được biểu diễn bởi mơ hình lập trình. Một mơ
hình lập trình thể hiện một quan điểm/một cách tiếp cận trong lập trình. Mỗi mơ
hình hỗ trợ một tập các khái niệm, các kỹ thuật và các nguyên tắc thiết kế. Các mơ
hình lập trình khác nhau có những mức độ diễn đạt khác nhau, các kỹ thuật lập
10
trình khác nhau và các cách lập luận khác nhau về chúng.
Mọi mơ hình lập trình đều có vị thế của nó, được thiết kế và sử dụng trong
hồn cảnh riêng. Một nguyên tắc quan trọng ta cần nhận biết đó là: Cần kết hợp
giữa các mơ hình để giải quyết triệt để một hệ thống ứng dụng phức tạp.
Một kiểu lập trình tốt yêu cầu sử dụng các khái niệm lập trình được kết hợp
trong các mơ hình khác nhau. Các ngơn ngữ lập trình chỉ cài đặt một mơ hình tạo
khó khăn cho việc tạo ra một chương trình tốt.
Ví dụ:
•
Các ngơn ngữ hướng đối tượng: Khuyến khích sử dụng quá nhiều khái
niệm về trạng thái và kế thừa => tạo sự rắc rối trong chương trình
•
Các ngơn ngữ lập trình hàm: Khuyến khích sử dụng q nhiều về lập
trình thứ bậc cao hơn. Nó xâu mọi hàm trong chương trình thành một biểu thức.
Điều này làm cho chương trình rắc rối, khơng đạt tính mơ-đun hóa.
•
Các ngơn ngữ lập trình logic: Khuyến khích sử dụng nhiều cú pháp mệnh
đề Horn và tìm kiếm. Các ngơn ngữ này định nghĩa chương trình như một tập các
mệnh đề Horn (lắp ráp các mệnh đề logic theo kiểu if … then). Điều này dẫn đến
nhiều giải thuật trở nên rắc rối khi được viết theo kiểu này, tìm kiếm lưu vết ln
được sử dụng thậm chí một cách tự nhiên, hầu như khơng cần nó.
Hệ thống Mozart – OZ: là một phần mềm hỗ trợ cài đặt hiệu quả một số mơ
hình lập trình (Logic, Hàm, Hướng đối tượng, có cấu trúc, ràng buộc, phân tán, ...).
Hệ thống này đã được phát triển trong một thời gian dài, bắt đầu từ năm 1991, nó
được phát hành với đầy đủ mã nguồn mở. Các phát hành:
- Phiên bản đầu được phát hành năm 1995;
- Phiên bản hỗ trợ phân tán phát hành năm 1999
- Phiên bản Morart 1.3.0 phát hành năm 2003
- Hiện nay đã phát hành phiên bản 1.4.0
Bạn đọc có thể vào Website để biết thêm các
thơng tin chi tiết. Mozart – System là một môi trường phát triển tăng dần và cung
cấp đầy đủ các công cụ trợ giúp phát triển ứng dụng. Mozart – OZ được cài đặt
11
bằng ngơn ngữ OZ.
Các mơ hình lập trình được liệt kê trong bảng sau:
Phương thức lập trình
1 Lập trình hướng thiết bị - Gear Oriented Programming
2 Lập trình hướng cơng tắc- Switch Oriented Programming
3 Lập trình hướng thủ tục – Procedural/structured Programming
4 Lập trình hướng đối tượng – Object Oriented Programming
5 Lập trình hướng lát cắt – Aspect Oriented Programming
Mệnh lệnh 6 Lập trình hướng cấu phần – Component Oriented Programming
7 Lập trình hướng dịch vụ - Service Oriented Programming
8 Điện tốn đám mây – Clound Computing
9 Lập trình tuyến tính - Linear Programming
10 Lập trình mã nguồn mở - Open source programming
11 Lập trình hướng cấu trúc - Procedure Oriented Programming
1 Lập trình logic – Logic Programming
Khai báo 2 Lập trình hàm – Functional Programming
3 Lập trình CSDL – Database Programming
• Với phương thức lập trình mệnh lệnh:
- Người lập trình phải tìm cách diễn đạt được thuật tốn, Chỉ ra cách thức
làm thế nào để giải quyết bài tốn đã cho.
- Ưu điểm: Hiệu quả trong lập trình, vì người lập trình có thể tác động trực
tiếp vào phần cứng
- Hạn chế: Chương trình khơng có khả năng suy đốn, khơng có trí tuệ.
•
Với phương thức lập trình khai báo:
- Người lập trình xây dựng cơ sở tri thức, các u cầu tính tốn, truy vấn
dựa trên các khai báo để giải quyết bài toán
- Ưu điểm: Chương trình có khả năng suy diễn
- Hạn chế: Khó cài đặt và vận hành hơn so với chương trình mệnh lệnh.
12
13
CHƯƠNG II. LẬP TRÌNH HƯỚNG KHÍA CẠNH - AOP (ASPECT-ORIENTED
PROGRAMMING)
2.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
14
chưa đáp ứng được hoặc đáp ứng được nhưng việc thực hiện nó q 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)
2.1.1.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.
•
Core concern/ Primary concern: là requirement, logic xử lý chính của
chương trình.
•
AOP: Mơ hình lập trình hướng tương quan
•
Cross-cutting concern: là những logic xử lý phụ cần được thực hiện của
chương trình khi core concern được gọi như security, logging, tracing, monitoring,
…
•
Joinpoint: là một điểm trong chương trình, là những nơi có thể được chèn
những cross-cutting concern. Chẳng hạn chúng ta cần ghi log lại sau khi chạy
method nào đó thì điểm ngay sau method đó được thực thi gọi là một Jointpoint.
Một Jointpoint có thể là một phương thức được gọi, một ngoại lệ được throw ra,
hay một field được thay đổi.
•
Pointcut: có nhiều cách để xác định Joinpoint, những cách như thế được
gọi là Pointcut. Nó là các biểu thức được sử dụng để kiểm tra nó có khớp với các
Jointpoint để xác định xem Advice có cần được thực hiện hay khơng.
•
Advice: những xử lý phụ (crosscutting concern) được thêm vào xử lý
chính (core concern), code để thực hiện các xử lý đó được gọi Advice. Advice
được chia thành các loại sau:
Before: được thực hiện trước join point.
After: được thực hiện sau join point.
Around: được thực hiện trước và sau join point.
After returning : được thực hiện sau join point hoàn thành một cách bình
thường.
After throwing : được thực hiện sau khi join point được kết thúc bằng một
15
Exception.
•
Aspect: tương tự như một Java class. Một Aspect đóng gói tồn bộ cross-
cutting concern và có thể chứa các JointPoint, PointCut, Advice.
•
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.
•
Target Object : là những đối tượng mà advice được áp dụng.
•
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)
•
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
Một vài cross-cutting concern thường thấy trong ứng dụng:
•
Logging
•
Monitor
•
Access control
•
Error handling
•
Transaction management
•
Session management
•
Input/output validation
2.1.2 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
16
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 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 hố, 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 hố.
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 hố 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.
17
2.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.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ụ, …Ngồ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
18
số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ạ u cầu người dùng sử dụng AOP
19
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 u cầu. Hình sau minh hoạ một ví dụ thiết kế dùng phương
20
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.
21
Hình 6: Giải quyết các concern hệ thống bằng phương pháp AOP
2.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. Q trình này cịn được gọi là q trình dệt mã, sử
dụng các thơng tin trong aspect để cấu thành hệ thống đích
22
Hình 7: Các giai đoạn phát triển sử dụng phương pháp AOP
*Ư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
*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 tố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.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
1. AspectJ
Địa chỉ
Aspectj.org
23
2.
3.
4.
5.
6.
7.
AspectWerkz
Jboss AOP
Sping AOP
Aspect#
AspectC++
JAC
Aspectwerkz.codehaus.org
Jboss.org
www.spring framework.org
Aspectsharp.sourceforge.net
Aspectc.org
Jac.objectweb.org
2.3.Giới thiệu AspectJ
2.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
2.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.
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
24
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! ");
25
