Khóa luậ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 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 đượ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. 6 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 7 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”. 8 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. 9 Hình 1-1 Theme base kích hoạt theme 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 10 + 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. 11 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 khung 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 12 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 trong 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 khung nhìn crosscutting. 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 13 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 14 hành vi của nó. Nhưng trong thực tế hai loại khung nhìns này cùng được tích hợp, nên có thể bạn sẽ thấy một khung nhìn relationship mà có một số crosscutting relationships, và cũng có một số requirement chia sẻ. Có thể coi rằng khung nhìn relationship giống như điểm bắt đầu, chỉ ra các theme, và liên kết chúng với các requirement liên quan; còn khung nhìn crosscutting giống như mục tiêu cuối, từ khung nhìn relationship tìm được theme aspect và theme base, từ đó xác định được các mối quan hệ cắt ngang, giao kết được requirement với theme phù hợp. 2.1.3 Khung nhìn individual Khung nhìn individial là một khung nhìn crosscutting (không chứa requirement chia sẻ) chỉ cho một theme. Thêm vào đó, nó bao gồm cả các key entities (các thực thể). Hình 2-3 mô tả ví dụ trừu tượng về khung nhìn individual. Mối giao kết giữa theme và requirement sẽ được liên kết giống như trong khung nhìn crosscutting. Với mối quan hệ trì hoãn nút requirement thường gán nhãn là text của requirement hơn là dùng nhãn của requirement (requirement đánh số thứ tự) trong khung nhìn crosscutting. Khung nhìn individual có thể có vài theme con, nếu ta cần thiết nhóm các theme. Hình 2-3 Ví dụ trừu tượng của khung nhìn individual . 2.2 Quá trình xử lý Theme/Doc Từ các phần của khung nhìn Theme/Doc, ta có ba phần chính khi xử lí Theme/Doc: deciding on a set of themes to include in your system- Xác định tập hợp các theme có trong hệ thống; determining the responsibilities of those themes- xác định trách nhiệm cho những theme đó; planning for design- lên kế hoạch thiết kế. Ba hoạt động này được mô tả trong hình sau: 15 Hình 2-4 Nhìn chung về quá trình phân tích. Họat động trên đỉnh của hình 2-4 là Decide on the themes. Quá trình này sẽ tìm các ra phần chức năng khác nhau của hệ thống, và mỗi chức năng đó sẽ được tách biệt trong khi thiêt kế - chính là các theme. Hoạt động này sử dụng khung nhìn relationship để tìm ra các theme. Phía dưới bên phải của hình là : Determing Theme Responsible. Hoạt động này có thể nói là : “Xác định đâu là theme aspect, và đâu là theme base”. Nếu theme Theme1 có khả năng chịu trách nhiệm cho hành vi mà được kích hoạt trong theme Theme2 thì Theme1 là một aspect của Theme2. Hoạt động này dựa vào khung nhìn crosscutting, để xác định trách nhiệm của theme. Cuối cùng là hoạt động Plan for Design: sẽ xem xét cấu trúc và hành vi của theme mà sẽ được mô-đun hóa sử dụng Theme/UML. Khung nhìn individual được sử dụng để đưa ra các kế hoạch cho thiết kế. Khi bắt đầu chúng ta sẽ áp dụng các hoạt động theo như các bước sắp xếp trong hình vẽ. Trong những lần xử lý Theme/Doc về sau, để làm mịn các thiết kế theme thì ta không nhất thiết phải theo thứ tự các bước nữa, có thể lựa chọn pha trộn giữa các hoạt động. 16 Hình 2-5. Các hoạt động trọng tâm khi chọn lựa các theme và quyết định trách nhiệm của chúng. Các công việc cụ thể hơn cần làm trong quá trình xử lý Theme/Doc được chỉ ra trong hình 2-5. Khung nhìn relationship được sử dụng trong cả hai hoạt động : quyết định theme, và xác định theme trách nhiệm. Khung nhìn individual liên quan nhiều đến quyết định trên theme. Khung nhìn crosscutting liên quan đến giao kết requirements (và trì hoãn giao kết), nó sử dụng trong hoạt động xác định theme base và theme aspect. Tất cả ba khung nhìn đều được sử dụng khi lên kế hoạch thiết kế. Các hoạt động khi quyết định trên theme: Add - thêm theme, Delete - xóa theme, Split - phân tách các theme, Group - nhóm các theme, Add requirement mới, Attach - giao kết requirement với một theme cụ thể, Postpone - trì hoãn giao kết đến khi có thêm thông tin để quyết định với requirements. Hoạt động xác định theme trách nhiệm là hoạt động trên requirement: Associate- giao kết requirement với một theme cụ thể, và split- phân tách requirement, postpone -trì hoãn giao kết requirement. 2.3 Quyết định trên theme Bước đầu tiên trong quá trình phân tích requirement với Theme/Doc là tìm hiểu các chức năng liên quan theme. Trong phần này chúng ta sẽ sử dụng các khung nhìn Theme/Doc (đặc biệt là khung nhìn relationship) để gán theme với requirement. 2.3.1 Chọn các theme ban đầu Đầu tiên là xác định tập hợp các concern từ các requirement, các hành vi được miêu tả trong requirement rất có khả năng sẽ trở thành một theme. Tìm các theme ở 17 thời điểm bắt đầu bằng cách: chọn tên của các đặc điểm, dịch vụ hay các trường hợp sẽ xảy ra trong hệ thống. Nếu requirement được chuyển thành nhiều trường hợp sử dụng thì mỗi trường hợp đó có thể trở thành một theme, hoặc nếu trường hợp sử dụng bao gồm rất nhiều các chức năng thì mỗi hành động trong trường hợp sử dụng sẽ là một theme. Nếu có một tập mục tiêu chính thức cho hệ thống mà đã được chỉ rõ và làm mịn, thì có thể áp dụng kĩ thuật tiếp cận yêu cầu hướng mục đích để chọn từ khóa từ mục đích hoặc các hành vi mục đích để miêu tả các theme. Có hai phương pháp chọn theme tiềm năng, đó là: The Choose –Carefully – Up- Front (chọn cẩn thận từ đầu), The Start-with-Everything (bắt đầu với tất cả). 2.3.1.1 Chọn cẩn thận từ đầu Với cách này, từ tập các requirement xác định những chức năng chính mà có khả năng trở thành các đặc điểm trong cài đặt. Ngay từ khi bắt đầu chọn lựa các theme tiềm năng, phải đánh giá cẩn thận các concern được mô tả trong requirement, các theme này có khả năng sẽ là các theme cuối trong hệ thống hay không. Với cách này, quá trình làm mịn theme sẽ phân tách các theme mà được coi là quá chung chung hoặc các theme mà có các requirement khi được nhóm vào sẽ hình thành tập chức năng không có sự dính liền, cố kết nhau (các chức năng của theme này hầu như không liên quan nhau, không có sự xảy ra đi liền với nhau). 2.3.1.2 Bắt đầu với tất cả Cách này sẽ chọn tất cả các động từ, hoặc các từ chỉ hành động được viết trong requirement để tìm tập theme ban đầu. Cách tiếp cận này tiếp kiệm thời gian trong bước đầu đọc qua các requirement và lựa chọn theme. Tuy nhiên , với cách tiếp cận này sẽ có rất nhiều theme tiềm năng vì thế mà quá trình làm mịn theme sẽ xem những theme nào thực sự sẽ tồn tại và phù hợp trong ứng dụng của mình để loại bỏ đi những theme không mong muốn, và nhóm các động từ để hình thành những theme thực tế lớn hơn. 2.3.1.3 Kết hợp cả hai hướng tiếp cận Bình thường, bạn sẽ kết hợp cả hai cách trên để quá trình tìm theme được hiệu quả. Khi đọc qua tài liệu về requirement, bạn nhặt ra tất cả những gì giống như một hành vi, concern, hay đặc điểm. Sự kết hợp này sẽ thu hẹp danh sách theme hơn so với cách lựa chọn bất kì động từ nào có trong tập requiremnent, và nó cũng lựa chọn thoải mái hơn so với cách chỉ chọn ra các khái niệm mà có triển vọng cao sẽ trở thành theme. Với cách đầu tiên, sẽ có những theme chắc chắn sẽ được cài đặt trong hệ thống nhưng sẽ có rất nhiều requirement là “mồ côi”, còn với cách thứ hai thì sẽ có quá 18 nhiều theme riêng lẻ, làm cho khung nhìn mối quan hệ sẽ vô cùng lớn, có thể trong số những theme đó có theme sẽ chẳng chịu trách nhiệm gì trong hệ thống của bạn. Vì thế kết hợp cả hai cách để giảm thiểu số lượng các requirement là “mồ côi” và giảm thiểu những theme không cần thiết. Xét một hệ thống đánh giá biểu thức đơn giản- expression evaluation system (EES), tập requirements của nó gồm: 1- An evaluation capability, which determines the result of evaluating an expression (khả năng đánh giá xác định kết quả đánh giá một biểu thức ). 2- A display capability, which depicts expressions textually ( khả năng hiển thị mô tả biểu thức dạng văn bản). 3- A check-syntax capability, which optionally determines whether expressions are syntactically and semantically correct (khả năng kiểm tra cú pháp, tùy chọn xác định cú pháp và ngữ nghĩa biểu thức đúng). 4- The check-syntax, display, and evaluation operations should all be logged (việc kiểm tra cú pháp, hiển thị, và các hoạt động đánh giá tất cả phải được lưu lại). 5- Expression is defined as a variableexpression or a numberexpression or a plusoperator or a minusoperator or a unaryplusop or a unaryminusop (biểu thức được định nghĩa là một biểu thức biến, hoặc biểu thức số, hoặc toán tử cộng, hoặc toán tử trừ, hoặc toán tử cộng một ngôi hoặc toán tử trừ một ngôi). 6- plusoperator is defined as an expression and a plusoperator and an expression (toán tử cộng được xác định giống như một biểu thức và một phép cộng và một biểu thức). 7- minusoperator is defined as an expression and a minusoperator and an expression (toán tử trừ được xác định giống như một biểu thức và một phép trừ và mộtbiểu thức). 8- unaryplusop is defined as a plusoperator and an expression (toán tử cộng một ngôi được xác định giống như một phép cộng và một biểu thức). 9- unaryminusop is defined as a minusoperator and an expression (toán tử trừ một ngôi được xác định giống như một phép trừ và một biểu thức). 10- variableexpression is defined as a letter and an expression (biểu thức biến được xác định giống như một văn tự và một biểu thức). 11- numberexpression is defined as a number and an expression (biểu thức số giống như một số và một biểu thức). Áp dụng cách tìm theme thứ hai, ta tìm tất cả các động từ trong tập requirement, đó chính là các theme tiềm năng. Có sáu theme tiềm năng: evaluation, display, determine, check-syntax, log, define. Chúng ta đã xác định được tập các theme ban đầu, và từ đó xậy dựng khung nhìn relationship. 19 Hình 2-6 Tổng hợp theme: khung nhìn relationship ban đầu 2.3.2 Các hoạt động trên theme Như trong hình 2-5 có bốn hoạt động chính trên theme: split, add, delete và group. 2.3.2.1 Split theme nếu theme quá tổng quát Sau khi lựa chọn được tập theme ban đầu, sẽ có những hành vi được giao kết với một theme cụ thể mà không phù hợp nhau. Các hành vi đó không có sự liên quan, móc nối với nhau. Để các theme được mạch lạc, cố kết thì theme không nên thực hiện nhiều requirement mà không liên quan đến nhau. Nếu một theme giao kết với nhiều requirement mà không liên quan đến nhau thì ta sẽ phân tách theme đó thành các theme con phù hợp. 2.3.2.2 Nhóm các theme tương tự Một số theme có tên đồng nghĩa nhau, hoặc có các sự kiện, hành vi luôn xảy ra cùng nhau chúng ta sẽ nhóm chúng vào một theme chính. Có hai thuật ngữ liên quan tới nhóm theme là : grouping (nhóm), unifying (đồng nhất). a) Đồng nhất theme : - Các theme hợp nhất được hiển thị với tên theme chính của chúng trong mọi khung nhìn. - Chủ yếu sử dụng cho giải quyết các theme đồng nghĩa nhau, kiểu này cơ bản là sự thay thế tham chiếu tới một theme thành tham chiếu tới theme khác, theme đó là theme chính. 20 tiên hãy xem xét các theme có cùng nghĩa. Tuy nhiên chỉ dựa vào tên của các theme ta không thể đảm bảo được chúng liên quan cùng khái niệm, cần phải kiểm tra các yêu cầu miêu tả chúng có giống nghĩa không. - Các theme có các requirements đồng nghĩa nhau. Hợp nhất các theme thành một thì theme hợp nhất đó có thể không thể nắm được hết các yêu cầu nó cần, bởi vì các theme con sử dụng tên theme chính, không phải tên theme của chính nó. Ta có thể lựa chọn requirement đồng nghĩa làm requirement chia sẻ giữa các theme để đồng nhất chúng theo requirement. b) Nhóm theme : - các theme con về cơ bản được chứa đựng bởi theme khác. Trong khung nhìn relationship và khung nhìn crosscutting chỉ hiển thị theme chính, các requirements kết nối với theme con được gắn tới theme chính, theme con không được hiển thị. Theme con chỉ hiển thị trong khung nhìn individual. - Điều này rất hữu ích cho việc nhóm các hành vi liên quan chặt chẽ trong các theme con vào một theme chính. Giúp bạn quyết định chuyển hành vi trong theme thành method. 2.3.2.3 Xóa những theme không muốn Khi refine các theme, nếu tìm thấy các theme quá tầm thường không cần thiết, hoặc không miêu tả chức năng hệ thống ta có thể xóa chúng. Trong ví dụ EES, vấn đề “determine” giống với một method hơn là một theme, vì thế chúng ta sẽ xóa nó khỏi tập theme. Khung nhìn relationship cho hệ thống EES bây giờ là: 21 Hình 2-7 Khung nhìn relationship sau khi xóa theme. 2.3.3 Hoạt động trên Requirements 2.3.3.1 Trì hoãn Requirement Chúng ta có thể trì hoãn quyết định requirement mà không được quan tâm trong thiết kế, hay chúng ta chưa thể đưa ra quyết định về requirement đó (cho đến khi thêm thông tin). Ta sẽ trì hoãn quyết định giao kết nó, đến khi quá trình phát triển sau này phát sinh những đặc điểm mà có thể đưa ra cách xử lý nó. Requirement được trì hoãn sẽ có viền là nét đứt, chỉ ra rằng requirement đó chưa được xử lý ngay. Các liên kết nếu có từ các theme liên quan đến requirement khi đó là đường nét đứt. 2.3.3.2 Thêm requirement Requirements có thể thêm vào bằng hai cách: đưa một requirement mới hoặc phân tách requirement đã có thành các requirement mới vào tập requirement . a) Kết hợp các requirement mới. Requirement mới có thể có thể nảy sinh trong quá trình phân tích. Khi thêm requirement mới vào tập requirement đã sắp xếp cần xem chúng có thể tích hợp với phần còn lại của hệ thống không. Thêm requirement vào Theme/Doc là đơn giản, chỉ cần thêm vào tập requirement và tạo lại các khung nhìn như yêu cầu. Nếu requirement mới tham chiếu tới các theme đã tồn tại thì ta liên kết chúng lại trong các khung nhìn. Các requirement mới cũng có thể phát sinh các theme mới ảnh hưởng tới các theme đã tồn tại, khi đó ta cần làm mịn lại theme, ví dụ thay đổi grouping. b) Phân tách requirement 22 Một số requirement được thêm mới do sự phân tách yêu cầu đã tồn tại. Requirements được viết không đủ cụ thể để tạo liên kết tới bất kì hành vi cụ thể, ta sẽ phân tách nó. 2.3.3.3 Gắn requirements tới các theme Gắn requirements với các theme mà nó tham chiếu đến. Một requirement mồ côi là requirement mà không tham chiếu đến bất kì tên của một theme đã tồn tại nào, nó xuất hiện trong khung nhìn relationship một cách cô lập. Chúng ta muốn giải thoát các requirements mồ côi đó, vì chúng miêu tả hành vi không được bao bọc trong bất kì đặc điểm nào của hệ thống. Requirements mồ côi có thể thuộc về một theme đã tồn tại hoặc nó thúc đẩy việc thêm một theme mới. Nếu cả hai cách đó không áp dụng được thì requirements mồ côi sẽ được trì hoãn. 2.4 Quyết định Theme trách nhiệm Mục tiêu của phương pháp theme là tìm ra nhiều theme, mỗi theme chịu trách nhiệm cài đặt một tập requirements hệ thống mà liên quan đến nhau. Mỗi requirement được cài đặt bởi chỉ một theme.Tuy nhiên cũng có ngoại lệ, một requirement được giao kết với hơn một theme. Một aspect là một theme mà miêu tả trong một requirement được rối lẫn với miêu tả của một theme khác. Sự mắc nối này xuất hiện khi có requirement được liên kết với nhiều hơn một theme, có requirement được chia sẻ. Nhưng không thể chắc chắn rằng: khi có một requirement được chia sẻ giữa các theme, thì sẽ có một theme là aspect và các theme còn lại là theme base. Chúng ta có bốn qui tắc để xử lý shared requiremets:  Split the requirement if possible: requirement chia sẻ có thể phân chia để miêu tả các theme riêng biệt.  Dominance means association: Khi requirement chia sẻ không thể phân chia, và nhận thấy nó chủ yếu liên quan tới một theme trong các theme chia sẻ, thì kết hợp nó với theme đó.  Base triggers aspect: Nếu hai theme được đề cập trong một requirement thì theme được kích hoạt là theme aspect và theme kích hoạt là base. Nếu xác định được theme aspect thì kết hợp requirement chia sẻ với theme đó.  Is the Aspect Crosscutting Enough : aspect được kích hoạt trong nhiều tình huống thì sẽ là một crosscutting. 23 2.4.1 Xác định Theme aspect 2.4.1.1 Split shared requirements if possible Mục đích cho quá trình này là kết hợp requirements với chỉ một theme. Chúng ta không muốn chức năng lặp lại trong các theme khác nhau. Ta xem xét liệu requirement chia sẻ có thể viết lại để các theme sẽ không còn liên kết với nhau. Nếu có thể tách requirement thành các requirement mới thì làm mịn các theme với các requirement mới. Xét R4 trong ví dụ EES: các hoạt động check-syntax, display, và evaluation nên được ghi lại – logged. Ta thử phân tách theme này ra thành các câu: log có khả năng ghi lại hoạt động check-syntax; log có khả năng ghi lại hoạt động display; log có khả năng ghi lại hoạt động evaluation. Khi đó tập các câu này lại có ý nghĩa như requirement ban đầu, đặc điểm log vẫn được mô tả liên quan đến check-syntax, display, và evaluation. R4 là requirement chia sẻ không thể bị phân tách. 2.4.1.2 Dominance means association: Khi requirement chia sẻ không thể phân tách để gỡ rối cho các theme thì chúng ta đi tới bước tiếp theo: tìm theme chi phối chịu trách nhiệm cho requirement chia sẻ. Có nhiều cách để kết luận một theme chi phối một requirement. - Trong requirement ta xem xét theo mặt: theme nào nên biết về các hành vi của requirement. Với R4, các hoạt động: check-syntax, display, và evaluation không cần biết là chúng đang được ghi lại. Nhưng theme log cần biết về cái mà nó ghi để điều chỉnh hành vi cho phù hợp. Trong requirement này có theme log là cần biết về hành vi đã miêu tả nên theme log sẽ chi phối requirement. - Xem xét tập các requirement khác kết hợp với mỗi theme, ta có thể kết luận theme nào quan tâm, cần biết về requirement chia sẻ nhiều hơn. Theme đó sẽ chi phối requirement chia sẻ. Theme nào chi phối requirement chia sẻ sẽ là theme aspect. 2.4.1.3 Base triggers aspect Ta đã chọn được theme nào là theme aspect, và bây giờ áp dụng qui tắc base- triggers-aspect. Hành vi của aspect sẽ được tự động kích hoạt bởi một số hành vi trong theme base. Việc kích hoạt hành vi của aspect sẽ thể hiện ngầm định tại vị trí kích hoạt. Nếu không có mối quan hệ aspect-base thì hành vi aspect phải được kích hoạt rõ ràng ở trong base. Log là aspect được kích hoạt bởi các theme base: check-syntax, display , và evaluation. 24 2.4.1.4 Đủ là aspect crosscutting Sau khi kiểm tra các ngyên tắc split/dominace/trigger ta tìm ra được một aspect và xem xét nó có là crosscutting. Aspect là hành vi bị kích hoạt được tách riêng với hành vi kích hoạt. Thuật ngữ crosscutting có nghĩa là tách riêng hành vi mà được trải rộng khắp trong hệ thống . Một aspect mà cắt ngang tại nhiều vị trí trong hệ thống (có thể cắt ngang tại nhiều vị trí mà chỉ thuộc một theme) thì aspect đó là một crosscutting. Một aspect mà chỉ được kích hoạt ở một vị trí thì nó không là crosscutting. Hành vi mà chỉ được kích hoạt tại một vị trí thì không nhất thiết phải quan tâm nó có phải là aspect, nó có thể tách riêng ra là một theme, hoặc đặt tại vị trí chính xác trong theme base. Ta có theme log được kích hoạt trong ba tình huống khác nhau, nên aspect log đủ là một crosscutting. 2.4.1.5 Make the association Trong khung nhìn crosscutting thì giao kết là mũi tên mầu xám đi từ theme aspect tới các theme khác liên quan trong requirement. Các requirement chia sẻ giờ chỉ liên kết đến theme aspect. Sử dụng các nguyên tắc split/dominance/trigger ta xác dịnh được theme log cắt ngang các theme: check-syntax, display , và evaluation. Trong hình 2-12 vẽ các mũi tên màu xám đi từ theme log tới các theme mà nó cắt ngang, requirement chia sẻ (R4) giữa theme log và các theme đó bây giờ chỉ được liên kết với duy nhất theme log, không liên kết với các theme base nữa. Hình 2-8 Khung nhìn rosscutting và relationship cho EES 25 2.4.1.6 Chuỗi của crosscutting Khi xác định được một theme cắt ngang một theme khác, không có nghĩa là theme crosscutting đó sẽ luôn cắt ngang các theme khác, hoặc các theme base được xác định sẽ luôn là theme base. Theme có thể vừa bị theme khác cắt ngang, vừa cắt ngang một theme khác. Khi themeA cắt ngang themeB, themeA là crosscutting. Trong một requirement chia sẻ khác thì themeA lại là theme base kích hoạt một theme crosscutting là themeC. Khi đó themeC là aspect của aspect. 2.4.2 Trì hoãn một số quyết định Khi chúng ta không thể đưa ra các quyết định về requirement chia sẻ: không tách được requirement, các theme đề cập trong requirement bình đẳng nhau không thể đưa ra theme nào chịu trách nhiệm cài đặt hành vi cho requirement, không xác định được theme nào kích hoạt thì có thể trì hoãn quyết định cho requirement lại. 2.5 Kế hoạch cho thiết kế Chúng ta đã xem xét mối quan hệ giữa các theme, và cố gắng giảm thiểu sự chồng chéo giữa các theme để có thể chuyển sang thiết kế. Các theme bây giờ được tách riêng biệt (trừ các mối quan hệ cắt ngang và trì hoãn), xem xét các khung nhìn individual của theme để thấy được những thứ ta có, và chuẩn bị chuyển thành thiết kế. Khung nhìn này mô tả các requirements giao kết với chỉ một theme. Nó bao quát các theme được hiển thị trong khung nhìn relationship, các theme con được nhóm lại trong các theme chính. Trong trường hợp theme crosscutting thì khung nhìn individual cũng chỉ ra các theme trừu tượng (theme base) nơi mà crosscutting xảy ra, giống như trong requirement miêu tả. 2.5.1 Xác định các đối tượng Tìm kiếm đối tượng theo bất cứ trật tự nào: trên các theme, hay xem xét tài liệu requirement để tìm kiếm các từ khóa object đáng quan tâm. Các từ khóa đối tượng được đưa vào khung nhìn individual của các theme, gắn với các requirement liên quan. Từ tập requirement cho EES ta xác định được các đối tượng cho hệ thống:  Expression (R5,R6,R7,R8,R9,R10,R11)  Variableexpression (R5,R10)  Numberexpression (R5,R11)  Plusoperator(R5,R6,R8) 26  Minusoperator(R5,R7,R9)  Unaryplusop(R5,R8)  Unaryminusop(R5,R9)  Letter(R10)  number(R11) 2.5.2 Khung nhìn theme base Theme bases chứa: các requirements giao kết với theme, danh sách object trong theme, và tất cả các hành vi được giao kết với theme. Hình2-9 Khung nhìn individualcủa check-syntax. Hình 2-9 là khung nhìn individual của theme check-syntax. Đối tượng expression được chỉ ra trong nút hình chữ nhật. R3 giao kết với theme . 2.5.3 Khung nhìn theme aspect Khung nhìn individual cho aspect cũng có các thông tin như khung nhìn individual của theme base, nhưng có thêm các mối quan hệ crosscutting. Các phần tử trong khung nhìn individual được phủ màu xám là các phần tử mà cũng được tìm thấy trong các theme khác (các theme mà kích hoạt aspect). Các nút màu xám chỉ cho ta biết chúng là các khái niệm được mô hình trừu tượng trong thiết kế . Các nút không phủ màu là các nút chỉ thuộc về thiết kế của khung nhìn này, nó được mô hình trực tiếp luôn trong thiết kế. Hình 2-10 khung nhìn individual của theme Log 27 Theme log cắt ngang các theme: display, check-syntax, evaluation. Các theme được cắt ngang chỉ ra trong các nút hình thoi phủ màu xám, và chúng liên kết với theme log bằng mũi tên xám đậm. 28 Chương 3 Thiết kế theme Trọng tâm chương này là thiết kế hướng khía giống như sự mở rộng của thiết kế hướng đối tượng, gọi là Theme/UML. Theme/UML của thiết kế hướng khía cạnh được mở rộng dựa trên chuẩn UML ngôn ngữ thiết kế hướng đối tượng. 3.1 Thiết kế theme base Sử dụng chuẩn UML để thiết kế cho theme base. Các phần tử trong các khung nhìn Theme/Doc được map (ánh xạ) tương ứng với phần tử thiết kế trong Theme/UML. Đối tượng thường được ánh xạ tới phần tử thiết kế cấu trúc như là class, attribute. Các hành vi được map tới một số method trên đối tượng. Trong hình 3-1, khung nhìn individual của Theme/Doc với các nút hành vi là hình thoi, các nút đối tượng là hình chữ nhật. Như trong hình 3-1, object4 là attribute trong thiết kế, các object còn lại được map tới các class khác nhau Hình 3-1 chuyển khung nhìn individual sang thiết kế theme. Bạn có thể thấy hình 3-1 cũng chứa một số cấu trúc và hành vi mà không trực tiếp được map từ các nút trong khung nhìn individual, đó là các phần tử phát sinh trong quá trình thiết kế. Các phần tử thiết kế có thể phát sinh bởi môi trường cụ thể mà bạn làm việc hoặc bởi vì các mối quan tâm đến kỹ thuật hệ thống không được biểu thị trong requirement. Sử dụng phương pháp thiết kế object-oriented phù hợp để tìm mô hình cấu trúc và hành vi của phần tử thiết kế, nắm bắt được hết tập requirements của theme chịu trách nhiệm. Thông thường trong hệ thống, khái niệm miền được sử dụng chung cho 29 rất nhiều theme khác nhau. Khi một khái niệm liên quan tới nhiều theme khác nhau, thì khái niệm đó được thiết kế khác nhau phù hợp với các requirement trong góc nhìn của mỗi theme. Và chúng sẽ được tổng hợp lại trong giai đoạn tổng hợp theme. Package theme – là tập các mô hình cấu trúc, hành vi cho theme. Chúng ta cần có một gói theme cho mỗi theme base được xác định. Một trong những điểm mạnh của Theme/UML là các requirements có thể được thiết kế trong góc nhìn của theme chịu trách nhiệm cho các requirement ấy. Điều đó cho phép các nhà thiết kế có thể thiết kế các theme khác nhau cùng lúc. 3.2 Thiết kế Theme crosscutting 3.2.1 Tổng quan về thiết kế Theme crosscutting Giống như theme base, theme crosscutting cũng có sự chia sẻ khái niệm về cấu trúc và hành vi giữa các theme với nhau, ngoài ra chúng có thể xác định hành vi mà được kích hoạt bởi theme khác. Hình3-2 chỉ ra sự mở rộng cần thiết cho thiết kế theme aspect, liên quan tới hành vi được kích hoạt. Đầu tiên xác định nơi hành vi aspect được kích hoạt, và giữ các kích hoạt giống như các template. Sau đó mô hình hành vi cắt ngang liên quan tới các template đó, và chỉ ra các giới hạn luồng điều khiển liên quan với các kích hoạt. Các phần tử còn lại trong theme không được kích hoạt thì sử dụng chuẩn UML thiết kế. Hình 3-2 Quá trình thiết kế aspect Trong hình 3-3, khung nhìn individual của theme aspect có một số nút hành vi, đối tượng được tô màu xám đậm, chỉ ra rằng chúng được tìm thấy trong theme khác. 30 Hình 3-3 Ánh xạ khung nhìn individual của theme aspect sang thiết kế aspect-theme Các nút cấu trúc màu xám nhạt (object1 và object5) và các nút hành vi màu xám nhạt (behavior3) là khái niệm tương tự như các theme base, thiết kế chúng giống như quá trình thiết kế theme base. Với các nút đối tượng màu xám (object2, object3, và object4) không nên đặc tả nhiều cho chúng trong thiết kế, bởi vì ta chỉ tham chiếu đến chúng trong thiết kế của aspect, chúng sẽ được thiết kế chi tiết ở một theme base bên ngoài.. Đối với mọi thiết kế theme, chúng ta cần chỉ rõ các vấn đề để về nắm bắt hết các requirements mà theme chịu trách nhiệm. Khi thiết kế crosscutting, chúng ta cần nói về hành vi kích hoạt trong các theme base mà không đề cập một cách rõ ràng tới nó. Nhưng chúng ta không muốn kết hợp thiết kế aspect với base cùng với nhau. Cho vấn đề này, chúng ta mở rộng khái niệm template của UML, template chính là các kích hoạt (trừu tượng), được đặt trong thiết kế crsscutting theme để theme đó có thể tham chiếu đến các hành động kích hoạt thực 31 ở theme base. Ta có thể lấy tên template giống tên hoạt động kích hoạt để cài đặt hành vi crosscutting được định nghĩa trong aspect. Để chỉ ra hành vi kích hoạt trong base theme xảy ra thật có thể thêm tiền tố _do_ vào tên template, nó sẽ gây ra chuỗi hành vi trong crosscutting. Hình 3-4 thiết kế theme aspect . Hình 3-4 minh họa một aspect-theme thiết kế như là một gói chuẩn UML với mô hình cấu trúc và hành vi, nhưng có thêm các tập template được liệt kê trong hình chữ nhật nét đứt góc trên phải của gói theme, với một biểu đồ tuần tự cho mỗi nhóm template. Trong hình có hai nhóm template viết trong mỗi ngoặc , sẽ có tương ứng hai biểu đổ tuần tự op1(), op2() miêu tả các chuỗi hành vi crosscutting. Các template được tham số cho các loại phần tử thiết kế khác nhau, như: class, operation, hoặc attribute. Khi tổng hợp, các phần tử thực trong theme base được cắt ngang sẽ thay thế các template trong thiết kế. Nếu template là một class, phần tử thiết kế trong theme crosscutting được thêm vào phần tử đã tồn tại trong class thực. Nếu template là một operation, sự thi hành của operation xuất hiện như được chỉ ra trong biểu đồ cộng tác của theme crosscutting. Nếu template là một attribute, attribute thực được sử dụng nơi các template được tham chiếu tới trong theme crosscutting. 32 3.2.2 Thay đổi với UML 3.2.2.1 Hành vi rosscutting và template Chuẩn UML có các mô hình hữu ích cho việc xác định hành vi cộng tác, ta có thể sử dụng chúng trong Theme/UML. Sử dụng lược đồ tuần tự để chỉ ra hành vi cắt ngang xuất hiện liên quan đến hành vi bị cắt ngang. Khi hành vi thực xảy ra, kéo theo các hành vi khác trong biểu đồ tuần tự cũng được thi hành theo tuần tự được chỉ ra trong biểu đồ. Trong lược đồ tuần tự, hành vi thực tham chiếu tới template. Cần phân biệt giữa hoạt động mà thay thế template (kích hoạt sự kết hợp hành vi của template và hành vi crosscutting) và sự thi hành thực của hoạt động thay thế (kích hoạt chuỗi hành vi trong lược đồ tuần tự). Thêm _do_ vào trước tên hoạt động thay thế để chỉ ra sự thi hành thật của nó trong biểu đồ tuần tự, khi đó nó chỉ ra hoạt động là một template trong biểu đồ. Hình 3-5 Ký pháp cho hành vi crosscutting Hình 3-5 minh họa một biểu đồ tuần tự cho template của theme log. Khi một hoạt động được ghi log cụ thể (thay thế cho loggedClass.loggedOp) trong theme base được bắt đầu, sẽ có một method LogFile.write() được gọi để ghi lại thông tin về hoạt động đó, sau đó nó sẽ được thực thi, sau khi nó thực thi xong thì LogFile.write() method lại được gọi để ghi lại thông tin mới về hoạt động. Sự cắt ngang của hành vi crosscutting có thể xảy ra: before (trước), after (sau) hoặc around (bao quanh) khi hành vi thực xảy ra, trong ví dụ này log crosscutting được kích hoạt trước và sau khi hảnh vi thực xảy ra. 33 3.2.2.2 Giới hạn luồng điều khiển cho hành vi kích hoạt Trong một số trường hợp, bạn muốn giới hạn hành vi thực trở thành một kích hoạt chỉ khi nó thi hành trong luồng điều khiển của hành vi khác. Minh họa trong hình 3-6, op2(..) kích hoạt hành vi crosscutting. Tuy nhiên nó được xác định trong luồng điểu khiển của _do_op1(..), có nghĩa là op2(..) trở thành kích hoạt cho hành vi cắt ngang before() và after() chỉ khi nó xuất hiện trong luồng điều khiển của _do_op1(..). Hình 3-6 Trigger trong luồng điều khiển cụ thể 3.2.2.3 Tham số operation template Bạn có thể nhận thấy tham số “..” được chỉ ra trong op1(..) và op2(..) trong các ví dụ trước. Điều này chỉ ra rằng một hoạt động của bất kỳ một signature (hành vi kích hoạt ở ngoài crosscutting) có thể thay thế template. Các đặc điểm tham số liên quan tới phạm vi mà hoạt động thay thế được thực hiện. Op() hoạt động thay thế không cần có tham số. Op(..) hoạt động thay thế có thể có bất kỳ dấu hiệu nào. Op(..,Type,..) hoạt động thay thế phải có một tham số kiểu Type trong danh sách tham số, nó được yêu cầu bởi chuỗi hành vi cắt ngang. 3.2.2.4 Danh sách Template cho theme class mà chứa các phần tử (operation và attribute) được mô hình tham số template thì class đó được gọi là class template. Trong Theme/UML một theme có thể có nhiều template mà là kiểu class nên vị trí đặt template trong theme có thể được thay thế bởi nhiều thành phần class thực. Ở đây có một qui tắc: Mọi operation template hoặc attribute template phải được định nghĩa như một phần của class template. Nói 34 cách khác nếu bạn có một class trong thiết kế crosscutting mà chứa một operation template hay tham số, thì chính class đó cũng được xem là một template, và tất cả những phần tử không phải là template cũng được thêm vào class thực khi tổng hợp các theme. Các template được xác định trong mỗi biểu đồ tuần tự thì được nhóm trong ngoặc , phân cách bởi dấu phảy. Hành vi crosscutting là cái mà được kích hoạt trong theme base, vì thế hoạt động đầu tiên trong nhóm phải kích hoạt hành vi crosscutting . Có thể có nhiều template được xác định trong chuỗi các hành vi, và sự sắp xếp trong nhóm này rất quan trọng vì nó liên quan đến trình tự hoạt động của lược đồ tuần tự. Các kích hoạt có thể được giới hạn bởi luồng điều khiển của cái khác hoặc không. Không giới hạn số nhóm hành vi, hay số operation/attribute là template được định nghĩa trong một nhóm hành vi. Nhưng lược đồ tuần tự mà sử dụng cho các template trong theme phải có một nhóm hành vi tương ứng các template đó. Trong một nhóm hành vi đơn , có thể có một số các operation template và attribute trong cùng class template. Để thuận tiện, ta mô tả chúng với một kí tự danh sách { }. Cho ví dụ, nhóm template sau có 6 operation template, trong ClassA có ba operation template, và trong ClassB có ba operation template. Nhớ rằng hoạt động đầu tiên trong nhóm template là hoạt động kích hoạt hành vi crosscutting trong biểu đồ tuần tự tương ứng, trong trường hợp này là ClassA.op1(). Và có tempalte class cho mô tả operation template và attribute, như trong ví dụ này hai class template là ClassA, ClassB, giúp không có sự xung đột giữa ClassA.op1() và ClassB.op1(). 3.2.2.5 Tham chiếu Template structure và hành vi Khi thiết kế crosscutting có ít nhất một số mô hình hành vi trong nó sẽ được kích hoạt bởi hành vi bên ngoài theme. Trong các theme base đó, các operation mà kích hoạt một chuỗi hành vi crosscutting xuất hiện trong các class khác nhau, chúng sẽ được nhóm trong một class template đơn để bắt hành vi crosscutting. Có thể có nhiều class mà được tổng hợp với class template bởi vì các class đó có các hoạt động mà kích hoạt các crosscutting hành vi liên quan (miêu tả trong chương sau). Điều này gợi ý cho việc sử dụng class template giống như kiểu tham chiếu trong thiết kế theme aspect. Giả sử, chúng ta có một class gọi là ClassA trong thiết kế aspect mà không phải là một class template, nó không có hành vi cắt ngang nào được kích 35 hoạt bên ngoài aspect. Tuy nhiên, chúng ta mong muốn ClassA được thêm vào thiết kế tổng thế. Cũng giả sử rằng, ClassA có một attribute gọi là att1. Nếu kiểu của att1 là template, có nhiều khả năng nó sẽ có trong tổng thể thiết kế? Nó là nhập nhằng bởi vì có nhiều class được tổng hợp với class template. Để tránh rối loạn Theme/UML không cho phép mở rộng tham chiếu đến class template.Tương tự, ta xét việc gọi các phương thức trong một class template từ một class khác trong theme aspect. Nếu một method trong ClassA (không phải template) gọi một method trong một class template, method đó có nên được thực thi khi mà theme aspect được tổng hợp với các theme base ? Điều đó lại là nhập nhằng, và để tránh rối loạn, Theme/UML không cho phép mở rộng gọi method trong một class template. Hình 3-7 ClassB là một class template, ClassA và ClassC thì không phải là template. ClassA không được tham chiếu đến thuộc tính att1- kiểu template trong ClassB, phương thức op3() trong ClassC không được tham chiếu đến op2() trong ClassB. Hình 3-7 Tham chiếu cấu trúc và hành vi template 36 Chương 4 Tổng hợp theme Chúng ta thiết kế mỗi theme individually mà không bao gồm các tham chiếu trực tiếp đến các theme khác. Bởi vì chúng ta muốn tránh đặc điểm rải rác và lẫn rối giữa các theme, ảnh hưởng xấu đến việc mô-đun hóa và gây nên sự hỗn độn cho sự khoa học của phần mềm. Trong chương này, chúng ta sẽ xem xét, xác định làm thế nào mà các theme liên quan đến nhau và làm thế nào chúng được tổng hợp thành một ứng dụng mạch lạc duy nhất. Với cách tiếp cận Theme’s symmetric, mỗi theme là một concern trong miền. Cần phải tổng hợp các theme cần thiết trong ứng dụng để đưa ra một ứng dụng mạch lạc. Tập các theme để tổng hợp cho ứng dụng có thể bao gồm tất cả các theme đã được thiết kế, hoặc các ứng dụng khác nhau có thể chỉ yêu cầu những tập con khác nhau từ những theme đã thiết kế. Thông thường, các bước trong quá trình tổng hợp là : 1 Chọn các theme để tổng hợp. Sự tổng hợp trong Theme/UML ở mức phần tử theme. 2 Xác định các phần tử thiết kế trong các theme tương đương nhau. Các theme mà có đặc tả cho cùng khái niệm miền sẽ được so khớp. 3 Chỉ ra làm thế nào các theme được tích hợp. Theme/UML cung cấp hai loại tích hợp : merge (hợp nhất) và override (ghi đè). 4 Chỉ ra làm cách giải quyết xung đột giữa các phần tử thiết kế được so khớp. 5 Xác định các hành vi kích hoạt trong theme base để bind (kết dính) tới template trong một theme aspect. 4.1 Pick Theme Đầu tiên bạn cần chọn các theme để tổng hợp cho ứng dụng và vẽ relationship tổng hợp (mối quan hệ tổng hợp) giữa các theme đã chọn. Một relationship tổng hợp là một kiểu mối quan hệ được xác định với Theme/UML. Kí hiệu cho một relationship tổng hợp là đường cong nét đứt giữa các phần tử thiết kế để tổng hợp. Trong Theme/UML tổng hợp xảy ra tại các mức phần tử theme: class, operation, attribute, và đầu tiên phải chọn các theme để tổng hợp. Các theme mà chứa các phần tử mà có ý nghĩa tương đương nhau, khớp nhau 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 37 cũng được tổng hợp. Sử dụng các relationship tổng hợp giữa các phần tử thiết kế sẽ được tổng hợp trong bối cảnh của tổng hợp theme. Không giới hạn số theme được tổng hợp đồng thời. Kết quả của mọi tổng hợp được chứa trong một theme mới. Ta có thể đặt tên cho theme mới với nhãn ThemeName[“name”] gắn trên relationship tổng hợp, “name” là tên của theme tổng hợp. 4.2 Xác định các phần tử thiết kế so khớp Khi chúng ta tổng hợp các theme, cơ bản là lấy tất cả các phần tử từ mỗi theme input (các theme được chọn để tổng hợp) và đặt chúng vào cùng một theme mới, vì thế ta muốn đảm bảo các phần tử chia sẻ cùng khái niệm được đặt vào theme mới. Tổng hợp đơn giản nhất là khi các thiết kế các theme không có khái niệm chung. Nhưng chúng miêu tả các khái niệm trong một miền hệ thống. Chúng xuất hiện trong theme kết quả với sự tách biệt nhau, không có relationship tổng hợp giữa chúng. Tuy nhiên,thường thì các theme input cung cấp các thiết kế có các khái niệm chung, từ góc nhìn các requirements của chúng. Trong thiết kế tổng hợp, các khái niệm chung phải được tổng hợp. Có hai cách so khớp các phần tử thiết kế: so khớp tường minh (explicit) và so khớp ngầm định (implicit). Hình 4-1 So khớp các phần tử thiết kế 38 4.2.1 So khớp tường minh Với phương pháp này, vẽ tường minh một relationship tổng hợp giữa các phần tử là khái niệm miền giống nhau. Relationship tổng hợp được xác định giữa các phần tử thiết kế cùng kiểu để chỉ ra các phần tử so khớp và cần được tổng hợp. Hình 4-1 , ở phía bên trái, tổng hợp Theme1 và Theme2 là được xác định với hai relationship tổng hợp. Vẽ một relationship tổng hợp giữa các theme được tổng hợp và một relationship tổng hợp giữa ClassB trong Theme1 và ClassB trong theme2 chỉ ra hai class được so khớp khái niệm, và ClassB xuất hiện một lần trong kết quả thiết kế tổng hợp. Phải dùng phương pháp tiếp cận này , khi các class không có cùng tên nhưng vẫn miêu tả cùng khái niệm, relationship tổng hợp được chỉ ra rõ ràng. 4.2.2 So khớp ngầm định So khớp tường minh các phần tử với một relationship tổng hợp cho mọi so khớp là hữu ích khi các phần tử không có cùng tên. Tuy nhiên, nó có thể nặng nề (và lộn xộn). Ta có thể định nghĩa một nguyên tắc cho relationship tổng hợp chỉ rõ các phần tử được đặt tên tương tự nhau được so khớp. Ở bên phải hình 4-4, chỉ có một relationship tổng hợp giữa các theme được tổng hợp, được gắn thêm nhãn là match[name]. Nhãn này chỉ ra rằng các class trong các theme cùng tên được so khớp và nên được tổng hợp. Ở đây các ClassB trong theme1, và theme2 sẽ được so khớp. Với nhãn match[name], ta có thể nói rằng bất kì phần tử nào nằm trong các phần tử so khớp mà có cùng tên sẽ được xem xét để so khớp: các class có cùng tên nằm trong các theme so khớp sẽ được so khớp; các attribute có cùng tên nằm trong các class so khớp cũng cần được so khớp … Relationship tổng hợp kiểu ngầm định là một relationship tổng hợp bắt buộc, chỉ ra các phần tử đặt tên giống nhau được so khớp như một sự bắt buộc. Ta có thể sử dụng một relationship tổng hợp tường minh giữa các phần tử bạn muốn so khớp mà không được phủ bởi nhãn match[name], nếu hai phần tử đó không cùng tên . Tất nhiên, chúng ta không muốn các phần tử có tên ngẫu nhiên giống nhau được so khớp. Chúng có thể không so khớp một cách tường minh bằng cách thêm một relationship tổng hợp với nhãn dontMatch giữa các phần tử không muốn so khớp. 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 Một đặc điểm quan trọng nhất của một phần tử thiết kế là xem xét cú pháp hợp lệ của một relationship tổng hợp, dù nó là một container chứa các phần tử khác, hoặc nó 39 là một thành phần của một phần tử khác (hoặc đồng thời là cả hai). Ví dụ attribute và operation được chứa trong một class; các class được chứa trong một theme… Quan hệ container/composition giữa các phần tử thiết kế là quan trọng cho xử lý tổng hợp, nó ảnh hưởng đến xác định các phần tử so khớp và xác định namespace của các phần tử được tổng hợp. Sau đây là các nguyên tắc cho so khớp : -Một relationship tổng hợp chỉ có thể vạch ra giữa các phần tử cùng kiểu. -Khi so khớp các phần tử thiết kế, đầu tiên cần vạch ra relationship tổng hợp giữa hai hay nhiều theme chứa các phần tử đó. -Hai (hoặc hơn) các phần tử thiết kế có thể được so khớp (tường minh hay ngầm định) chỉ khi containers của chúng được so khớp. Mọi phần tử tổng hợp phải có một namespace, điều này đảm bảo không có rối loạn trong container chứa các phần tử tổng hợp. -Mỗi phần tử thiết kế chỉ được so khớp trong một tập các phần tử so khớp. Có nghĩa là mọi phần tử thiết kế chỉ được tổng hợp trong một bản thiết kế tổng hợp. Nguyên tắc này nhằm không có sự rối loạn với tham chiếu trong kết quả tổng hợp. - Theme aspect được phép có ngoại lệ với quy luật “match –once”. Hành vi được định nghĩa trong theme crosscutting có thể được tổng hợp với nhiều phần tử khác nhau mà thay thế template sử dụng trong crosscutting hành vi. 4.3 Kiểu tích hợp- Integration Theme/UML xác định hai lối tích hợp để xác định cách lựa chọn các thành phần trong phần tử input đưa vào kết quả tổng hợp. Tích hợp merge (hợp nhất), tích hợp override (ghi đè). 4.3.1 Tích hợp merge Thông thường, kết quả tổng hợp của hợp nhất theme là sự hợp nhất của các mô hình cấu trúc và hành vi trong các theme input. Các mô hình class được hợp nhất vào một class đơn trong kết quả tổng hợp. Khi tổng hợp các mô hình class, các phần tử cấu trúc không được so khớp sẽ được thêm vào mô hình class tổng hợp. Các phần tử cấu trúc được so khớp sẽ xuất hiện chỉ một lần trong thiết kế. Các hoạt động được so khớp sẽ hợp nhất theo nghĩa: sự thi hành của một trong các hoạt động so khớp sẽ kích hoạt sự thi hành của tất cả hoạt động so khớp. Hình 4-2 minh họa kết quả của việc hợp nhất hai theme đơn giản. 40 Hình 4-2. Hợp nhất khái niệm so khớp. Các lớp so khớp (ví dụ hai lớp ClassB trong hai theme) và các attribute so khớp của chúng (a và b) xuất hiện chỉ một lần trong mô hình tổng hợp. Tất cả các elements khác được thêm vào không thay đổi trong mô hình tổng hợp. Khi các phần tử so khớp là container cùng kiểu, tất cả các phần tử thành phần của chúng được hợp nhất vào một container tổng hợp. Trong tích hợp merge, mũi tên relationship tổng hợp chỉ đến các phần tử thiết kế được so khớp. Hợp nhất hoạt động Hợp nhất hoạt động thực hiện khác với hợp nhất các phần tử cấu trúc. Các hành vi khác nhau thường được mô-đun trong các theme riêng biệt, chúng ta nên chỉ ra một tập các hoạt động so khớp khi chúng cần được thi hành cùng nhau. Ví dụ, bạn có các lớp so khớp có các attribute khác nhau, và có một method print()mà in ra các giá trị attribute. Khi các lớp như vậy được tổng hợp, tất cả thông tin đều được in, và vì thế khi print() được thi hành trên class tổng hợp, tất cả các hoạt động print() trên các lớp so khớp đều sẽ thi hành. 41 Khi hợp nhất các hoạt động có tên giống nhau, các hoạt động input được đổi tên (có thể là thêm tiền tố là tên theme của chúng) để tránh rối loạn, và tên ban đầu được sử dụng để tạo biểu đồ tuần tự mà thi hành mỗi operation trong biểu đồ tuần tự. Đây là cách xử lý mặc định cho các operation được so khớp. Xét sự hợp nhất operation trong hình 4-2, khi hợp nhất theme1 và theme2 thì các hoạt động op1() trong cả hai class ClassB được so khớp. Để chỉ ra các hành vi được hợp nhất, một biểu đồ tuần tự được tạo ra để xác định khi mà một yêu cầu thực hiện op1(), hai operation op1() trong các theme cũng được gọi. Các operation input được thay tên để tránh mâu thuẫn tên trong cả hai mô hình class và đặc tả biểu đồ tuần tự của chúng, ở đây các operation thay tên bằng cách thêm tên theme của chúng vào đầu tên operation, op1() trong theme1 được đổi thành Theme1_op1(). Tuy nhiên sự hợp nhất operation mặc định đó không phải lúc nào cũng được yêu cầu, ta có thể tránh hợp nhất bằng một relationship tổng hợp rõ ràng giữa hai operation với nhãn [dontMatch]. Một số operation khác tên nhau, được mô-đun hóa trong các theme riêng biệt nhưng chúng cùng mô tả các hành vi liên quan đến một vấn đề, hoạt động liên quan đến nhau thì chúng ta sẽ nhóm chúng lại để các hoạt động xảy ra cùng nhau, và thi hành chúng một cách tuần tự. Việc đó chính là hợp nhất các hoạt động. Khi các operation được hợp nhất (dù chúng có cùng tên hay không), sự sắp xếp thi hành trong chuỗi các operation so khớp là tạo ngẫu nhiên. Nếu thứ tự thi hành các hoạt động là quan trọng thì biểu đồ tuần tự tương ứng sẽ sắp xếp thứ tự các hoạt động . Bây giờ chúng ta sẽ xem xét vấn đề khi xảy ra xung đột tham số trong hợp nhất operation, hoặc nếu có nhiều operation trả về một giá trị. Trong trường hợp đầu tiên, nguyên tắc chung cho so khớp operation là chúng phải có cùng dấu hiệu kích hoạt. Khi thi hành, các giá trị input cho hoạt động tổng hợp có thể được sử dụng để gọi mỗi hoạt động của so khớp. Có một ngoại lệ cho nguyên tắc này, nếu một trong các operation so khớp có các tham số mà giá trị của chúng được sử dụng trong các operation so khớp khác (với tập các tham số của các operation được gọi), các operation đó có thể xác định là so khớp. Trong trường hợp này bạn phải gắn một biểu đồ tuần tự tới relationship tổng hợp chỉ ra làm thế nào các operation đó được gọi. Nếu không làm thế, các operation không được so khớp. Trong trường hợp thứ hai, sẽ mặc định là giá trị trong operation thi hành cuối cùng được trả về. Nếu bạn muốn hành vi khác trả về giá trị, bạn phải chỉ ra sự xác định hành vi đó trong biểu đồ tuần tự trên relationship tổng hợp. 42 Các phần tử không so khớp Nói chung, các phần tử thiết kế không so khớp với các phần phần tử khác thì được thêm vào thiết kế tổng hợp trong các namespace tương ứng. Cho ví dụ, các class mà không so khớp bất kỳ class nào, các thành phần của nó sẽ không thay đổi trong tổng hợp theme; các attribute mà không so khớp attribute khác trong các class so khớp của chúng thì đơn giản là thêm vào class tổng hợp. .. 4.3.2 Tích hợp override Dùng khi bạn có một phiên bản mới của theme mà cung cấp thêm đặc điểm mới cập nhật của requirements thay đổi với một theme đã tồn tại. Với tích hợp override, bạn có thể chỉ ra một theme ghi đè một theme khác, các phần tử trong theme ghi đè sẽ thay thế các phần tử được so khớp trong theme ghi đè. Các phần tử không được so khớp sẽ được bổ sung vào kết quả tổng hợp. Hình 4-3 Tích hợp ghi đè Hình 4-3 là một ví dụ minh họa. Nhãn Match[name] trên relationship tổng hợp đưa ra một so khớp cho các lớp ClassB từ theme input , các attribute của chúng là a,b và operation của chúng là op1(). Attribute a trong theme tổng hợp là public, giống như được xác định trong overriding theme (Theme1). Ngoài ra, hành vi của op1() trong theme kết quả giống như trong Theme1, biểu đồ tuần tự cho op1() trong Theme2 đã được thay thế với biểu đồ tuần tự cho op1() trong Theme1. 43 Trong tích hợp override mũi tên của quan hệ tổng hợp đi từ theme bị ghi đè sang theme ghi đè. Các nguyên tắc ghi đè Các nguyên tắc cho xác định relationship tổng hợp với tích hợp override gồm có : -Một relationship tổng hợp với tích hợp override phải là 1-1. Hay nói cách khác, một phần tử thiết kế chỉ ghi đè một phần tử thiết kế khác. -Một phần tử thiết kế chỉ được ghi đè một lần, trong một đặc tả tổng hợp đơn. -Các phần tử thiết kế ghi đè và bị ghi đè không tham gia trong các tổng hợp merge và override nào khác. Điều này đảm bảo không có sự rối rắm với tham chiếu trong kết quả tổng hợp. 4.3.3 Kết hợp các phương pháp tích hợp Các kiểu tích hợp có thể sử dụng trong cùng đặc tả tổng hợp. Nguyên tắc chung cho bất kỳ kiểu tổng hợp nào: đầu tiên phải xác định một relationship tổng hợp giữa các theme được tổng hợp. Sau đó có thể làm mịn hơn so khớp và tích hợp với bổ xung thêm các relationship tổng hợp giữa các thành phần của theme container. Một relationship tổng hợp được chỉ ra giữa các phần tử container áp dụng cho tất cả các thành phần bên trong container, trừ các relationship tổng hợp sâu hơn được chỉ ra giữa các thành phần bên trong các container so khớp. Do vậy, đặc điểm tích hợp của các relationship tổng hợp không giống nhau, khi áp dụng merge hay override là phải rõ ràng. Khi chỉ ra tích hợp overrride giữa các phần tử trong các theme, có một qui tắc ngầm định rằng đầu tiên phải lựa chọn các theme tham gia tổng hợp. Xác định relationship tổng hợp mức theme với tích hợp merge, và sau đó xác định các yêu cầu tích hợp ghi đè tại mức phần tử chỉ được xác định giữa các phần tử thuộc hai theme đó. 4.4 Giải quyết xung đột Với tích hợp merge, các phần tử được so khớp như các attribute và các class xuất hiện trong kết quả một lần, sẽ xảy ra xung đột nếu như các phần tử được so khớp có sự đặc tả khác nhau. Vì vậy chúng ta cần có một phương pháp để giải quyết các xung đột trong đặc tả của các phần tử được tích hợp. 44 Theme/UML cung cấp ba kỹ thuật khác nhau cho phép bạn thực hiện khi xung đột phát sinh: xác định rõ ràng các giá trị cho một xung đột cụ thể; xác định giá trị mặc định cho các cấu trúc thiết kế cụ thể; và xác định độ ưu tiên của theme. 4.4.1 Explicit values Cách cơ bản nhất để giải quyết xung đột giữa hai phần tử thiết kế là đặc tả kết quả nên nói một cách rõ ràng. Trong ví dụ hình 4-4, xung đột sinh ra do sự khác nhau về đặc tả tầm nhìn. ClassB trong Theme1 coi attribute a là public, trong khi ClassB trong theme2 cho rằng attribute a là private. Trong nhãn “resolve” trên relationship tổng hợp chúng ta nói rõ ràng rằng ClassB.a có tầm nhìn là private. Hình 4-4 Giải quyết xung đột với giá trị rõ ràng Bất kỳ đặc điểm cấu trúc nào cũng có khả năng xung đột, ví dụ, thuộc tính có tên, kiểu, giá trị khởi tạo, … Bạn có thể yêu cầu giá trị cho tất cả nhãn nếu cần thiết. Nếu có rất nhiều xung đột thì ta không nên chọn cách giải quyết này. Hai kỹ thuật giải quyết tiếp theo đưa ra câu lệnh tổng quát hơn khi xung đột xảy ra. 4.4.2 Giá trị mặc định Ta có thể chỉ ra giá trị mặc định cho tất cả các phần tử của một kiểu cụ thể được sử dụng chỉ trong một sự kiện xung đột. Ví dụ, khi có xung đột trong một tầm nhìn của attribute ta có thể chỉ ra nó là private, hoặc khi có xung đột cho tầm nhìn class thì ta có thể chỉ ra nó là public…. Hình 4-5 minh họa một ví dụ mà có xung đột attribute a trong các ClassB. 45 Hình 4-5 Giải quyết xung đột với giá trị mặc định Trong nhãn “resolve” trên relationship tổng hợp, chúng ta nói rằng với sự kiện xung đột cho bất kỳ tầm nhìn của attribute nào thì nó cũng xác định là private. Trong trường hợp này ClassB.a trong kết quả tổng hợp có tầm nhìn là private. Bạn có thể chỉ ra giá trị mặc định cho tất cả các attribute của một construct, nhưng không có khả năng chỉ ra giá trị mặc định cho các thuộc tính như: name, kiểu. Giá trị mặc định không sử dụng cho thuộc tính mà xác định một phần tử thiết kế (miêu tả phần tử theo hướng vật chất). Nếu cần giải quyết một xung đột thuộc tính như vậy thì chỉ ra giá trị rõ ràng (hoặc theo độ ưu tiên theme) là cách giải quyết. 4.4.3 Theme Precedence Nếu một theme có độ ưu tiên hơn những cái khác, nếu có xung đột xảy ra khi so khớp phần tử, đặc tả trong theme với độ ưu tiên cao nhất sẽ được sử dụng trong kết quả. Hình 4-6 Giải quyết xung đột với độ ưu tiên 46 Hình 4-6, relationship tổng hợp có nhãn “1.prec” , ta nói trong sự kiện xung đột giữa các đặc tả của các phần tử so khớp, đặc tả xác định trong theme2 sẽ được sử dụng trong kết quả tổng hợp. ClassB.a có tầm nhìn là private. Số thứ tự trong nhãn ưu tiên chỉ ra một sự sắp xếp cho độ ưu tiên. Khi tổng hợp nhiều theme, có thể chỉ ra theme có độ ưu tiên hơn các theme khác, với độ ưu tiên 1 là cao nhất. Đặc tả từ theme với độ ưu tiên cao nhất sẽ được sử dụng trong kết quả tổng hợp. 4.5 Chỉ ra binding cho Theme aspect Khi tổng hợp các theme base với theme aspect, các theme thường được tổng hợp với tích hợp merge. Chúng ta sẽ gắn nhãn bind[] trên Theme/ UML's relationship. Với nhãn bind[] cơ bản là liệt kê tất cả các kích hoạt mà so khớp với mỗi template trong theme aspect. Hình 4-7 minh họa một ví dụ đơn giản. Hình 4-7 Ràng buộc triggers với aspect tmeplates Theme1 trong hình 4-7 có một khối hành vi crosscutting (op2()) mà thi hành sau bất kì kích hoạt nào. Kích hoạt được mô tả trong thiết kế là một operation template op1(). Gắn ràng buộc bind xác định hai kích hoạt trong Theme2 base: x() từ ClassC và o() từ ClassE. Thiết kế này chỉ ra rằng, khi một trong hai ClassC.x() hoặc ClassE.o() xảy ra thì op2() trong theme aspect cũng được thi hành sau đó. Hình 4-8 minh họa cách Theme/UML mô hình kết quả của theme aspect được bind với theme base. Một biểu đồ tuần tự được tạo chỉ ra hành vi mà xảy do các kích hoạt từ theme base. 47 Hình 4-8 Hoạt động base kích hoạt hành vi aspect Khi chỉ ra một operation trong theme base so khớp với một operation template trong theme aspect, chính là so khớp các class tương ứng. Trong kết quả của sự so khớp này, các class được hợp nhất và các class được so khớp trong theme base được đổi tên để tránh xung đột. Ví dụ như hình 4-7 và hình 4-8, ClassB được hợp nhất với cả hai ClassC, ClassE. Bởi vì chỉ phần tử trong class có template mới có thể tham chiếu đến các phần tử khác trong class đó, nên trong các class được hợp nhất bằng tham chiếu sẽ không có sự rối loạn. Chỉ các methods trong ClassB mới có thể gọi methods trong ClassB va tham chiếu đến các attribute trong ClassB, và các tham chiếu map tới ClassC và ClassE tương ứng trong kết quả. Methods trong ClassB có thể thi hành các methods khác trong các class khác ở trong aspect, với điều kiện là các class khác không có khả năng hợp nhất với nhiều class khác. Các operation mà sẽ bind tới các template trong theme log được chỉ ra bằng relationship tổng hợp gắn nhãn bind[]. Tập template biểu thị các biểu đồ tuần tự khác nhau của các hành vi trong ngoặc trong nhãn bind , có thể xác định một hay nhiều phần tử thực để bind tới các template đó trong các ngoặc . Chú ý là có nhiều operation để chỉ ra một template thì chúng được nhóm trong ngoặc { }. Chúng ta nên tổng hợp các theme base trước, sau đó tổng hợp với các theme crosscutting. 48 Hình 4-9 Bind log crosscutting Trong hình, theme log chỉ có một tập template, tương ứng với hoạt động trong theme base được ghi log. Ngoặc trong nhãn bind chỉ ra rằng có một tập các hoạt động mà sẽ được ghi log: expression.check(..), expression.asString(..), expression.evaluate(..). Không giới hạn số template trong một chuỗi hành vi. Nhưng template đầu tiên trong nhóm của hộp template phải miêu tả operation thay thế mà kích hoạt chuỗi hành vi. Tương ứng, operation thay thế đầu tiên trong bind[] sẽ là một trong các hành vi kích hoạt. Mẫu thiết kế Observer là một ví dụ cho template trong một chuỗi các sự kiện. Trong mẫu Observer có các subjects (đối tượng) và observers (người quan sát). Observers ghi những chú ý về thay đổi trạng thái của các subjects. Khi subject thay đổi trạng thái (một Theme/UML template), một sự kiện được send tới observers (cũng là một template). Hình 4-10 minh họa một hộp template của thiết kế theme crosscutting Observer, chứa các template cho ba chuỗi hành vi: observer crosscutting được kích hoạt khi thay đổi trạng thái trong object, khi một observer khởi đầu, và observer chấm dứt sự quan tâm một subject. 49 Hình 4-10. Observer template. Chuỗi hành vi thay đổi trạng thái có hai template : aStateChange(..) và update(), khi subject thay đổi trạng thái sẽ kéo theo hành vi update() của người quan sát, các hành vi này được so khớp và đưa vào biểu đồ tuần tự. Như vậy, một biểu đồ tuần tự được tạo cho mỗi tập operation thay thế liên quan với một chuỗi hành vi (mỗi nhóm hoạt động trong ngoặc trong template box sẽ tương ứng với một biểu đồ tuần tự). bind[ ] Nếu có nhiều trạng thái thay đổi được quan sát, ngoặc { } có thể sử dụng để nhóm các operation mà thay thế cho một template. Ví dụ: bind[ < { subject._do_aStateChange1(),subject._do_aStateChange2()}, observers.update() > ] Trong ví dụ này, hai biểu đồ tuần tự được tạo để chỉ điều xảy ra khi thi hành hai hoạt động thay đổi trạng thái khác nhau của subject. Trong cả hai trường hợp, hành vi 50 update() của observers cũng được thi hành. Làm mịn cú pháp hơn với ngoặc { } để nhóm các operation trong cùng lớp, ta có thể viết lại nhãn bind trên như sau: bind[ < { subject.{_do_aStateChange1(), _do_aStateChange2()}}, observers.update() > ] Nói chung, khi nhiều operation thay thế template đầu tiên (template miêu tả sự kích hoạt của hành vi crosscutting), thì sẽ có một biểu đồ tuần tự được tạo ra cho mỗi cái. Nếu không muốn observers.update() thực thi trong mọi thể hiện của thay đổi trạng thái, các nhóm phải được xác định rõ ràng, chúng ta không cho phép có nhiều thay thế cho các template tiếp sau hoạt động kích hoạt đầu tiên. Chúng ta cần xác định nhiều bindings lồng nhau trong một tập . Ví dụ, tất cả operation bắt đầu với add của object class mà kích hoạt hành vi observers.addUpdate() được bao trong một ngoặc < > con, trong khi _do_aStateChange1() và _do_aStateChange2() kích hoạt thi hành của observers.update() được bao trong một ngoặc con, cả hai ngoặc con đó được đặt trong một ngoặc cha để chỉ ra hai hành vi khác nhau được kích hoạt cho template thứ hai trong tập template thay đổi trạng thái của object. bind[ < { subject.{_do_aStateChange1(),_do_aStateChange2()}},observers.update() > > ] Với mỗi nhóm , template đầu tiên trong một nhóm tuần tự mà kích hoạt hành vi crosscutting có thể có nhiều bindings, nhưng các template tiếp theo thì không. Không cần thiết phải luôn có danh sách rõ ràng các kích hoạt trong theme base. Theme/UML cũng cấp các cách thức chỉ ra nhiều phần tử thay thế mà không cần đặt tên rõ ràng, kể cả một số operation phức. Bảng 4-1 Chỉ ra nhiều phần tử. Cấu trúc Ý nghĩa * Tất cả các phần tử cấu trúc sẽ là phần tử thay thế. Ví dụ, ClassName.*() thỏa mãn với tất cả các operation trong 51 ClassName. Khi sử dụng *.* (để thay thế cho một operation template) thỏa mãn với mọi operation trong mọi class trong theme base. cc* Giống với *, nhưng các kí tự đầu của phần tử thay thế phải giống như kí tự được chỉ ra trước *. Ví dụ Player.set* (để thay thế cho một operation template) thỏa mãn với mọi operation mà bắt đầu với “set” trong Player class *cc Tương tự như cc*, nhưng các kí tự cuối của phần tử thay thế phải giống với các kí tự chỉ ra sau *. Meta:property=value Sử dụng nhãn đặc tả, xác định phần tử thay thế bằng cách đưa ra yêu cầu giá trị của metaproperties của construct. () AND () Tất cả các phần tử thỏa mãn trong các toán hạng sẽ thay thế mẫu () AND NOT () Toán tử AND NOT bao gồm tập các operation mà thỏa mãn toán hạng đầu và không bao gồm tập operation thỏa mãn trong toán hạng sau 52 Chương 5 Xây dựng hệ thống điện thoại với phương pháp Theme 5.1 Tóm tắt về dự án: Ngày nay, điện thoại không chỉ để thông tin liên lạc mà còn xem tivi, nghe nhạc, duyệt web, thoại video, gửi hình ảnh-âm thanh, định vị GPS, rút tiền từ máy ATM, thanh toán mua hàng từ máy bán hàng tự động… Mọi việc từ chia sẻ thông tin đến phục vụ các nhu cầu giải trí đều nằm gọn trong một chiếc điện thoại . Điều đó cho ta thấy tầm ảnh hưởng vô cùng to lớn của mobile trong cuộc sống. Công nghệ xây dựng các ứng dụng cho hệ thống mobile đang rất phát triển. Đi kèm với nó là một loạt các công nghệ và kĩ thuật để giúp bạn có thể xây dựng và phát triển các ứng dụng mobile, như J2ME của Java, hay .NET Mobile. Trong phạm vi nghiên cứu của khóa luận này em chỉ đề cập tới việc phân tích và ứng dụng kĩ thuật aspect để xây dựng các đặc điểm trên hệ thống mobile cơ bản mà bất cứ một chiệc điện thoại cầm tay nào cũng có, như dịch vụ SMS, nghe nhạc hay chơi game... xây dựng ứng dụng với aspectJ. + Phạm vi dự án : ứng dụng giả lập chạy trên PC. + Đối tượng sử dụng: Là người dùng tương tác trực tiếp với ứng dụng mobile giả lập. 5.2 Phân tích yêu cầu dự án Trong phần này chúng ta sẽ ứng dụng cách sử dụng theme với việc phân tích và thiết kế các đặc điểm của hệ thống điện thoại. Chúng ta sẽ không đặt trọng tâm vào các giao tác như là xử lý cuộc gọi… mà chủ yếu xem xét kĩ tới các đặc điểm của hệ thống điện thoại, cụ thể là: cuộc gọi thoại (voice call), dịch vụ tin nhắn ngắn (SMS), một máy nghe nhạc đa phương tiện (media player), và một ứng dụng game (game application). Bảng 5-1. Danh sách các requirement của hệ thống. Đặc Điểm Requirements (Các yêu cầu) Menu R1: menu chứa một vài tùy chọn: làm một cuộc gọi thoại, viết một tin nhắn, sử dụng trình nghe nhạc, chơi một trò chơi. 53 R1: The menu consists of several options: make a voice call, write an SMS, use the media player, play a game. R2: Người dùng có thể cuộn menu và lựa chọn một mục để bắt đầu. R2: A user can scroll through the menu and select an item to start. Alert and Rings (Cảnh báo và chuông) R3: Chuông báo được sử dụng để làm tín hiệu khi một cuộc gọi thoại đến R3: Ringing is used to signal an incoming voice call R4: Hộp cảnh báo được sử dụng để làm tín hiệu khi một tin nhắn tới. R4: Alerts are used to signal an incoming SMS R5: khi cảnh báo và chuông xảy ra, những âm thanh khác như (media player, voice call, âm thanh của game) được chuyển về trạng thái mù âm nhưng không bị dừng lại R5: when alerts and rings occur, other audio (media player, voice call. game sound) is momentarily muted but not paused. Voice Call R6: khi một cuộc gọi thoại xảy ra, những hoạt động khác như (media player, game, chỉnh sửa tin nhắn) đều bị dừng lại, và trạng thái của chúng được lưu lại, để có thể phục hồi khi cuộc gọi kết thúc. R6: when a voice call occurs, other activities (media player, game, SMS edit) are paused, and their state saved, to be resumed when the call ends. SMS R7: Người dùng có thể gửi và chỉnh sửa một tin nhắn từ trong ứng dụng SMS. R7: A user can send and edit an SMS from within the SMS application Game R8: Người dùng có thể chơi, tạm dừng, lưu trạng thái và thoát khỏi một game. R8: A user can play, pause, save, and exit a game session. Media Player R9: Trình nghe nhạc có các chức năng: chơi audio, thu âm audio, radio, chơi memo và thu âm memo R9: The media player has several functions: play audio, record audio, radio, memo play. and memo record R10: Trình nghe nhạc có thể bắt đầu, dừng, tạm dừng và resume tất cả các chức năng ở trên. 54 R10: The media player can start, stop, pau