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

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Lệ Huyền

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

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

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

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

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

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

HÀ NỘI - 2010

2

Lời cảm ơn

Lời đầu tiên, em xin được bày tỏ lòng biết ơn sâu sắc tới thầy Đặng Văn Hưng-

Người đã trực tiếp hướng dẫn, tận tình giúp đỡ em trong thời gian thực hiện khóa luận.

Em xin được bày tỏ lòng biết ơn tới các thầy, cô trong khoa Công Nghệ Thông

Tin, trường Đại Học Công Nghệ, ĐHQGHN. Các thầy cô đã nhiệt tình dạy bảo và tạo

mọi điều kiện học tập tốt nhất cho chúng em trong những năm học tập tại ĐHCN

Tôi xin cảm ơn các bạn sinh viên lớp K51CC và K51CNPM Trường Đại học

Công nghệ, những người bạn đã cùng tôi học tập và rèn luyện trong suốt những năm

học đại học.

Hà Nội, ngày 19 tháng 5 năm 2010

Trần Lệ Huyền

3

Tóm tắt

Lập trình hướng khía cạnh (Aspect Oriented Programming - AOP) là một kiểu

lập trình mới nhanh chóng thu hút được các nhà phát triển trong giới công nghệ thông

tin. AOP là một mô hình lập trình tách biệt các chức năng phụ với logic nghiệp vụ của

chương trình chính. Các chức năng phụ rải rác nằm xuyên suốt trong hệ thống được

tách thành các đơn vị duy nhất, gọi là aspect( khía cạnh). Một aspect là một đơn vị mô-

đun cho sự thi hành cắt ngang chương trình. Nó đóng gói các hành vi mà ảnh hưởng

đến nhiều lớp vào các mô-đun có khả năng sử dụng lại. Đây là một phương pháp lập

trình phát triển dựa trên lập trình hướng đối tượng.

Bài luận tìm hiểu về cách xây dựng hệ thống với phương pháp AOP. Và ứng dụng

AOP vào xây dựng thiết kế một hệ thống điện thoại với các chức năng cơ bản.

4

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

STT Từ viết tắt

Giải nghĩa

1

2

AOP

OOP

Aspect Oriented Programming

Object Oriented Programming

5

Mục lục

Chương 1 Tiếp cận AOP ...................................................................................................... 2

1.1 Giới thiệu:................................................................................................................ 2

1.2 Đặc điểm của AOP .................................................................................................. 3

1.2.1 Aspect là gì? ..................................................................................................... 3

1.2.2 Nguyên tắc: ...................................................................................................... 4

1.2.3 Những lợi ích “separate of concerns”................................................................ 4

1.2.4 Tiếp cận aspect ................................................................................................. 5

1.3 Giới thiệu sơ qua về Theme ..................................................................................... 7

1.3.1 Định nghĩa về Theme........................................................................................ 7

1.3.2 Mối quan hệ giữa các theme :............................................................................ 8

1.3.3 Áp dụng cách tiếp cận theme: ........................................................................... 9

Chương 2 Phân tích........................................................................................................... 11

2.1 Các khung nhìn Theme/Doc................................................................................... 11

2.1.1 Khung nhìn relationship của theme ................................................................. 11

2.1.2 Khung nhìn crosscutting của Theme ............................................................... 12

2.1.3 Khung nhìn individual .................................................................................... 14

2.2 Quá trình xử lý Theme/Doc.................................................................................... 14

2.3 Quyết định trên theme............................................................................................ 16

2.3.1 Chọn các theme ban đầu ................................................................................. 16

2.3.2 Các hoạt động trên theme................................................................................ 19

2.3.3 Hoạt động trên Requirements.......................................................................... 21

2.4 Quyết định Theme trách nhiệm .............................................................................. 22

2.4.1 Xác định Theme aspect................................................................................... 23

2.4.2 Trì hoãn một số quyết định ............................................................................. 25

2.5 Kế hoạch cho thiết kế............................................................................................. 25

2.5.1 Xác định các đối tượng ................................................................................... 25

2.5.2 Khung nhìn theme base................................................................................... 26

2.5.3 Khung nhìn theme aspect................................................................................ 26

Chương 3 Thiết kế theme.................................................................................................... 28

3.1 Thiết kế theme base.................................................................................................... 28

3.2 Thiết kế Theme crosscutting .................................................................................. 29

3.2.1 Tổng quan về thiết kế Theme crosscutting ...................................................... 29

3.2.2 Thay đổi với UML.......................................................................................... 32

Chương 4 Tổng hợp theme................................................................................................. 36

4.1 Pick Theme............................................................................................................ 36

4.2 Xác định các phần tử thiết kế so khớp.................................................................... 37

6

4.2.1 So khớp tường minh ....................................................................................... 38

4.2.2 So khớp ngầm định......................................................................................... 38

4.2.3 Các nguyên tắc cho so khớp khái niệm chung với relationship tổng hợp ......... 38

4.3 Kiểu tích hợp- Integration...................................................................................... 39

4.3.1 Tích hợp merge............................................................................................... 39

4.3.2 Tích hợp override ........................................................................................... 42

4.3.3 Kết hợp các phương pháp tích hợp.................................................................. 43

4.4 Giải quyết xung đột................................................................................................ 43

4.4.1 Explicit values ................................................................................................ 44

4.4.2 Giá trị mặc định.............................................................................................. 44

4.4.3 Theme Precedence.......................................................................................... 45

4.5 Chỉ ra binding cho Theme aspect ........................................................................... 46

Chương 5 Xây dựng hệ thống điện thoại với phương pháp Theme..................................... 52

5.1 Tóm tắt về dự án:................................................................................................... 52

5.2 Phân tích yêu cầu dự án ......................................................................................... 52

5.2.1 Xác định các theme ban đầu............................................................................ 54

5.2.2 Làm mịn tập theme ......................................................................................... 55

5.3 Thiết kế các theme................................................................................................. 60

5.3.1 Phân tích UseCase .......................................................................................... 60

5.3.2 Thiết kế theme ................................................................................................ 61

5.4 Tổng hợp theme..................................................................................................... 79

7

Mở đầu

Lập trình hướng đối tượng (Object Oriented Programming - OOP) là mô hình

phát triển được lựa chọn cho hầu hết các dự án phần mềm. OOP rất hữu hiệu trong

việc lập mô hình hành vi chung của các đối tượng, tuy nhiên nó không giải quyết thỏa

đáng những hành vi liên quan đến nhiều đối tượng. AOP giải quyết được vấn đề này,

và rất có thể sẽ là bước phát triển lớn kế tiếp trong phương pháp lập trình.

Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một

cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung cho kỹ

thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đun khác, cho phép kéo

thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘aspect’ (khía

cạnh), từ chữ ‘aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới:

aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ

kiểm soát hơn. Các aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch

và có thể tái sử dụng.

Aspect-orientation là một hướng tiếp cận mạnh mẽ cho lập trình hệ thống phức

tạp. Áp dụng phương pháp aspect vào mô hình và thiết kế hệ thống có nhiều ưu điểm

so với OOP. Cách tiếp cận Theme (chủ đề) là một ưu điểm quan trọng trong AOP,

cung cấp phương tiện để ứng dụng aspect-orientation.

Bài luận của em tìm hiểu về AOP dựa trên tài liệu “Aspect-Oriented Analysis

and Design: The Theme Approach “ của tác giả Siobhán Clarke và Elisa Baniassad.

Bài luận trình bày về phân tích xây dựng một hệ thống bằng phương pháp AOP.

Bài luận gồm năm chương:

Chương 1: Giới thiệu và trình bày các đặc điểm về AOP.

Chương 2: Phân tích yêu cầu hệ thống để tìm ra tập theme .

Chương 3: Thiết kế riêng biệt các theme sử dụng UML, với một số mở rộng của

UML chuẩn.

Chương 4: Tổng hợp các thiết kế theme riêng biệt thành một hệ thống hoàn chỉnh

mạch lạc.

Chương 5: Ứng dụng AOP với phương pháp theme vào xây dụng các đặc điểm

cơ bản cho hệ thống điện thoại.

1

Chương 1 Tiếp cận AOP

1.1 Giới thiệu:

Vào những ngày đầu của ngành khoa học máy tính, các thảo chương viên lập

trình trực tiếp bằng mã máy. Những nhà phát triển phần mềm thời đó đã phải tốn nhiều

thời gian suy nghĩ về tập lệnh riêng của từng phần cứng máy tính cụ thể hơn là tập

trung để giải quyết các yêu cầu của bài toán đặt ra. Dần dần, người ta chuyển sang các

ngôn ngữ lập trình cấp cao hơn, cho phép khái quát hoá ở mức độ nào đó mã máy chạy

bên dưới.

Rồi kế đến là các ngôn ngữ lập trình có cấu trúc cho phép phân tích bài toán

thành các thủ tục thực hiện những tác vụ cần thiết. Phương pháp lập trình này thực

hiện theo cách tiếp cận hướng chức năng chủ yếu dựa vào phân rã các chức năng chính

của bài toán thành các chức năng đơn giản hơn và thực hiện làm mịn dần từ trên xuống

để tạo ra cấu trúc phân cấp. Chương trình theo hướng tiếp cận này thực chất là một tập

các chương trình con (các hàm) mà máy tính cần thực hiện để hoàn thành nhiệm vụ

của hệ thống. Trong đó dữ liệu và các hàm là tách rời nhau, các hàm muốn liên kết

trao đổi với nhau thì phải thông các biến chung (global). Nếu phải sửa đổi dữ liệu thì

sẽ phải sửa đổi mọi nơi mà sử dụng dữ liệu đó, và như vậy sẽ ảnh hưởng tới tất cả mọi

người tham gia lập trình.

Khi độ phức tạp của các bài toán tăng lên, chúng ta cần có những kỹ thuật tốt

hơn là lập trình hướng thủ tục.

Lập trình hướng đối tượng OOP đã trở thành sự lựa chọn chính khi phát triển và

xây dựng hệ thống phần mềm trong nhiều năm qua, mà thay thế hoàn toàn cho cách

tiếp cận hướng thủ tục. Một trong những ưu điểm lớn nhất của hướng đối tượng là hệ

thống phần mềm có thể được xem như là việc xây dựng một tuyển tập các lớp riêng

biệt. Mỗi một class (lớp) trong tuyển tập các lớp đó chịu trách nhiệm cho một tác vụ

nào đó trong hệ thống. Trong ứng dụng hướng đối tượng, các lớp này sẽ hợp tác lại với

nhau để hoàn thành mục tiêu chung của ứng dụng.

Kỹ thuật OOP thực hiện tốt việc đóng gói các hành vi và chủ thể , miễn là chúng

hoàn toàn riêng biệt. Tuy nhiên, các bài toán thực tế thường có những hành vi đan

nhau liên quan đến nhiều lớp, không thể được xem như là trách nhiệm riêng của một

lớp. Ví dụ như là việc tiến hành locking (khóa) trong các ứng dụng phân tán, xử lí

ngoại lệ, hoặc việc ghi log…Tất nhiên code để mà xử lý các phần này có thể được

thêm vào mỗi lớp một cách riêng biệt, nhưng điều này sẽ dẫn tới sự vi phạm trách

nhiệm chính của mỗi lớp mà ta đã định nghĩa. Theo truyền thống, hầu hết ngôn ngữ

2

lập trình hướng đối tượng như C++ và Java đều không hỗ trợ đóng gói những hành vi

đan nhau, dẫn đến mã chương trình có thể nằm lẫn lộn, rải rác và khó quản lý.

AOP là kỹ thuật lập trình mới cho phép đóng gói những hành vi có liên quan đến

nhiều lớp. Nó tập trung vào các khái niệm cắt ngang hoặc các khía cạnh - phần mã sử

dụng chung cho các đối tượng khác nhau. Nhờ mã được tách riêng, vấn đề đan nhau

trở nên dễ kiểm soát hơn. AOP tách riêng các đặc điểm mà rải rác, đan xen trong hệ

thống thành một mô-đun riêng để xử lý, nhưng nó không phải là sự kết hợp của lập

trình hướng thủ tục và lập trình hướng đối tượng. AOP có thể xem là một sự bổ sung

cho OOP, OOP là cách thức mô-đun hoá các mối quan tâm nói chung và AOP là cách

mô-đun hoá các mối quan tâm đặc biệt chạy xuyên suốt và cắt ngang các đơn vị

môđun hoá tự nhiên (là các class trong OOP truyền thống). AOP cho phép chúng ta

giải quyết các bài toán phức tạp tốt hơn và hiệu quả hơn. AOP tổng hợp hệ thống đi từ

các vấn đề đan nhau đến vấn đề chính, còn OOP đi theo hướng ngược lại. Tuy nhiên,

OOP và AOP không phủ định nhau mà bổ sung cho nhau.

1.2 Đặc điểm của AOP

1.2.1 Aspect là gì?

Concern (mối quan tâm) có thể là bất kì một đoạn code nào mà có liên quan đến

mục tiêu, đặc điểm, khái niệm hoặc một loại chức năng của ứng dụng. Aspect là một

concern mà các chức năng của nó sẽ được kích hoạt bởi những concern khác, và trong

nhiều tình huống khác nhau.

Nếu một concern không được tách riêng biệt trong một aspect, chức năng của nó

sẽ phải được kích hoạt một cách tường minh trong các đoạn code có liên quan tới

những concern khác và do đó sẽ dẫn tới sự rối, lẫn lộn trong hai concern có liên quan

tới nhau, và giải rác code trong nhiều nơi của hệ thống.

Ví dụ, nếu một hệ thống phần mềm cần ghi log tới các method được gọi thực thi

(như constructor để tìm vết khi tạo ra đối tượng). Ở đây, việc thêm một method log()

là cần thiết và method này cần phải được gọi trong một vị trí cụ thể trong code . Chắc

chắn rằng không một ai sẽ lãng phí, lạm dụng sự liên kết thừa kế của những lớp hoàn

toàn khác nhau (thực hiện các tác vụ khác nhau, không có cùng điểm tương đồng trong

cấu trúc kế thừa) mà chỉ để giới thiệu method log() trong các lớp hệ thống. AOP có thể

giúp bạn bằng cách tạo ra một aspect mà cung cấp một method log() tới các lớp mà

cần nó ghi lại, và bằng cách gọi method này bất kì đâu mà nó được yêu cầu. Một ví dụ

khác mà aspect sẽ được sử dụng là trường hợp xử lí ngoại lệ, aspect có thể định nghĩa

3

ra các mệnh đề catch() cho các method của lớp, hơn nữa cho phép xử lý ngoại lệ một

cách nhất quán xuyên suốt cả ứng dụng.

1.2.2 Nguyên tắc:

Aspect-Oriented Programming còn được gọi là Aspect-Oriented Software

Development (AOSD, phát triển phần mềm hướng khía cạnh) là một nguyên tắc thiết

kế giúp tách rời các yêu cầu hay các vấn đề được quan tâm (gọi là separation of

concerns) trong chương trình thành các thành phần độc lập và từ đó tăng tính uyển

chuyển cho chương trình. “Separation of concerns” là một trong những kĩ thuật được

quan tâm nhất trong ngành kỹ nghệ phần mềm. Người ta cho rằng những vấn đề tương

tự nhau nên được giải quyết trong một “đơn vị code”. Khi lập trình thủ tục, một “unit

of code” là một function, một method. Còn trong lập trình hướng đối tượng thì “unit

of code” là một class.

1.2.3 Những lợi ích “separate of concerns”

Trong AOP, “aspect” chính là vấn đề người lập trình quan tâm và nó xuất hiện

trong rất nhiều class cũng như nhiều method khác nhau. Kĩ thuật AOP thường được sử

dụng để giải quyết các vấn đề như bộ nhớ đệm, lưu vết, và bảo mật. Vì thế, nhiều tài

liệu nói rằng AOP giúp mô-đun hóa ứng dụng, biến chương trình thành các mô-đun

hoạt động độc lập, mỗi mô-đun làm một chức năng riêng, từ đó dễ bảo trì và nâng cấp.

AOP xác định các vấn đề một cách tách biệt, nó hạn chế tối thiểu việc nhập nhằng mã,

cho phép mô-đun hoá các vấn đề liên quan đến nhiều lớp đối tượng.

Ở vai trò của người thiết kế phần mềm, chúng ta nên đưa ra các cách làm đơn

giản nhất. Để thỏa mãn yêu cầu của chương trình, người ta sẽ tạo ra thành phần chính

của chương trình (gồm các class/component/method); các chức năng bổ sung như ghi

(log), tính toán hiệu năng chương trình cũng sẽ được xem xét để tạo ra. Vì do các chức

năng bổ sung này không phải là yêu cầu chính của hệ thống nên người ta sẽ có yêu cầu

bật tắt chúng theo ý muốn. Vậy làm thế nào để có thể tạo ra chương trình có thể linh

hoạt được như thế? Câu trả lời là “Separate of concerns”.

Ở vai trò của người lập trình, chúng ta có hai vấn đề cần quan tâm là xử lý logic

chính của chương trình và các xử lý logic cho những thành phần phụ. Do đó tất nhiên

sẽ phải tạo ra các class/method cho các yêu cầu thực sự, và tạo ra những class/method

khác độc lập để thực hiện các yêu cầu phụ. Tất cả các class/method này có thể được

kết hợp lúc runtime theo ý muốn. Chẳng hạn như trong môi trường test, người ta có

thể bật chức năng log, đo đạc hiệu năng làm việc của chương trình để theo dõi. Nhưng

khi chạy ứng dụng, các chức năng phụ này có thể được tắt đi. Và trên nguyên tắc,

4

trong code của những xử lý logic chính sẽ không chứa code để thực hiện các yêu cầu

phụ.

Dễ dàng phát triển hệ thống: Việc thêm chức năng mới có thể thực hiện dễ dàng

bằng cách tạo aspect mới mà không cần quan tâm đến vấn đề đan nhau. Khi thêm các

mô-đun mới vào hệ thống, các aspect hiện có sẽ đan kết với chúng và tạo nên sự phát

triển chặt chẽ.

Cho phép để lại quyết định thiết kế tương lai: Một thiết kế tốt phải tính đến cả

yêu cầu hiện tại và tương lai, việc xác định yêu cầu tương lai là một công việc khó

khăn. Nếu bỏ sót những yêu cầu tương lai có thể bạn sẽ phải thay đổi hay thực hiện lại

nhiều phần hệ thống. Với AOP, người thiết kế hệ thống có thể để lại các quyết định

thiết kế cho những yêu cầu tương lai nhờ thực hiện theo các aspect riêng biệt.

Tái sử dụng mã tốt hơn: Các aspect là những mô-đun riêng biệt, được kết hợp

linh động – đây chính là yếu tố quan trọng để tái sử dụng mã. AOP cho phép tái sử

dụng mã tốt hơn OOP.

1.2.4 Tiếp cận aspect

Trong khi phát triển ngôn ngữ hướng aspect, aspect có nhiều hình dạng khác

nhau. Có hai cách để tiếp cận với aspect là: asymmetric and the symmetric (bất đồng

bộ và đồng bộ) :

Phân tách bất đồng bộ

Trong quan điểm tiếp cận này, các aspect được phân tách từ các chức năng chính

của một chương trình. Các aspect được mã hóa như là các sự kiện mà bị kích hoạt

trước, sau, hoặc thay thế cho những sự kiện cụ thể đã biết trước. Chúng mô tả thêm

các hành vi động của hệ thống mà sẽ có ảnh hưởng trên các chức năng chính. Ví dụ

như , trong hệ thống phân tán có một tập các đối tượng đặc tả miền hệ thống mà cần

phải được quản lý về việc phân phối, đồng bộ hóa, và giao dịch.

Chức năng chính sẽ chứa đựng cấu trúc và hành vi phù hợp tới các chức năng

miền của hệ thống. Việc phân tách các aspect khỏi chức năng chính của hệ thống

giống như là việc phân phối các đối tượng trong hệ thống, sự sắp xếp hệ thống đồng

bộ hóa được giao kết với các method thuộc các đối tượng đó, và bao bọc tập hợp các

thao tác vào trong một giao dịch đơn. Tất cả những việc này sẽ được mô tả trong một

mô-đun chuyên biệt (mỗi mô-đun sẽ là một aspect), và được gọi tại một điểm cụ thể

trong khi thực thi các phần chính của một chương trình.

5

Trong mức độ khái niệm, các aspect sẽ có hai thuộc tính quan trọng trong sự phối

hợp này. Đầu tiên, các aspect sẽ chỉ được kích hoạt bởi các điểm thực thi trong các

chức năng chính. Thứ hai, các aspect sẽ bị kích hoạt trong rất nhiều phần của hệ

thống, nhìn chung thì việc phân tách design/code trong một aspect sẽ không hữu dụng

nếu aspect này chỉ được thực thi tại một nơi trong hệ thống.

Bảng 1-1. Định nghĩa về các thuật ngữ trong mẫu phân tách theo hướng asymmetric

Thuật ngữ

Mô tả

Crosscutting

Các concern mà hành vi của nó bị kích hoạt trong nhiều tình huống khác

nhau.

Advice

Aspect

Core

Là các hành vi bị kích hoạt

Sự bao bọc advice và đặc tả cái nơi mà advide bị kích hoạt

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

Pointcut

Weaving

Điểm thực thi mà kích hoạt advide

Là việc bạn chọn những jointpoint nào để thực thi

Việc ứng dụng các advice tới các core của hệ thống tại tại một jointpoint

mà được so khớp tại các câu lệnh pointcut trong các aspect

Phân tách đồng bộ

Trong mẫu phân tách symmetric, để thêm vào việc mô-đun hóa các aspect, các

chức năng chính của hệ thống phải được phân tích cho việc mô-đun sâu hơn. Các đặc

điểm khác nhau của hệ thống sẽ được mô-đun hóa trong các chương trình riêng biệt.

Toàn bộ hệ thống được cấu thành từ những chức năng riêng rẽ, là các concern

hay đặc điểm. Chúng có thể được kết hợp trong các cách khác nhau để hình thành đầy

đủ chức năng. Với cách tiếp cận này, một tập hợp các đối tượng được phân phối sẽ

hình thành bằng cách tổng hợp các mẫu chức năng của các đối tượng cơ bản với các

chức năng phân phối, chức năng đồng bộ hóa và các chức năng giao dịch.

Thoáng nhìn qua, sự trùng lặp trình bày trong cách tiếp cận symmetric như thể nó

làm cho việc giải rác code trở nên tồi tệ và rắc rối hơn. Sự trùng lặp được yêu cầu

trong cách tiếp cận hướng symmetric để cung cấp một cách nhìn toàn vẹn về hệ thống

từ góc nhìn của concern cụ thể. Cách nhìn trọn vẹn sẽ giúp hiểu một cách riêng biệt

6

về các concern cụ thể trong hệ thống. Tất cả các chức năng phù hợp cho một concern

được trình bày trong một mô-đun concern. Khả năng bảo trì concern được cũng được

nâng cao hơn bởi vì xác định rõ vị trí cũng như chức năng của nó trong hệ thống. Khi

sửa đổi mỗi method thuộc về một class sẽ yêu cầu bạn quan tâm đến concern liên

quan, vì mức độ yêu cầu duy trì của hệ thống ảnh hưởng thường xuyên đến quá trình

tiến hóa của hệ thống phần mềm nên xác định được nhóm các mô-đun mà giúp cho

việc quản lý tốt việc bảo trì hệ thống là rất cần thiết.

Cách tiếp cận symmetric có thể được ứng dụng một cách liên tục trong quá trình

phát triển hệ thống. Không cần thiết giữ các mối quan tâm nhỏ nhặt trong các concern

riêng biệt cũng như không cần thiết bó tất cả các mối quan tâm nguồn lại với nhau.

Các thuật ngữ khi sử dụng với phương pháp này sẽ khác với cách dùng của

phương pháp bất đồng bộ:

-Concern: Vài loại chức năng trong hệ thống. Nó có thể là một đặc điểm (hàm)

hoặc một loại tiến trình xử lí.

-Crosscutting: là một concern bị kích hoạt trong nhiều tình huống hoặc những

cấu trúc và hành vi của concern nào bị giải rác xuyên suốt cac code base và bị rối với

mối liên quan code tới các concern khác.

-Composition: Tổng hợp cài đặt riêng biệt của các concern để hình thành nên một

chức năng của hệ thống.

1.3 Giới thiệu sơ qua về Theme

Approach Theme (tiếp cận chủ đề) là cách để bạn sử dụng AOP trong quá trình

phân tích và thiết kế một dự án phần mềm.

Chúng ta dùng theme chủ yếu là để xác định các aspect trong hệ thống, sử dụng

các mẫu phân tách Asymmetric hoặc Symmetric.

1.3.1 Định nghĩa về Theme

“Theme” sẽ không được coi như là tương đồng với từ aspect. Theme được định

nghĩa tổng quan hơn các aspect và có sự chặt chẽ hơn khi bao bọc các concern như đã

được mô tả cho cách tiếp cận symmetric. Hãy xem với mỗi một chức năng hay một

concern hay một aspect lập trình viên phải coi như là một theme riêng biệt để phục vụ

cho hệ thống . Theo như các thuật ngữ trong cách tiếp cận symmetric thì concern được

định nghĩa là : “vài loại chức năng của hệ thống , các chức năng này có thể là một đặc

điểm hay một kiểu xử lý”. Như vậy theme sẽ được mô tả như “là một sự bao bọc các

concern”.

7

Trong mức độ requirement, một theme là một tập các trách nhiệm được mô tả

trong một tập các requirement. Trong mức độ thiết kế, các theme bao gồm cấu trúc và

hành vi cần phải thực hiện các trách nhiệm trong mức độ các requirement.

1.3.2 Mối quan hệ giữa các theme :

Có hai cách mà xác định những theme nào có mối quan hệ với nhau.

a) Concept sharing (chia sẻ cùng khái niệm):

Khi bạn đọc một requirement bạn sẽ xác định được các chức năng (chính là các

động từ trong requirement) và các thực thể (entity- chính là các danh từ) mà có thể sẽ

là một class sau này trong hệ thống. Nếu hai theme cùng tham chiếu tới một

requirement tức là chúng có chung một entity.

Tuy nhiên, mối quan hệ này là một loại crosscutting trong mẫu thiết kế tách biệt

đồng bộ (symmetric separation), mà không được thảo luận hay đề cập trong mẫu thiết

kế bất đồng bộ (asymmetric). Sự bao bọc theo kiểu này có lợi ích, chỉ có các chức

năng thích hợp cho một concern sẽ được trình bày trong một theme.

b) Crosscutting :

Mối quan hệ thứ hai được đề cập ở đây là cắt ngang mà sẽ có ý nghĩa tương đồng

như thuật ngữ crosscutting trong mẫu thiết kế bất đồng bộ.Tức là các hành vi trong

một theme bị kích hoạt bởi các hành vi trong những theme khác.

Chúng ta sẽ sử dụng các thuật ngữ theme base, theme crosscutting, theme aspect

để nói về mối quan hệ này. Theme aspect và theme crosscutting sẽ được coi là một vì

chúng cùng có chung một định nghĩa (trong mẫu thiết kế bất đồng bộ) là các hành vi

mà bị kích hoạt bởi các hành vi khác.

Theme base là những theme mà kích hoạt các theme aspect. Các theme base này

phải là các theme mà có mối quan hệ chia sẻ khái niệm với những theme khác, trong

mối quan hệ chia sẻ khái niệm này sẽ phải lựa chọn ra đâu là theme aspect và đâu là

theme base. Đôi khi chúng ta nói một theme base là kết quả của sự tổng hợp các các

theme khác nhau thành, và nó kích hoạt một aspect.

8

Hình 1-1 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

9

+ Xác định trách nhiệm của mỗi theme mà từ đó xác định ra được theme aspect.

Trong quá trình tiến hóa của hệ thống, kiểm định thực tế qua sử dụng, chúng ta

có thể dùng hai hoạt động chính ở trên để lên kế hoạch thiết kế các thay đổi của hệ

thống.

1.3.3.2 Thiết kế các theme với Theme/UML

Theme/UML cho phép thiết kế riêng các mô-đun cho mỗi theme xác định trong

requirement. Nó là một trong những cơ sở quan trọng của AOSD để: mô-đun hóa

theme, chỉ ra mối quan hệ giữa các theme liên quan, và tổng hợp các theme thành một

hệ thống mạch lạc.

Các theme được xác định với theme/doc có thể được thiết kế riêng biệt dù có sự

cắt ngang giữa các theme hay không, hoặc có sự trùng lặp giữa các theme hay không.

Chúng ta sẽ gần như hoàn toàn sử dụng chuẩn UML để thiết kế cho mỗi theme, sẽ có

một vài mở rộng của chuẩn UML để thiết kế cho theme aspect. Tất cả các class,

methods phù hợp cho mỗi concern phải được thiết kế trong theme.

1.3.3.3 Quá trình xử lý theme

Có ba hoạt động chính khi áp dụng cách tiếp cận theme: analysis (phân tích),

design (thiết kế), composition (tổng hợp).

-Analysis: Đây là bước đầu tiên trong cách tiếp cận, cần phải phân tích các

requirement để xác định được các theme. Bước này bao gồm mapping (ánh xạ) các

requiemernt tới các concern của hệ thống. Theme/Doc chỉ ra mối quan hệ giữa các

hành vi, chính là mối quan hệ giữa các theme. Mối quan hệ đó sẽ giúp tìm ra các

concern là rối lẫn với các concern khác để xác định các theme aspect.

-Design: Thiết kế các Theme sử dụng Theme/UML. Sử dụng các theme đã tìm

thấy trong Theme/Doc để xác định các class và method tiềm năng.

-Composition: chỉ ra cách mà mô hình Theme/UML sẽ được kết hợp. Trong

nhiều trường hợp một vài khung nhìn của Theme/Doc giúp bạn xác định được cách

thức các theme có liên quan tới nhau, xem chúng có lạp chồng hay cắt ngang những

theme khác. Các theme mà chứa các khái niệm chung thì sẽ được chọn để tổng hợp

theme. Hoặc các theme không có các khái niệm chung, nhưng thuộc một miền trong hệ

thống cũng được tổng hợp.

Chúng ta sẽ xem xét chi tiết các hoạt động trong việc thiết kế cho hệ thống

AOP trong các phần tiếp theo.

10

Chương 2 Phân tích

Trong chương này sẽ mô tả cách tiếp cận Theme với sự phân tích các

requirements. Các requirements miêu tả các hành vi liên quan đến các concern. Một

concern có thể được miêu tả trong các phần của các requirements khác nhau, việc

nhóm các phần đó lại là đóng gói một theme ở mức requirements. Các requirements

có thể miêu tả nhiều hơn một concern, chúng có thể được nhóm thành nhiều nhóm

requirements. Để có theme- orthogonality (trực giao) ta cần phải chú ý: các theme

không nên lạp chồng trong các nhóm yêu cầu của chúng, ta có thể viết lại các

requirement chia sẻ để tránh lạp chồng các hành vi trong theme , hoặc xử lý sự lạp

chồng đó trong thiết kế .

2.1 Các khung nhìn Theme/Doc

Sử dụng Theme/Doc giúp chúng ta thấy các mối quan hệ giữa các chức năng bị

làm rối lẫn một cách trực quan hơn và đưa ra quyết định cách đóng gói trong hệ thống.

Có ba loại khung nhìn Theme/Doc: khung nhìn relationship (khung nhìn quan hệ),

khung nhìn crosscutting (khung nhìn cắt ngang), và khung nhìn individual (khung nhìn

cá nhân).

2.1.1 Khung nhìn relationship của theme

Khung nhìn relationship của theme (có thể gọi ngắn gọn là khung nhìn

relationship) chỉ ra các relationships giữa các theme.

Hình 2-1 ví dụ trừu tượng của một 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

11

hiển thị trong khung nhìn với các hình chữ nhật bo góc. Các requirements có thể được

đánh nhãn với phần toàn bộ nội dung text của nó hay đơn giản là đánh số requirement,

như là R1, R2…

Khung nhìn relationship không chỉ ra “trực tiếp” mối quan hệ của các theme, nó

sẽ chỉ ra cách các theme liên quan tới các requirement. Nếu đoạn text của requirement

chứa một tham chiếu tới tên một theme, một liên kết được vẽ mô tả kết nối

requirement đó tới theme đó. Nếu một requirement đề cập nhiều hơn một theme, giống

như requirement 1 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

12

requirement. Tuy nhiên, đây không phải là một nguyên tắc cứng nhắc. Nhưng trong

giai đoạn đầu của phân tích chúng ta cố gắng đưa ra các theme chịu trách nhiệm cơ

bản cho chức năng hệ thống, việc xác định được rõ ràng theme nào sẽ chịu trách nhiệm

cho hành vi của requirement ngay từ đầu sẽ giúp các công việc thiết kế về sau thuận

lợi hơn, nên sử dụng mối quan hệ từ requirement tới theme - N:1.

Với requirement chia sẻ thì nó tham chiếu tới nhiều hơn một theme, vậy theme

nào sẽ chịu trách nhiệm cho requirement đó ? Có hai lựa chọn để giao kết một share

requirement.

a)

Đầu tiên là giao kết nó với một theme mà bạn tin là “aspect” trong tình

huống cụ thể đã được xác định trước. Trong khung nhìn crosscutting vẽ sự giao kết

mới, là mũi tên màu xám dày mở rộng từ theme aspect (theme mà chịu trách nhiệm

nắm giữ hành vi chia sẻ chung - tức là chi phối requirement chia sẻ đó) tới các theme

base (requirement chia sẻ chung bây giờ không giao kết với các theme base nữa).

Nếu một requirement được giao kết với một theme aspect thì nó chỉ được liên kết với

theme đó. Các theme khác được tham chiếu trong requirement được liên kết với theme

aspect với mũi tên xám đậm chỉ ra rằng chúng bị cắt ngang bởi theme aspect. Như vậy

trong khung nhìn crosscutting mỗi requirement chỉ giao kết với một theme. Trong

hình 2-2, miêu tả mối quan hệ crosscutting từ First Theme (được xác định là theme

aspect) tới Second Theme (theme base được requirement chia sẻ tham chiếu),

requirement chia sẻ bây giờ chỉ giao kết với duy nhất First theme.

b)

Lựa chọn thứ hai là postpone (trì hoãn) quyết định về những theme

chia sẻ chung requirement sẽ được giao kết như thế nào, ta chưa quyết định theme nào

sẽ chịu trách nhiệm cho requirement chia sẻ. Việc postpone được mô tả trong khung

nhìn crosscutting với đường nét đứt, được gán nhãn bằng nhãn (hoặc text) requirement

của giao kết bị trì hoãn. Trong ví dụ hình 2-2, requirement 3 được chia sẻ bởi First

theme và Third Theme, ta chưa xác định được theme nào chịu trách nhiệm cho hành vi

của requirement 3 nên trì hoãn việc giao kết theme của nó lại, và nó được liên kết với

First Theme, Third Theme bằng đường nét đứt, và gán nhãn là text của requirement 3.

Hai khung nhìn relationship và crosscutting thực sự là hai cực của một thể liên

tục. Khung nhìn relationship bao hàm tất cả các mối quan hệ giữa các theme và các

requirements, nhưng nó không bao hàm mối quan hệ relationship crosscutting.

Khung nhìn crosscutting bao gồm các mối quan hệ giao kết giữa các theme và các

requirement, và mô tả các quan hệ giao kết giữa các theme – quan hệ cắt ngang.

Khung nhìn crosscutting sẽ không chứa requirement chia sẻ, các requirement chia sẻ

lúc này đã được giao kết gắn với duy nhất một theme aspect chịu trách nhiệm cho

13

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:

14

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.

15

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 ở

16

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.1Chọ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á

17

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.

18

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.

19

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

20

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

21

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.

22

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.

23