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

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

Trần Lệ Huyền


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




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

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





HÀ NỘI - 2010







2

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

Trần Lệ Huyền


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




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

Ngành: Công Nghệ Thông Tin
Cán bộ hướng dẫn: TS. Đặng Văn Hưng




HÀ NỘI - 2010

3


Lời cảm ơn
Lời đầu tiên, em xin được bày tỏ lòng biết ơn sâu sắc tới thầy Đặng Văn Hưng-
Người đã trực tiếp hướng dẫn, tận tình giúp đỡ em trong thời gian thực hiện khóa luận.
Em xin được bày tỏ lòng biết ơn tới các thầy, cô trong khoa Công Nghệ Thông
Tin, trường Đại Học Công Nghệ, ĐHQGHN. Các thầy cô đã nhiệt tình dạy bảo và tạo
mọi điều kiện học tập tốt nhất cho chúng em trong những năm học tập tại ĐHCN
Tôi xin cảm ơn các bạn sinh viên lớp K51CC và K51CNPM Trường Đại học
Công nghệ, những người bạn đã cùng tôi học tập và rèn luyện trong suốt những năm
học đại học.
Hà Nội, ngày 19 tháng 5 năm 2010
Trần Lệ Huyền


4


Tóm tắt

Lập trình hướng khía cạnh (Aspect Oriented Programming - AOP) là một kiểu
lập trình mới nhanh chóng thu hút được các nhà phát triển trong giới công nghệ thông
tin. AOP là một mô hình lập trình tách biệt các chức năng phụ với logic nghiệp vụ của
chương trình chính. Các chức năng phụ rải rác nằm xuyên suốt trong hệ thống được
tách thành các đơn vị duy nhất, gọi là aspect( khía cạnh). Một aspect là một đơn vị mô-
đun cho sự thi hành cắt ngang chương trình. Nó đóng gói các hành vi mà ảnh hưởng
đến nhiều lớp vào các mô-đun có khả năng sử dụng lại. Đây là một phương pháp lập
trình phát triển dựa trên lập trình hướng đối tượng.

Bài luận tìm hiểu về cách xây dựng hệ thống với phương pháp AOP. Và ứng dụng
AOP vào xây dựng thiết kế một hệ thống điện thoại với các chức năng cơ bản.


5


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

Từ viết tắt

Giải nghĩa
1 AOP Aspect Oriented Programming
2 OOP Object Oriented Programming


6

Mục lục

Chương 1 Tiếp cận AOP 2
1.1 Giới thiệu: 2
1.2 Đặc điểm của AOP 3
1.2.1 Aspect là gì? 3
1.2.2 Nguyên tắc: 4
1.2.3 Những lợi ích “separate of concerns” 4
1.2.4 Tiếp cận aspect 5
1.3 Giới thiệu sơ qua về Theme 7
1.3.1 Định nghĩa về Theme 7

1.3.2 Mối quan hệ giữa các theme : 8
1.3.3 Áp dụng cách tiếp cận theme: 9
Chương 2 Phân tích 11
2.1 Các khung nhìn Theme/Doc 11
2.1.1 Khung nhìn relationship của theme 11
2.1.2 Khung nhìn crosscutting của Theme 12
2.1.3 Khung nhìn individual 14
2.2 Quá trình xử lý Theme/Doc 14
2.3 Quyết định trên theme 16
2.3.1 Chọn các theme ban đầu 16
2.3.2 Các hoạt động trên theme 19
2.3.3 Hoạt động trên Requirements 21
2.4 Quyết định Theme trách nhiệm 22
2.4.1 Xác định Theme aspect 23
2.4.2 Trì hoãn một số quyết định 25
2.5 Kế hoạch cho thiết kế 25
2.5.1 Xác định các đối tượng 25
2.5.2 Khung nhìn theme base 26
2.5.3 Khung nhìn theme aspect 26
Chương 3 Thiết kế theme 28
3.1 Thiết kế theme base 28
3.2 Thiết kế Theme crosscutting 29
3.2.1 Tổng quan về thiết kế Theme crosscutting 29
3.2.2 Thay đổi với UML 32
Chương 4 Tổng hợp theme 36
4.1 Pick Theme 36
4.2 Xác định các phần tử thiết kế so khớp 37


7

4.2.1 So khớp tường minh 38
4.2.2 So khớp ngầm định 38
4.2.3 Các nguyên tắc cho so khớp khái niệm chung với relationship tổng hợp 38
4.3 Kiểu tích hợp- Integration 39
4.3.1 Tích hợp merge 39
4.3.2 Tích hợp override 42
4.3.3 Kết hợp các phương pháp tích hợp 43
4.4 Giải quyết xung đột 43
4.4.1 Explicit values 44
4.4.2 Giá trị mặc định 44
4.4.3 Theme Precedence 45
4.5 Chỉ ra binding cho Theme aspect 46
Chương 5 Xây dựng hệ thống điện thoại với phương pháp Theme 52
5.1 Tóm tắt về dự án: 52
5.2 Phân tích yêu cầu dự án 52
5.2.1 Xác định các theme ban đầu 54
5.2.2 Làm mịn tập theme 55
5.3 Thiết kế các theme 60
5.3.1 Phân tích UseCase 60
5.3.2 Thiết kế theme 61
5.4 Tổng hợp theme 79

1

Mở đầu
Lập trình hướng đối tượng (Object Oriented Programming - OOP) là mô hình
phát triển được lựa chọn cho hầu hết các dự án phần mềm. OOP rất hữu hiệu trong
việc lập mô hình hành vi chung của các đối tượng, tuy nhiên nó không giải quyết thỏa
đáng những hành vi liên quan đến nhiều đối tượng. AOP giải quyết được vấn đề này,
và rất có thể sẽ là bước phát triển lớn kế tiếp trong phương pháp lập trình.
Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một
cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung cho kỹ
thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đun khác, cho phép kéo
thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘aspect’ (khía
cạnh), từ chữ ‘aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới:
aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ
kiểm soát hơn. Các aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch
và có thể tái sử dụng.
Aspect-orientation là một hướng tiếp cận mạnh mẽ cho lập trình hệ thống phức
tạp. Áp dụng phương pháp aspect vào mô hình và thiết kế hệ thống có nhiều ưu điểm
so với OOP. Cách tiếp cận Theme (chủ đề) là một ưu điểm quan trọng trong AOP,
cung cấp phương tiện để ứng dụng aspect-orientation.
Bài luận của em tìm hiểu về AOP dựa trên tài liệu “Aspect-Oriented Analysis
and Design: The Theme Approach “ của tác giả Siobhán Clarke và Elisa Baniassad.
Bài luận trình bày về phân tích xây dựng một hệ thống bằng phương pháp AOP.
Bài luận gồm năm chương:
Chương 1: Giới thiệu và trình bày các đặc điểm về AOP.
Chương 2: Phân tích yêu cầu hệ thống để tìm ra tập theme .

Chương 3: Thiết kế riêng biệt các theme sử dụng UML, với một số mở rộng của
UML chuẩn.
Chương 4: Tổng hợp các thiết kế theme riêng biệt thành một hệ thống hoàn chỉnh
mạch lạc.
Chương 5: Ứng dụng AOP với phương pháp theme vào xây dụng các đặc điểm
cơ bản cho hệ thống điện thoại.




2

Chương 1 Tiếp cận AOP
1.1 Giới thiệu:
Vào những ngày đầu của ngành khoa học máy tính, các thảo chương viên lập
trình trực tiếp bằng mã máy. Những nhà phát triển phần mềm thời đó đã phải tốn nhiều
thời gian suy nghĩ về tập lệnh riêng của từng phần cứng máy tính cụ thể hơn là tập
trung để giải quyết các yêu cầu của bài toán đặt ra. Dần dần, người ta chuyển sang các
ngôn ngữ lập trình cấp cao hơn, cho phép khái quát hoá ở mức độ nào đó mã máy chạy
bên dưới.
Rồi kế đến là các ngôn ngữ lập trình có cấu trúc cho phép phân tích bài toán
thành các thủ tục thực hiện những tác vụ cần thiết. Phương pháp lập trình này thực
hiện theo cách tiếp cận hướng chức năng chủ yếu dựa vào phân rã các chức năng chính
của bài toán thành các chức năng đơn giản hơn và thực hiện làm mịn dần từ trên xuống
để tạo ra cấu trúc phân cấp. Chương trình theo hướng tiếp cận này thực chất là một tập
các chương trình con (các hàm) mà máy tính cần thực hiện để hoàn thành nhiệm vụ
của hệ thống. Trong đó dữ liệu và các hàm là tách rời nhau, các hàm muốn liên kết
trao đổi với nhau thì phải thông các biến chung (global). Nếu phải sửa đổi dữ liệu thì
sẽ phải sửa đổi mọi nơi mà sử dụng dữ liệu đó, và như vậy sẽ ảnh hưởng tới tất cả mọi
người tham gia lập trình.

Khi độ phức tạp của các bài toán tăng lên, chúng ta cần có những kỹ thuật tốt
hơn là lập trình hướng thủ tục.
Lập trình hướng đối tượng OOP đã trở thành sự lựa chọn chính khi phát triển và
xây dựng hệ thống phần mềm trong nhiều năm qua, mà thay thế hoàn toàn cho cách
tiếp cận hướng thủ tục. Một trong những ưu điểm lớn nhất của hướng đối tượng là hệ
thống phần mềm có thể được xem như là việc xây dựng một tuyển tập các lớp riêng
biệt. Mỗi một class (lớp) trong tuyển tập các lớp đó chịu trách nhiệm cho một tác vụ
nào đó trong hệ thống. Trong ứng dụng hướng đối tượng, các lớp này sẽ hợp tác lại với
nhau để hoàn thành mục tiêu chung của ứng dụng.
Kỹ thuật OOP thực hiện tốt việc đóng gói các hành vi và chủ thể , miễn là chúng
hoàn toàn riêng biệt. Tuy nhiên, các bài toán thực tế thường có những hành vi đan
nhau liên quan đến nhiều lớp, không thể được xem như là trách nhiệm riêng của một
lớp. Ví dụ như là việc tiến hành locking (khóa) trong các ứng dụng phân tán, xử lí
ngoại lệ, hoặc việc ghi log…Tất nhiên code để mà xử lý các phần này có thể được
thêm vào mỗi lớp một cách riêng biệt, nhưng điều này sẽ dẫn tới sự vi phạm trách
nhiệm chính của mỗi lớp mà ta đã định nghĩa. Theo truyền thống, hầu hết ngôn ngữ


3

lập trình hướng đối tượng như C++ và Java đều không hỗ trợ đóng gói những hành vi
đan nhau, dẫn đến mã chương trình có thể nằm lẫn lộn, rải rác và khó quản lý.
AOP là kỹ thuật lập trình mới cho phép đóng gói những hành vi có liên quan đến
nhiều lớp. Nó tập trung vào các khái niệm cắt ngang hoặc các khía cạnh - phần mã sử
dụng chung cho các đối tượng khác nhau. Nhờ mã được tách riêng, vấn đề đan nhau
trở nên dễ kiểm soát hơn. AOP tách riêng các đặc điểm mà rải rác, đan xen trong hệ
thống thành một mô-đun riêng để xử lý, nhưng nó không phải là sự kết hợp của lập
trình hướng thủ tục và lập trình hướng đối tượng. AOP có thể xem là một sự bổ sung
cho OOP, OOP là cách thức mô-đun hoá các mối quan tâm nói chung và AOP là cách
mô-đun hoá các mối quan tâm đặc biệt chạy xuyên suốt và cắt ngang các đơn vị

môđun hoá tự nhiên (là các class trong OOP truyền thống). AOP cho phép chúng ta
giải quyết các bài toán phức tạp tốt hơn và hiệu quả hơn. AOP tổng hợp hệ thống đi từ
các vấn đề đan nhau đến vấn đề chính, còn OOP đi theo hướng ngược lại. Tuy nhiên,
OOP và AOP không phủ định nhau mà bổ sung cho nhau.
1.2 Đặc điểm của AOP
1.2.1 Aspect là gì?
Concern (mối quan tâm) có thể là bất kì một đoạn code nào mà có liên quan đến
mục tiêu, đặc điểm, khái niệm hoặc một loại chức năng của ứng dụng. Aspect là một
concern mà các chức năng của nó sẽ được kích hoạt bởi những concern khác, và trong
nhiều tình huống khác nhau.
Nếu một concern không được tách riêng biệt trong một aspect, chức năng của nó
sẽ phải được kích hoạt một cách tường minh trong các đoạn code có liên quan tới
những concern khác và do đó sẽ dẫn tới sự rối, lẫn lộn trong hai concern có liên quan
tới nhau, và giải rác code trong nhiều nơi của hệ thống.
Ví dụ, nếu một hệ thống phần mềm cần ghi log tới các method được gọi thực thi
(như constructor để tìm vết khi tạo ra đối tượng). Ở đây, việc thêm một method log()
là cần thiết và method này cần phải được gọi trong một vị trí cụ thể trong code . Chắc
chắn rằng không một ai sẽ lãng phí, lạm dụng sự liên kết thừa kế của những lớp hoàn
toàn khác nhau (thực hiện các tác vụ khác nhau, không có cùng điểm tương đồng trong
cấu trúc kế thừa) mà chỉ để giới thiệu method log() trong các lớp hệ thống. AOP có thể
giúp bạn bằng cách tạo ra một aspect mà cung cấp một method log() tới các lớp mà
cần nó ghi lại, và bằng cách gọi method này bất kì đâu mà nó được yêu cầu. Một ví dụ
khác mà aspect sẽ được sử dụng là trường hợp xử lí ngoại lệ, aspect có thể định nghĩa


4

ra các mệnh đề catch() cho các method của lớp, hơn nữa cho phép xử lý ngoại lệ một
cách nhất quán xuyên suốt cả ứng dụng.
1.2.2 Nguyên tắc:

Aspect-Oriented Programming còn được gọi là Aspect-Oriented Software
Development (AOSD, phát triển phần mềm hướng khía cạnh) là một nguyên tắc thiết
kế giúp tách rời các yêu cầu hay các vấn đề được quan tâm (gọi là separation of
concerns) trong chương trình thành các thành phần độc lập và từ đó tăng tính uyển
chuyển cho chương trình. “Separation of concerns” là một trong những kĩ thuật được
quan tâm nhất trong ngành kỹ nghệ phần mềm. Người ta cho rằng những vấn đề tương
tự nhau nên được giải quyết trong một “đơn vị code”. Khi lập trình thủ tục, một “unit
of code” là một function, một method. Còn trong lập trình hướng đối tượng thì “unit
of code” là một class.
1.2.3 Những lợi ích “separate of concerns”
Trong AOP, “aspect” chính là vấn đề người lập trình quan tâm và nó xuất hiện
trong rất nhiều class cũng như nhiều method khác nhau. Kĩ thuật AOP thường được sử
dụng để giải quyết các vấn đề như bộ nhớ đệm, lưu vết, và bảo mật. Vì thế, nhiều tài
liệu nói rằng AOP giúp mô-đun hóa ứng dụng, biến chương trình thành các mô-đun
hoạt động độc lập, mỗi mô-đun làm một chức năng riêng, từ đó dễ bảo trì và nâng cấp.
AOP xác định các vấn đề một cách tách biệt, nó hạn chế tối thiểu việc nhập nhằng mã,
cho phép mô-đun hoá các vấn đề liên quan đến nhiều lớp đối tượng.
Ở vai trò của người thiết kế phần mềm, chúng ta nên đưa ra các cách làm đơn
giản nhất. Để thỏa mãn yêu cầu của chương trình, người ta sẽ tạo ra thành phần chính
của chương trình (gồm các class/component/method); các chức năng bổ sung như ghi
(log), tính toán hiệu năng chương trình cũng sẽ được xem xét để tạo ra. Vì do các chức
năng bổ sung này không phải là yêu cầu chính của hệ thống nên người ta sẽ có yêu cầu
bật tắt chúng theo ý muốn. Vậy làm thế nào để có thể tạo ra chương trình có thể linh
hoạt được như thế? Câu trả lời là “Separate of concerns”.
Ở vai trò của người lập trình, chúng ta có hai vấn đề cần quan tâm là xử lý logic
chính của chương trình và các xử lý logic cho những thành phần phụ. Do đó tất nhiên
sẽ phải tạo ra các class/method cho các yêu cầu thực sự, và tạo ra những class/method
khác độc lập để thực hiện các yêu cầu phụ. Tất cả các class/method này có thể được
kết hợp lúc runtime theo ý muốn. Chẳng hạn như trong môi trường test, người ta có
thể bật chức năng log, đo đạc hiệu năng làm việc của chương trình để theo dõi. Nhưng

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


5

trong code của những xử lý logic chính sẽ không chứa code để thực hiện các yêu cầu
phụ.
Dễ dàng phát triển hệ thống: Việc thêm chức năng mới có thể thực hiện dễ dàng
bằng cách tạo aspect mới mà không cần quan tâm đến vấn đề đan nhau. Khi thêm các
mô-đun mới vào hệ thống, các aspect hiện có sẽ đan kết với chúng và tạo nên sự phát
triển chặt chẽ.
Cho phép để lại quyết định thiết kế tương lai: Một thiết kế tốt phải tính đến cả
yêu cầu hiện tại và tương lai, việc xác định yêu cầu tương lai là một công việc khó
khăn. Nếu bỏ sót những yêu cầu tương lai có thể bạn sẽ phải thay đổi hay thực hiện lại
nhiều phần hệ thống. Với AOP, người thiết kế hệ thống có thể để lại các quyết định
thiết kế cho những yêu cầu tương lai nhờ thực hiện theo các aspect riêng biệt.
Tái sử dụng mã tốt hơn: Các aspect là những mô-đun riêng biệt, được kết hợp
linh động – đây chính là yếu tố quan trọng để tái sử dụng mã. AOP cho phép tái sử
dụng mã tốt hơn OOP.
1.2.4 Tiếp cận aspect
Trong khi phát triển ngôn ngữ hướng aspect, aspect có nhiều hình dạng khác
nhau. Có hai cách để tiếp cận với aspect là: asymmetric and the symmetric (bất đồng
bộ và đồng bộ) :
Phân tách bất đồng bộ
Trong quan điểm tiếp cận này, các aspect được phân tách từ các chức năng chính
của một chương trình. Các aspect được mã hóa như là các sự kiện mà bị kích hoạt
trước, sau, hoặc thay thế cho những sự kiện cụ thể đã biết trước. Chúng mô tả thêm
các hành vi động của hệ thống mà sẽ có ảnh hưởng trên các chức năng chính. Ví dụ
như , trong hệ thống phân tán có một tập các đối tượng đặc tả miền hệ thống mà cần
phải được quản lý về việc phân phối, đồng bộ hóa, và giao dịch.

Chức năng chính sẽ chứa đựng cấu trúc và hành vi phù hợp tới các chức năng
miền của hệ thống. Việc phân tách các aspect khỏi chức năng chính của hệ thống
giống như là việc phân phối các đối tượng trong hệ thống, sự sắp xếp hệ thống đồng
bộ hóa được giao kết với các method thuộc các đối tượng đó, và bao bọc tập hợp các
thao tác vào trong một giao dịch đơn. Tất cả những việc này sẽ được mô tả trong một
mô-đun chuyên biệt (mỗi mô-đun sẽ là một aspect), và được gọi tại một điểm cụ thể
trong khi thực thi các phần chính của một chương trình.


6

Trong mức độ khái niệm, các aspect sẽ có hai thuộc tính quan trọng trong sự phối
hợp này. Đầu tiên, các aspect sẽ chỉ được kích hoạt bởi các điểm thực thi trong các
chức năng chính. Thứ hai, các aspect sẽ bị kích hoạt trong rất nhiều phần của hệ
thống, nhìn chung thì việc phân tách design/code trong một aspect sẽ không hữu dụng
nếu aspect này chỉ được thực thi tại một nơi trong hệ thống.
Bảng 1-1. Định nghĩa về các thuật ngữ trong mẫu phân tách theo hướng asymmetric
Thuật ngữ Mô tả
Crosscutting

Các concern mà hành vi của nó bị kích hoạt trong nhiều tình huống khác
nhau.
Advice Là các hành vi bị kích hoạt
Aspect Sự bao bọc advice và đặc tả cái nơi mà advide bị kích hoạt
Core
Là các phần của hệ thống hướng đối tượng truyền thống nơi mà các aspect
sẽ được ứng dụng vào
Jointpoint Điểm thực thi mà kích hoạt advide
Pointcut Là việc bạn chọn những jointpoint nào để thực thi
Weaving

Việc ứng dụng các advice tới các core của hệ thống tại tại một jointpoint
mà được so khớp tại các câu lệnh pointcut trong các aspect

Phân tách đồng bộ
Trong mẫu phân tách symmetric, để thêm vào việc mô-đun hóa các aspect, các
chức năng chính của hệ thống phải được phân tích cho việc mô-đun sâu hơn. Các đặc
điểm khác nhau của hệ thống sẽ được mô-đun hóa trong các chương trình riêng biệt.
Toàn bộ hệ thống được cấu thành từ những chức năng riêng rẽ, là các concern
hay đặc điểm. Chúng có thể được kết hợp trong các cách khác nhau để hình thành đầy
đủ chức năng. Với cách tiếp cận này, một tập hợp các đối tượng được phân phối sẽ
hình thành bằng cách tổng hợp các mẫu chức năng của các đối tượng cơ bản với các
chức năng phân phối, chức năng đồng bộ hóa và các chức năng giao dịch.
Thoáng nhìn qua, sự trùng lặp trình bày trong cách tiếp cận symmetric như thể nó
làm cho việc giải rác code trở nên tồi tệ và rắc rối hơn. Sự trùng lặp được yêu cầu
trong cách tiếp cận hướng symmetric để cung cấp một cách nhìn toàn vẹn về hệ thống
từ góc nhìn của concern cụ thể. Cách nhìn trọn vẹn sẽ giúp hiểu một cách riêng biệt


7

về các concern cụ thể trong hệ thống. Tất cả các chức năng phù hợp cho một concern
được trình bày trong một mô-đun concern. Khả năng bảo trì concern được cũng được
nâng cao hơn bởi vì xác định rõ vị trí cũng như chức năng của nó trong hệ thống. Khi
sửa đổi mỗi method thuộc về một class sẽ yêu cầu bạn quan tâm đến concern liên
quan, vì mức độ yêu cầu duy trì của hệ thống ảnh hưởng thường xuyên đến quá trình
tiến hóa của hệ thống phần mềm nên xác định được nhóm các mô-đun mà giúp cho
việc quản lý tốt việc bảo trì hệ thống là rất cần thiết.
Cách tiếp cận symmetric có thể được ứng dụng một cách liên tục trong quá trình
phát triển hệ thống. Không cần thiết giữ các mối quan tâm nhỏ nhặt trong các concern
riêng biệt cũng như không cần thiết bó tất cả các mối quan tâm nguồn lại với nhau.

Các thuật ngữ khi sử dụng với phương pháp này sẽ khác với cách dùng của
phương pháp bất đồng bộ:
-Concern: Vài loại chức năng trong hệ thống. Nó có thể là một đặc điểm (hàm)
hoặc một loại tiến trình xử lí.
-Crosscutting: là một concern bị kích hoạt trong nhiều tình huống hoặc những
cấu trúc và hành vi của concern nào bị giải rác xuyên suốt cac code base và bị rối với
mối liên quan code tới các concern khác.
-Composition: Tổng hợp cài đặt riêng biệt của các concern để hình thành nên một
chức năng của hệ thống.
1.3 Giới thiệu sơ qua về Theme
Approach Theme (tiếp cận chủ đề) là cách để bạn sử dụng AOP trong quá trình
phân tích và thiết kế một dự án phần mềm.
Chúng ta dùng theme chủ yếu là để xác định các aspect trong hệ thống, sử dụng
các mẫu phân tách Asymmetric hoặc Symmetric.
1.3.1 Định nghĩa về Theme
“Theme” sẽ không được coi như là tương đồng với từ aspect. Theme được định
nghĩa tổng quan hơn các aspect và có sự chặt chẽ hơn khi bao bọc các concern như đã
được mô tả cho cách tiếp cận symmetric. Hãy xem với mỗi một chức năng hay một
concern hay một aspect lập trình viên phải coi như là một theme riêng biệt để phục vụ
cho hệ thống . Theo như các thuật ngữ trong cách tiếp cận symmetric thì concern được
định nghĩa là : “vài loại chức năng của hệ thống , các chức năng này có thể là một đặc
điểm hay một kiểu xử lý”. Như vậy theme sẽ được mô tả như “là một sự bao bọc các
concern”.


8

Trong mức độ requirement, một theme là một tập các trách nhiệm được mô tả
trong một tập các requirement. Trong mức độ thiết kế, các theme bao gồm cấu trúc và
hành vi cần phải thực hiện các trách nhiệm trong mức độ các requirement.

1.3.2 Mối quan hệ giữa các theme :
Có hai cách mà xác định những theme nào có mối quan hệ với nhau.
a) Concept sharing (chia sẻ cùng khái niệm):
Khi bạn đọc một requirement bạn sẽ xác định được các chức năng (chính là các
động từ trong requirement) và các thực thể (entity- chính là các danh từ) mà có thể sẽ
là một class sau này trong hệ thống. Nếu hai theme cùng tham chiếu tới một
requirement tức là chúng có chung một entity.
Tuy nhiên, mối quan hệ này là một loại crosscutting trong mẫu thiết kế tách biệt
đồng bộ (symmetric separation), mà không được thảo luận hay đề cập trong mẫu thiết
kế bất đồng bộ (asymmetric). Sự bao bọc theo kiểu này có lợi ích, chỉ có các chức
năng thích hợp cho một concern sẽ được trình bày trong một theme.
b) Crosscutting :
Mối quan hệ thứ hai được đề cập ở đây là cắt ngang mà sẽ có ý nghĩa tương đồng
như thuật ngữ crosscutting trong mẫu thiết kế bất đồng bộ.Tức là các hành vi trong
một theme bị kích hoạt bởi các hành vi trong những theme khác.
Chúng ta sẽ sử dụng các thuật ngữ theme base, theme crosscutting, theme aspect
để nói về mối quan hệ này. Theme aspect và theme crosscutting sẽ được coi là một vì
chúng cùng có chung một định nghĩa (trong mẫu thiết kế bất đồng bộ) là các hành vi
mà bị kích hoạt bởi các hành vi khác.
Theme base là những theme mà kích hoạt các theme aspect. Các theme base này
phải là các theme mà có mối quan hệ chia sẻ khái niệm với những theme khác, trong
mối quan hệ chia sẻ khái niệm này sẽ phải lựa chọn ra đâu là theme aspect và đâu là
theme base. Đôi khi chúng ta nói một theme base là kết quả của sự tổng hợp các các
theme khác nhau thành, và nó kích hoạt một aspect.


9


Hình 1-1 Theme base kích hoạt theme aspect.

1.3.3 Áp dụng cách tiếp cận theme:
Có hai quá trình khi bạn áp dụng phương pháp theme: sử dụng Theme/Doc, giúp
phân tích tài liệu yêu cầu về phần mềm, và sử dụng Theme/UML giúp thiết kế các
theme. Hình 1-2 sẽ mô tả các hoạt động ở mức tổng quan khi bạn ứng dụng cách tiếp
cận theme.

Hình 1-2. Các hoạt động tiếp cận Theme.
1.3.3.1 Phân tích yêu cầu với Theme/Doc
Dùng Theme/Doc để xác định các theme trong tài liệu yêu cầu (requirement
document). Nó cung cấp phương pháp phân tích bằng kinh nghiệm để xác định những
theme nào là theme aspect hay crosscutting.
Quá trình phân tích bằng Theme/Doc có hai hoạt động chính:
+ Xác định các theme chính trong hệ thống


10

+ Xác định trách nhiệm của mỗi theme mà từ đó xác định ra được theme aspect.
Trong quá trình tiến hóa của hệ thống, kiểm định thực tế qua sử dụng, chúng ta
có thể dùng hai hoạt động chính ở trên để lên kế hoạch thiết kế các thay đổi của hệ
thống.
1.3.3.2 Thiết kế các theme với Theme/UML
Theme/UML cho phép thiết kế riêng các mô-đun cho mỗi theme xác định trong
requirement. Nó là một trong những cơ sở quan trọng của AOSD để: mô-đun hóa
theme, chỉ ra mối quan hệ giữa các theme liên quan, và tổng hợp các theme thành một
hệ thống mạch lạc.
Các theme được xác định với theme/doc có thể được thiết kế riêng biệt dù có sự
cắt ngang giữa các theme hay không, hoặc có sự trùng lặp giữa các theme hay không.
Chúng ta sẽ gần như hoàn toàn sử dụng chuẩn UML để thiết kế cho mỗi theme, sẽ có
một vài mở rộng của chuẩn UML để thiết kế cho theme aspect. Tất cả các class,

methods phù hợp cho mỗi concern phải được thiết kế trong theme.
1.3.3.3 Quá trình xử lý theme
Có ba hoạt động chính khi áp dụng cách tiếp cận theme: analysis (phân tích),
design (thiết kế), composition (tổng hợp).
-Analysis: Đây là bước đầu tiên trong cách tiếp cận, cần phải phân tích các
requirement để xác định được các theme. Bước này bao gồm mapping (ánh xạ) các
requiemernt tới các concern của hệ thống. Theme/Doc chỉ ra mối quan hệ giữa các
hành vi, chính là mối quan hệ giữa các theme. Mối quan hệ đó sẽ giúp tìm ra các
concern là rối lẫn với các concern khác để xác định các theme aspect.
-Design: Thiết kế các Theme sử dụng Theme/UML. Sử dụng các theme đã tìm
thấy trong Theme/Doc để xác định các class và method tiềm năng.
-Composition: chỉ ra cách mà mô hình Theme/UML sẽ được kết hợp. Trong
nhiều trường hợp một vài khung nhìn của Theme/Doc giúp bạn xác định được cách
thức các theme có liên quan tới nhau, xem chúng có lạp chồng hay cắt ngang những
theme khác. Các theme mà chứa các khái niệm chung thì sẽ được chọn để tổng hợp
theme. Hoặc các theme không có các khái niệm chung, nhưng thuộc một miền trong hệ
thống cũng được tổng hợp.
Chúng ta sẽ xem xét chi tiết các hoạt động trong việc thiết kế cho hệ thống
AOP trong các phần tiếp theo.


11

Chương 2 Phân tích
Trong chương này sẽ mô tả cách tiếp cận Theme với sự phân tích các
requirements. Các requirements miêu tả các hành vi liên quan đến các concern. Một
concern có thể được miêu tả trong các phần của các requirements khác nhau, việc
nhóm các phần đó lại là đóng gói một theme ở mức requirements. Các requirements
có thể miêu tả nhiều hơn một concern, chúng có thể được nhóm thành nhiều nhóm
requirements. Để có theme- orthogonality (trực giao) ta cần phải chú ý: các theme

không nên lạp chồng trong các nhóm yêu cầu của chúng, ta có thể viết lại các
requirement chia sẻ để tránh lạp chồng các hành vi trong theme , hoặc xử lý sự lạp
chồng đó trong thiết kế .
2.1 Các khung nhìn Theme/Doc
Sử dụng Theme/Doc giúp chúng ta thấy các mối quan hệ giữa các chức năng bị
làm rối lẫn một cách trực quan hơn và đưa ra quyết định cách đóng gói trong hệ thống.
Có ba loại khung nhìn Theme/Doc: khung nhìn relationship (khung nhìn quan hệ),
khung nhìn crosscutting (khung nhìn cắt ngang), và khung nhìn individual (khung nhìn
cá nhân).
2.1.1 Khung nhìn relationship của theme
Khung nhìn relationship của theme (có thể gọi ngắn gọn là khung nhìn
relationship) chỉ ra các relationships giữa các theme.

Hình 2-1 ví dụ trừu tượng của một khung nhìn relationship.
Hình 2-1 miêu tả một ví dụ trừu tượng cho khung nhìn relationship. Các theme
được chỉ ra trong các nút hình thoi, nhãn của nút là tên theme. Các requirements được


12

hiển thị trong khung nhìn với các hình chữ nhật bo góc. Các requirements có thể được
đánh nhãn với phần toàn bộ nội dung text của nó hay đơn giản là đánh số requirement,
như là R1, R2…
Khung nhìn relationship không chỉ ra “trực tiếp” mối quan hệ của các theme, nó
sẽ chỉ ra cách các theme liên quan tới các requirement. Nếu đoạn text của requirement
chứa một tham chiếu tới tên một theme, một liên kết được vẽ mô tả kết nối
requirement đó tới theme đó. Nếu một requirement đề cập nhiều hơn một theme, giống
như requirement 1 trong hình 2-1, thì nó sẽ được liên kết tới nhiều hơn một nút
theme. Các requirement mà tham chiếu tới nhiều hơn một theme được gọi là
requirement chia sẻ. Nếu hai theme mà cùng liên kết tới cùng một requirement, chúng

ta sẽ nói rằng các theme đó chia sẻ chung requirement đó và nói rằng các theme này
liên quan tới nhau.
Nếu requirement không chứa bất kì tham chiếu nào tới danh sách các theme đã
có và các requirement này cũng là chung chung, không xác định được theme – chức
năng cần quan tâm thì nó sẽ không được liên kết tới bất kì một theme nào trong khung
nhìn. Các requirement đó gọi là requiremetn orphaned (requirment mồ côi).
2.1.2 Khung nhìn crosscutting của Theme
Các requirement chia sẻ thường mô tả các hành vi crosscutting. Trong phần này,
chúng ta sẽ không đi vào xem các hành vi crosscutting là gì, hay cách xác định nó.
Thay vào đó, chúng ta sẽ chỉ ra các quyết định xử lý cho các requirement chia sẻ.

Hình 2-2 Ví dụ trừu tượng của khung nhìn crosscutting.
Nhìn chung, hành được mô tả trong các requirements phải được giao kết với chỉ
một theme , có nghĩa là một theme sẽ chịu trách nhiệm nắm giữ hành vi của một


13

requirement. Tuy nhiên, đây không phải là một nguyên tắc cứng nhắc. Nhưng trong
giai đoạn đầu của phân tích chúng ta cố gắng đưa ra các theme chịu trách nhiệm cơ
bản cho chức năng hệ thống, việc xác định được rõ ràng theme nào sẽ chịu trách nhiệm
cho hành vi của requirement ngay từ đầu sẽ giúp các công việc thiết kế về sau thuận
lợi hơn, nên sử dụng mối quan hệ từ requirement tới theme - N:1.
Với requirement chia sẻ thì nó tham chiếu tới nhiều hơn một theme, vậy theme
nào sẽ chịu trách nhiệm cho requirement đó ? Có hai lựa chọn để giao kết một share
requirement.
a) Đầu tiên là giao kết nó với một theme mà bạn tin là “aspect” trong tình
huống cụ thể đã được xác định trước. Trong khung nhìn crosscutting vẽ sự giao kết
mới, là mũi tên màu xám dày mở rộng từ theme aspect (theme mà chịu trách nhiệm
nắm giữ hành vi chia sẻ chung - tức là chi phối requirement chia sẻ đó) tới các theme

base (requirement chia sẻ chung bây giờ không giao kết với các theme base nữa).
Nếu một requirement được giao kết với một theme aspect thì nó chỉ được liên kết với
theme đó. Các theme khác được tham chiếu trong requirement được liên kết với theme
aspect với mũi tên xám đậm chỉ ra rằng chúng bị cắt ngang bởi theme aspect. Như vậy
trong khung nhìn crosscutting mỗi requirement chỉ giao kết với một theme. Trong
hình 2-2, miêu tả mối quan hệ crosscutting từ First Theme (được xác định là theme
aspect) tới Second Theme (theme base được requirement chia sẻ tham chiếu),
requirement chia sẻ bây giờ chỉ giao kết với duy nhất First theme.
b) Lựa chọn thứ hai là postpone (trì hoãn) quyết định về những theme
chia sẻ chung requirement sẽ được giao kết như thế nào, ta chưa quyết định theme nào
sẽ chịu trách nhiệm cho requirement chia sẻ. Việc postpone được mô tả trong khung
nhìn crosscutting với đường nét đứt, được gán nhãn bằng nhãn (hoặc text) requirement
của giao kết bị trì hoãn. Trong ví dụ hình 2-2, requirement 3 được chia sẻ bởi First
theme và Third Theme, ta chưa xác định được theme nào chịu trách nhiệm cho hành vi
của requirement 3 nên trì hoãn việc giao kết theme của nó lại, và nó được liên kết với
First Theme, Third Theme bằng đường nét đứt, và gán nhãn là text của requirement 3.
Hai khung nhìn relationship và crosscutting thực sự là hai cực của một thể liên
tục. Khung nhìn relationship bao hàm tất cả các mối quan hệ giữa các theme và các
requirements, nhưng nó không bao hàm mối quan hệ relationship crosscutting.
Khung nhìn crosscutting bao gồm các mối quan hệ giao kết giữa các theme và các
requirement, và mô tả các quan hệ giao kết giữa các theme – quan hệ cắt ngang.
Khung nhìn crosscutting sẽ không chứa requirement chia sẻ, các requirement chia sẻ
lúc này đã được giao kết gắn với duy nhất một theme aspect chịu trách nhiệm cho


14

hành vi của nó. Nhưng trong thực tế hai loại khung nhìns này cùng được tích hợp, nên
có thể bạn sẽ thấy một khung nhìn relationship mà có một số crosscutting
relationships, và cũng có một số requirement chia sẻ. Có thể coi rằng khung nhìn

relationship giống như điểm bắt đầu, chỉ ra các theme, và liên kết chúng với các
requirement liên quan; còn khung nhìn crosscutting giống như mục tiêu cuối, từ khung
nhìn relationship tìm được theme aspect và theme base, từ đó xác định được các mối
quan hệ cắt ngang, giao kết được requirement với theme phù hợp.
2.1.3 Khung nhìn individual
Khung nhìn individial là một khung nhìn crosscutting (không chứa requirement
chia sẻ) chỉ cho một theme. Thêm vào đó, nó bao gồm cả các key entities (các thực
thể). Hình 2-3 mô tả ví dụ trừu tượng về khung nhìn individual.
Mối giao kết giữa theme và requirement sẽ được liên kết giống như trong khung
nhìn crosscutting. Với mối quan hệ trì hoãn nút requirement thường gán nhãn là text
của requirement hơn là dùng nhãn của requirement (requirement đánh số thứ tự) trong
khung nhìn crosscutting. Khung nhìn individual có thể có vài theme con, nếu ta cần
thiết nhóm các theme.

Hình 2-3 Ví dụ trừu tượng của khung nhìn individual .
2.2 Quá trình xử lý Theme/Doc
Từ các phần của khung nhìn Theme/Doc, ta có ba phần chính khi xử lí
Theme/Doc: deciding on a set of themes to include in your system- Xác định tập hợp
các theme có trong hệ thống; determining the responsibilities of those themes- xác
định trách nhiệm cho những theme đó; planning for design- lên kế hoạch thiết kế. Ba
hoạt động này được mô tả trong hình sau:


15


Hình 2-4 Nhìn chung về quá trình phân tích.
Họat động trên đỉnh của hình 2-4 là Decide on the themes. Quá trình này sẽ tìm
các ra phần chức năng khác nhau của hệ thống, và mỗi chức năng đó sẽ được tách biệt
trong khi thiêt kế - chính là các theme. Hoạt động này sử dụng khung nhìn relationship

để tìm ra các theme.
Phía dưới bên phải của hình là : Determing Theme Responsible. Hoạt động này
có thể nói là : “Xác định đâu là theme aspect, và đâu là theme base”. Nếu theme
Theme1 có khả năng chịu trách nhiệm cho hành vi mà được kích hoạt trong theme
Theme2 thì Theme1 là một aspect của Theme2. Hoạt động này dựa vào khung nhìn
crosscutting, để xác định trách nhiệm của theme.
Cuối cùng là hoạt động Plan for Design: sẽ xem xét cấu trúc và hành vi của
theme mà sẽ được mô-đun hóa sử dụng Theme/UML. Khung nhìn individual được sử
dụng để đưa ra các kế hoạch cho thiết kế.
Khi bắt đầu chúng ta sẽ áp dụng các hoạt động theo như các bước sắp xếp trong
hình vẽ. Trong những lần xử lý Theme/Doc về sau, để làm mịn các thiết kế theme thì
ta không nhất thiết phải theo thứ tự các bước nữa, có thể lựa chọn pha trộn giữa các
hoạt động.


16


Hình 2-5. Các hoạt động trọng tâm khi chọn lựa các theme và quyết định
trách nhiệm của chúng.
Các công việc cụ thể hơn cần làm trong quá trình xử lý Theme/Doc được chỉ ra
trong hình 2-5. Khung nhìn relationship được sử dụng trong cả hai hoạt động : quyết
định theme, và xác định theme trách nhiệm. Khung nhìn individual liên quan nhiều
đến quyết định trên theme. Khung nhìn crosscutting liên quan đến giao kết
requirements (và trì hoãn giao kết), nó sử dụng trong hoạt động xác định theme base
và theme aspect. Tất cả ba khung nhìn đều được sử dụng khi lên kế hoạch thiết kế. Các
hoạt động khi quyết định trên theme: Add - thêm theme, Delete - xóa theme, Split -
phân tách các theme, Group - nhóm các theme, Add requirement mới, Attach - giao
kết requirement với một theme cụ thể, Postpone - trì hoãn giao kết đến khi có thêm
thông tin để quyết định với requirements. Hoạt động xác định theme trách nhiệm là

hoạt động trên requirement: Associate- giao kết requirement với một theme cụ thể, và
split- phân tách requirement, postpone -trì hoãn giao kết requirement.
2.3 Quyết định trên theme
Bước đầu tiên trong quá trình phân tích requirement với Theme/Doc là tìm hiểu
các chức năng liên quan theme. Trong phần này chúng ta sẽ sử dụng các khung nhìn
Theme/Doc (đặc biệt là khung nhìn relationship) để gán theme với requirement.
2.3.1 Chọn các theme ban đầu
Đầu tiên là xác định tập hợp các concern từ các requirement, các hành vi được
miêu tả trong requirement rất có khả năng sẽ trở thành một theme. Tìm các theme ở


17

thời điểm bắt đầu bằng cách: chọn tên của các đặc điểm, dịch vụ hay các trường hợp
sẽ xảy ra trong hệ thống. Nếu requirement được chuyển thành nhiều trường hợp sử
dụng thì mỗi trường hợp đó có thể trở thành một theme, hoặc nếu trường hợp sử dụng
bao gồm rất nhiều các chức năng thì mỗi hành động trong trường hợp sử dụng sẽ là
một theme. Nếu có một tập mục tiêu chính thức cho hệ thống mà đã được chỉ rõ và
làm mịn, thì có thể áp dụng kĩ thuật tiếp cận yêu cầu hướng mục đích để chọn từ khóa
từ mục đích hoặc các hành vi mục đích để miêu tả các theme.
Có hai phương pháp chọn theme tiềm năng, đó là: The Choose –Carefully – Up-
Front (chọn cẩn thận từ đầu), The Start-with-Everything (bắt đầu với tất cả).
2.3.1.1 Chọn cẩn thận từ đầu
Với cách này, từ tập các requirement xác định những chức năng chính mà có
khả năng trở thành các đặc điểm trong cài đặt. Ngay từ khi bắt đầu chọn lựa các theme
tiềm năng, phải đánh giá cẩn thận các concern được mô tả trong requirement, các
theme này có khả năng sẽ là các theme cuối trong hệ thống hay không. Với cách này,
quá trình làm mịn theme sẽ phân tách các theme mà được coi là quá chung chung hoặc
các theme mà có các requirement khi được nhóm vào sẽ hình thành tập chức năng
không có sự dính liền, cố kết nhau (các chức năng của theme này hầu như không liên

quan nhau, không có sự xảy ra đi liền với nhau).
2.3.1.2 Bắt đầu với tất cả
Cách này sẽ chọn tất cả các động từ, hoặc các từ chỉ hành động được viết trong
requirement để tìm tập theme ban đầu.
Cách tiếp cận này tiếp kiệm thời gian trong bước đầu đọc qua các requirement và
lựa chọn theme. Tuy nhiên , với cách tiếp cận này sẽ có rất nhiều theme tiềm năng vì
thế mà quá trình làm mịn theme sẽ xem những theme nào thực sự sẽ tồn tại và phù hợp
trong ứng dụng của mình để loại bỏ đi những theme không mong muốn, và nhóm các
động từ để hình thành những theme thực tế lớn hơn.
2.3.1.3 Kết hợp cả hai hướng tiếp cận
Bình thường, bạn sẽ kết hợp cả hai cách trên để quá trình tìm theme được hiệu
quả. Khi đọc qua tài liệu về requirement, bạn nhặt ra tất cả những gì giống như một
hành vi, concern, hay đặc điểm. Sự kết hợp này sẽ thu hẹp danh sách theme hơn so với
cách lựa chọn bất kì động từ nào có trong tập requiremnent, và nó cũng lựa chọn thoải
mái hơn so với cách chỉ chọn ra các khái niệm mà có triển vọng cao sẽ trở thành
theme. Với cách đầu tiên, sẽ có những theme chắc chắn sẽ được cài đặt trong hệ thống
nhưng sẽ có rất nhiều requirement là “mồ côi”, còn với cách thứ hai thì sẽ có quá


18

nhiều theme riêng lẻ, làm cho khung nhìn mối quan hệ sẽ vô cùng lớn, có thể trong số
những theme đó có theme sẽ chẳng chịu trách nhiệm gì trong hệ thống của bạn. Vì thế
kết hợp cả hai cách để giảm thiểu số lượng các requirement là “mồ côi” và giảm thiểu
những theme không cần thiết.
Xét một hệ thống đánh giá biểu thức đơn giản- expression evaluation system
(EES), tập requirements của nó gồm:
1- An evaluation capability, which determines the result of evaluating an
expression (khả năng đánh giá xác định kết quả đánh giá một biểu thức ).
2- A display capability, which depicts expressions textually ( khả năng hiển thị mô

tả biểu thức dạng văn bản).
3- A check-syntax capability, which optionally determines whether expressions
are syntactically and semantically correct (khả năng kiểm tra cú pháp, tùy chọn xác
định cú pháp và ngữ nghĩa biểu thức đúng).
4- The check-syntax, display, and evaluation operations should all be logged (việc
kiểm tra cú pháp, hiển thị, và các hoạt động đánh giá tất cả phải được lưu lại).
5- Expression is defined as a variableexpression or a numberexpression or a
plusoperator or a minusoperator or a unaryplusop or a unaryminusop (biểu thức được
định nghĩa là một biểu thức biến, hoặc biểu thức số, hoặc toán tử cộng, hoặc toán tử
trừ, hoặc toán tử cộng một ngôi hoặc toán tử trừ một ngôi).
6- plusoperator is defined as an expression and a plusoperator and an expression
(toán tử cộng được xác định giống như một biểu thức và một phép cộng và một biểu
thức).
7- minusoperator is defined as an expression and a minusoperator and an
expression (toán tử trừ được xác định giống như một biểu thức và một phép trừ và
mộtbiểu thức).
8- unaryplusop is defined as a plusoperator and an expression (toán tử cộng một
ngôi được xác định giống như một phép cộng và một biểu thức).
9- unaryminusop is defined as a minusoperator and an expression (toán tử trừ một
ngôi được xác định giống như một phép trừ và một biểu thức).
10- variableexpression is defined as a letter and an expression (biểu thức biến được
xác định giống như một văn tự và một biểu thức).
11- numberexpression is defined as a number and an expression (biểu thức số giống
như một số và một biểu thức).
Áp dụng cách tìm theme thứ hai, ta tìm tất cả các động từ trong tập requirement,
đó chính là các theme tiềm năng. Có sáu theme tiềm năng: evaluation, display,
determine, check-syntax, log, define.
Chúng ta đã xác định được tập các theme ban đầu, và từ đó xậy dựng khung nhìn
relationship.