LUẬN VĂ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

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

Thêm vào BST

Báo xấu

127
lượt xem 34
download

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

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...

Chủ đề:

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

Lưu

Nội dung Text: LUẬN VĂ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

ĐẠ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
ĐẠ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 2
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 3
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. 4
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 5
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 6
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 7
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. 1
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ữ 2
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 3
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, 4
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 được mã hóa như là các sự kiện mà bị kích hoạt trước, sau, hoặc thay thế cho những sự kiện cụ thể đã biết trước. Chúng mô tả thêm các hành vi động của hệ thống mà sẽ có ảnh hưởng trên các chức năng chính. Ví dụ như , trong hệ thống phân tán có một tập các đối tượng đặc tả miền hệ thống mà cần phải được quản lý về việc phân phối, đồng bộ hóa, và giao dịch. Chức năng chính sẽ chứa đựng cấu trúc và hành vi phù hợp tới các chức năng miền của hệ thống. Việc phân tách các aspect khỏi chức năng chính của hệ thống giống như là việc phân phối các đối tượng trong hệ thống, sự sắp xếp hệ thống đồng bộ hóa được giao kết với các method thuộc các đối tượng đó, và bao bọc tập hợp các thao tác vào trong một giao dịch đơn. Tất cả những việc này sẽ được mô tả trong một mô-đun chuyên biệt (mỗi mô-đun sẽ là một aspect), và được gọi tại một điểm cụ thể trong khi thực thi các phần chính của một chương trình. 5
Trong mức độ khái niệm, các aspect sẽ có hai thuộc tính quan trọng trong sự phối hợp này. Đầu tiên, các aspect sẽ chỉ được kích hoạt bởi các điểm thực thi trong các chức năng chính. Thứ hai, các aspect sẽ bị kích hoạt trong rất nhiều phần của hệ thống, nhìn chung thì việc phân tách design/code trong một aspect sẽ không hữu dụng nếu aspect này chỉ được thực thi tại một nơi trong hệ thống. Bảng 1-1. Định nghĩa về các thuật ngữ trong mẫu phân tách theo hướng asymmetric Thuật ngữ Mô tả Crosscutting Các concern mà hành vi của nó bị kích hoạt trong nhiều tình huống khác nhau. Advice Là các hành vi bị kích hoạt Aspect Sự bao bọc advice và đặc tả cái nơi mà advide bị kích hoạt Core Là các phần của hệ thống hướng đối tượng truyền thống nơi mà các aspect sẽ được ứng dụng vào Jointpoint Điểm thực thi mà kích hoạt advide Pointcut Là việc bạn chọn những jointpoint nào để thực thi Weaving Việc ứng dụng các advice tới các core của hệ thống tại tại một jointpoint mà được so khớp tại các câu lệnh pointcut trong các aspect Phân tách đồng bộ Trong mẫu phân tách symmetric, để thêm vào việc mô-đun hóa các aspect, các chức năng chính của hệ thống phải được phân tích cho việc mô-đun sâu hơn. Các đặc điểm khác nhau của hệ thống sẽ được mô-đun hóa trong các chương trình riêng biệt. Toàn bộ hệ thống được cấu thành từ những chức năng riêng rẽ, là các concern hay đặc điểm. Chúng có thể được kết hợp trong các cách khác nhau để hình thành đầy đủ chức năng. Với cách tiếp cận này, một tập hợp các đối tượng được phân phối sẽ hình thành bằng cách tổng hợp các mẫu chức năng của các đối t ượng cơ bản với các chức năng phân phối, chức năng đồng bộ hóa và các chức năng giao dịch. Thoáng nhìn qua, sự trùng lặp trình bày trong cách tiếp cận symmetric như thể nó làm cho việc giải rác code trở nên tồi tệ và rắc rối hơn. Sự trùng lặp được yêu cầu trong cách tiếp cận hướng symmetric để cung cấp một cách nhìn toàn vẹn về hệ thống từ góc nhìn của concern cụ thể. Cách nhìn trọn vẹn sẽ giúp hiểu một cách riêng biệt 6
về các concern cụ thể trong hệ thống. Tất cả các chức năng phù hợp cho một concern được trình bày trong một mô-đun concern. Khả năng bảo trì concern được cũng được nâng cao hơn bởi vì xác định rõ vị trí cũng như chức năng của nó trong hệ thống. Khi sửa đổi mỗi method thuộc về một class sẽ yêu cầu bạn quan tâm đến concern liên quan, vì mức độ yêu cầu duy trì của hệ thống ảnh hưởng thường xuyên đến quá trình tiến hóa của hệ thống phần mềm nên xác định được nhóm các mô-đun mà giúp cho việc quản lý tốt việc bảo trì hệ thống là rất cần thiết. Cách tiếp cận symmetric có thể được ứng dụng một cách liên tục trong quá trình phát triển hệ thống. Không cần thiết giữ các mối quan tâm nhỏ nhặt trong các concern riêng biệt cũng như không cần thiết bó tất cả các mối quan tâm nguồn lại với nhau. Các thuật ngữ khi sử dụng với phương pháp này sẽ khác với cách dùng của phương pháp bất đồng bộ: -Concern: Vài loại chức năng trong hệ thống. Nó có thể là một đặc điểm (hàm) hoặc một loại tiến trình xử lí. -Crosscutting: là một concern bị kích hoạt trong nhiều tình huống hoặc những cấu trúc và hành vi của concern nào bị giải rác xuyên suốt cac code base và bị rối với mối liên quan code tới các concern khác. -Composition: Tổng hợp cài đặt riêng biệt của các concern để hình thành nên một chức năng của hệ thống. 1.3 Giới thiệu sơ qua về Theme Approach Theme (tiếp cận chủ đề) là cách để bạn sử dụng AOP trong quá trình phân tích và thiết kế một dự án phần mềm. Chúng ta dùng theme chủ yếu là để xác định các aspect trong hệ thống, sử dụng các mẫu phân tách Asymmetric hoặc Symmetric. 1.3.1 Định nghĩa về Theme “Theme” sẽ không được coi như là tương đồng với từ aspect. Theme được định nghĩa tổng quan hơn các aspect và có sự chặt chẽ hơn khi bao bọc các concern như đã được mô tả cho cách tiếp cận symmetric. Hãy xem với mỗi một chức năng hay một concern hay một aspect lập trình viên phải coi như là một theme riêng biệt để phục vụ cho hệ thống . Theo như các thuật ngữ trong cách tiếp cận symmetric thì concern được định nghĩa là : “vài loại chức năng của hệ thống , các chức năng này có thể là một đặc điểm hay một kiểu xử lý”. Như vậy theme sẽ được mô tả như “là một sự bao bọc các concern”. 7
Trong mức độ requirement, một theme là một tập các trách nhiệm được mô tả trong một tập các requirement. Trong mức độ thiết kế, các theme bao gồm cấu trúc và hành vi cần phải thực hiện các trách nhiệm trong mức độ các requirement. 1.3.2 Mối quan hệ giữa các theme : Có hai cách mà xác định những theme nào có mối quan hệ với nhau. a) Concept sharing (chia sẻ cùng khái niệm): Khi bạn đọc một requirement bạn sẽ xác định được các chức năng (chính là các động từ trong requirement) và các thực thể (entity- chính là các danh từ) mà có thể sẽ là một class sau này trong hệ thống. Nếu hai theme cùng tham chiếu tới một requirement tức là chúng có chung một entity. Tuy nhiên, mối quan hệ này là một loại crosscutting trong mẫu thiết kế tách biệt đồng bộ (symmetric separation), mà không được thảo luận hay đề cập trong mẫu thiết kế bất đồng bộ (asymmetric). Sự bao bọc theo kiểu này có lợi ích, chỉ có các chức năng thích hợp cho một concern sẽ được trình bày trong một theme. b) Crosscutting : Mối quan hệ thứ hai được đề cập ở đây là cắt ngang mà sẽ có ý nghĩa tương đồng như thuật ngữ crosscutting trong mẫu thiết kế bất đồng bộ.Tức là các hành vi trong một theme bị kích hoạt bởi các hành vi trong những theme khác. Chúng ta sẽ sử dụng các thuật ngữ theme base, theme crosscutting, theme aspect để nói về mối quan hệ này. Theme aspect và theme crosscutting sẽ được coi là một vì chúng cùng có chung một định nghĩa (trong mẫu thiết kế bất đồng bộ) là các hành vi mà bị kích hoạt bởi các hành vi khác. Theme base là những theme mà kích hoạt các theme aspect. Các theme base này phải là các theme mà có mối quan hệ chia sẻ khái niệm với những theme khác, trong mối quan hệ chia sẻ khái niệm này sẽ phải lựa chọn ra đâu là theme aspect và đâu là theme base. Đôi khi chúng ta nói một theme base là kết quả của sự tổng hợp các các theme khác nhau thành, và nó kích hoạt một aspect. 8
H ình 1 - 1 T heme base k ích ho ạt t heme aspect . 1.3.3 Áp dụng cách tiếp cận theme: Có hai quá trình khi bạn áp dụng phương pháp theme: sử dụng Theme/Doc, giúp phân tích tài liệu yêu cầu về phần mềm, và sử dụng Theme/UML giúp thiết kế các theme. Hình 1-2 sẽ mô tả các hoạt động ở mức tổng quan khi bạn ứng dụng cách tiếp cận theme. H ình 1 - 2. Các ho ạt động tiếp cận Theme. 1.3.3.1 Phân tích yêu cầu với Theme/Doc Dùng Theme/Doc để xác định các theme trong tài liệu yêu cầu (requirement document). Nó cung cấp phương pháp phân tích bằng kinh nghiệm để xác định những theme nào là theme aspect hay crosscutting. Quá trình phân tích bằng Theme/Doc có hai hoạt động chính: + Xác định các theme chính trong hệ thống 9
+ Xác định trách nhiệm của mỗi theme mà từ đó xác định ra được theme aspect. Trong quá trình tiến hóa của hệ thống, kiểm định thực tế qua sử dụng, chúng ta có thể dùng hai hoạt động chính ở trên để lên kế hoạch thiết kế các thay đổi của hệ thống. 1.3.3.2 Thiết kế các theme với Theme/UML Theme/UML cho phép thiết kế riêng các mô-đun cho mỗi theme xác định trong requirement. Nó là một trong những cơ sở quan trọng của AOSD để: mô-đun hóa theme, chỉ ra mối quan hệ giữa các theme liên quan, và tổng hợp các theme thành một hệ thống mạch lạc. Các theme được xác định với theme/doc có thể được thiết kế riêng biệt dù có sự cắt ngang giữa các theme hay không, hoặc có sự trùng lặp giữa các theme hay không. Chúng ta sẽ gần như hoàn toàn sử dụng chuẩn UML để thiết kế cho mỗi theme, sẽ có một vài mở rộng của chuẩn UML để thiết kế cho theme aspect. Tất cả các class, methods phù hợp cho mỗi concern phải được thiết kế trong theme. 1.3.3.3 Quá trình xử lý theme Có ba hoạt động chính khi áp dụng cách tiếp cận theme: analysis (phân tích), design (thiết kế), composition (tổng hợp). -Analysis: Đây là bước đầu tiên trong cách tiếp cận, cần phải phân tích các requirement để xác định được các theme. Bước này bao gồm mapping (ánh xạ) các requiemernt tới các concern của hệ thống. Theme/Doc chỉ ra mối quan hệ giữa các hành vi, chính là mối quan hệ giữa các theme. Mối quan hệ đó sẽ giúp tìm ra các concern là rối lẫn với các concern khác để xác định các theme aspect. -Design: Thiết kế các Theme sử dụng Theme/UML. Sử dụng các theme đã tìm thấy trong Theme/Doc để xác định các class và method tiềm năng. -Composition: chỉ ra cách mà mô hình Theme/UML sẽ được kết hợp. Trong nhiều trường hợp một vài khung nhìn của Theme/Doc giúp bạn xác định được cách thức các theme có liên quan tới nhau, xem chúng có lạp chồng hay cắt ngang những theme khác. Các theme mà chứa các khái niệm chung thì sẽ được chọn để tổng hợp theme. Hoặc các theme không có các khái niệm chung, nhưng thuộc một miền trong hệ thống cũng được tổng hợp. Chúng ta sẽ xem xét chi tiết các hoạt động trong việc thiết kế cho hệ thống AOP trong các phần tiếp theo. 10
Chương 2 Phân tích Trong chương này sẽ mô tả cách tiếp cận Theme với sự phân tích các requirements. Các requirements miêu tả các hành vi liên quan đến các concern. Một concern có thể được miêu tả trong các phần của các requirements khác nhau, việc nhóm các phần đó lại là đóng gói một theme ở mức requirements. Các requirements có thể miêu tả nhiều hơn một concern, chúng có thể được nhóm thành nhiều nhóm requirements. Để có theme- orthogonality (trực giao) ta cần phải chú ý: các theme không nên lạp chồng trong các nhóm yêu cầu của chúng, ta có thể viết lại các requirement chia sẻ để tránh lạp chồng các hành vi trong theme , hoặc xử lý sự lạp chồng đó trong thiết kế . 2.1 Các khung nhìn Theme/Doc Sử dụng Theme/Doc giúp chúng ta thấy các mối quan hệ giữa các chức năng bị làm rối lẫn một cách trực quan hơn và đưa ra quyết định cách đóng gói trong hệ thống. Có ba loại khung nhìn Theme/Doc: khung nhìn relationship (khung nhìn quan hệ), khung nhìn crosscutting (khung nhìn cắt ngang), và khung nhìn individual (khung nhìn cá nhân). 2.1.1 Khung nhìn relationship của theme Khung nhìn relationship của theme (có thể gọi ngắn gọn là khung nhìn relationship) chỉ ra các relationships giữa các theme. H ình 2 - 1 v í d ụ trừu t ư ợng của một k hung nhìn relationship . Hình 2-1 miêu tả một ví dụ trừu tượng cho khung nhìn relationship. Các theme được chỉ ra trong các nút hình thoi, nhãn của nút là tên theme. Các requirements được 11
hiển thị trong khung nhìn với các hình chữ nhật bo góc. Các requirements có thể được đánh nhãn với phần toàn bộ nội dung text của nó hay đơn giản là đánh số requirement, như là R1, R2… Khung nhìn relationship không chỉ ra “trực tiếp” mối quan hệ của các theme, nó sẽ chỉ ra cách các theme liên quan tới các requirement. Nếu đoạn text của requirement chứa một tham chiếu tới tên một theme, một liên kết được vẽ mô tả kết nối requirement đó tới theme đó. Nếu một requirement đề cập nhiều hơn một theme, giống như requirement 1 t rong h ình 2 - 1 , thì nó sẽ được liên kết tới nhiều hơn một nút theme. Các requirement mà tham chiếu tới nhiều hơn một theme được gọi là requirement chia sẻ. Nếu hai theme mà cùng liên kết tới cùng một requirement, chúng ta sẽ nói rằng các theme đó chia sẻ chung requirement đó và nói rằng các theme này liên quan tới nhau. Nếu requirement không chứa bất kì tham chiếu nào tới danh sách các theme đã có và các requirement này cũng là chung chung, không xác định được theme – chức năng cần quan tâm thì nó sẽ không được liên kết tới bất kì một theme nào trong khung nhìn. Các requirement đó gọi là requiremetn orphaned (requirment mồ côi). 2.1.2 Khung nhìn crosscutting của Theme Các requirement chia sẻ thường mô tả các hành vi crosscutting. Trong phần này, chúng ta sẽ không đi vào xem các hành vi crosscutting là gì, hay cách xác định nó. Thay vào đó, chúng ta sẽ chỉ ra các quyết định xử lý cho các requirement chia sẻ. H ình 2 - 2 V í d ụ trừu t ư ợng của k hung nhìn cros scutting . Nhìn chung, hành được mô tả trong các requirements phải được giao kết với chỉ một theme , có nghĩa là một theme sẽ chịu trách nhiệm nắm giữ hành vi của một 12
requirement. Tuy nhiên, đây không phải là một nguyên tắc cứng nhắc. Nhưng trong giai đoạn đầu của phân tích chúng ta cố gắng đưa ra các theme chịu trách nhiệm cơ bản cho chức năng hệ thống, việc xác định được rõ ràng theme nào sẽ chịu trách nhiệm cho hành vi của requirement ngay từ đầu sẽ giúp các công việc thiết kế về sau thuận lợi hơn, nên sử dụng mối quan hệ từ requirement tới theme - N:1. Với requirement chia sẻ thì nó tham chiếu tới nhiều hơn một theme, vậy theme nào sẽ chịu trách nhiệm cho requirement đó ? Có hai lựa chọn để giao kết một share requirement. a) Đầu tiên là giao kết nó với một theme mà bạn tin là “aspect” trong tình huống cụ thể đã được xác định trước. Trong khung nhìn crosscutting vẽ sự giao kết mới, là mũi tên màu xám dày mở rộng từ theme aspect (theme mà chịu trách nhiệ m nắm giữ hành vi chia sẻ chung - tức là chi phối requirement chia sẻ đó) tới các theme base (requirement chia sẻ chung bây giờ không giao kết với các theme base nữa). Nếu một requirement được giao kết với một theme aspect thì nó chỉ được liên kết với theme đó. Các theme khác được tham chiếu trong requirement được liên kết với theme aspect với mũi tên xám đậm chỉ ra rằng chúng bị cắt ngang bởi theme aspect. Như vậy trong khung nhìn crosscutting mỗi requirement chỉ giao kết với một theme. Trong h ình 2 - 2 , miêu tả mối quan hệ crosscutting từ First Theme (được xác định là theme aspect) tới Second Theme (theme base được requirement chia sẻ tham chiếu), requirement chia sẻ bây giờ chỉ giao kết với duy nhất First theme. b) Lựa chọn thứ hai là postpone (trì hoãn) quyết định về những theme chia sẻ chung requirement sẽ được giao kết như thế nào, ta chưa quyết định theme nào sẽ chịu trách nhiệm cho requirement chia sẻ. Việc postpone được mô tả trong khung nhìn crosscutting với đường nét đứt, được gán nhãn bằng nhãn (hoặc text) requirement của giao kết bị trì hoãn. Trong ví dụ hình 2-2, requirement 3 được chia sẻ bởi First theme và Third Theme, ta chưa xác định được theme nào chịu trách nhiệm cho hành vi của requirement 3 nên trì hoãn việc giao kết theme của nó lại, và nó được liên kết với First Theme, Third Theme bằng đường nét đứt, và gán nhãn là text của requirement 3. Hai khung nhìn relationship và crosscutting thực sự là hai cực của một thể liên tục. Khung nhìn relationship bao hàm tất cả các mối quan hệ giữa các theme và các requirements, nhưng nó không bao hàm mối quan hệ relationship crosscutting. Khung nhìn crosscutting bao gồm các mối quan hệ giao kết giữa các theme và các requirement, và mô tả các quan hệ giao kết giữa các theme – quan hệ cắt ngang. Khung nhìn crosscutting sẽ không chứa requirement chia sẻ, các requirement chia sẻ lúc này đã được giao kết gắn với duy nhất một theme aspect chịu trách nhiệm cho 13