LUẬN VĂN: TÌM HIỂU VỀ TIẾP CẬN THEME VÀ ỨNG DỤNG CỦA CÁCH TIẾP CẬN VÀO XÂY DỰNG HỆ THỐNG ĐIỆN THOẠI pdf

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 đó

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Lệ Huyền

TÌM HIỂU VỀ TIẾP CẬN THEME

VÀ ỨNG DỤNG CỦA CÁCH TIẾP CẬN VÀO XÂY

DỰNG HỆ THỐNG ĐIỆN THOẠI

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công Nghệ Thông Tin

HÀ NỘI - 2010

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Lệ Huyền

TÌM HIỂU VỀ TIẾP CẬN THEME

VÀ ỨNG DỤNG CỦA CÁCH TIẾP CẬN VÀO XÂY

DỰNG HỆ THỐNG ĐIỆN THOẠI

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công Nghệ Thông Tin

Cán bộ hướng dẫn: TS Đặng Văn Hưng

HÀ NỘI - 2010

Hà Nội, ngày 19 tháng 5 năm 2010 Trần Lệ Huyền

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

Danh sách chữ viết tắt

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

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

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

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

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ữ

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

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

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,

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

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

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

sẽ được ứng dụng vào

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

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”

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

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

+ 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

-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

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

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

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

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

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

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:

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

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 ở

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 – Front (chọn cẩn thận từ đầu), The Start-with-Everything (bắt đầu với tất cả)

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

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:

expression (khả năng đánh giá xác định kết quả đánh giá một biểu thức )

tả biểu thức dạng văn bản)

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)

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)

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)

(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)

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)

ngôi được xác định giống như một phép cộng và một biểu thức)

ngôi được xác định giống như một phép trừ và một biểu thức)

xác định giống như một văn tự và một biểu thức)

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

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

- 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

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

- 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à:

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

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

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

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

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

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

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

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,

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

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

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

ở 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

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

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