Lập trình hướng đối tượng (Object Oriented Programming - OOP) là mô hình
phát triển được lựa chọn cho hầu hết các dự án phần mềm. OOP rất hữu hiệu trong
việc lập mô hình hành vi chung của các đối tượng,tuy nhiên nó không giải quyết thỏa
đáng những hành vi liên quan đến nhiều đối tượng. AOP giải quyết được vấn đề này,
và rất có thể sẽ là bước phát triển lớn kế tiếp trong phương pháp lập trình.
Vấn đề cốt lõicủa AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một
cách linh hoạt và kết hợp chúng lại đểtạo nên hệ thống sau cùng. AOP bổ sung cho kỹ
thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đunkhác, cho phép kéo
thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘aspect’(khía
cạnh), từ chữ ‘aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới:
aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ
kiểm soát hơn. Các aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch
và có thể tái sử dụng.
Aspect-orientation là một hướng tiếp cận mạnh mẽ cho lập trình hệ thống phức
tạp.Áp dụng phương pháp aspect vào mô hình và thiết kếhệ thốngcó nhiều ưu điểm
so với OOP. Cách tiếp cận Theme(chủ đề) là một ưu điểm quan trọng trong AOP,
cung cấp phương tiện để ứng dụng aspect-orientation.
101 trang |
Chia sẻ: lvbuiluyen | Lượt xem: 2012 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu Tìm hiểu về tiếp cận theme và ứng dụng của cách tiếp cận vào xây dựng hệ thống điện thoại, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Trần Lệ Huyền
TÌM HIỂU VỀ TIẾP CẬN THEME
VÀ ỨNG DỤNG CỦA CÁCH TIẾP CẬN VÀO XÂY
DỰNG HỆ THỐNG ĐIỆN THOẠI
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin
HÀ NỘI - 2010
2
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Trần Lệ Huyền
TÌM HIỂU VỀ TIẾP CẬN THEME
VÀ ỨNG DỤNG CỦA CÁCH TIẾP CẬN VÀO XÂY
DỰNG HỆ THỐNG ĐIỆN THOẠI
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin
Cán bộ hướng dẫn: TS. Đặng Văn Hưng
HÀ NỘI - 2010
3
Lời cảm ơn
Lời đầu tiên, em xin được bày tỏ lòng biết ơn sâu sắc tới thầy Đặng Văn Hưng-
Người đã trực tiếp hướng dẫn, tận tình giúp đỡ em trong thời gian thực hiện khóa luận.
Em xin được bày tỏ lòng biết ơn tới các thầy, cô trong khoa Công Nghệ Thông
Tin, trường Đại Học Công Nghệ, ĐHQGHN. Các thầy cô đã nhiệt tình dạy bảo và tạo
mọi điều kiện học tập tốt nhất cho chúng em trong những năm học tập tại ĐHCN
Tôi xin cảm ơn các bạn sinh viên lớp K51CC và K51CNPM Trường Đại học
Công nghệ, những người bạn đã cùng tôi học tập và rèn luyện trong suốt những năm
học đại học.
Hà Nội, ngày 19 tháng 5 năm 2010
Trần Lệ Huyền
4
Tóm tắt
Lập trình hướng khía cạnh (Aspect Oriented Programming - AOP) là một kiểu
lập trình mới nhanh chóng thu hút được các nhà phát triển trong giới công nghệ thông
tin. AOP là một mô hình lập trình tách biệt các chức năng phụ với logic nghiệp vụ của
chương trình chính. Các chức năng phụ rải rác nằm xuyên suốt trong hệ thống được
tách thành các đơn vị duy nhất, gọi là aspect( khía cạnh). Một aspect là một đơn vị mô-
đun cho sự thi hành cắt ngang chương trình. Nó đóng gói các hành vi mà ảnh hưởng
đến nhiều lớp vào các mô-đun có khả năng sử dụng lại. Đây là một phương pháp lập
trình phát triển dựa trên lập trình hướng đối tượng.
Bài luận tìm hiểu về cách xây dựng hệ thống với phương pháp AOP. Và ứng dụng
AOP vào xây dựng thiết kế một hệ thống điện thoại với các chức năng cơ bản.
5
Danh sách chữ viết tắt
STT Từ viết tắt Giải nghĩa
1 AOP Aspect Oriented Programming
2 OOP Object Oriented Programming
6
Mục lục
Chương 1 Tiếp cận AOP ...................................................................................................... 2
1.1 Giới thiệu:................................................................................................................ 2
1.2 Đặc điểm của AOP .................................................................................................. 3
1.2.1 Aspect là gì? ..................................................................................................... 3
1.2.2 Nguyên tắc: ...................................................................................................... 4
1.2.3 Những lợi ích “separate of concerns” ................................................................ 4
1.2.4 Tiếp cận aspect ................................................................................................. 5
1.3 Giới thiệu sơ qua về Theme ..................................................................................... 7
1.3.1 Định nghĩa về Theme........................................................................................ 7
1.3.2 Mối quan hệ giữa các theme :............................................................................ 8
1.3.3 Áp dụng cách tiếp cận theme: ........................................................................... 9
Chương 2 Phân tích........................................................................................................... 11
2.1 Các khung nhìn Theme/Doc................................................................................... 11
2.1.1 Khung nhìn relationship của theme ................................................................. 11
2.1.2 Khung nhìn crosscutting của Theme ............................................................... 12
2.1.3 Khung nhìn individual .................................................................................... 14
2.2 Quá trình xử lý Theme/Doc.................................................................................... 14
2.3 Quyết định trên theme............................................................................................ 16
2.3.1 Chọn các theme ban đầu ................................................................................. 16
2.3.2 Các hoạt động trên theme................................................................................ 19
2.3.3 Hoạt động trên Requirements.......................................................................... 21
2.4 Quyết định Theme trách nhiệm .............................................................................. 22
2.4.1 Xác định Theme aspect ................................................................................... 23
2.4.2 Trì hoãn một số quyết định ............................................................................. 25
2.5 Kế hoạch cho thiết kế............................................................................................. 25
2.5.1 Xác định các đối tượng ................................................................................... 25
2.5.2 Khung nhìn theme base................................................................................... 26
2.5.3 Khung nhìn theme aspect ................................................................................ 26
Chương 3 Thiết kế theme .................................................................................................... 28
3.1 Thiết kế theme base .................................................................................................... 28
3.2 Thiết kế Theme crosscutting .................................................................................. 29
3.2.1 Tổng quan về thiết kế Theme crosscutting ...................................................... 29
3.2.2 Thay đổi với UML .......................................................................................... 32
Chương 4 Tổng hợp theme................................................................................................. 36
4.1 Pick Theme............................................................................................................ 36
4.2 Xác định các phần tử thiết kế so khớp .................................................................... 37
7
4.2.1 So khớp tường minh ....................................................................................... 38
4.2.2 So khớp ngầm định ......................................................................................... 38
4.2.3 Các nguyên tắc cho so khớp khái niệm chung với relationship tổng hợp ......... 38
4.3 Kiểu tích hợp- Integration ...................................................................................... 39
4.3.1 Tích hợp merge............................................................................................... 39
4.3.2 Tích hợp override ........................................................................................... 42
4.3.3 Kết hợp các phương pháp tích hợp .................................................................. 43
4.4 Giải quyết xung đột................................................................................................ 43
4.4.1 Explicit values ................................................................................................ 44
4.4.2 Giá trị mặc định .............................................................................................. 44
4.4.3 Theme Precedence .......................................................................................... 45
4.5 Chỉ ra binding cho Theme aspect ........................................................................... 46
Chương 5 Xây dựng hệ thống điện thoại với phương pháp Theme..................................... 52
5.1 Tóm tắt về dự án: ................................................................................................... 52
5.2 Phân tích yêu cầu dự án ......................................................................................... 52
5.2.1 Xác định các theme ban đầu............................................................................ 54
5.2.2 Làm mịn tập theme ......................................................................................... 55
5.3 Thiết kế các theme ................................................................................................. 60
5.3.1 Phân tích UseCase .......................................................................................... 60
5.3.2 Thiết kế theme ................................................................................................ 61
5.4 Tổng hợp theme ..................................................................................................... 79
1
Mở đầu
Lập trình hướng đối tượng (Object Oriented Programming - OOP) là mô hình
phát triển được lựa chọn cho hầu hết các dự án phần mềm. OOP rất hữu hiệu trong
việc lập mô hình hành vi chung của các đối tượng, tuy nhiên nó không giải quyết thỏa
đáng những hành vi liên quan đến nhiều đối tượng. AOP giải quyết được vấn đề này,
và rất có thể sẽ là bước phát triển lớn kế tiếp trong phương pháp lập trình.
Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một
cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung cho kỹ
thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đun khác, cho phép kéo
thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘aspect’ (khía
cạnh), từ chữ ‘aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới:
aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ
kiểm soát hơn. Các aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch
và có thể tái sử dụng.
Aspect-orientation là một hướng tiếp cận mạnh mẽ cho lập trình hệ thống phức
tạp. Áp dụng phương pháp aspect vào mô hình và thiết kế hệ thống có nhiều ưu điểm
so với OOP. Cách tiếp cận Theme (chủ đề) là một ưu điểm quan trọng trong AOP,
cung cấp phương tiện để ứng dụng aspect-orientation.
Bài luận của em tìm hiểu về AOP dựa trên tài liệu “Aspect-Oriented Analysis
and Design: The Theme Approach “ của tác giả Siobhán Clarke và Elisa Baniassad.
Bài luận trình bày về phân tích xây dựng một hệ thống bằng phương pháp AOP.
Bài luận gồm năm chương:
Chương 1: Giới thiệu và trình bày các đặc điểm về AOP.
Chương 2: Phân tích yêu cầu hệ thống để tìm ra tập theme .
Chương 3: Thiết kế riêng biệt các theme sử dụng UML, với một số mở rộng của
UML chuẩn.
Chương 4: Tổng hợp các thiết kế theme riêng biệt thành một hệ thống hoàn chỉnh
mạch lạc.
Chương 5: Ứng dụng AOP với phương pháp theme vào xây dụng các đặc điểm
cơ bản cho hệ thống điện thoại.
2
Chương 1 Tiếp cận AOP
1.1 Giới thiệu:
Vào những ngày đầu của ngành khoa học máy tính, các thảo chương viên lập
trình trực tiếp bằng mã máy. Những nhà phát triển phần mềm thời đó đã phải tốn nhiều
thời gian suy nghĩ về tập lệnh riêng của từng phần cứng máy tính cụ thể hơn là tập
trung để giải quyết các yêu cầu của bài toán đặt ra. Dần dần, người ta chuyển sang các
ngôn ngữ lập trình cấp cao hơn, cho phép khái quát hoá ở mức độ nào đó mã máy chạy
bên dưới.
Rồi kế đến là các ngôn ngữ lập trình có cấu trúc cho phép phân tích bài toán
thành các thủ tục thực hiện những tác vụ cần thiết. Phương pháp lập trình này thực
hiện theo cách tiếp cận hướng chức năng chủ yếu dựa vào phân rã các chức năng chính
của bài toán thành các chức năng đơn giản hơn và thực hiện làm mịn dần từ trên xuống
để tạo ra cấu trúc phân cấp. Chương trình theo hướng tiếp cận này thực chất là một tập
các chương trình con (các hàm) mà máy tính cần thực hiện để hoàn thành nhiệm vụ
của hệ thống. Trong đó dữ liệu và các hàm là tách rời nhau, các hàm muốn liên kết
trao đổi với nhau thì phải thông các biến chung (global). Nếu phải sửa đổi dữ liệu thì
sẽ phải sửa đổi mọi nơi mà sử dụng dữ liệu đó, và như vậy sẽ ảnh hưởng tới tất cả mọi
người tham gia lập trình.
Khi độ phức tạp của các bài toán tăng lên, chúng ta cần có những kỹ thuật tốt
hơn là lập trình hướng thủ tục.
Lập trình hướng đối tượng OOP đã trở thành sự lựa chọn chính khi phát triển và
xây dựng hệ thống phần mềm trong nhiều năm qua, mà thay thế hoàn toàn cho cách
tiếp cận hướng thủ tục. Một trong những ưu điểm lớn nhất của hướng đối tượng là hệ
thống phần mềm có thể được xem như là việc xây dựng một tuyển tập các lớp riêng
biệt. Mỗi một class (lớp) trong tuyển tập các lớp đó chịu trách nhiệm cho một tác vụ
nào đó trong hệ thống. Trong ứng dụng hướng đối tượng, các lớp này sẽ hợp tác lại với
nhau để hoàn thành mục tiêu chung của ứng dụng.
Kỹ thuật OOP thực hiện tốt việc đóng gói các hành vi và chủ thể , miễn là chúng
hoàn toàn riêng biệt. Tuy nhiên, các bài toán thực tế thường có những hành vi đan
nhau liên quan đến nhiều lớp, không thể được xem như là trách nhiệm riêng của một
lớp. Ví dụ như là việc tiến hành locking (khóa) trong các ứng dụng phân tán, xử lí
ngoại lệ, hoặc việc ghi log…Tất nhiên code để mà xử lý các phần này có thể được
thêm vào mỗi lớp một cách riêng biệt, nhưng điều này sẽ dẫn tới sự vi phạm trách
nhiệm chính của mỗi lớp mà ta đã định nghĩa. Theo truyền thống, hầu hết ngôn ngữ
3
lập trình hướng đối tượng như C++ và Java đều không hỗ trợ đóng gói những hành vi
đan nhau, dẫn đến mã chương trình có thể nằm lẫn lộn, rải rác và khó quản lý.
AOP là kỹ thuật lập trình mới cho phép đóng gói những hành vi có liên quan đến
nhiều lớp. Nó tập trung vào các khái niệm cắt ngang hoặc các khía cạnh - phần mã sử
dụng chung cho các đối tượng khác nhau. Nhờ mã được tách riêng, vấn đề đan nhau
trở nên dễ kiểm soát hơn. AOP tách riêng các đặc điểm mà rải rác, đan xen trong hệ
thống thành một mô-đun riêng để xử lý, nhưng nó không phải là sự kết hợp của lập
trình hướng thủ tục và lập trình hướng đối tượng. AOP có thể xem là một sự bổ sung
cho OOP, OOP là cách thức mô-đun hoá các mối quan tâm nói chung và AOP là cách
mô-đun hoá các mối quan tâm đặc biệt chạy xuyên suốt và cắt ngang các đơn vị
môđun hoá tự nhiên (là các class trong OOP truyền thống). AOP cho phép chúng ta
giải quyết các bài toán phức tạp tốt hơn và hiệu quả hơn. AOP tổng hợp hệ thống đi từ
các vấn đề đan nhau đến vấn đề chính, còn OOP đi theo hướng ngược lại. Tuy nhiên,
OOP và AOP không phủ định nhau mà bổ sung cho nhau.
1.2 Đặc điểm của AOP
1.2.1 Aspect là gì?
Concern (mối quan tâm) có thể là bất kì một đoạn code nào mà có liên quan đến
mục tiêu, đặc điểm, khái niệm hoặc một loại chức năng của ứng dụng. Aspect là một
concern mà các chức năng của nó sẽ được kích hoạt bởi những concern khác, và trong
nhiều tình huống khác nhau.
Nếu một concern không được tách riêng biệt trong một aspect, chức năng của nó
sẽ phải được kích hoạt một cách tường minh trong các đoạn code có liên quan tới
những concern khác và do đó sẽ dẫn tới sự rối, lẫn lộn trong hai concern có liên quan
tới nhau, và giải rác code trong nhiều nơi của hệ thống.
Ví dụ, nếu một hệ thống phần mềm cần ghi log tới các method được gọi thực thi
(như constructor để tìm vết khi tạo ra đối tượng). Ở đây, việc thêm một method log()
là cần thiết và method này cần phải được gọi trong một vị trí cụ thể trong code . Chắc
chắn rằng không một ai sẽ lãng phí, lạm dụng sự liên kết thừa kế của những lớp hoàn
toàn khác nhau (thực hiện các tác vụ khác nhau, không có cùng điểm tương đồng trong
cấu trúc kế thừa) mà chỉ để giới thiệu method log() trong các lớp hệ thống. AOP có thể
giúp bạn bằng cách tạo ra một aspect mà cung cấp một method log() tới các lớp mà
cần nó ghi lại, và bằng cách gọi method này bất kì đâu mà nó được yêu cầu. Một ví dụ
khác mà aspect sẽ được sử dụng là trường hợp xử lí ngoại lệ, aspect có thể định nghĩa
4
ra các mệnh đề catch() cho các method của lớp, hơn nữa cho phép xử lý ngoại lệ một
cách nhất quán xuyên suốt cả ứng dụng.
1.2.2 Nguyên tắc:
Aspect-Oriented Programming còn được gọi là Aspect-Oriented Software
Development (AOSD, phát triển phần mềm hướng khía cạnh) là một nguyên tắc thiết
kế giúp tách rời các yêu cầu hay các vấn đề được quan tâm (gọi là separation of
concerns) trong chương trình thành các thành phần độc lập và từ đó tăng tính uyển
chuyển cho chương trình. “Separation of concerns” là một trong những kĩ thuật được
quan tâm nhất trong ngành kỹ nghệ phần mềm. Người ta cho rằng những vấn đề tương
tự nhau nên được giải quyết trong một “đơn vị code”. Khi lập trình thủ tục, một “unit
of code” là một function, một method. Còn trong lập trình hướng đối tượng thì “unit
of code” là một class.
1.2.3 Những lợi ích “separate of concerns”
Trong AOP, “aspect” chính là vấn đề người lập trình quan tâm và nó xuất hiện
trong rất nhiều class cũng như nhiều method khác nhau. Kĩ thuật AOP thường được sử
dụng để giải quyết các vấn đề như bộ nhớ đệm, lưu vết, và bảo mật. Vì thế, nhiều tài
liệu nói rằng AOP giúp mô-đun hóa ứng dụng, biến chương trình thành các mô-đun
hoạt động độc lập, mỗi mô-đun làm một chức năng riêng, từ đó dễ bảo trì và nâng cấp.
AOP xác định các vấn đề một cách tách biệt, nó hạn chế tối thiểu việc nhập nhằng mã,
cho phép mô-đun hoá các vấn đề liên quan đến nhiều lớp đối tượng.
Ở vai trò của người thiết kế phần mềm, chúng ta nên đưa ra các cách làm đơn
giản nhất. Để thỏa mãn yêu cầu của chương trình, người ta sẽ tạo ra thành phần chính
của chương trình (gồm các class/component/method); các chức năng bổ sung như ghi
(log), tính toán hiệu năng chương trình cũng sẽ được xem xét để tạo ra. Vì do các chức
năng bổ sung này không phải là yêu cầu chính của hệ thống nên người ta sẽ có yêu cầu
bật tắt chúng theo ý muốn. Vậy làm thế nào để có thể tạo ra chương trình có thể linh
hoạt được như thế? Câu trả lời là “Separate of concerns”.
Ở vai trò của người lập trình, chúng ta có hai vấn đề cần quan tâm là xử lý logic
chính của chương trình và các xử lý logic cho những thành phần phụ. Do đó tất nhiên
sẽ phải tạo ra các class/method cho các yêu cầu thực sự, và tạo ra những class/method
khác độc lập để thực hiện các yêu cầu phụ. Tất cả các class/method này có thể được
kết hợp lúc runtime theo ý muốn. Chẳng hạn như trong môi trường test, người ta có
thể bật chức năng log, đo đạc hiệu năng làm việc của chương trình để theo dõi. Nhưng
khi chạy ứng dụng, các chức năng phụ này có thể được tắt đi. Và trên nguyên tắc,
5
trong code của những xử lý logic chính sẽ không chứa code để thực hiện các yêu cầu
phụ.
Dễ dàng phát triển hệ thống: Việc thêm chức năng mới có thể thực hiện dễ dàng
bằng cách tạo aspect mới mà không cần quan tâm đến vấn đề đan nhau. Khi thêm các
mô-đun mới vào hệ thống, các aspect hiện có sẽ đan kết với chúng và tạo nên sự phát
triển chặt chẽ.
Cho phép để lại quyết định thiết kế tương lai: Một thiết kế tốt phải tính đến cả
yêu cầu hiện tại và tương lai, việc xác định yêu cầu tương lai là một công việc khó
khăn. Nếu bỏ sót những yêu cầu tương lai có thể bạn sẽ phải thay đổi hay thực hiện lại
nhiều phần hệ thống. Với AOP, người thiết kế hệ thống có thể để lại các quyết định
thiết kế cho những yêu cầu tương lai nhờ thực hiện theo các aspect riêng biệt.
Tái sử dụng mã tốt hơn: Các aspect là những mô-đun riêng biệt, được kết hợp
linh động – đây chính là yếu tố quan trọng để tái sử dụng mã. AOP cho phép tái sử
dụng mã tốt hơn OOP.
1.2.4 Tiếp cận aspect
Trong khi phát triển ngôn ngữ hướng aspect, aspect có nhiều hình dạng khác
nhau. Có hai cách để tiếp cận với aspect là: asymmetric and the symmetric (bất đồng
bộ và đồng bộ) :
Phân tách bất đồng bộ
Trong quan điểm tiếp cận này, các aspect được phân tách từ các chức năng chính
của một chương trình. Các aspect đư